How to Prevent Replay Attacks on Your Website

This article was originally published at Ben's Tech Talks site.

Replay attacks, in which attackers intercept and resend network packets that do not belong to them, are extremely dangerous and can in some cases cause serious damage. What makes these kinds of attacks even more noisome is that they can even be staged on encrypted communication channels without gaining access to the decryption keys. Attackers only have to eavesdrop on your line and have a general knowledge of what task a specific set of packets are performing, and by resending those packets or requests, they will be able to disrupt your communications or cause more damaging effects.

In this article, I’ll show you a basic, easy-to-implement method that will prevent replay attacks on your website. It will also have the side benefit of preventing the annoying effects of confused users repeating their last POST request by constantly refreshing their browser at the wrong time.

This is far from a complete solution. It has flaws and pending issues, but it gives you a general view of how tokens and simple protocols can enhance security in your websites. Sample codes and implementation are done in ASP.NET and C#, but the concept can be deployed on any other platform or programming language.

The One-time Token Concept

The idea behind the solution that will be offered in this post is to tie every HTTP response to a token string which will be valid only for the next post request. Here’s a simple breakdown of the steps involved:

1. The client makes a GET request by typing the URL or a page or by clicking on a link.
2. The server generates a random token. Subsequently, it stores a copy of the token in the session and embeds a copy of the token in the <form> tag of the response it sends to the client.
3. The client processes the content, and sends a POST request to the server, say when the user clicks on a button, which contains the randomly-generated token.
4. The server receives the request and proceeds with processing it only if the attached token is equal to the one stored in the user’s session.
5. The server invalidates the token and returns to step 2, where it formulates the response with a new random token.

In this manner, even if a critical request sent to the server is intercepted by a malicious user, it cannot be repeated because the token it contains is no longer valid after the request is sent to the server. The same goes for the scenario where a careless user mistakenly presses F5 on the keyboard and resends the request after posting information to the server.

Continue reading %How to Prevent Replay Attacks on Your Website%

by Ben Dickson via SitePoint