[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



This is a good standing point for a FAQ on XSRF. Nice going Bob!

> 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
shopping cart, etc). It is possible for the accomplice the victim to be
the same site. 

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.

> 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
site and the victim site are the same. It also requires an XSS vuln.
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=&to=] is a good example. 


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

All and all, good work, 
Billy Hoffman
--
Lead Researcher, SPI Labs
SPI Dynamics Inc. - http://www.spidynamics.com
Phone:  678-781-4800
Direct:   678-781-4845

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



Brought to you by http://www.webappsec.org
Search this site