ilikeasfen.blogg.se - Dynamic website examples github

DYNAMIC WEBSITE EXAMPLES GITHUB CODE

Our current CSP policy looks like this: CONTENT-SECURITY-POLICY:Ĭonnect-src 'self' wss:// įorm-action 'self'

We have refactored the vast majority of our third-party script dependencies and CSP itself has also added a number of new directives to further help mitigate content injection bugs and strengthen our policy. However, that was almost three years ago, and a lot has changed since then. The above policy did nothing to help with HTML injection that could be used to exfiltrate sensitive information (demonstrated below). During our initial ship we were forced to trust a number of domains to maintain backward compatibility. After the initial ship we knew there was quite a bit more we could do to tighten things up. The policy was relatively simple, but substantially reduced the risk of XSS on. CSP was in its infancy then and our initial policy reflected this: CONTENT-SECURITY-POLICY: GitHub was an early adopter of CSP, having shipped our initial implementation approximately three years ago. CSP is incredibly useful for leveling up the security of your site and is particularly suited for mitigating content injection bugs. Content Security PolicyĬontent Security Policy is an HTTP header that enables a site to use a declarative policy to set restrictions for web resources (JavaScript, CSS, form submissions, etc).

We can’t wait to follow up on this blog to additionally review some of the “non-traditional” approaches we have taken to further mitigate content injection. In this post we will focus on our ever evolving use of Content Security Policy (CSP), as it is our single most effective mitigation. As with most problems, there is no single magical fix, and therefore we have employed multiple techniques to help with mitigation. We decided that the only practical approach is to pair prevention and detection with additional defenses that make content injection bugs much more difficult for attackers to exploit. Any strategy that relies on preventing any and all content injection bugs is bound for failure and will leave your engineers, and security team, constantly fighting fires.

DYNAMIC WEBSITE EXAMPLES GITHUB CODE

GitHub uses auto-escaping templates, code review, and static analysis to try to prevent these kinds of bugs from getting introduced in the first place, but history shows they are unavoidable. Stealing the Pie Without Touching the Sill”, and other related work, preventing XSS does not solve all of your content injection problems. But, as has been documented by Michal Zalewski in “Postcards from the post-XSS world”, Mario Heiderich (et al) in “Scriptless Attacks –

Scriptless attacks – This is a more nuanced issue and is frequently not considered since people are too busy fending off XSS.

Given its prevalence, many developers are familiar with XSS and the obvious security consequences of allowing injected JavaScript to execute on your site.

Cross Site Scripting (XSS) – Yup, the most common web vulnerability of the past, present, and foreseeable future.

Just to get everyone on the same page, when talking about “content injection” we are talking about: We have been tackling this side of the problem over the past few years and thought it would be fun, and hopefully useful, to share what we have been up to. That is a big win, but does not address related content injection issues that may exist on itself. We shipped subresource integrity a few months back to reduce the risk of a compromised CDN serving malicious JavaScript.