Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: FW: blocking CSRF attacks

Subject: RE: FW: blocking CSRF attacks
Date: Thu, 20 Dec 2007 16:45:13 +0200
Hi Paul

I think reading the following to articles (with emphasis on the FAQ) may
clarify matters:

http://www.cgisecurity.com/articles/csrf-faq.shtml
http://taossa.com/index.php/2007/02/08/same-origin-policy/

Best Regards,

Boaz Shunami

Comsec Consulting

-----Original Message-----
From: Paul Johnston [mailto:info@plot.uz] 
Sent: Wednesday, December 19, 2007 9:26 PM
To: Boaz Shunami
Cc: webappsec@securityfocus.com
Subject: 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
------------------------------------------------------------------------
-
**********************************************************************************************
IMPORTANT: The contents of this email and any attachments are confidential. 
They are intended for the 
named recipient(s) only.
If you have received this email in error, please notify the system manager or 
the sender immediately and do 
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************


-------------------------------------------------------------------------
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
-------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>