Re: FW: blocking CSRF attacks

Hi,

Just want to set the record straight on a couple of points.

> If the token is only on the form, then this is still vulnerable to
> CSRF as the attacker would just need to write a bit of JavaScript that
> gets the page the form is on first, then reads the token and then
> posts the form using the valid token.
This is not true - JavaScript cannot read the token because of the 
browser's same origin policy.

> Referrer can be spoofed; same goes for post and get requests, hence 
> this method will not be reliable as a security mechanism

In a CSRF attack the victim's browser is making the request, so the 
attacker does not get free control of the referer header. Sure, using 
this as a security control is not perfect, but it does have some merit 
as a quick fix.

In may be possible for an attacker to avoid the referer header being 
sent - if they use <meta http-equiv="refresh" ...> but I have not 
experimented with this, and it would only do this for GET requests.

Paul

> .

-------------------------------------------------------------------------
Sponsored by: Watchfire 
Methodologies & Tools for Web Application Security Assessment 
With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! 

https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F
-------------------------------------------------------------------------