We shipped subresource integrity a few months back to reduce the risk of a compromised CDN serving malicious JavaScript. That is a big win, but does not address related content injection issues that may exist on GitHub.com itself. 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.
Just to get everyone on the same page, when talking about “content injection” we are talking about:
Cross Site Scripting (XSS) – Yup, the most common web vulnerability of the past, present, and foreseeable future. Given its prevalence, many developers are familiar with XSS and the obvious security consequences of allowing injected JavaScript to execute on your site.
Scriptless attacks – This is a more nuanced issue and is frequently not considered since people are too busy fending off XSS. But, as has been documented by Michal Zalewski in “Postcards from the post-XSS world”, Mario Heiderich (et al) in “Scriptless Attacks –
Stealing the Pie Without Touching the Sill”, and other related work, preventing XSS does not solve all of your content injection problems.
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. 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. 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. As with most problems, there is no single magical fix, and therefore we have employed multiple techniques to help with mitigation. In this post we will focus on our ever evolving use of Content Security Policy (CSP), as it is our single most effective mitigation. 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.
With the rollout of GitHub Pages, why not show the world that you collaborate on GitHub? I’ve prepared these ribbons that you can overlay on your site by copying and pasting the appropriate snippet into your site’s HTML. Make sure to change the URL in the link to contain your username instead of “you”.
If you’re not satisfied with one of the colors here, I’ve provided the PSD files (MIT licensed). Feel free to modify as you please. The font being used is Collegiate.
Here at Ably, we have an immense amount of information that needs to be shared among our employees, from the various services we use to the usage of our own system and various company protocols.
Until recently, we’ve been using the GitHub Wiki functionality to do the job but lately, we have had a few issues with this. Firstly, there’s no form of version control for the wiki available through the GitHub interface. Secondly, we wanted the wiki’s content to be easily searchable from the actual page.
You can find the base code used to build this tool, in our GitHub Repository.
1. Web Application Framework — Sinatra
We based our wiki on Sinatra, a web application library written in Ruby. This is a really simple way to get the foundation of your site running. It comes with some great tutorials on how to get started. With Sinatra we had the infrastructure to present our pages, however we still needed a way to interpret our markdown files to display them.
2. Presenting Markdown files — Jekyll
To convert our markdown pages we settled on Jekyll. Jekyll will process any markdown, HTML, and CSS and combine it all into a static site, which is exactly what we needed. By creating some CSS files to structure our pages, and storing our markdown pages in a folder, we were able to construct HTML pages with ease. Once the static site has been generated into a folder called _site, we were able to have Sinatra use this folder as a basis for presenting pages.
3. Searching Pages — Simple-Jekyll-Search
Beyond simply hosting and presenting our wiki pages, we wanted to be able to search through them. To do this, we constructed a sidebar containing the titles of each of the searchable pages, and then made use of Simple-Jekyll-Search to easily search through these titles and content of each page. This was just a matter of defining the search structure and results we wanted in a search.json file, followed by presenting the results in place of the usual sidebar results.
4. Authentication — Auth0
As we intended to use this wiki for internal use only, we needed some method of authentication when accessing it. Auth0provides a simple API to authenticate throughout the site, abstracting away all the complexities involved with authentication.
5. Deploying — Heroku
Finally, we needed a way to make our site widely accessible. In order to simplify the process, we made use of Heroku for hosting our new site. With its easy GitHub integration, this allows us to not only automatically pull new wiki material from our master branch when it gets updated, but also allows access to versioned sites for testing.