5 ms·

I'm having a little trouble parsing this post. Is he saying he's discovered a variant of CSRF that cannot be stopped by using the Synchronizer Token Pattern?

I'm having a little trouble parsing this post. Is he saying he's discovered a variant of CSRF that cannot be stopped by using the Synchronizer Token Pattern? Or has he found something that a lot of site's protection patterns don't follow?

homakov 15y ago
nope. Token Pattern is ugly workaround browsers' vulnerability - that's the point.
- spamizbad 15y ago
  You know more about this stuff than me, but I always assumed it was the cost of using the HTTP protocol due to its stateless nature. Even if browsers "fix" this issue, you're still placing a measure of trust in the client by not implementing server-side protections.
  - tptacek 15y ago
    He is incorrect on this point. Authentication of requests is not an "ugly workaround" to a browser security issue. The browser isn't just doing what it's "supposed to be doing" (always a flimsy argument in favor of the status quo, I agree!) but also all it can do, since only the server has the information needed to judge how sensitive a request is. It's true that servers & browsers work together to create a semblance of a security model for the web. But the bulk of the job belongs to the server; there are hundreds of thousands of different applications each with different needs. And the servers have a means of enforcing controls flexibly: by authenticating requests. The browser isn't protecting your email. The server is. The browser isn't protecting your bank account. The server is. The browser isn't protecting your HN karma. The server is. The browser isn't protecting your code repository. The server is. No simple HTTP standard will cover all these cases, and so it's silly to suggest that HTTP is where this security controlled should be expressed.
epimenov 15y ago
he discovered that you can log out from google via a GET request (surprise!)
- homakov 15y ago
  lol it's just funny trick 4 lulz. It has nothing to do with future stuff
- ceol 15y ago
  Specifically, <img src="https://mail.google.com/mail/u/0/?logout" style="display: none;"> When your browser loads the page, it requests that "image", which logs you out. I don't see a way browsers could effectively enable CSRF protections. How is it supposed to know you don't want to request that page as an image? What about sites linking to images on other domains? CDNs would be blocked, because how is Chrome supposed to know you actually wanted to load the image from fbcdn.net or s3.amazonaws.com?
  - f055 15y ago
    You can prevent the iframe CSRF with X-Frame-Options: SAMEORIGIN I suppose? - maybe browser could implement X-Image-Options: SAMEORIGIN as well - kind of a hotlinking prevention header.
    - nbpoole 15y ago
      That prevents the result from being displayed, it doesn't prevent the request from being made. The distinction is subtle but hugely important. In other words, the browser makes the request, gets the response, and doesn't render it. The server doesn't know that the browser didn't render it: it treats it like any other request.
      - f055 15y ago
        Ah you are correct, forgot about that. Thanks for this point.
huhtenberg 15y ago
You seem to be familiar with the subject. I just read through CSRF and Token stuff on [1] and there's one thing I don't seem to understand. What would prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at http://bank/operations/move-funds http://bank/operations/move-funds that contains a fund transfer form. Wouldn't this page include a correct CSRFToken, making the form readily submittable by a malicious script? [1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...
- aaronblohowiak 15y ago
  are the contents of an iframe open from another domain available to you?
- njs12345 15y ago
  This is prevented by only allowing frames to interact with each other if they're on the same domain. See (for instance) http://msdn.microsoft.com/en-us/library/ms533028(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ms533028(v=vs.85).as...
- lojack 15y ago
  Usually with banks, they will require that users enter their password for important requests. Additionally, servers can use the X-Frame-Options to prevent their website from being displayed in an iframe.
- deleted 15y ago
  [deleted]

homakov 15y ago

nope. Token Pattern is ugly workaround browsers' vulnerability - that's the point.

spamizbad 15y ago
You know more about this stuff than me, but I always assumed it was the cost of using the HTTP protocol due to its stateless nature. Even if browsers "fix" this issue, you're still placing a measure of trust in the client by not implementing server-side protections.
- tptacek 15y ago
  He is incorrect on this point. Authentication of requests is not an "ugly workaround" to a browser security issue. The browser isn't just doing what it's "supposed to be doing" (always a flimsy argument in favor of the status quo, I agree!) but also all it can do, since only the server has the information needed to judge how sensitive a request is. It's true that servers & browsers work together to create a semblance of a security model for the web. But the bulk of the job belongs to the server; there are hundreds of thousands of different applications each with different needs. And the servers have a means of enforcing controls flexibly: by authenticating requests. The browser isn't protecting your email. The server is. The browser isn't protecting your bank account. The server is. The browser isn't protecting your HN karma. The server is. The browser isn't protecting your code repository. The server is. No simple HTTP standard will cover all these cases, and so it's silly to suggest that HTTP is where this security controlled should be expressed.

epimenov 15y ago

he discovered that you can log out from google via a GET request (surprise!)

homakov 15y ago
lol it's just funny trick 4 lulz. It has nothing to do with future stuff
ceol 15y ago
Specifically, <img src="https://mail.google.com/mail/u/0/?logout" style="display: none;"> When your browser loads the page, it requests that "image", which logs you out. I don't see a way browsers could effectively enable CSRF protections. How is it supposed to know you don't want to request that page as an image? What about sites linking to images on other domains? CDNs would be blocked, because how is Chrome supposed to know you actually wanted to load the image from fbcdn.net or s3.amazonaws.com?
- f055 15y ago
  You can prevent the iframe CSRF with X-Frame-Options: SAMEORIGIN I suppose? - maybe browser could implement X-Image-Options: SAMEORIGIN as well - kind of a hotlinking prevention header.
  - nbpoole 15y ago
    That prevents the result from being displayed, it doesn't prevent the request from being made. The distinction is subtle but hugely important. In other words, the browser makes the request, gets the response, and doesn't render it. The server doesn't know that the browser didn't render it: it treats it like any other request.
    - f055 15y ago
      Ah you are correct, forgot about that. Thanks for this point.

huhtenberg 15y ago

You seem to be familiar with the subject. I just read through CSRF and Token stuff on [1] and there's one thing I don't seem to understand. What would prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at http://bank/operations/move-funds http://bank/operations/move-funds that contains a fund transfer form. Wouldn't this page include a correct CSRFToken, making the form readily submittable by a malicious script? [1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...

aaronblohowiak 15y ago
are the contents of an iframe open from another domain available to you?
njs12345 15y ago
This is prevented by only allowing frames to interact with each other if they're on the same domain. See (for instance) http://msdn.microsoft.com/en-us/library/ms533028(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ms533028(v=vs.85).as...
lojack 15y ago
Usually with banks, they will require that users enter their password for important requests. Additionally, servers can use the X-Frame-Options to prevent their website from being displayed in an iframe.
deleted 15y ago
[deleted]