Hacker News Reader

Comment by spamizbad | Hacker News Reader

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?

View on HN

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 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_%...

are the contents of an iframe open from another domain available to you?

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).as...

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.

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

lol it's just funny trick 4 lulz. It has nothing to do with future stuff

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?

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.

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.

Ah you are correct, forgot about that. Thanks for this point.

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

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.

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.

Reply on news.ycombinator.com