Am I exposing any vulnerabilities by using this redirect method? Play Framework 2

Question

In my current Play 2 application, login sessions timeout after 5 minutes. When the user then clicks on any links in the app, they are redirected to the login page. After successful authentication, they are redirected to the main page.

I have implemented a system where the user is redirected to the page they were trying to reach before being redirected to the login page.

The system works like this: when the user with an expired session clicks an internal link, Deadbolt determines they are not logged in and redirects them to the login page. Before the redirect, it grabs the target url from the request header and stores it in the session. After the user fills out the login form on the following page, they submit the details to the authentication action. If the authentication is successful, the action checks to see if a target url exists in session; if so, it clears the item from the session and redirects to the target url, if not, it redirects to the main page.

The target url exists as a String for the duration and is fed into the play.mvc.Results.redirect( String url ) method as such.

I'm wondering if this opens up any potential attack vectors to my app?

Answer 1

As you are storing the URL in the session, this should be secure from manipulation as the URL had to be valid in the first place for it to hit your application.

However, there could be a possible way for a user to cause an invalid URL to be stored in your session and redirect a user there, but it would have to be either from the same computer, or the attacker would have to have a mechanism to fixate a session on another computer:

1. Attacker sets a host file entry to point www.evil.com at your website.
2. Attacker logs in to your website using the www.evil.com domain name and their own credentials.
3. Attacker waits for session to expire.
4. Attacker clicks an internal link causing the URL http://www.evil.com/link to be stored in your session variable.
5. Attacker logs out and removes hosts entry.
6. Another user logs in using the same session and the user is redirected to the rouge link.

If the user is logging in on the same computer then the attacker would have to edit the cookie domain from www.evil.com to www.yourwebsite.com. If on a different computer then the attacker would have to fixate the session somehow (possible of there was another vulnerability in your site such as having predictable tokens of if the session ID is passed in the clear at any point).

How to lock down your application:

1. Make sure your website is only bound to www.yourwebsite.com - this would stop host file entries pointing at the same IP from hitting your site.
2. Validate the URL before it is stored - reject any absolute URLs pointing to unknown domain names for your application, or store the relative part only (make sure this code is not vulnerable to any string manipulation that could be entered into the address bar and still be made to hit your application - e.g. if user appends a URL to query string or enters any other unexpected input).
3. Store the redirect URL in the query string and invalidate the session on login/logout to protect against session fixation. This time it should be validated on point of redirect as it is now a client-side variable - you should make sure it is redirecting to a domain name you expect or it is definitely a relative URL.
4. Use a secure cookie for the session ID to make sure it is not transmitted over HTTP.