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

41–50 of 60 posts

Re: GitHub's post-CSP journey

#41

Post by skj »

peteretep wrote: post #17
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.

You are getting downvoted because in complaining we are below your technical baseline, you've ironically revealed you're not familiar with the rather more interesting CSP.

As one of the more prominent gophers out there, dfc is quite familiar with communicating sequential processes.

That said, I disagree with his original point. I am a regular HN reader and did not know about content security policy.

Re: GitHub's post-CSP journey

#42

Post by skj »

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…

In my opinion, it is good writing style to expand technical acronyms with their first use in any publication.

It's certainly the rule for academic writing.

Re: GitHub's post-CSP journey

#43

Post by ptoomey3 »

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…

Yes, the attack assumes a content injection bug in GitHub.com. The attack is not using our own gravatar URL generation against us; it is the attacker crafting an arbitrary URL and using that URL inside of an arbitrary image tag. The reason for the attacker being "forced" to use a gravatar URL is that it was one of the very few third-party hosts we previously allowed by our CSP policy. So, the attack demonstrates how this previously allowed host could be used to exfiltrate sensitive content if/when an attacker found a way to inject arbitrary HTML into a page on GitHub.com.

Re: GitHub's post-CSP journey

#44

Post by Eridrus »

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.

It boils down to how much you trust browsers to implement this without fucking up. In the past trusting browsers to get it right was a questionable idea, with Flash being a particularly reliable weak point which caused Rails to change how they do CSRF protection. I'm not sure Adobe ever fully fixed the issue in all browsers.

Nonces have the benefit of only relying on browsers preventing cross-domain reads.

When Flash is deprecated, and if a site wants to use CSP, then this might start looking like a better trade off.

ATM though, nonces can be automatically added to all same domain forms on your site with JavaScript and you can check it trivially on all POST requests, getting most of the non-CSP related benefits without waiting on browsers.

And even if browsers were to implement it, there is still a long tail of browsers out there that will take forever to update.

Re: GitHub's post-CSP journey

#45

Post by LamaOfRuin »

skj wrote: post #41
peteretep wrote: post #17

Earlier quoted context omitted.

You are getting downvoted because in complaining we are below your technical baseline, you've ironically revealed you're not familiar with the rather more interesting CSP.

As one of the more prominent gophers out there, dfc is quite familiar with communicating sequential processes. That said, I disagree with his original point. I am a regular HN reader and did not know about content security policy.

I did already know about content security policy. I still wasn't certain that's what the article was referring to without reading several paragraphs of the two articles.

Re: GitHub's post-CSP journey

#46

Post by ChoGGi »

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

Well, it's obviously the Canadian Ski Patrol.

Re: GitHub's post-CSP journey

#47

Post by tannhaeuser »

Awesome article and thumbs up to github.

I'm having great reservations towards CSP however. I think it breaks the web in a way that wouldn't have been necessary had we been a little bit more careful about HTML syntax rather than dismissing markup validation as an obsolete technique back when the vulgar "HTML 5 rocks" campaigns were in full swing.

CSP spec drafts have been around forever but were never finalized. CSP basically blocks execution of JavaScript in script tags in content (as opposed to script in the header), as well as in content handler attributes (onclick and co.) by disabling those alltogether on a page. This totally breaks page composibility where you assemble content at the markup stream level from multiple sources, like, say on every single news aggregation site. The removal of scoped CSS styles from HTML similarly breaks composition.

From Chrome's Content Security Policy page:

[Blocking inline script] does, however, require you to write your code with a clean separation between content and behavior (which you should of course do anyway, right?)

I think this comment is totally clueless wrt. what the Web is about. "Separation of concerns" is most certainly not a characteristic of the Web, and never has been.

I'm sorry, but rather than using kludges such as CSP to turning the lights off with a broad brush, how about fixing HTML and JavaScript in the first place?

