Replay attacks
It's quite to track login status using a cookie: each secure page looks for a specific cookie coming with the requrest, if user doesn't have the logged-in cookie send them to the login page where the user enters their username & password, the login page checks these and if they are ok sends the user back to the page they wanted to go to along with the "logged-in" cookie. This is generally a GoodThing as it means the user only has to type in their username & password once* - which lessens the chances someone sees what you're typing - and the browser only has to submit them once - which lessens the chances someone can catch them flying across the internet.
The thing often overlooked is that the "logged-in" cookie is sent with every browser request so any hacker watching the network traffic has plenty of opportunity to catch that cookie. Once they've got the "logged-in" cookie they can send a request to the same web site with that cookie attached and hence they'll be identified as being logged on. As you. This is known as a replay attack.
The only way to stop against a replay attack is to use https for all the secure pages on you site. Now often you will sees sites using https for the logon page but this only secures your username and password; if the rest of the pages use http then the "logged-in" cookie is still sent unencrypted to those pages and is hence catchable.
Even when you turn on https for all the secure pages of your site you're still not 100% secure against replay attacks. The thing to remember is that cookies are sent to the web server with every applicable request - to set applicability there are options you can set on the cookie - domain (web site), path (area of web site), expires (date and time), secure (only over https). If you don't set the secure flag then, when you navigate away from one of the secure pages, back to a page over plain (unsecure) http, the "logged-in" cookie is still sent and hence you are open to a replay attack again.
And this is exactly what this hacking toolkit takes advantage of: http://www.theregister.co.uk/2008/09/11/cookiemonstor_rampage/
So if you're writing web apps and you need to avoid reply attacks being inflicted on your users, the please set the secure flag of your "logged-in" cookie. E.g. if you're using ASP.NET set the requireSSL attribute in the <forms> element of your web.config file: http://msdn.microsoft.com/en-us/library/1d3t3c61(VS.71).aspx
* Usually once per session.
(Read comments)
|
