Another way would be to get the remote_host and put it in a cookie
too (encrypted/hashed) and compare it in further invocations - or
hash it and add it to the session ID itself.
Not sure this would help? The exploit is pretty clever ... Basically
you setup a man-in-the-middle attack where you just proxy through SSL
requests, but you exploit sites that do not set "secure only" on
cookies and from the proxy issue a non-https request to the site,
which sends back your wosid cookie unencrypted, at which point you can
then steal the session. Practicality of setting up the attack is
another thing entirely, but it's definitely exploitable in WO because
the wosid and woinst cookies are set to be secure-only=false. The
downside, of course, is that you MUST be https end-to-end, but in
reality, the only secure session is one that is https end-to-end.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
