Re: [WEB SECURITY] Announcement: The Cross-site Request Forgery FAQ

[bugtraq@xxxxxxxxxxxxxxx]

Hey Billy!


> > What is Cross Site Request Forgery?
> 
> I think this needs to be expanded. For an XSRF attack to work, there are
> 2 parts:
> 
> 1- making a user agent send an HTTP request to a website that has their
> credentials or session id without the controlling user's knowledge or
> consent.
> 
> 2-The target of that HTTP request does something bad for that user.
> 
> I like to put this in terms of an XSRF accomplice an XSRF victim. The
> accomplice is an entity that performs part 1. This can be many different
> things, like a website or an email message. The victim is part 2, the
> target of the HTTP request that does something bad.
> 
> Its useful to think of this was websites. An XSRF accomplice is a
> website (WebsiteA) where user's can submit a URL (full or partial) that
> is ultimately requested by a user agent when that user agent is
> interpreting WebsiteA's content. In short, WebsiteA acts as a platform
> for the XSRF attack. Website's can/should take steps to prevent
> themselves from being used as an accomplice. An XSRF victim is a site
> which has not properly protected the various actions, allows a automated
> HTTP request to cause some malicious action (transfer money, add to

Thanks for the feedback Billy, I'll take your suggestions for improvement into consideration.
Ping me offline if you'd like to chat about this some more. 


> shopping cart, etc). It is possible for the accomplice the victim to be
> the same site.=20

I mention that scenerio briefly.

> Also, I cannot think of one instance where XSS was used as a vector to
> bootstrap an XSRF attack. I'm sure it has happened but it's not
> "typical" as mentioned.

While not typical, it is entirely possible and for that reason I've included it.


> > What are common ways to perform a CSRF attack?
> 
> Since step one of an XSRF attack requires sending an HTTP request, you
> should add more ways that a browser can be forced to make an HTTP
> request to an arbitrary site? XHR only works on where the accomplice

The document will be updated in a similar fashion as RSnake's XSS cheatsheet in relation
to additional ways to perform remote requests as I find them.

> site and the victim site are the same. It also requires an XSS vuln.

Correct. 

> Image objects also require an XSS vuln. Think about things like <LINK>
> or external style sheets. Also stop focusing on HTML/JavaScript
> injection. Even sites that use "meta markup": languages like BBcode can
> be used. [image:http://site/transfer?amount=3D&to=3D] is a good example. =
> 

In order for a CSRF issue to be exploited if you really think about it, some sort of injection
needs to take place at some level (at the time of this writing anyways). Typically
Markup languages such as XML or HTML, scripting languages such as JavaScript  
are the vectors used. I'd love to get some discussion going on the list if anyone know of any unusual
execution vectors. 

I've added Lightweight markup languages in light of your comment to the document and referenced your post.


> On a whole, I'm still uneasy about the all the XSS mentioned in this
> article. Once I have script execution on a website, I *am* that user.

While XSS and CSRF are entirely different issues, they are tightly grouped together. 
XSS is typically the vector for performing the remote request there's no debating that. This FAQ
is a collection of existing documents and mailing list postings. I'm more than happy to add additional
content including additional attack vectors if you know of any, or as they are discovered and published. 


> The server cannot tell the difference between requests made by
> JavaScript and Requests made by the user. Yes, this is technically XSRF
> against the site with the XSS vuln, but that's an obvious conclusion
> covered by "server cannot tell the difference" because that includes
> cookies and cached auth information.

Exactly this is not a simple black and white issue. If an XSS issue exists, there is no way to  
prevent CSRF either by using the token method, or by prompting the user to relogin every time at least
at the time of this writing (if you know of one do let me know). If I can
XSS you, I can rewrite the login form and 'own you' as you mentioned above.

One of the reasons for publishing this document was to begin the clarification process of what CSRF is, as well as
start some discussion on it. 

Thanks for the feedback.

- Robert


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