the-web-application-hackers-handbook

820 Chapter 21 n A Web Application Hacker’s Methodology
5.9 Check for CSRF
5.9.1 If the application relies solely on HTTP cookies as its method of transmitting
session tokens, it may be vulnerable to cross-site request forgery
attacks.
5.9.2 Review the application’s key functionality, and identify the specific
requests that are used to perform sensitive actions. If an attacker can
fully determine in advance parameters for any of these requests (that
is, they do not contain any session tokens, unpredictable data, or other
secrets), the application is almost certainly vulnerable.
5.9.3 Create an HTML page that will issue the desired request without any
user interaction. For GET requests, you can place an tag with the
src parameter set to the vulnerable URL. For POST requests, you can
create a form that contains hidden fields for all the relevant parameters
required for the attack and that has its target set to the vulnerable
URL. You can use JavaScript to autosubmit the form as soon as the
page loads. While logged in to the application, use the same browser
to load your HTML page. Verify that the desired action is carried out
within the application.
5.9.4 If the application uses additional tokens within requests in an attempt to
prevent CSRF attacks, test the robustness of these in the same manner as
for session tokens. Also test whether the application is vulnerable to UI
redress attacks, in order to defeat the anti-CSRF defenses (see Chapter 13
for more details).
5.10 Check Cookie Scope
5.10.1 If the application uses HTTP cookies to transmit session tokens (or
any other sensitive data), review the relevant Set-Cookie headers, and
check for any domain or path attributes used to control the scope of the
cookies.
5.10.2 If the application explicitly liberalizes its cookies’ scope to a parent
domain or parent directory, it may be leaving itself vulnerable to attacks
via other web applications that are hosted within the parent domain
or directory.
5.10.3 If the application sets its cookies’ domain scope to its own domain
name (or does not specify a domain attribute), it may still be exposed
to attacks via any applications hosted on subdomains. This is a consequence
of how cookie scoping works. It cannot be avoided other than
by not hosting any other applications on a subdomain of a securitysensitive
application.