4

I read this post Understanding CSRF - Simple Question But I still do not understanding how the CSRF token can prevent a CSRF token.

The main problem which confused me is that why the attacker can make any http request to my site, but he cannot read back the response?

1、If I post a http request to get token before every post request, attacker also can make an "get token" request to get token.

2、If I set token to the hidden input while the .html page is loading, attacker also can make a "get html" request to get the this .html page and read the value of hidden page.

I just don't understand why the attacker can make request but can not read the response?

Community
  • 1
  • 1
Skyline
  • 53
  • 4
  • Attacker cannot make a "get html" request, because since the two pages don't share the same domain name, the browser would reject the request and fail with an error. Try it. – Pacerier Jun 04 '13 at 13:19

1 Answers1

2

The attacker cannot make the request himself at all. What he can do is trick his victim (or the victim's browser) to make that request. So any response would go back to the victim's browser, too.

The problem here is that the attacker can choose the URL, and even without seeing any response, accessing that URL may have harmful consequences for the victim.

The reason why the attacker needs to trick the victim into making the request (as opposed to just accessing the URL himself) is that if the victim does it, the victim's session cookies will also be sent along, so it looks like an authenticated action for the server.

If I set token to the hidden input while the .html page is loading, attacker also can make a "get html" request to get the this .html page and read the value of hidden page.

The attacker can only get a hidden input for his own session, not for the victim's session. This hidden input will be different from session to session (otherwise there is not point).

The CSRF token makes sure that every (critical) request includes a random piece of data that must match the user's session. This way, an attacker cannot just guess what the complete URL would be, and trick someone into clicking on it.

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • You said that the hidden input will be different from session to session,but if I login http://qqx.com(for example), then I open http://qqx.com/XXX.html in a new IE tab, which belong to qqx.com, it shows I was login , doesn't this means the session in qqx.com is the same as in qqx.com/XXX.html? – Skyline Jul 02 '12 at 06:41
  • *You* opened a new tab. Now try that on your friend's computer, with you friend's user id. He will see a different token value (I hope ...) The CSRF attacker will not be able to come to your house and open tabs on your computer. If he could do that, he can use all kinds of even more dangerous attacks. – Thilo Jul 02 '12 at 08:00
  • My website only allow one user to login at the same time..my testing steps is: 1.make a html page including javascript,once user access this page, it can post request,just call it "bad website", 2.login to my website,now the session and cookie is created, 3.now access the "bad website",the script is executing and can post request successfully. – Skyline Jul 02 '12 at 08:59
  • and where does the CSRF token come in? How can the "bad website" post a request that contains the CSRF token? – Thilo Jul 02 '12 at 09:01
  • I create a API "getCSRFToken.php", when user execute "post getCSRFToken.php", it can return the token value. Maybe I should not provide this API because every body can execute this API to get token, I should generate the token when the html loading and storage in the hidden input. – Skyline Jul 02 '12 at 09:17
  • I preferred to generate token when the html loading,but there is a problem.In my website, if user create an entry, it will create a form div.If different form must have different token, I must get token dynamic,so I have to create the "gettoken" API, this will be dangerous,because every body can get token and post data. – Skyline Jul 02 '12 at 09:28