[dokuwiki] Re: CookieMonster

Andreas Gohr wrote:

[...] My understanding is that
this means that DokuWiki sites may be vulnerable to attacks using the
CookieMonster toolkit.

I solved this on my other project by setting the "secure" boolean when I did
the set_cookie() call if the site was using SSL but I can't see any way of
forcing that behaviour via PHP flag setting so it's going to require a tiny
DW code change.


As I understand it, setting the "secure" option of cookies would
prevent users from securing the login via SSL only. This is very
common because putting the whole wiki under SSL needs much more CPU
power. Using the httponly option on the other hand might be sensible.

The register article unfortunately didn't really describe how the
cookie monster attack works. We try to make sure to make the cookie as
secure as possible by encrypting it and binding it to a combination of
the IP address and the Browser-ID to make cookie stealing harder.

Andy, what are your thoughts on this?
The Cookie Monster attack (aka "sidejacking") is an attack where the user has authenticated via SSL and has a session to say <https://example/com/doku.php>. But the user is on an insecure network (such as a public access WiFi, hotel LAN, etc). The attacker performs a low level attack such as ARP spoofing, rouge Access point or a Kaminsky DNS poisoning attack. The attacker wants to snoop traffic and maybe steal the session token to example.com. Of course, with SSL all is encrypted so not possible. So the attacker has to force non-SSL traffic to steal (or rather "clone") the session.
So with the low level attack, the attacker must make sure she can snoop the traffic _and_ make sure that the session identifier can be stolen. She needs to get the victim to access the non-SSL protected version of the site. This may include using cross site scripting, and/or acting as a proxy (with ARP spoof, DNS poison, rouge AP) and possibly poisoning some other http page to include a reference to <http://example/com/doku.php> [no SSL] - but if she is acting as a proxy she can do whatever she wants with any in-clear traffic.
Now, if the cookie is not marked as "secure", the browser will send the same cookie to the non-SSL version of the site that it would have done to the SSL version and the attacker can steal a copy and "clone" the session. Note that it doesn't matter whether a non-SSL version exists or not - the attacker only needs to get the browser to send the cookie in clear for the hack to succeed.
The "secure" flag tells the browser to not send the cookie via a method that is less secure than the method used to set the cookie. It does not mean "send this cookie only by SSL". So you can have cookies marked as "secure" and set on non-SSL connections - it will never be sent by any method less secure than the currently least secure method there is. Ie it will have no material effect on non-SSL connections. But on SSL connections, it will make sure that the attacker can not sidejack the session.
Essentially, every cookie should be "secure" unless there is an explicit need to share the cookie between SSL and non-SSL versions of a site. But that was not made the default when the secure option was introduced probably because it would have broken some sites.
If wiki admins want to use SSL to protect only the login (where the password is posted) but use non-SSL for all other traffic then this will only work with the session cookie no marked as "secure". Such sites will then be vulnerable to sidejacking. Such sites need to balance the risk of sidejacking against the cost of SSL encrypting everything.
Note that the session cookie value could be just a pseudo-random number (as with JSessionID, for example). The Cookie Monster/Sidejacking attack will work just the same because it clones the currently active session. The "remember my login" cookie is more interesting, of course, as it has longer term 'value'. 

Cheers
Andy
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: