Don’t Let Replay Attacks De-rail You – All You Need to Know About Replay Attacks

If you’re developing an web application using authentication or your business uses such a service, you need to be aware of the possible threat of a Replay attack. In Replay attacks, a valid data transmission will be repeated or altered maliciously, which will expose your data to possible theft and corruption. Definitely not something that you want. So how do you protect yourself?

Who is vulnerable to Replay attacks?

Is your protection fro replay attacks in place?Web apps that use any sort of authentication need to be aware of (and protected from) Replay attacks. Examples of such web apps are Gmail, Facebook, Dropbox and the Panorama9 Dashboard. If your data is even remotely sensitive, you need to take measures to ensure that it is protected. In broad terms here’s what to look out for as a developer or user of web applications.

 

Encrypt or Be Stripped

If you want your confidential data to remain that way, you’re going to need to start by ensuring that you are using an encrypted channel. An attacker will try to imitate a user by stealing the access credentials; in order to prevent that, you should send information only through encrypted channels, which generally means using HTTPS.

Encryption has been a fairly common practice for several years now, but until a few years ago there was not a wide spread acceptance that login and all subsequent communication should happen via HTTPS. If you are a user worried about your data, double check that every page you visit while logged in is served via HTTPS – look for the lock icon in your browser’s address bar. If you are developing a web app make sure that once logged in the users are served only encrypted content.

Take the Sugar out of Your Cookies

Even once you are using an encrypted channel for your app, you are still vulnerable to Replay attacks at both ends of the channel – the server and the user side, where the information will be decrypted.

Your server is probably relatively safe; pulling off an attack on the server is more difficult and if penetrated there are juicier targets than a replay attack. The user side, however, will be both more susceptible and still alluring to potential hackers. On the user side sensitive information, like login credentials and private information, is often stored in cookies. Generally, an attack here will take the form of stealing a cookie from the user’s hard disk.

There are several ways to protect yourself (and your users) from stolen cookies. The best way is to not keep valuable information in the cookie (take out the “sugar,” if you will.) When the app is dealing with authentication, the solution is to stop having the complete credentials in the cookie. Instead, you should make it so that after login your server notes an identifier in the cookie that means that it is valid and on logout note that that identifier can no longer be used. This will limit Replay attacks to only work until the user logs out.

If you need greater security, you can look into implementing a cryptographic nonce for your servers, which is a good deal more complicated, but for most apps simply removing sensitive info from your cookies should be sufficient to protect your users.

Replay attacks can be seriously damaging, but they are easily avoidable. With the right precautions, you and your business can keep running worry-free with no replays in sight.

Fresh Tips Directly in Your Inbox

Submit your email address below and get our updates on the most important things MSPs should know.

Leave a Reply

Your email address will not be published. Required fields are marked *