July 25, 2011

I am sure this issue has already been discussed but I would like to spend few words on it.
I recently performed a test against an application which would "remember" the URI of the request even if the user is not authenticated. To make myself clear with an example, think about the following:

User not authenticated requests:

GET /DoSomething/Element/Component?something=value HTTP/1.1

The response brings to the login page and sets a cookie "MyCookie" with a value (e.g. AAA111).

Set-Cookie: MyCookie=AAA111

The above request requires the user to be authenticated but at this stage the user is not. So the user makes the above request without having valid authentication cookies. When the user authenticates with the same browser and the "MyCookie" cookie, the login function sets new cookies (authentication cookies) and automatically redirects the user to the page requested previously (a 302 redirection to: http://myapp/DoSomething/Element/Component?something=value ).

This is where the application makes a "connection" between a previous request and a succesful login. The interesting part is that normally you would expect a login function to bring the user to a specific landing page/homepage without performing an automatic redirection.

I am not sure about the application internals since I did not have any information on the back-end, but it is using the cookie (e.g. "MyCookie") to perform the redirection. In fact, if the cookie "MyCookie" is sent within the authentication request, the application performs the redirection otherwise no redirection occurs.

Associating an URI to a cookie to perform a redirection is not good, since it is possible to force a user to perform a request following a succesful login, a kind of "delayed" XSRF attack, if you allow me to use that expression.

Associating a redirection or using a "routing" cookie is not a good idea and could lead to this type of issue which would allow a malicious user to still perform XSRF even though the user is not *yet* authenticated. The only difference from a traditional XSRF is the additional condition for the exploit which implies the user has to login after the malicious request has been performed.

The table below summarises the above:

Nr. Sequence Comment
1 User is not yet authenticated  
2 XSRF attack occurs No immediate effect
3 User authenticates Additional condition for exploit
4 Forged request triggered by automatic redirection Attack has 'delayed' effect


Share - permalink - Comment/Contact me