ansaurus

Question

Any logical loop holes in this idea for preventing Cross Site Request Forgery?

Answer 1

+1 A:

The point is that JavaScript can't read the anti-XSRF token from a cross-domain context, and XMLHTTPRequest is same-origin only, so it cannot be used to steal the token.

If your site already has a XSS vulnerability, you're already hosed, and anti-XSRF tokens won't help you.

EricLaw -MSFT- 2009-07-02 04:37:17

Hmm, interesting. Your referring to HTTPOnly double submitted cookies, right?About XSS, true, but you don't need XSS to pull off a XSRF? The classic example is a email with either JavaScript for POSTs or an image tag for GETs.

MatthewMartin 2009-07-02 04:52:27

If a site doesn't attempt to mitigate XSRF at all, then yes, a bad guy won't need XSS to exploit it.The typical defense against XSRF is to use a one-time token, either in a form, or cookie. This defense is generally void if the site in question has an XSS vulnerability.

EricLaw -MSFT- 2009-07-06 03:06:37

Answer 2

+1 A:

Neither XmlHttpRequests nor javascript frame manipulation work cross-domain these days; that would be sheer insanity. CSRF attacks these days usually consist of either the image tag like you mentioned or autogenerating a form that POSTs to another site. However, retrieving an anti-XSRF token (presumably a cryptographic nonce generated on a per-session basis) is next to impossible. Only if it's an exceedingly poor token that doesn't check the user session and IP address could a server-side language possibly be leveraged to retrieve it and then combine it with a client-side CSRF. Aside from tokens, plenty of people stop CSRF simply by checking the referrers and blocking all remote domains. Submitting CSRF with XmlHttpRequests is virtually impossible thanks to domain restrictions.

At any rate, you don't have to worry about XmlHttpRequest being able to access a remote domain. The only time something like that could happen is if you have a XSS vulnerability, in which case, as EricLaw said, you're already hosed.

Coding With Style 2009-07-02 04:44:38

If the page is loaded from the local file system (say as the result of a malicous email), then xhr seems to be able to make posts to sites which the user is logged on to. I'm not clear on how the cross domain rules affect JS running on the local file system.

MatthewMartin 2009-07-02 04:59:01

As far as I can tell those tricks have been blocked for a while now. Moreover, if you're discussing your users downloading and running trojan horses, you really can't defend your site from that.

Coding With Style 2009-07-02 05:46:54

Answer 3

+1 A:

I think you are confused about the same-origin policy. Requesting a html page that is in a local file does not circumvent this policy. In fact, i beleive even more strict rules apply to a file resource. You will find that Javascript in a local html file will not be able to make a succesful request to retreive a non-local resource.

Modern browsers do not allow Javascript in local HTML files access to remote HTTP resources.

In which browser have you been able to succesfully perform a cross-domain XHR from a file:/// resource?

I have tested this in ie6, ie7, ie8, firefox 3, firefox 3.5 and recent versions of chrome, opera, and safari on windows; they all reject the cross-domain http request.

<html>
<head>
<script 
  type="text/javascript" 
  src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"&gt;&lt;/script&gt;
<script type="text/javascript">
  $(document).ready(function() {
    $( '#xhr' ).append( 'replace me with remote xhr' );
    $( '#xhr' ).load( 'http://stackoverflow.com/', function() {
      $( '#xhr' ).append( 'xhr load complete' );        
    });
  });
</script>
</head>
<body>
  test
  <div id="xhr">original</div>
</body>
</html>

It is possible that some much older browsers are less restrictive.

Cheekysoft 2009-07-02 09:06:20

Less "possible" and more "known fact." Before greasemonkey existed, I wrote pages that embedded remote sites in frames and modified them with javascript.

Coding With Style 2009-10-16 23:41:37

ansaurus

tags:

views:

answers:

Any logical loop holes in this idea for preventing Cross Site Request Forgery?

related questions