GitHub's post-CSP journey • Hacker News Board

Re: GitHub's post-CSP journey

#21

Post by Sacho » Fri, Jan 20, 2017, 7:30 AM UTC

niftich wrote: post #18

dfc wrote: post #8

Earlier quoted context omitted.

At a certain point you need to set a baseline expectation of your audience in order to communicate effectively. Do you think they should also explain exploitation, img-src, the mechanics of parsing unmatched quotes, javascript or CSRF? The target audience of the article knows what CSP stands for and most likely has been reading the other entries along this journey.

I think this comment raises a very good point and I struggle to see sure why it's proving so unpopular so far. It's true that the submitted blog post doesn't expand the CSP initialism -- this has been acknowledged as an oversight by the author and the post will be edited, as it's simply good practice as recommended in several style guides [1][2][3][4]. But the post's very first sentence links to a previous entry abou…

I think your comment is much more reasonable than parent; I too wondered what CSP they were talking about so I clicked the first link, and figured it out(after scrolling through several paragraphs). However, parent asserted that the audience here was not up to the level to read the author, when actually, the confusion was an overloaded acronym.

Re: GitHub's post-CSP journey

#22

Post by [deleted] » Fri, Jan 20, 2017, 8:33 AM UTC

wsh91 wrote: post #3

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

To that end, it might be worth spelling out in the title here. I got my hopes up thinking it was about https://en.wikipedia.org/wiki/Communicating_sequential_proce... .

[deleted]

Re: GitHub's post-CSP journey

#23

Post by skrebbel » Fri, Jan 20, 2017, 8:34 AM UTC

ptoomey3 wrote: post #9

sethammons wrote: post #4

Earlier quoted context omitted.

Ditto

Apologies for that not being clear. Given I had linked to the original article in the first sentence, I took the perspective of people knowing which "CSP" I was talking about. I'll update the post in the morning to spell/link out to the first CSP reference.

If you ever have a post-Communicating Sequential Processes journey at GitHub, please do write a post! Most people I know are moving to something CSP based (say, Go channels) so it would be very cool to understand why someone would consciously decide to ditch the concept again, after a serious engineering effort.

Re: GitHub's post-CSP journey

#24

Post by db48x » Fri, Jan 20, 2017, 9:08 AM UTC

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

Heh, I was slightly confused at first, then very confused when I got to "post-CSP exploitation". Trying to come up with a plausible meaning for that phrase is an interesting exercize.

Re: GitHub's post-CSP journey

#25

Post by steffenweber » Fri, Jan 20, 2017, 9:24 AM UTC

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 unfortunately Firefox [3] and Edge [4] have not yet done so.

The "Origin" header is similar to the "Referer" header but never contains the path or query. Furthermore, CSRF protection requires it only for "POST" requests (i.e. "GET" requests are unaffected). So there is little incentive for an option disable it for privacy concerns.

[1] https://tools.ietf.org/html/rfc6454

[2] https://en.wikipedia.org/wiki/Cross-site_request_forgery

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=446344

[4] https://developer.microsoft.com/en-us/microsoft-edge/platfor... (filed by me)

Re: GitHub's post-CSP journey

#26

Post by technion » Fri, Jan 20, 2017, 9:29 AM UTC

CSP is more of a landmine than we give it credit for. It tripped up Troy Hunt:

https://www.troyhunt.com/how-chromes-buggy-content-security-...

I had a very similar experience, and I'm still hunting for the specifics of the browser that caused it in my case.

Re: GitHub's post-CSP journey

#27

Post by joshschreuder » Fri, Jan 20, 2017, 9:39 AM UTC

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?

Re: GitHub's post-CSP journey

#28

Post by pixdamix » Fri, Jan 20, 2017, 9:57 AM UTC

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 could have been used to leak CSRF tokens.

Re: GitHub's post-CSP journey

#29

Post by ricardobeat » Fri, Jan 20, 2017, 10:33 AM UTC

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.

Re: GitHub's post-CSP journey

#30

Post by dividuum » Fri, Jan 20, 2017, 10:52 AM UTC

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.

Not sure I follow your reasoning: CSRF requires a browser, as that's where you'll find a logged-in user that you want to force into doing something without their knowledge. The network layer is already protected by HTTPS. Some browser plugin might modify the header, at which point the whole exercise is pointless anyway as you can't trust the client in that case. Happy to learn where I'm wrong.