On 2001.12.27, Rob Mayoff <[EMAIL PROTECTED]> wrote:
> +-- On Dec 27, Dossy said:
> > Netscape has the option of "allow all cookies" or "allow cookies
> > that get sent back to the originating server." So, if you just
> > set "allow all cookies" then send your browser a set-cookie where
>
For C modules, simply create the C functions you want exposed from your
module as externs and call them Ns_SomeName. Just make sure you don't
conflict with a C function name that already exists in the core or in other
modules. You do this by prepending something that you think is going to be
uniqu
+-- On Dec 27, Ramin Naimi said:
> Hello,
> How can a module X expose API's to other modules?
Hmm. I thought a module could refer to another module's exported C
functions directly. Have you tried it?
+-- On Dec 27, Dossy said:
> Netscape has the option of "allow all cookies" or "allow cookies
> that get sent back to the originating server." So, if you just
> set "allow all cookies" then send your browser a set-cookie where
> domain= the domain you want to attack, setting cookies becom
Hello,
How can a module X expose API's to other modules?
I can think of the following possiblities:
A) Add Tcl commands, so the other modules could execute the commands
B) Register for URL(s), maybe one URL with parameters for which function and
the function parameters encoded in the URL, or multi
I can't put the whole thing together off the top of my head, and I'm a
little busy this week, but I think the risks include the following:
- guessing a session ID
- replaying a session ID
- accidentally generating a duplicate session ID
The server should take a unique session ID, a per-request d
I'd encourage those running a public web site to weigh the trade-offs
of setting cookies on every page view for extra security vs. annoying
users that have privacy settings that prompt for cookie changes. This
isn't a huge group of users, but they tend to be very vocal when
complaining.
Jim
...
On 2001.12.27, Wojciech Kocjan <[EMAIL PROTECTED]> wrote:
> As I mentioned before, I use 32 bytes long mostly random SessionIDs -
> that is, there is no ID related to database. The only way to hijack a
> session is to guess (or probably sniff :) the 32byte ID...
>
> I have no idea how to effective
On Thu, 27 Dec 2001, Wojciech Kocjan wrote:
> As I mentioned before, I use 32 bytes long mostly random SessionIDs -
> that is, there is no ID related to database. The only way to hijack a
> session is to guess (or probably sniff :) the 32byte ID...
The two big ones that I can think of are bookmar
Hmmm.
As I mentioned before, I use 32 bytes long mostly random SessionIDs -
that is, there is no ID related to database. The only way to hijack a
session is to guess (or probably sniff :) the 32byte ID...
I have no idea how to effectively protect against that.
Dossy wrote:
> On 2001.12.27, Woj
On 2001.12.27, Wojciech Kocjan <[EMAIL PROTECTED]> wrote:
> I think that anything the user supplies cannot be trusted and as such
> sessions are a real problem to make secure.
What about using using symmetric key crypto to encrypt a sequence
number that gets stored along with the session ID on th
On 2001.12.27, Peter M. Jansson <[EMAIL PROTECTED]> wrote:
> The one way cookies can help avoid hijacking is in a
> security-through-obscurity sense, since it's more difficult to set a
> cookie using the conventional command-line tools, or even through browsers
> (browsers I use allow viewing and
On Thursday, December 27, 2001, at 05:40 AM, Wojciech Kocjan wrote:
> I think that anything the user supplies cannot be trusted and as such
> sessions are a real problem to make secure.
You and I are in violent agreement on this point. This is the least-risk
strategy; it is also the hardest to i
It's about 5 minutes of work for an experienced user - modify /etc/hosts
or c:\winnt\hosts.sam to point www.domain.com to localhost and write a
small script that'd set a session cookie.
Also, my IE5 stores all the cookies as plaintext in this directory:
C:\Documents and Settings\zoro\Cookies
Bes
On Thu, 27 Dec 2001, Wojciech Kocjan wrote:
> First of all, why do I need cookie? My SIDs are 32bytes long so guessing
> it could be a bit of a PITA. And if someone would sniff the SID, he
> could set his browser's cookies to send this SID. So I don't understand
> how cookies might help? [espec
First of all, why do I need cookie? My SIDs are 32bytes long so guessing
it could be a bit of a PITA. And if someone would sniff the SID, he
could set his browser's cookies to send this SID. So I don't understand
how cookies might help? [especially that they are sent from a
potentially untrusted
16 matches
Mail list logo