The mission of the Web Application Security Working Group, part of the Security Activity, is to develop security and policy mechanisms to improve the security of Web Applications, and enable secure cross-origin communication.
If you work with websites, you are probably already familiar with the web features that the WebAppSec WG has recently introduced. But not many web developers (or even web security specialists) feel comfortable reading or referencing the specifications for these features.
I typically hear one of two things when I mention WebAppSec WG web features:
- Specifications are hard to read. I’d rather read up on this topic at [some other website].
- This feature does not really cover my use-case. I’ll just find a workaround.
Specifications are not always the best source if you are looking to get an introduction to a feature, but once you are familiar with it, the specification should be the first place you go when looking for a reference or clarification. And if you feel the language of the specification can be better or that more examples are needed, go ahead and propose the change!
To cover the second complaint, I’d like to detail out our experience contributing a feature to a WebAppSec WG specification. I hope to clarify the process and debunk the myth that your opinion is going to be unheard or that you can’t, as an individual, make a meaningful contribution to a web feature used by millions.
Content Security Policy is a WebAppSec WG standard that allows a website author to, among other things, declare the list of endpoints with which a web page is expecting to communicate. Another great WebAppSec WG standard, SRI, allows a website author to ensure that the resources received by their web page (like scripts, images, and stylesheets) have the expected content. Together, these web features significantly reduce the risk that an attacker can substitute web page resources for their own malicious resources.
I helped standardise and implement
require-sri-for, a new CSP directive that mandates SRI integrity metadata to be present before requesting any subresource of a given type.
Currently, SRI works with resources referenced by
link HTML elements. Also, the Request interface of the Fetch API allows to specify the expected integrity metadata. For example,
Content-Security-Policy: require-sri-for script style; extends the expectations and forbids pulling in any resources of a given type without integrity metadata.
Contributing to a WebAppSec WG Specification
Unlike some other working groups, there is no formal process on how to start contributing to W3C’s Web Application Security Working Group specifications, and it might look scary. It is actually not, and usually flows in the following order:
- A feature idea forms in somebody’s head enough to be expressed as a paragraph of text.
- A paragraph or two is proposed either in WebAppSec’s public mailing list or in the Github Issues section of the relevant specification. Ideally, examples, algorithms and corner-cases are included.
- After some discussion, which can sometimes take quite a while, the proposal starts to be formalised as a patch to the specification.
- The specification strategy is debated, wording details are finalised, and the patch lands in the specification.
- Browser vendors implement the feature.
- Websites start using the feature.
Anyone can participate in any phase of feature development, and I’ll go over the
require-sri-fordevelopment timeline to highlight major phases and show how we participated in the process.
- Development started in an issue on the WebAppSec GitHub repo opened back in April 2014 by Devdatta Akhawe. He wonders how one might describe a desire to require SRI metadata, e.g. the integrity hash, be present for all subresources of a given type.
- Much time passes. SRI is supported by Chrome and Firefox. Github is among first big websites to use it in the wild.
- A year later, Github folks raise the same question that Dev did on the
public-webappsecmailing list, with an addition of having an actual use case: they intended to have an integrity attribute on every script they load, but days later after deplyoing the SRI feature, determined that they had missed one script file.
- Neil from Github Security starts writing up a paragraph in the CSP specification to cover a feature that would enforce integrity attribute on scripts and styles. Lots of discussion irons out the details that were not covered in the earlier email thread.
- I pick up the PR and move it to the SRI specification GitHub repo. 65 comments later, it lands in the SRI spec v2.
- Frederik Braun patches Firefox Nightly with
- I submit a PR to Chromium with basic implementation. 85 comments later, it evolves into a new Chrome platform feature and lands with plans to be released in Chrome 54.
Specification development is happening on Github, and there are many great specifications that you should be looking at:
- Content Security Policy and Content Security Policy: Embedded Enforcement,
- Subresource Integrity,
- Mixed Content,
- Upgrade Insecure Requests,
- Clear Site Data,
- and many more!
We Are Hiring!
If you reached here, there is a chance that Shape has a career that looks interesting to you.
*** This is a Security Bloggers Network syndicated blog from Shape Security Blog authored by Sergey Shekyan. Read the original post at: https://blog.shapesecurity.com/2016/09/28/contributing-to-the-future/