6

So I know there are a lot of questions about CSRF (because I have read some of them) but there is one point I still don't understand. Let's imagine the following case:

  1. I am logged in(with cookies) on my server where there is a page with a button 'Delete my account'. Which I don't want to press.

  2. I visit a hacker's server:

    a. My browser requests 'bad.html', which contains JS, with a callback function defined. It also has a script like:(thus avoiding the Same-Origin Policy problem)

    var s = document.createElement('script'); 
    s.src = 'url to "deleteAccountPage" of my server?'
    s.src += 'callback=hackerCallback'; 
    s.type = 'text/javascript';
document.body.appendChild(s);

    b. Script is "appended" the browser will load the page and then call hackerCallback passing the page HTML text as parameter.

    c. With this HTML, the callback can parse the token in there.

  3. The hackerCallback now has the token, sends an Ajax request to my server on the "deleteMyAccount" page.

  4. My account is now deleted, because the Token, the cookies and even the browser trace matches the ones registered by the server.

How do you avoid that behaviour ? I have read things about only allowing certain Headers on my server. This would cut short all Cross-Domain request on my server, however according to this link (http://blog.alexmaccaw.com/jswebapps-csrf) it is not enough... (Which I totally believe)

Thansk for the help Seba-1511

seba-1511
  • 71
  • 5
  • did you ever figure this out? can you explain callback=hackerCallback a little more? what do expect the delete page to do with the "callback" query string parameter? certainly the delete page shouldn't just execute any javascript that's passed in through the uri. – Alexander Taylor Mar 06 '15 at 07:09
  • No, did not figure this out yet. callback=hackerCallback specifies the function that will be called once the response is returned to the user. (It will be executed by the browser, not the server) This allows the hacker to parse the returned page from the original server, and thus get the correct token to by-pass the CSRF security mechanism. – seba-1511 May 02 '15 at 01:37
  • Can you furnish the example with domains? e.g. `s.src = "http://www.example.com/deleteAccountPage.html?"` `http://www.evil.com/bad.html` It appears like the `hackerCallback` is a JS function on `evil.com`, am I right? – light Apr 27 '19 at 12:24

1 Answers1

0

You are using JSONP in order to make a cross domain request via a scr tag. The JSONP is only allowed for GET requests and you shouldn't have GET endpoints that make changes (not idempotent).

deleteAccount should be a POST endpoint that couldn't be requested via JSONP.

If you insist in use GET on deleteAccount you should use CSRF tokens or send the token in a header instead of a cookie (if you're using XHR requests)

gabrielgiussi
  • 9,245
  • 7
  • 41
  • 71