the-web-application-hackers-handbook

Chapter 13 n Attacking Users: Other Techniques 543
HACK STEPS
1. Identify every instance within the application where a redirect occurs.
2. An effective way to do this is to walk through the application using an
intercepting proxy and monitor the requests made for actual pages (as
opposed to other resources, such as images, stylesheets, and script files).
3. If a single navigation action results in more than one request in succession,
investigate what means of performing the redirect is being used.
The majority of redirects are not user-controllable. For example, in a typical
login mechanism, submitting valid credentials to /login.jsp might return an
HTTP redirect to /myhome.jsp. The target of the redirect is always the same, so
it is not subject to any vulnerabilities involving redirection.
However, in other cases, data supplied by the user is used in some way to
set the target of the redirect. A common instance of this is when an application
forces users whose sessions have expired to return to the login page and
then redirects them to the original URL following successful reauthentication.
If you encounter this type of behavior, the application may be vulnerable to a
redirection attack, and you should investigate further to determine whether
the behavior is exploitable.
HACK STEPS
1. If the user data being processed in a redirect contains an absolute URL,
modify the domain name within the URL, and test whether the application
redirects you to the different domain.
2. If the user data being processed contains a relative URL, modify this into
an absolute URL for a different domain, and test whether the application
redirects you to this domain.
3. In both cases, if you see behavior like the following, the application is certainly
vulnerable to an arbitrary redirection attack:
GET /updates/8/?redir=http://mdattacker.net/ HTTP/1.1
Host: mdsec.net
HTTP/1.1 302 Object moved
Location: http://mdattacker.net/