[unisog] Using cookies for authentication

Pascal Meunier pmeunier at purdue.edu
Fri Mar 7 15:24:14 GMT 2003


On 3/6/03 7:26 PM, "Russell Fulton" <r.fulton at auckland.ac.nz> wrote:

> Hi All,
> We are currently looking at a new web based application that uses
> cookies for authentication.  The cookies contains amongst other things,
> userid, issue time, the issuing system ID and a SHA1 hash of the
> contents (and a secret) to prevent one changing the cookie.  All
> exchanges of the cookies over the network are via SSL and the cookie
> also had flags that tell the browser not to write it to disk.
> 
> So far as I can tell if an attacker can steal a cookie then they can use
> it to impersonate the cookie's owner for the lifetime of the cookie.
> 
> We are try to do a risk analysis of this system and so I am trying to
> figure out how easy (or otherwise) it is to steal memory based cookies
> from systems running common browsers (mostly IE, some old :( ).
> 
> Two schemes that occur to me are 1/ to tamper with the browser (so it
> writes the cookie to disk or better still sends it directly to the
> attacker) or 2/ to introduce malware on the the user's computer that
> will search for the cookie in memory and send it to the attacker.  If an
> attacker has the ability to do either of these things then they could
> probably also install keyboard loggers and grab the users credentials
> directly -- something that affects almost all authentication systems so
> I am ignoring this for this particular exercise.
> 
> What I am really focusing on is the risk of browser bugs and XSS bugs
> that might allow the cookie to be stolen.  We must assume that the
> attacker may have a web server under their control in the same domain as
> the cookie and that they may be able to induce users to visit the site.
> 
> Any thoughts or references gratefully received.

My suggestion would be to have a script that tells users to turn scripting
off if they want to use the system, and enforces it (i.e., makes their life
miserable until javascript is turned off).  If that system requires
scripting to operate, then dump it.  There's no other way to be reasonably
safe from XSS vulnerabilities.

regards,

Pascal Meunier, Ph.D., M.Sc.
Assistant Research Scientist
Purdue University CERIAS
Recitation Building
656 Oval Drive
West Lafayette, IN 47907-2039

+1 (765) 494-7841 (main)
http://www.cerias.purdue.edu/




More information about the unisog mailing list