Re: [WEB SECURITY] Suggestions for the CSRF FAQ

[Stefan Esser <sesser@xxxxxxxxxxxxxxxx>]

John,
> Its true that an email verification step would defeat CSRF in some cases
> but I don't see that being very practical. It also leaves the web app
>   
An email verification step will defeat CSRF in all cases. It might not
be practical in all situations but a lot of web-applications already use
it, whenever a password change request or a new registration is
submitted. While this is of course meant as a protection against dumb
robots and to verify that the email belongs to the new user, it is also
a protection against CSRF.
> arena and assumes that no one has access to your mail server, local box,
> or the traffic on your local network. Not to mention that an email is
> almost always going to be plain text.
>   
This argumentation has nothing todo with CSRF. HTTP traffic is also
plaintext, so what? As long you are not able to sniff traffic with XSS
it is not possible to get around email verification with XSS. (Ohh yes I
know that there are bugs in certain home routers that actually allow
sniffing via XSS but this is not the normal case).
> In reference to most CAPTCHA's, if an XSS attack exists, then a captcha
> can be defeated due to bi-directional channels where an attacker could
> solve the captcha remotely.
>   
A captcha is usually an image, that can only be viewed by the browser of
the user. As long you don't have a method to access the image data from
within JavaScript and send it to the attacker your attack relies on a
flaw in the session management that allows arbitrary users to view the
captcha images. Okay at this point you might require implemented HTTP
only cookies or sessions bound to the users ip for captcha viewing, but
that is another story.
> What are you talking about when you mention the cross-domain policy? A
> cross-domain policy is intended to expand the access of an application,
> not to restrict it. The cross-domain restrictions in the browser already
> do that.
>   
Yeah well, I was speaking of cross-domain restrictions on JavaScript
code, that can be used by a webpage against JS malware. There are some
(different) ideas about using multiple domains and iframes to stop JS
malware. I already wrote about one  complicated crazy idea  that puts
every single formular onto another domain. There are other simpler
solutions that I will document once I finally get some free time again.

Stefan Esser

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

The Web Security Mailing List: 
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]