Re: [CSP] ‘unsafe-hashed-attributes’, ‘unsafe-inline-attributes’ and CSP directive versioning

On Thu, Apr 5, 2018 at 10:29 PM Craig Francis <craig@craigfrancis.co.uk>
wrote:

> Hi Andy,
>
> You mention "Google has ~30 thousand instances"... do you know the average
> number of unique attributes per page?
>

> I've seen some pages where there are hundreds of inline styles and JS
> attributes.
>

Note that this is certainly anecdata, but I just looked at the static help
documentation for Gmail and in ~1.1 thousand HTML files about 80% have an
inline event handler, the total number of event handlers is 2.1 thousand,
and the median is 2 event handlers per document. Less than 3% of documents
have more than 10 unique inline event handlers and there is only one
document which has more than 20.

We also did some quick tests with the search index, and from the data it
looked like 95% of registerable domains have fewer than 100 distinct inline
event handlers across all documents crawled on that site. There is
certainly a possibility that big applications which could use this have
some documents with a much higher number of distinct event handlers, but an
automated CSP generator for static content could handle this case by
refusing to set a policy for such documents.

For inline style="..." attributes this shouldn't be a problem because
developers would bless all of them via 'unsafe-inline-attributes' so they
would not need to be individually whitelisted via hashes.

Which means that the size of the CSP header could become be quite large
> (e.g. ~28KB for 300 attributes, each one needing 95+1 characters for a
> base64 encoded sha256 hash).
>
> And when using an "automated solution" to set a CSP for those pages... I
> assume you would have something that looks at the static HTML as it's
> requested, then build a CSP based on the attributes it finds in that HTML
> file? i.e. you going on the basis that the static HTML file hasn't been
> tampered with (which might be fair assumption to make).
>

Yes, that's the plan. Since static HTML files don't have the risk of
reflected/persistent XSS, and the main concern are DOM XSS bugs, the
middleware could inspect all existing event handlers and calculate their
hashes, add nonces to <script> elements, and generate the CSP. If the
document has a DOM XSS, the attacker would be limited to executing scripts
present in that document, rather than get full JS execution in the context
of the hosting origin.

Cheers,
-Artur


>
> Craig
>
>
>
>
>
> On 5 Apr 2018, at 13:50, Andy Paicu <andypaicu@chromium.org> wrote:
>
> Hello folks at webappsec,
>
> The CSP 'unsafe-hashed-attributes' keyword proposal has traditionally had
> quite a bit of controversy and discussion and I would like to try to
> channel all of these discussions and opinions towards some end decision of
> some sort.
>
> 'unsafe-inline-attribute' has also had some discussion and has recently
> resurfaced in light of some CSS-based keylogger attacks. Seeing that it is
> quite similar to 'unsafe-hashed-attributes' I think they're worth
> discussing together.
>
> CSP directive versioning follows logically from the two above so I have
> also bundled it up in the explainer below:
>
>
> https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit?usp=sharing
>
> I would like to hear all of your thoughts and opinions on this as I
> believe there is real benefit in adding these features.
>
> Regads,
> Andy Paicu
>
>
>