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
>
+-- 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
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
You might benefit from a look at the arsDigita Community System security
routines. In particular, ad-security.tcl implements a cookie-based
mechanism for session IDs, including extensions to handle https. The
session ID has several components, including a simple integer session number
and a long
It seems like it would be easier to register a proc for
/* to a special procedure that does all routing. The procedure
could check the URL for what looks like a ssn# and redirect/generate SID
if necessary. The procedure would then either do an ns_returnfile (in the
case of a static doc) or ns_ad
This ends up being quite a pain. My current employer's site works like
this, www.businessolver.com. Doing relative links in everything is no fun,
especially static html. You do need a cookie along with this method or you
are vulnerable to session highjacking.
dave
On Thu, 27 Dec 2001, Wojciech K
Hello.
I realize that this idea is quite weird and probably useless, but what
if sessions on AOLserver would be implemented in this weird way:
/ created/gets (cookie - if available) a SID and redirects to
/ssn0123456789abcde/index.adp which is the real page from documentroot
this way, tracking
17 matches
Mail list logo
