Session Fixation Principle and Defense

Session

Session

A storage structure for a class of schemes used to maintain state between a client and a server

Session

Since the Session is stored in the form of a text file on the server side, it is not afraid that the Client can modify the content. It can be stored directly in memory or in a memory database such as redis. Of course, it is also possible to store it in other databases.

Sessions have a lifecycle

The so-called lightweight means that its creation and deletion do not need to consume too many resources

There is a cache inside the Session object

Session

It is used to store the attributes and configuration information of a specific user session, such as the user’s identity information, etc., which will not be lost when the web page jumps.

Usually used for the following operations:

  • Store information that maintains user status throughout the session, such as login information or other information generated by user browsing
  • Store objects that only need to maintain state between pages during a new load, or a set of functional pages
    Maintain user status information on the web server for accessing pages from any device at any time

Restrictions:

  • The more users log in, the more memory the session needs
  • The duration of each session object is user access time plus inactivity time

Why do we need a session?

Because the HTTP protocol itself is stateless, there is no way for users to remember the login status within a period of time after logging in. It requires another tool to record the login status and generate an id for this record to return to the Client. After being saved, each subsequent request will take this id to automatically authenticate the login status.

An example of coffee:

  1. The clerk of the store is very powerful and can remember the consumption amount of each customer. As long as the customer walks into the coffee shop, the clerk will know how to treat it. This approach is the support state of the protocol itself.

  2. Give the customer a card, which records the amount of consumption, usually with an expiration date. Every time the customer presents this card, the consumption will be linked to previous or future consumption. This practice is to keep the status in the Client.

  3. A membership card is issued to the customer, and no information is recorded except the card number. Every time the customer produces the card, the clerk finds the record corresponding to the card number in the store’s record book and adds some consumption information. This approach is to maintain the state on the server side.

Specific mechanisms

  1. When the program needs to create a’session ‘for a client’s request (usually after the login information is successfully verified to create a session for these information), the server first checks whether the client’s request already contains a ** session Identifier ** - called’session id’, if it already contains a’session id ‘, it means that a session has been created for this Client before, and the server retrieves the’session’ according to the’session id ’ (if it cannot be retrieved, it may create a new one), if the Client request does not contain the’session id’, then this is Client creates a’session ‘and generates a’session id’ associated with this’session ‘. The value of the’session id’ should be a string ** that will not be repeated and is not easy to find patterns to imitate **, this The’session id 'will be returned to the Client for saving in this response (usually set this sessionid to the cookie through the set-cookie header in the return header, and the next request will automatically send this sessionid to the background through the cookie).

  2. Since’cookies’ can be artificially disabled, there must be other mechanisms in place to still be able to pass the’session id ‘back to the server when’cookies’ are disabled. A technique often used is called’URL 'rewriting

    Two forms:

    1
    2
    3
    4
    5
    6
    7
    //append path as url
    'http://..../xxx;jsessionid=abcdefjijeoijoifjioe'


    //as a query string
    'http://..../xxx?jsessionid=abcdefjijeoijoifjioe'
    Copy the code
  3. Older technology, ** form hidden fields **, this method is useful in preventing csrf

Session

Definition

Session fixation attack is to use the session ID fixed mechanism of the application system in the server to obtain authentication and authorization with the help of others with the same session ID, and then use the session ID to hijack other people’s sessions to successfully impersonate others, resulting in session fixation attack

Attack flow

  1. Attackers can access the application website normally;

  2. The application website server returns a session ID (attackSessionID) to him;

  3. The Attacker uses the session ID to construct a link to the website (http://website.kom/login.php? sessionid = attackerSessionID) and sends it to the Victim;

  4. Click the link, carry the attacker’s session ID and username password to log in to the website normally, and the session is successfully established; at this time, if you use the attackerSessionID to access the server, the server will consider the attacker to be the victim.

  5. The Attacker successfully impersonated and hijacked the Victim’s session with the session ID.

Defense methods

The root cause of the entire attack process is to directly use the sessionID sent by the link to generate a session and return the sessionID directly.

The solution is also very simple. Interfaces with sensitive information like login need to regenerate a new sessionID.

Express-session

Express-session is a plugin for the node server framework express. For details, please refer to how to use it.express-session文档If you want to understand the principle, you can also look at the source code. In fact, the principle is very simple, but it is encapsulated. It is the generation of cookies and set-cookies in the request header, and the encapsulation of CRUD in the session.

It is worth noting that its store option, that is, the storage location. If it does not pass a value, it will be stored in memory by default. We can implement a plugin ourselves, as long as the plugin implements the get, set, touch and other interfaces mentioned in the doc above. It doesn’t matter if your interfaces store data to Redis, MongoDB or anywhere else.

If you just use express-session to manage the session, there is no way to defend against session fixation, and there is no need to regenerate the sessionID for every request. We only need to regenerate the sessionID for some sensitive operations, such as login. Good. Such as:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
const fixation = (options) => {
options = options || {};
return function(req, res, next) {
req.resetSessionID = function() {
return new Promise(function(resolve, reject) {
let session = req.session;
req.session.regenerate(function(err) {
if (err) {
reject(err);
} else {
for (let i in session) {
if (!req.session[i]) {
req.session[i] = session[i];
}
}
resolve(req.session);
}
});
});
};
if (options.everyRequest && req.headers['X-Requested-With'] ! 'XMLHttpRequest' && !req.xhr) {
req.resetSessionID().then(function() {
next();
}).catch(function(err) {
next(err);
});
} else {
next();
}
};
};

The above code regenerates an id through the regenerate method built into express-session, and sets the original session content to the newly generated session.

We only need to call this method in the request that needs to reset the id.

Reference article:

https://juejin.im/post/5af828e96fb9a07ab83e1f10