(note my comment isn't addressed at github but at web standard comitees)

[1]: https://developer.chrome.com/extensions/contentSecurityPolic...

Re: GitHub's post-CSP journey

#48

Post by jerf »

tannhaeuser wrote: post #47

Awesome article and thumbs up to github. I'm having great reservations towards CSP however. I think it breaks the web in a way that wouldn't have been necessary had we been a little bit more careful about HTML syntax rather than dismissing markup validation as an obsolete technique back when the vulgar "HTML 5 rocks" campaigns were in full swing. CSP spec drafts have been around forever but were never finalized. CSP…

"I'm sorry, but rather than using kludges such as CSP to turning the lights off with a broad brush, how about fixing HTML and JavaScript in the first place?"

OK... how?

To be clear, I'm asking for an HN-comment level of detail, not a standards-body level of detail. I can't speak for everyone else on HN but I won't go over things with a fine-tooth comb, I'll only look at top-level issues.

But I will at least point out that being able to casually float third-party content into any site that has a weakness to XSS or man-in-the-middle or vulnerabilities in any other third-party content in the website is pretty fundamental. The fundamental composition power of the web is too powerful and it is going to have to be cut back. Some of the obvious solutions like "whitelisting hashes of valid content" have their own problems, like how a lot of the scripts being included out there are deliberately not constant and that's their whole point in the first place.

Re: GitHub's post-CSP journey

#49

Post by jerf »

Tone: I assume GitHub knows what they are doing, and I ask this question because I have a hole in my understanding that I have a professional interest in making sure is filled, not because I'm trying to "gotcha!" anybody or be critical. This article clearly demonstrates they are trying hard and not ignorant.

I don't understand why so much of this article is talking about dangling markup? While I highly recommend using the highest quality library you can get your hands on for this task, cleaning up user-supplied markup to at least be valid HTML is generally not that difficult. Cleaning up every last vector within that valid HTML is much harder and much more subtle; I have fought that fight myself, so I understand the bits about how awful the tag can be and so forth (and how how many other vectors there are for javascript, and how many vectors there are for loading content you didn't want loaded, and how many vectors there are for subtle leaks of information, etc., even within syntactically-valid HTML). But making syntactically-invalid HTML into syntactically-valid HTML that is at least not "dangling" is not that hard, and can be done reliably.

So I assume I'm missing some sort of context here about why they are having so much trouble with this? What's the context where they can't run this sort of syntax cleaner over the user input?

Re: GitHub's post-CSP journey

#50

Post by tannhaeuser »

jerf wrote: post #48
tannhaeuser wrote: post #47

Awesome article and thumbs up to github. I'm having great reservations towards CSP however. I think it breaks the web in a way that wouldn't have been necessary had we been a little bit more careful about HTML syntax rather than dismissing markup validation as an obsolete technique back when the vulgar "HTML 5 rocks" campaigns were in full swing. CSP spec drafts have been around forever but were never finalized. CSP…

"I'm sorry, but rather than using kludges such as CSP to turning the lights off with a broad brush, how about fixing HTML and JavaScript in the first place?" OK... how? To be clear, I'm asking for an HN-comment level of detail, not a standards-body level of detail. I can't speak for everyone else on HN but I won't go over things with a fine-tooth comb, I'll only look at top-level issues. But I will at least point out…

1. Defining and using safe JavaScript subsets (in the style of Google's Caja [3] and AdSafe [4], though probably that ship has sailed and cramming syntax sugar into JS is the order of the day instead)

2. Defining and using safe CSS subsets (with countermeasures against click-jacking/-phishing, and hiding "nose print" etc.) though granted this is challenging; I had hoped a formal semantics for CSS came along (such as in [2]) but it didn't

3. Using HTML-aware template engines (such as [1] but there are maybe lighter approaches with hard-coded HTML rules as well; disclaimer: my project)

[1]: http://sgmljs.net/blog/blog1701.html

[2]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/extend...

[3]: https://developers.google.com/caja/

[4]: http://www.adsafe.org/

Post reply on HN