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

Thanks for checking Artur,

Personally I won't need this feature (I ended up replacing the website I was thinking about)... but I can see how this would be helpful for the static help for GMail.

Craig




> On 9 Apr 2018, at 15:39, Artur Janc <aaj@google.com> wrote:
> 
> 
> On Thu, Apr 5, 2018 at 10:29 PM Craig Francis <craig@craigfrancis.co.uk <mailto: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 <mailto: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 <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
>