[13636] in cryptography@c2.net mail archive
Re: Session Fixation Vulnerability in Web Based Apps
daemon@ATHENA.MIT.EDU (Rich Salz)
Sat Jun 14 19:44:22 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sat, 14 Jun 2003 19:07:10 -0400 (EDT)
From: Rich Salz <rsalz@datapower.com>
To: "James A. Donald" <jamesd@echeque.com>
Cc: Ben Laurie <ben@algroup.co.uk>,
"cryptography@metzdowd.com" <cryptography@metzdowd.com>
In-Reply-To: <3EEB000F.30628.FC61833@localhost>
> 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@metzdowd.com
