Session Fixation Vulnerability in Web Based Apps

[Rich Salz]

> To avoid it, one has to roll one's own state management, for
> example by providing one's own cryptographically strong login
> label in the Urls in the web page one generates in response to
> a login, the label acting as primary key to a table of
> currently active logins.

When I've done login and state management, it's all maintained on
the server side.  It's completely independant of SSL sessions -- that's
transport, has no place in application -- just like it's completely
independant of HTTP/1.1 session management.  A logout page isn't
the same as "Connection: close" :)

The only thing in the cookie is an opaque identifer.  It's purely
random bytes (for which OPenSSL's RANDbytes() is useful), that is
a key into a server-side table that has all the state.  Depending
on the size, that table will be in-core or in a databse.

        /r$
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com