0

What would be the potential attack vectors if a browser were to ignore the certificates when making a network request that is verified via subresource integrity?

As an example, lets say I had the script tag:

<script src="https://example.com/my-script.js" integrity="..." crossorigin="anonymous">

The browser would make the request for my-script, but wouldn't bother checking the certificate, as the validity of the script is verified by the integrity attribute.

The webpage that contains the script tag would still be verified via certificates, but the script itself wouldn't.

Are there any possible attack vectors in this scenario?

1

Since only strong hash algorithms (i.e. sha-256 and better) are allowed for subsource integrity one can be pretty sure that the payload itself was not compromised. Still, the payload is not encrypted so any sensitive data contained in the payload can be sniffed. This is less likely when including public and static resources but might be the case if the server controls both the file including the script and the script itself.

Apart from that subsource integrity only protects the payload of the response. It does neither protect the response header nor the request against sniffing and manipulation so a man in the middle attacker could at least get the cookies from the request or could even modify existing or inject new cookies in the response. The first one might be used for tracking or depending on the cookie also identity theft or similar. The last one might be used for tracking too. Also, some web applications don't treat the cookies as some opaque value only but use them to store data in it. Changing an existing cookie or adding a new cookie might cause confusion or even cross site scripting, depending on how much the application trusts the cookie value. And the last one is what one tries to avoid when using subsource integrity.

  • altering cookies or headers on a JS file should not affect anything JS can see; only parsed document's cookies are used. To JS, cookies all come from the page domain, so there should be no XSS potential, and if someone can mod cookies, they can mod the whole document response and not mess with mere cookies... – dandavis Dec 10 '16 at 9:25
  • @dandavis: if the subsource comes for example from a subdomain of the document domain cookies set in the subdomain can affect cookies of the document domain. For example you can get from js.example.com: Set-Cookie: name=value; domain=example.com – Steffen Ullrich Dec 10 '16 at 9:57
  • yes, but only if the subsource is an HTML document. Server-set cookies on JS URLs have no effect on document.cookie. – dandavis Dec 10 '16 at 19:50
  • @dandavis: I've just tried it and I can easily set a cookie into example.com from the HTTP response header of a request to a Javascript on js.example.com with the example I've given above. Tested with both Chrome and Firefox. I doubt that there are any restrictions on the content-types of the payload when setting a cookie in the response header but maybe you can provide a source which says otherwise. – Steffen Ullrich Dec 10 '16 at 20:07
  • you're right, my bad. even new Image().src="/test.php"; update the page's cookie without reloading. sorry to waste our time diving on a dud grenade... – dandavis Dec 12 '16 at 10:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.