From: Santiago Barahona (sant-bar@dsv.su.se)
Date: Tue Apr 10 2007 - 03:01:45 EDT
Regarding the relationship between the cookie and the session ID:
The cookie the web server generates and associates to a session ID
is used to prevent DoS... basically what it does is that the server
gives the cookies in the second face of the connection establishment
and then "forgets" about it whilst it attends other connection
requests which lines up in its stack... if the space in the stack is
full, the server starts throwing away the oldest connection requests
from the stack... if a client who's connection attempt has been
dropped returns with the last phase of the connection establishment,
it will still be able to connect because of the cookie...
Please correct me if I'm wrong...
cheers,
santiago
On 3 Apr 07, at 18:32, Serguey Forcade wrote:
Thanks, but I based my assumptions on an article from Microsoft
(http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/
iisbook/c06_asp_session_id_and_session_security.mspx?mfr=true)
Even tho your statement makes sense. It's just that I haven't been
able to find more info about the relationship between the session ID
and the cookie.
On 4/3/07, Rogan Dawes <discard@dawes.za.net> wrote:
> Serguey Forcade wrote:
> > Hi, I'd like to know if anyone knows of a paper that explains how to
> > extract the encryption password IIS creates when it starts up, and
> > uses to encrypt the session ID + random data in order to generate
> the
> > cookie value the users receives.
> >
> > I'm interested in IIS 5.0.
> >
> > Thanks.
> >
>
> Take this with a pinch of salt, but I don't think that the session
> identifier and the cookie value are directly related.
>
> One reason for this statement is that if you abandon the session
> (using
> ASP), and create a new one, the cookie value does not change. However,
> the result of "Session.SessionID" DOES change.
>
> I suspect that the cookie value is generated using a combination of
> some
> static/sequential info, and some random data, and then associated with
> the next available (i.e sequential integer) SessionID. When the
> session
> is abandoned, the session object associated with that integer
> SessionID
> is discarded. A subsequent request from the client containing the old
> Session Cookie value will then automatically be associated with the
> next
> available sequential integer SessionID.
>
> Hope this helps.
>
> Rogan
>
> P.S. One consequence of this inability to change the cookie value
> through abandoning the session is that ASP apps are AUTOMATICALLY
> vulnerable to Session Fixation
> <http://www.owasp.org/index.php/Session_Fixation>. An approach to
> protecting ASP apps against session fixation is shown here
> <http://www.owasp.org/index.php/Session_Fixation_Protection>
>
------------------------------------------------------------------------
-
Sponsored by: Watchfire
It's been reported that 75% of websites are vulnerable to attack.
That's because hackers know to exploit weaknesses in web
applications. Traditional approaches to securing these assets no
longer apply. Download the "Addressing Challenges in Application
Security" whitepaper today, and see for yourself.
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008fHF
------------------------------------------------------------------------
-- ------------------------------------------------------------------------ This List Sponsored by: Cenzic Need to secure your web apps? Cenzic Hailstorm finds vulnerabilities fast. Click the link to buy it, try it or download Hailstorm for FREE. http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW ------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:42 EDT