1. Computing

Is Your Ruby Code Secure?

CSRF Attacks Without XSS



Although CSRF attacks are similar in nature to Cross-Site Scripting (XSS) attacks and can occur in conjunction with an XSS attack, they don't always go hand-in-hand and differ in nature. While XSS attacks rely on HTML code injected into the target site, a CSRF attack may also be initiated from a second site. The ability to launch the CSRF attack from a second site lifts any restrictions attackers may have on the HTML code they're allowed to use in the attack. It allows attackers to freely use things like forms, IFRAMEs and Javascript to perform the CSRF attack.

Let's, for example, assume that Alice is logged into Site A, a site which she uses frequently and to which she has authorization information. Maybe Alice doesn't log out of Site A or clear her cookies when she's finished, which leaves her still authorized to make requests to Site A. Whatever the reasons, Alice's authorization information for Site A is carried in the form of a cookie or HTTP Authorization header. So, unless she's the type to toss her cookies on a regular basis (and it doesn't seem as though she is), any request Alice makes to Site A carries her authorization information.

Like most of us, Alice has a bunch of other sites she likes to visit, too. One of those sites--let's call it Site B--allows users to post HTML tags. Assume that one of Site B's other users, Mallory, isn't as trustworthy and naive as Alice and deliberately posts HTML tags on Site B that will cause other users to preform unintentional GET or POST HTTP requests to sites to which they hold unexpired cookies. The HTML tag on Site B that can cause Alice to send a malicious request to Site A can be any of the following:

  • A link Alice clicks on. This link is likely to be disguised as something innocent that Alice would click on.
  • A form Alice must submit. Mallory may create a new website at Site B or tell Alice her authentication information was accidentally deleted on Site B. Mallory will alter the form so it looks legitimate, but it actually submits a POST request to Site A. Hidden fields in the form can be used to submit any variables Mallory wishes. However, since the form actually submits to Site A, Site A's response will be displayed in Alice's web browser and she will notice something is wrong.
  • An IFRAME or hidden IFRAME that Alice's browser will load when Site B loads. Cascading Style Sheets can be used to hide any IFRAME element on Site B. That IFRAME element can then submit any GET request as soon as Site B is loaded.
  • Javascript that performs a GET request or submits a form or hidden form. The Javascript can be used to submit a POST request to Site B. GET requests can be performed by Javascript in a number of ways, including pre-loading images. Any forms submitted will show Site A's response to the form, unless the forms are in a hidden IFRAME.
  • Any other tag that will cause Alice's web browser to perform a HTTP request on Site A, such as an IMG tag. The classic example of the CSRF attack uses the IMG tag. In that example, the URL Mallory wishes Alice to visit is placed in the src attribute of the IMG tag and Alice's web browser will dutifully make a GET request to that address. Since the response from Site A isn't likely to be an image, no image is displayed and, instead, the Web browser's "image failed to load" icon may be displayed.
  • A link to Site C that Alice must click on that contains any of the above elements. Since Mallory might not have the freedom to post the HTML tags on Site B that she needs in order to perform the attack, she may need to lure Alice to a third site over which Mallory has more control. Mallory can also use reflection techniques. If Site B only allows Mallory to link to URLs ending in .jpg for example, Mallory can create a custom script on Site C that uses the Location HTTP header or an HTML redirect to redirect Alice to Site A.

The malicious request made to Site A by Alice will carry with it any authentication information stored in cookies such as session IDs. The GET or POST request chosen by Mallory will execute on Site A using all of Alice's permissions and privileges, as well as her identity. Also, since it's Alice making the actual HTTP requests to Site A that performs the attack, it may be difficult--if not impossible--to determine who initiated the attack with the malicious HTML.

  1. About.com
  2. Computing
  3. Ruby
  4. Ruby on Rails
  5. Security
  6. CSRF Without XSS

©2014 About.com. All rights reserved.