Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub's post-CSP journey

githubengineering.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: GitHub's post-CSP journey

#31

Post by steffenweber »

ricardobeat wrote: post #29
steffenweber wrote: post #25

If all browsers sent the "Origin" HTTP header [1] with POST requests (such that web applications could rely on it) then CSRF [2] tokens mentioned in the article would become obsolete. You'd just have to check whether the "Origin" header sent by the browser is identical to your scheme + domain name (e.g. " https://www.example.com" ) and be done. Chrome and Safari have implemented the "Origin" header long ago but unfor…

The Origin header is not as good to prevent CSRF since it's a known value. A CSRF token is a one-time value generated in the server, it's impossible to guess or get a valid one from the outside.

CSRF protection is not about attacks from evil clients (you can easily spoof any header with the HTTP client library of your choice, of course). CSRF protection is about preventing innocent / well-behaving clients from being tricked into POSTing some data on behalf of their (logged-in) user.

Re: GitHub's post-CSP journey

#32

Post by gcp »

steffenweber wrote: post #25

If all browsers sent the "Origin" HTTP header [1] with POST requests (such that web applications could rely on it) then CSRF [2] tokens mentioned in the article would become obsolete. You'd just have to check whether the "Origin" header sent by the browser is identical to your scheme + domain name (e.g. " https://www.example.com" ) and be done. Chrome and Safari have implemented the "Origin" header long ago but unfor…

"It's probably worth reading through https://github.com/w3c/resource-timing/issues/64 and the proposal I linked above. In short, it's not clear that implementing the Origin header the way Chrome supports it actually helps with CSRF and it makes it harder (impossible really) to distinguish CORS requests."

Seems Firefox will implement it anyway because it's still better than nothing.

Re: GitHub's post-CSP journey

#33

Post by laurent123456 »

pixdamix wrote: post #28
joshschreuder wrote: post #27

Can someone explain more about how the Gravatar example would work? How would the attacker embed a dangling markup on Github.com? If they could do that, couldn't they just use a standard XSS attack by embedding arbitrary HTML?

CSP mitigates the risks of XSS attacks. If you look at : https://cspvalidator.org/#url=https://github.com you'll see that the CSP policy directive defines the origins from which images can be loaded 'self' data: assets-cdn.github.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com ; Previously, images could have been loaded from additional domains (gravatar) and cou…

What I don't understand is how the image URL ends up in a non-closed img src attribute. They might be getting the URL from a third party:

  https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f
But GitHub is the one opening and closing the tag, probably in some kind of template:

  
  
secret
Which should result in this:

  
  
secret
and not this:

  secret
Any idea why they are getting the latter?

Re: GitHub's post-CSP journey

#35

Post by ricardobeat »

steffenweber wrote: post #31
ricardobeat wrote: post #29

Earlier quoted context omitted.

The Origin header is not as good to prevent CSRF since it's a known value. A CSRF token is a one-time value generated in the server, it's impossible to guess or get a valid one from the outside.

CSRF protection is not about attacks from evil clients (you can easily spoof any header with the HTTP client library of your choice, of course). CSRF protection is about preventing innocent / well-behaving clients from being tricked into POSTing some data on behalf of their (logged-in) user.

Yes. Forwarding a unique CSRF token from the backend gives you some assurance that it's a legitimate request, initiated from a pageview within a timeframe. A header (origin) which always has the same value (the hostname) is inherently less secure, though I overstated how much in the previous comment.

Re: GitHub's post-CSP journey

#36

Post by steffenweber »

gcp wrote: post #32
steffenweber wrote: post #25

If all browsers sent the "Origin" HTTP header [1] with POST requests (such that web applications could rely on it) then CSRF [2] tokens mentioned in the article would become obsolete. You'd just have to check whether the "Origin" header sent by the browser is identical to your scheme + domain name (e.g. " https://www.example.com" ) and be done. Chrome and Safari have implemented the "Origin" header long ago but unfor…

"It's probably worth reading through https://github.com/w3c/resource-timing/issues/64 and the proposal I linked above. In short, it's not clear that implementing the Origin header the way Chrome supports it actually helps with CSRF and it makes it harder (impossible really) to distinguish CORS requests." Seems Firefox will implement it anyway because it's still better than nothing.

The conclusion of this discussion seems to be that "SameSite" cookies should be used to help preventing CSRF.

https://www.igvita.com/2016/08/26/stop-cross-site-timing-att...

Re: GitHub's post-CSP journey

#37

Post by scrollaway »

laurent123456 wrote: post #33
pixdamix wrote: post #28

Earlier quoted context omitted.

CSP mitigates the risks of XSS attacks. If you look at : https://cspvalidator.org/#url=https://github.com you'll see that the CSP policy directive defines the origins from which images can be loaded 'self' data: assets-cdn.github.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com ; Previously, images could have been loaded from additional domains (gravatar) and cou…

What I don't understand is how the image URL ends up in a non-closed img src attribute. They might be getting the URL from a third party: https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f But GitHub is the one opening and closing the tag, probably in some kind of template: secret Which should result in this: secret and not this: secret Any idea why they are getting the latt…

They weren't getting the latter, they specifically went in there looking to mitigate what a theoretical content injection attack could do.

> In a relatively unique project, we asked Cure53 to assess what an attacker could do, assuming a content injection bug in GitHub.com

Re: GitHub's post-CSP journey

#38

Post by losvedir »

ricardobeat wrote: post #29
steffenweber wrote: post #25

If all browsers sent the "Origin" HTTP header [1] with POST requests (such that web applications could rely on it) then CSRF [2] tokens mentioned in the article would become obsolete. You'd just have to check whether the "Origin" header sent by the browser is identical to your scheme + domain name (e.g. " https://www.example.com" ) and be done. Chrome and Safari have implemented the "Origin" header long ago but unfor…

The Origin header is not as good to prevent CSRF since it's a known value. A CSRF token is a one-time value generated in the server, it's impossible to guess or get a valid one from the outside.

Can you expand on the threat model here? After noodling a bit I can't think of an attack that CSRF prevents that an origin header wouldn't, but obviously that doesn't mean there isn't one. Be real curious to hear of one!

Re: GitHub's post-CSP journey

#39

Post by sb8244 »

jaredsohn wrote: post #2

The article says CSP seven times in the first two paragraphs without saying what it stands for; it would be much more readable if they did. (It stands for content security policy for those wondering.)

The first sentence is a link to a blog post with an in depth introduction to what they are talking about.

No child comment on here seems to have pointed it out. Surely that is acceptable considering the level of detail they go into in their original post?

Re: GitHub's post-CSP journey

#40

Post by mwexler »

While I'm not a security expert, seeing the various ways that someone can steal info from a site even after all the protections GitHub put into place was fascinating, and does bring back the old concern: if a site as large and respected as GitHub has to do all this work and still encounters exploits, what can an average person do who might run ad scripts, a tracking script, and a few helper scripts from various sites? And how can tools try to put in more protections for average folks (cough, wordpress)?

If you liked this, btw, worth reading some content from their pentester https://cure53.de/ which also had some interesting findings and links.

Post reply on HN