Two days ago, I talked with you about the session concurrency problem in Spring Security. I also talked with my friends about how, like QQ, after a user successfully logs in on one device, it will automatically kick out the login on another device.

Of course, there are more than just session functions in Spring Security. As I told you before, we learn Spring Security and also learn various network attack and defense strategies. Today, Songo will talk with you about a simple one: What session fixation attacks are and how to prevent session fixation attacks in Spring Security.

This is the 16th article in the Spring Security series, and reading previous articles in this series will help you understand it better:

  1. Dig a big hole and Spring Security will do it!
  2. How to decrypt the password
  3. A step-by-step guide to customizing form logins in Spring Security
  4. Spring Security does front and back separation, so don’t do page jumps! All JSON interactions
  5. Authorization in Spring Security used to be so simple
  6. How does Spring Security store user data into the database?
  7. Spring Security+Spring Data Jpa, Security management is only easier!
  8. Spring Boot + Spring Security enables automatic login
  9. Spring Boot automatic login. How to control security risks?
  10. How is Spring Security better than Shiro in microservices projects?
  11. Two ways for SpringSecurity to customize authentication logic (advanced play)
  12. How can I quickly view information such as the IP address of the login user in Spring Security?
  13. Spring Security automatically kicks out the previous login user.
  14. How can I kick out a user who has logged in to Spring Boot + Vue?
  15. Spring Security comes with a firewall! You have no idea how secure your system is!

1.HttpSession

HttpSession fixed attack (HttpSession) : HttpSession fixed attack (HttpSession)

HttpSession is a server concept, the server generated HttpSession will have a corresponding sessionID, this sessionID will be passed to the front end through cookies, the front end later when sending requests, Sessionid = sessionID = sessionID = sessionID = sessionID = sessionID = sessionID

Closing the browser does not invalidate the server’s HttpSession. To invalidate the server’s HttpSession, you can either manually call the httpssession #invalidate method. Or wait until the session expires automatically; Or restart the server.

But why do some people feel like their session is invalid when the browser is closed? This is because when the browser closes, the sessionid stored in the browser is lost (by default), so when the browser accesses the server again, the server assigns a new sessionid to the browser. This sessionID does not correspond to the previous HttpSession, so the user will feel that the session is invalid.

Note that I used a default, which means that you can manually configure the sessionID to not be lost after the browser restarts, but this is a security risk and is generally not recommended.

Take Spring Boot as an example. After the server generates the sessionID, the response header returned to the front end looks like this:

There is a set-cookie field in the response header of the server side, which instructs the browser to update the sessionID. At the same time, note that there is also an HttpOnly attribute, which indicates that Cookie information cannot be read through THE JS script, which can effectively prevent XSS attacks.

The next time the browser sends a request, it will automatically carry the jsessionID:

Now that you have an overview of HttpSession, let’s look at session fixation attacks.

2. Fixed session attack

What is a session fixed attack? Session fixation attack.

Normally, as long as you do not close the browser, and the server HttpSession does not expire, then the server and the browser sessionid will not change, and the session fixed attack is to use this mechanism, with the victim with the same sessionid to obtain authentication and authorization. Then, the session ID is used to hijack the victim’s session to successfully impersonate the victim, resulting in a session fixed attack.

Generally speaking, the flow of session fixed attack is like this, taking Taobao as an example:

  1. The attacker can visit Taobao website normally. During the visit, Taobao website assigned a sessionID to the attacker.
  2. The attacker used the sessionID he got to construct a link to taobao website, and sent the link to the victim.
  3. The victim uses this link to log in to the Taobao website (the link contains the sessionID), and after the successful login, a legitimate session is successfully established.
  4. The attacker uses the sessionID in his hand to impersonate the victim.

In this process, if Taobao website supports URL rewriting, then the attack will be easier.

What is URL rewriting? If cookies are disabled in the browser, the sessionID will not be used. If cookies are disabled in the browser, the sessionID will not be used.

http://www.taobao.com; jsessionid=xxxxxxCopy the code

If the server supports URL rewriting, it would be too easy for an attacker to construct such an address by following the attack flow above.

This type of request address is something you probably don’t see in Spring Security (for reasons below), but you might see more or less in Shiro.

3. How to defend

The root cause of this problem is the same as the sessionid. If the user has a sessionid before logging in, the server can give the user a new sessionid after logging in, which can prevent the session fixation attack.

If you’re using Spring Security, you don’t have to worry about this because Spring Security already does defense by default.

Defense in Spring Security is mainly reflected in three aspects:

First is the last article about StrictHttpFirewall, request address; The request will be rejected outright.

On the other hand, there is an HttpOnly attribute in the set-cookie field of the response. In this way, the session information in the Cookie can be obtained through XSS attack to achieve the session fixation attack.

The third thing is to change the sessionID. Since the problem is caused by the constant sessionID, I will let the sessionID change.

The configuration is as follows:

As you can see, here we have four options:

  1. MigrateSession indicates that after a successful login, a new session is created and the information in the old session is copied to the new session. This is the default value.
  2. None indicates that nothing is done and the old session continues.
  3. ChangeSessionId indicates that the session does not change, but changes the session ID, which actually uses the Servlet container’s defense against session fixation attacks.
  4. NewSession: creates a newSession after login.

The default migrateSession is a sessionID for anonymous user access and another sessionID for successful user login. In this way, session locking attacks can be effectively avoided.

With these three options, we can effectively avoid session fixation attacks!

4. Summary

Having said that, you can see that if you use Spring Security, you don’t actually need to do anything. Spring Security has already helped us to do a good job of defending against session fixed attacks. Isn’t it very nice!

Ok, today and you talk about such a simple topic, if the partners feel harvest, remember to point under the encouragement of songge oh ~