The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

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 of the relevant parameters

required for the attack and has its target set to the vulnerable URL. You

can use JavaScript to auto-submit the form as soon as the page loads. 

■

While logged in to the application, use the same browser to load your

crafted HTML page. Verify that the desired action is carried out within the

application.

Preventing XSRF Flaws

XSRF vulnerabilities arise because of the way browsers automatically submit

cookies back to the issuing web server with each subsequent request. If a web

application relies solely upon HTTP cookies as its mechanism for transmitting

session tokens, then it is inherently at risk from this type of attack.

XSRF attacks can be prevented by not relying only upon cookies in this way.

In the most security-critical applications, such as online banks, it is usual to see

some session tokens being transmitted via hidden fields in HTML forms.

When each request is submitted, in addition to validating session cookies, the

application verifies that the correct tokens were received in the form submis-

sion. If an application behaves in this way, then an attacker will not be able to

mount a XSRF attack without already knowing the value of the tokens being

transmitted in hidden fields. To be successful, the attacker will already need to

have hijacked the user’s session, making any XSRF attack unnecessary. 

Do not make the mistake of relying upon the HTTP 

Referer

header to indi-

cate whether a request originated on-site or off-site. The 

Referer

header can be

70779c12.qxd:WileyRed  9/14/07  3:14 PM  Page 444

---

spoofed using older versions of Flash or masked altogether using a meta

refresh tag. In general, the 

Referer

header is not a reliable foundation on

which to build any security defenses within web applications.

An anti-XSRF safeguard employed in some applications is to require that

users complete multiple steps in order to carry out sensitive actions such as

funds transfers. If this is done, then to be effective the application must employ

some kind of token or nonce within the multistep process. Typically, at the first

stage, the application places a token into a hidden form field, and at the second

stage, it verifies that the same token has been submitted. Because XSRF attacks

are one-way, the attacking web site cannot retrieve the token from the first

stage in order to submit it at the second. If the application uses two steps with-

out the safeguard of a token, then the defense achieves nothing because an

XSRF attack can simply issue the two required requests in turn, or (very often)

proceed directly to the second request.