Cookieless Forms Authentication


In version 1.x, if you wanted to use Forms authentication, your clients had to support cookies; if a user turned off cookies, she would be denied access to any page that required Forms authentication. Many Web sites would simply inform the user that she needed to "turn on cookies" in order to allow her to log on, but smarter Web sites actually took the time to explain to the user what cookies are and how to enable them for specific, trusted Web sites. But for many mobile devices, cookies simply aren't an option at all. Because of this, the ASP.NET team decided to provide a cookieless alternative (which uses URL mangling) in version 2.0.

This new feature can be enabled by setting the cookieless attribute on the <forms> configuration element. There are four options, the default being UseDeviceProfile, which looks at the User-Agent header to determine whether the browser being used supports cookies at all. For browsers that are known not to support cookies, the cookieless option will be used. The next two options are pretty obvious: UseCookies and UseUri, which indicates that cookies or URL mangling should be used all the time, respectively. The last option, AutoDetect, will attempt to set a cookie, and if that fails, it automatically switches to using URL mangling.

If you end up using URL mangling, the URL for a Web page changes from looking like this:

http://www.pluralsight.com/foo/bar.aspx 


. . . to something like this:

http://www.pluralsight.com/foo/(F(Cvc...A1))/bar.aspx 


The parenthesized section of the URL (which I've shortened quite a bitthe ellipses are mine) contains the data that would normally be stored in the Forms authentication cookie. It has tamper detection and encryption built in just like the cookie would, but because it is now part of the URL, it's easier for the user to accidentally share this URL with someone else (one benefit of cookies is that it's difficult to accidentally share them).

Let's say Alice logs in and copies the resulting mangled URL to her friend Bob via instant messenger. If Bob clicks that link, he's effectively (if not knowingly) conducting a replay attack against Alice's logon, and the Web server will treat his request as if it came from Alice. And if you think about it, SSL isn't going to stop this sort of thing from happening, although you should still use SSL even with cookieless authentication to protect these URLs from being stolen by an adversary who is sniffing packets on the network.

One approach you can take to reduce the risk of this kind of attack is to reduce the timeout value for each logon in the <forms> element. This reduces the window of time that any given mangled URL is valid; if an attacker submits an expired URL, he'll be asked to log in like any anonymous user. Another approach is to educate your users not to share URLs. Some Web sites make this easier by providing explicit hyperlinks with unmangled URLs that users can copy if they want to share or bookmark a Web page (you can use Request.Path to get an unmangled URL for this purpose).




Essential ASP. NET 2.0
Essential ASP.NET 2.0
ISBN: 0321237706
EAN: 2147483647
Year: 2006
Pages: 104

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net