Firstly I just want to clear up and kill the thread on session cookies and
move on to what I think is a whole lot more interesting and promising a
topic.

There are only three mechanisms for keeping state in the HTTP stateless
protocol. Cookies, URL re-writing and hidden form fields. Officially read
the RFC for the cookie spec. When you have selected a mechanism (probably
ignoring hidden form fields) you still need a scheme to create
non-predictable data to pass to the HTTP user agent using the mechanism. ASP
session variables (and other similar ones) just use application server API's
for such a pre-built scheme. If you can set a cookie on IE when the prompt
is enabled and get no pop-up then I would suggest following up on vuln-dev
as it sound like a bug (interesting all the same). ASP session variables (or
PHP variables etc) are by no means magic and still have to use an
established HTTP method for managing state which the browser should
understand and manage as part of its security model.

But like others who mailed me off-line have asked, how does the session
variable get computed ? Well I tracked a few whilst quickly searching the MS
site on the subject and am still intrigued. I am not an NT / MS person at
all so this maybe an implementation problem but the cookies set by MS had
some interesting properties.

Over a 10 minute period my sessionID (I am assuming a table maintained
server-side) only varied 5 characters (note the three G's) all case
insensitive. I swapped machines to make sure my ID wasn't being incremented
and it seems not.

The variable seems to be 24 case insensitive characters of a very limited
character set (A-Z).

ASPSESSIONIDGGGQGVAQ=LPCAGLIDMCLAMKGNOJEKJHJH
ASPSESSIONIDGGGQQCZK=COKOKCLCFPOIIFOBDMKAENGD
ASPSESSIONIDGGGGGRDK=GFBPAHPCONGCBKADDOGKDCBC

Before I start poking around and wasting my time, there must be someone
knowledgeable out there who can explain the scheme? Please ;-)

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]