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

51–60 of 60 posts

Re: GitHub's post-CSP journey

#51

Post by ptoomey3 »

jerf wrote: post #49

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 usin…

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 `` tag, but is no longer able, so they must go to the next best thing...dangling markup.

Re: GitHub's post-CSP journey

#52

Post by ptoomey3 »

skj wrote: post #42
niftich wrote: post #18

Earlier quoted context omitted.

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.

I have updated the article to link out and define the first reference of CSP.

Re: GitHub's post-CSP journey

#53

Post by ptoomey3 »

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.

I've updated the post to spell out/link to a description of CSP upon first mention.

Re: GitHub's post-CSP journey

#54

Post by ptoomey3 »

chias wrote: post #15
niftich wrote: post #7

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,…

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/

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/

Re: GitHub's post-CSP journey

#55

Post by jerf »

ptoomey3 wrote: post #51
jerf wrote: post #49

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 usin…

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…

Thank you. That makes sense now.

Re: GitHub's post-CSP journey

#56

Post by dfc »

Sacho wrote: post #21
niftich wrote: post #18

Earlier quoted context omitted.

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.

My comment was not about establishing an across the board level of technical competence. In my opinion the audience was not general tech people, the audience is security / infrastructure folks. I apologize if anyone felt slighted.

Re: GitHub's post-CSP journey

#57

Post by rhpistole »

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.

You can use it to identify unsophisticated attacks, sure.

However, if someone has the ability to make malicious HTTP requests on my behalf using my browser can you really be sure that they don't have the ability to make malicious HTTP requests with altered headers through a malicious extension or a browser specific exploit or some other vector?

You still have to do all the other attack mitigation strategies in addition to checking the Origin header, and I'm not sure the extra complexity buys you anything in the long-term.

Re: GitHub's post-CSP journey

#58

Post by nadaviv »

jerf wrote: post #49

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 usin…

> cleaning up user-supplied markup to at least be valid HTML

The root cause of XSS is improper user input sanitization. Usually it is in places that shouldn't allow HTML at all, where the developer forgot to properly HTML-escape the user-provided input. If not encoding it at all can slip by, then obviously not verifying that its valid HTML could too (plus, it doesn't make sense to verify valid HTML when you aren't even expecting HTML).

The focus on dangling markup is because a CSP policy that prevents unauthorized JavaScript from executing (no inline scripts, remote scripts from trusted hosts only) can resolve most of the XSS issues, but it doesn't resolve leakage of information over other channels (such as via images).

While CSP could be used to completely block images from external hosts (and thus solve the leakage issue), you sometimes do want to allow users to inline external images and so an alternative solution to prevent sensitive information from being leaked is required.

Edit: haven't seen ptoomey3's comment while I wrote mine. He explained it better :-)

Re: GitHub's post-CSP journey

#59

Post by tinus_hn »

ptoomey3 wrote: post #51
jerf wrote: post #49

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 usin…

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…

XSS is unavoidable if you think the solution is sanitizing user input.

The solution to sql injection is parametrized query construction, instead of automatically filtering the ' character and then pasting the template and the user input together.

Similarly, to avoid cross site scripting you have to combine your templates and user input by escaping it properly, instead of just concatenating them and then hoping you can avoid the issues by input 'sanitizing'.

Re: GitHub's post-CSP journey

#60

Post by [deleted] »

tinus_hn wrote: post #59
ptoomey3 wrote: post #51

Earlier quoted context omitted.

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…

XSS is unavoidable if you think the solution is sanitizing user input. The solution to sql injection is parametrized query construction, instead of automatically filtering the ' character and then pasting the template and the user input together. Similarly, to avoid cross site scripting you have to combine your templates and user input by escaping it properly, instead of just concatenating them and then hoping you ca…

[deleted]
Post reply on HN