171–180 of 256 posts
Earlier quoted context omitted.
There's an info now at the top of the post > To stir up your interest - check any google service e.g. gmail, you are logged out. Great hook btw. Even more impressively, I have all js on his blog blocked through NoScript and it still worked.
I don't run any JS. It's just an image:D
CSRF isn't a browser vulnerability. It's a serverside application vulnerability. To say otherwise is to say there there is some trivial policy, just an HTTP header away, that would allow IE, Firefox, and Webkit to coherently express cross-domain request policy for every conceivable application --- or to say that no FORM element on any website should be able to POST off-site (which, for the non-developers on HN, is an…
It's clear that developers need a simple way to specify that a piece of API should not be accesible from third-party sites. I propose a new set of HTTP verbs, "SECPOST", "SECGET", etc that comes with the implication that it is never intended to be called by third-party sites or even navigated to from third-party sites. It is a resource that can only be called from the same origin. Application developers (and framewor…
First, every mainstream web framework already comes with a simple-to-use way to block forged requests. Even if we adopted new HTTP verbs to give them a common name in the protocol, by the time developers are making decisions they're not working with the ALL-CAPS-NAMES-OF-HTTP-VERBS anyways.
Second, there isn't anything inherently "cross-site" about CSRF, so denying off-site POSTs isn't a complete solution to the problem either. Every site that accepts any form of user-generated content must deal with intra-site request forgery as well.
So no, I don't think that's a great idea.
The things that are insecure here are serverside web applications. Changes to the HTTP protocol or to browsers are a red herring. There's no way around it: web developers have to figure out how to write secure code.
CSRF isn't a browser vulnerability. It's a serverside application vulnerability. To say otherwise is to say there there is some trivial policy, just an HTTP header away, that would allow IE, Firefox, and Webkit to coherently express cross-domain request policy for every conceivable application --- or to say that no FORM element on any website should be able to POST off-site (which, for the non-developers on HN, is an…
If a form is served from domain A (via GET) in to an iframe on a page that was served from domain B, then the JS on the page from domain B is prevented from reading or writing data on the page from domain A (unless an x-domain policy is in place) though it may be able to post it.
CSRF isn't a browser vulnerability. It's a serverside application vulnerability. To say otherwise is to say there there is some trivial policy, just an HTTP header away, that would allow IE, Firefox, and Webkit to coherently express cross-domain request policy for every conceivable application --- or to say that no FORM element on any website should be able to POST off-site (which, for the non-developers on HN, is an…
Earlier quoted context omitted.
It's not that the referer header is not "enough". "Enough" implies that it falls somewhere on the scale of trustworthiness. It's user input. Don't trust user input.
Why shouldn't you trust user-provided data to secure the same user's data? The potential attack is someone forging their own referer header in order to attack themself.
Earlier quoted context omitted.
Why shouldn't you trust user-provided data to secure the same user's data? The potential attack is someone forging their own referer header in order to attack themself.
The referer header can easily be forged. The whole point of a CSRF attack is to turn a user's credentials against him.
Just in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom). Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).
There's an info now at the top of the post > To stir up your interest - check any google service e.g. gmail, you are logged out. Great hook btw. Even more impressively, I have all js on his blog blocked through NoScript and it still worked.
Site ALL
Accept INCLUSION(XHR, SUBDOC) from SELF++
Anon INCLUSION
Just in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom). Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).
Looks that Google detects the type of logout and doesn't ask for two-factor authentication in this case.
Earlier quoted context omitted.
I don't want the legitimate uses prevented. The default behavior should be to prevent, and the legitimate uses should explicitly opt-in. That way, you only have to do security analysis for those explicit points.
This to me is a server side issue- but that doesn't necessarily mean it's on the app developer. The behavior you're talking about can be set most servers directly, by adding the "X-Frame-Options" header into every request by default. Then exceptions would have to be made explicitly, by either the server admin or application developer. If anyone should change the default behavior (which I am not convinced is the case)…
So, in the context of this discussion, why don't the browsers make X-Frame-Origin: DENY the default behavior?????
Earlier quoted context omitted.
But he didn't access Google's systems, your browser did. You requested the page, and your browser dutifully loaded the cross-site request image.
He provided instructions to my browser without my consent, the exact same way he would have if he had done it from his computer. How far are we willing to take the semantics here? I guess a lot of people disagree with this? To clarify, I don't think this guy's guilty of a felony-- to my knowledge computer fraud requires at least some malicious intent or damage. But you seriously think if somebody used CSRF to drain y…
If that is considered 'without your consent', then so is every site that is embedding external plugins, images, and videos.
How are you supposed to 'give your consent'? Must you be given a list of all the content on the website before the browser will be allowed to display it?
When you requested the page, you gave your consent to load whatever was on that page. If you don't want that, then you should use wget instead of a browser.