[deleted]
#1 CSRF Is A Vulnerability In All Browsers
151–160 of 256 posts
Re: #1 CSRF Is A Vulnerability In All Browsers
#152Am I correct in interpreting that the proposed fix would the be the same as the functionality provided by RequestPolicy (which he mentions in the post)? I've used it for quite a while now, and although it works well for me as a power-user (who is concerned about security), I can't imagine the confusion and pain a user will feel despite the message suggested. Blocking resources loaded over separate domains breaks a lo…
As my other comment highlighted, disabling 3rd party cookies will prevent most CSRF. As an added bonus it will also increase your privacy by preventing some (but not all) cross domain tracking.
I'm not following (but I'm a little buzzed). What do third-party cookies have to do with CSRF? CSRF is a flaw in the victim application.
Re: #1 CSRF Is A Vulnerability In All Browsers
#153This attack vector requires:
1) previous authentication to a service.
2) service which supports destructive actions as guessable URLs.
3) "third-party cookie" support in the user agent. [1]
4) a visit to a page with a malicious resource construct (an image, script, iframe, external style sheet, or object). Note that this resource could be generated by JavaScript, although this is not necessary.
Sadly, the first three criteria are widely met. If we are to systematically remove this threat, then we have to look at removing each in turn:
1) Previous authentication to a service can be mitigated by simply logging out when you are done, but this is inconvenient and requires manual user intervention. However, there is an interesting possibility to limit "important" services to a separate process - a browser, an "incognito" window, etc.
2) Services should be built with an unguessable component that is provided just prior to calling by a known-good API, probably with additional referrer verification.
3) It is my belief that disabling third-party cookies is the right solution here: users rarely, if ever, get value from third-party cookies. Denying them would allow API authors to write simpler APIs that do not have a secret component, and would allow users to maintain the same behavior and login to all their services from the same browser.
4) While it seems that little can be done on this front apart from releasing some chemical agent into the atmosphere that made people trustworthy and good, actually it may be possible for browser makers to do some simple analysis of resource URLs to detect possible hanky-panky.
[1] https://en.wikipedia.org/wiki/HTTP_cookie#Privacy_and_third-...
Re: #1 CSRF Is A Vulnerability In All Browsers
#154Earlier quoted context omitted.
I have no problem with cross-site GET requests because I know GETs should behave as 'read-only' anyway for lots of reasons. What I don't get is how arbitrary cross-site POSTs with malicious values are allowed. As far as I can tell, anyone can post this form: http://bank.com/send_money> name="to_account" value="SCAMMER-1234"> Worse, one article will tell you to only allow Referrer == "bank.com", and then another will…
Browsers don't prevent it because there are legitimate uses for cross-domain posts. Good frameworks do prevent it with CSRF tokens.
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.
Re: #1 CSRF Is A Vulnerability In All Browsers
#155Earlier quoted context omitted.
Another clarification: He wasn't making noises for a long time with _GitHub_ and being ignored. His support responses were replied to nearly immediately (except where the timezone differences came into play). We take security reports very seriously. We'd have preferred a more responsible disclosure, and I hope he (and others) are more careful about this in the future. Most reporters we get act very responsible, and w…
I'm sorry, but why should he? If I find a major hole in SHA1 key handling, should I contact GitHub since you are users of it? Of course not.
"SHA1 key handling"?
Anyways, you misread him. All he's saying is that the delay Egor Homakov experienced was with the Rails dev team, not Github. Github's response to Homakov's finding was very fast.
Re: #1 CSRF Is A Vulnerability In All Browsers
#156This attack vector requires: 1) previous authentication to a service. 2) service which supports destructive actions as guessable URLs. 3) "third-party cookie" support in the user agent. [1] 4) a visit to a page with a malicious resource construct (an image, script, iframe, external style sheet, or object). Note that this resource could be generated by JavaScript, although this is not necessary. Sadly, the first three…
Third party cookie support isn't necessary. You could just use a link instead of an image.
Re: #1 CSRF Is A Vulnerability In All Browsers
#157[deleted]
Re: #1 CSRF Is A Vulnerability In All Browsers
#158Earlier quoted context omitted.
His relatively harmless change demonstrated a Major Security Vulnerability in the site that hosts thousands of companies secure code.
And got it fixed. Security vulnerabilities aren't the sort of things that go away just because you don't know they're there.
From experience: had he simply told Github about it, they would have fixed it quickly, and there would have been no window of public exposure. That's the point being made here.
Re: #1 CSRF Is A Vulnerability In All Browsers
#159Earlier quoted context omitted.
The difficulty is how to deny this happening. Pages making GET requests across domains is so common and necessary that several technology standards would have to come together to propose a real fix. Every image or script loaded from a CDN. Anyone hosting their own static assets domains. Anyone using a plugin from Google, Facebook, Twitter, Disqus uses this ability. The tech companies can't even easily create a system…
I have no problem with cross-site GET requests because I know GETs should behave as 'read-only' anyway for lots of reasons. What I don't get is how arbitrary cross-site POSTs with malicious values are allowed. As far as I can tell, anyone can post this form: http://bank.com/send_money> name="to_account" value="SCAMMER-1234"> Worse, one article will tell you to only allow Referrer == "bank.com", and then another will…
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.
Re: #1 CSRF Is A Vulnerability In All Browsers
#160Earlier quoted context omitted.
Browsers don't prevent it because there are legitimate uses for cross-domain posts. Good frameworks do prevent it with CSRF tokens.
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.
But there's existing code that would break.