If the tokens are not hidden, I think the attacker can load the exploited site in an iframe, but he won't be able to access the token because of same-origin-policy (SOP).
Is this correct, or are there other ways of accessing CSRF tokens?
-
1Great question. I am also curious about the answer. – Mike Ounsworth Jul 11 '17 at 19:51
-
I'm interested as well. – ISMSDEV Jul 11 '17 at 19:52
-
I think you have to make sure your site cannot be loaded in an iframe in order for it to work. – Thomas Jul 11 '17 at 20:01
-
What do you mean by "hidden"? This sounds like security by obscurity. – symcbean Aug 11 '17 at 11:25
You cannot hide or encrypt your CSRF token, as it is usually passed to the web application in HTTP GET or HTTP POST request and it should be present on HTML page (or generated by JavaScript, which is basically the same).
CSRF-token is only one way to protect your web application against auto submissions (aka CSRF attack). Its usage is recommended when dealing with not very sensitive data. If you want to protect your web application against CSRF with CSRF token, I recommend you generate a new token at least every 15-20 minutes, so it cannot be easily brute-forced.
In many real-world implementations CSRF token is bound to session identifier. The same advice is valid for session identifier as well.
As for SOP, it should not allow by default to access elements within iframes. However, there have been vulnerabilities in many browsers in the past, which allowed this behavior.
The bottom line – you do not have to hide CSRF token. Instead, generate a new one once in a while. For very sensitive actions use additional means of user verification, e.g. request for user's password or use OTP.
Hidden? I prefer to say communicated securely where only the user has access to the token. If there is a malicious iframe on your site (maybe an evil ad or better yet an invisible iframe) you should still be protected by SOP as long as you didn't make a bad configuration with Cross Origin Resource Sharing.
I also want to add as a caveat that older browsers (even a year ago) had some exploits that allowed you to get out of the SOP. This isn't by design!
The CSRF token doesn't need to be hidden on the html page, but it should be encrypted during transit to prevent a MITM situation where the attacker sniffs the CSRF token and makes a form submission on your behalf. This type of attack typically involves making form submissions using an authenticated user's session.
If an attacker loads the site with a CSRF protected form into an iframe, then that site has a problem with it's CSP response headers. Mainly, the site is missing a securely configured X-Frame-Options directive.
-
While all pages should use SSL, if an attacker is in a MITM scenario, he/she can post data on the user's behalf without using CSRF. – Dan Landberg Aug 11 '17 at 13:58
