the-web-application-hackers-handbook

Chapter 21 n A Web Application Hacker’s Methodology 831
an arbitrary redirect to an external website. If so, this behavior can be
exploited to lend credibility to a phishing-style attack.
7.3.4.2 If the application ordinarily transmits an absolute URL as the parameter’s
value, modify the domain name within the URL, and test whether the
application redirects you to the different domain.
7.3.4.3 If the parameter normally contains a relative URL, modify this into an
absolute URL for a different domain, and test whether the application
redirects you to this domain.
7.3.4.4 If the application carries out some validation on the parameter before
performing the redirect, in an effort to prevent external redirection,
this is often vulnerable to bypasses. Try the various attacks described
in Chapter 13 to test the robustness of the filters.
7.3.5 Test for Stored Attacks
7.3.5.1 If the application stores items of user-supplied input and later displays these
on-screen, after you have fuzzed the entire application you may observe
some of your attack strings being returned in responses to requests that did
not themselves contain those strings. Note any instances where this occurs,
and identify the original entry point for the data that is being stored.
7.3.5.2 In some cases, user-supplied data is stored successfully only if you complete
a multistage process, which does not occur in basic fuzz testing. If
your application mapping exercises identified any functionality of this
kind, manually walk through the relevant process and test the stored
data for XSS vulnerabilities.
7.3.5.3 If you have sufficient access to test it, review closely any administrative
functionality in which data originating from low-privileged users is
ultimately rendered on-screen in the session of more privileged users.
Any stored XSS vulnerabilities in functionality of this kind typically lead
directly to privilege escalation.
7.3.5.4 Test every instance where user-supplied data is stored and displayed
to users. Probe these for XSS and the other response injection attacks
described previously.
7.3.5.5 If you find a vulnerability in which input supplied by one user is displayed
to other users, determine the most effective attack payload with which
you can achieve your objectives, such as session hijacking or request
forgery. If the stored data is displayed only to the same user from whom
it originated, try to find ways of chaining any other vulnerabilities you
have discovered (such as broken access controls) to inject an attack into
other users’ sessions.