CODEWITHSUNDEEP
ruby-on-rails
markiv
markiv

Reputation: 2351

session fixation

I am new to web development, and trying to get a hold on security issues. I went through this article on http://guides.rubyonrails.org/security.html these are some of the steps the author has mentioned how an attacker fixes session.

  1. The attacker creates a valid session id: He loads the login page of the web application where he wants to fix the session, and takes the session id in the cookie from the response (see number 1 and 2 in the image).
  2. He possibly maintains the session. Expiring sessions, for example every 20 minutes, greatly reduces the time-frame for attack. Therefore he accesses the web application from time to time in order to keep the session alive.
  3. Now the attacker will force the user’s browser into using this session id (see number 3 in the image). As you may not change a cookie of another domain (because of the same origin policy), the attacker has to run a JavaScript from the domain of the target web application. Injecting the JavaScript code into the application by XSS accomplishes this attack. Here is an example: <script> document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9"; </script>. Read more about XSS and injection later on.
  4. The attacker lures the victim to the infected page with the JavaScript code. By viewing the page, the victim’s browser will change the session id to the trap session id.
  5. As the new trap session is unused, the web application will require the user to authenticate.
  6. From now on, the victim and the attacker will co-use the web application with the same session: The session became valid and the victim didn’t notice the attack.

I dont understand couple of points.

  1. Why is user made to login in step5, since session is sent through?
  2. I saw possible solutions on wiki, like user properties check and others. Why cant we just reset the session for the user whoever is login in when they enter username and password in step5?

Upvotes: 2

Views: 1445

Answers (1)

Veger
Veger

Reputation: 37905

1) The attacker receives a session in steps 1&2 which is not logged in yet. This is the trap session. At step 5 the victim logs in thinking that the session id is new (and 'secret'). At the moment when the victim is logged in the attacker is able to re-use the 'secret' session id and effectively is logged in as well.

So to answer your question: the victim is made to login because the trap session is not logged in yet in order to trick the victim to login using this session id.

2) After explaining the steps of session fixation, the first counter measure (section 2.8) is to create a new session and abandon the old on after logging in. Exactly what your idea was!

Upvotes: 1

Related Questions