Cookie replay attack protection
Following on my previous security article on Defensive Programming I’ll be talking you through and providing a sample class to protect against replay attacks. Internet security is not one to be taken lightly. There is a saying that Internet Security is a trade-off between security and usability. And that’s true for the most part, but luckily protection against replay attacks does not hinder usability—it’s almost completely transparent to the end users.
So let’s jump straight in, what is a replay attack? Essentially a security breach whereby someone poses as someone else using some unique piece of data the user supplied/was issued to/from the Web server. It’s kind of similar to a man-in-the-middle attack. We’re going to be looking at the attack using specifically cookie authorisation, a very common means of implementing a “remember me” function.
Replay attacks are often one thing that programmers forget to protect against. This really is quite a worry since I want my identity to be safe online and I’m sure you do, too. Let’s look at the problem in a readable form:
- John logs into example.org.
- Server issues John a cookie with value of 12345.
- John revisits example.org again and is logged in.
- Evil Joe looked at the request and steals the cookie.
- Joe visits example.org which logs him in as John.
Due to the very nature of the attack it isn’t possible to 100% protect against it, it’s inherently insecure. But there are ways to increase the security, and that’s to add another step after (3) above:
- Server reissues John a cookie with value of 67891.
It’s called token regeneration. We have recognised that John has a valid cookie, logged the user in, removed their old cookie and recreate a new one that no one else should know. Even if Joe had the old cookie it’s no longer valid and has to perform the same actions as (4) in the original way.
Another method is to add some kind of time restriction, so only make the cookie valid for a certain amount of days. So if Joe happens to stumble across the cookie after a month he should no longer be able to login as John. Another to add in which browser John is using, the chances of John using exactly the same as Joe is unlikely. But again it is possible, so don’t rely on it!
Firstly we will need another table into our database (I’m going to assume you have a semi-advanced knowledge of databases and PHP), I’ll call it login_token.
With that in place, let’s create a couple of small PHP class to do the remembering. I’ll start with a nice cookie class
so our remembering function is a little neater (Remember, we want high cohesion and low coupling!).
Now we’ll create our actual remembering class:*
- Firstly remove all the past cookies they may have had. *
- Generate the new MD5 cookie. *
- Create the cookie on users computer. *
- Insert the cookie into the database. *
And there we go. We have successfully written an almost secure way to implement a “remember me” function. Of course you can take this further by adding even more security, such as:
- Prepared SQL statements.
- Add the user agent to the database (You expect returning visitors to use the same browser, if not then they will need to login again anyway (unless they upgrade their browser, but this is infrequent!))
- Store the user ID in the cookie to reduce hash collisions.
- And a myriad of other ways.