There are plenty of places where people can access the Internet using computers shared among many users: public libraries, schools or Internet cafés.

Different people can get there. Unfortunately, some of them may be malicious. Usually we can expect that the user will have very limited rights and there will be some type of anti-malware software. Sadly, if our app keeps the same session ID after logging the user in, our users are in danger.

The action of this story takes place in a fictional public library.

A malicious person visits the login page, presses F12 to open the developer tools and takes a picture of the session ID with his phone. Then he closes the tab and sits somewhere else, where he enters the session ID stolen from himself. The trap is set.

Somebody takes the seat previously taken by the attacker. The computer is not infected, the connection is encrypted and the victim is totally unaware of the threat. He authenticates.

This is the moment the attacker has been waiting for! Because the app doesn’t regenerate the session ID before putting there the data of the authenticated user, now both the victim and the attacker share the same session. The attacker can do everything he could do as he would be sitting in front of the victim’s computer.

How can we protect our users against that kind of attacks? We should never put their data into “old” sessions. Before we log the user in, we regenerate the session and get a new ID.

If we write node and the authentication middleware we use doesn’t regenerate the session, we can use the express-new-session middleware:

const newSession = require("express-new-session");

//..."/login", newSession(), tryToLogin, (req, res) => {

If you work with different technologies, the easiest way to figure out whether the system is vulnerable to this type of attacks, is to check whether the session ID changes after an user logs in.