5 ms·

It'd be cool if the browser used this to allow cross-origin caching as well. Say I have jQuery previously loaded a page that included jQuery from CDNJS and now

by yeldarb 10y ago

It'd be cool if the browser used this to allow cross-origin caching as well. Say I have jQuery previously loaded a page that included jQuery from CDNJS and now I'm in China and another site tries to load jQuery from Google's CDN. Currently that request would get blocked by the great firewall. But since the browser should know that this file matches one it has seen (and cached) before it should be able to just serve the cached file. This could also save a network request even if I'm linking to a self-hosted file on my own servers if I include the hash.

renesd 10y ago
Yeah, that would be cool. They could also even potentially save JIT typing, specialization, and even parsing. This is a big deal on mobile. There is Cache-Control: immutable https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/ https://hacks.mozilla.org/2017/01/using-immutable-caching-to... https://bitsup.blogspot.de/2016/05/cache-control-immutable.html https://bitsup.blogspot.de/2016/05/cache-control-immutable.h...
tetrep 10y ago
> It'd be cool if the browser used this to allow cross-origin caching as well. As a caveat, there's info leaking here depending on whether the cache hits/misses, so this would need to be opt-in from the cache source, e.g. You set up subresource integrity and also say "allow other domains to load this resource from the cache." Call it subresource sharing? Edit: opt-in would need to be on both "sides" (sharer and sharee).
- throwaway2048 10y ago
  This still wouldnt be enough, because you could still target the unique mix of script/script versions some specific site has, and have a high chance of being accurate, or at least high enough for statistical purposes.
  - problems 10y ago
    Given the accumulation of scripts from many sites it might work out alright, those specific versions could come from anywhere - not like only 1 site around uses a specific version of jquery or something. It might be enough, but would need testing to prove it out either way.
  - tetrep 10y ago
    Why is it insufficient? If the site doesn't want to leak that information, it doesn't participate in cache sharing. Since sharing is opt-in, sites won't unknowingly leak this information. Edit: whoops. I see what you mean. I missed an edit while modifying an earlier draft and left the opt-in only on one side, the sharer.
problems 10y ago
The potential problem I see with this is that it could be abused for a "have you loaded this resource" privacy leak. Simply pick a unique script on a website, if my server doesn't get a hit then I know you went there before.
- cryptarch 10y ago
  Save the load time and simulate it?
  - cryptarch 10y ago
    Why do you think this would be a bad idea?
- zrm 10y ago
  Possible solution is to have a content hash proxy trusted by the user but shared between multiple users. Then the site can only get the data at the proxy-level rather than the user-level, and not even that if the proxy is large enough to justify crawling the web to pre-cache everything, or is behind a larger cache that does.
  - nothrabannosir 10y ago
    That's not a solution but a work-around. The original privacy issue stands. browsers can't cache hashed content by default. :/
    - zrm 10y ago
      The browser would know if it had a content hash proxy configured and then could use it for all content hashed data. The issue becomes getting people to use one, but partial uptake is better than nothing. You could at least get most corporate and education environments with some equivalent to WPAD[1], and maybe even some consumer-level ISPs the same way if they want to reduce the traffic over their network. [1] https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Proto...
deleted 10y ago
[deleted]
michaelt 10y ago
Unfortunately this would break Content Security Policy. Not that many people use CSP, but that's the excuse I've heard for not allowing cross-origin caching.
- niftich 10y ago
  More detail on this: in a browser's current usage model, this is vulnerable to a 'cache origin confusion attack'. See this thread [1]. It's a bit hard to follow, so perhaps see these posts [2][3], which state the problem succinctly. Let me adapt the text from [3]: The problem is that www.victim.example/evil.js doesn't exist, and never did, but your browser won't know that if it's in the cache -- this gives you a way of faking files existing on other servers at the URL of your choice, and as long as they're in the cache you'll get away with it. and from [2]: 0. evil.example hosts evil.js, <script src=evil.js integrity=foo>. 1. you visit evil.example and the browser stores evil.js with the cache key "foo". 2. you visit victim.example which has an XSS vulnerability, but victim.example thinks it is safe because it uses Content Security Policy and does not allow inline scripts or scripts form evil domains. 3. the XSS attack is loading <script src=www.victim.example/evil.js hash=foo> 4. the browser detects that "foo" is a known hash key and loads the evil.js from cache. Thinking that the file is hosted on victim.example - when the file is in fact not even present. 5. the evil.js script executes in the context of victim.example, even though they use a Content Security Policy to prevent XSS from being exploitable. [1] https://news.ycombinator.com/item?id=10310594 https://news.ycombinator.com/item?id=10310594 [2] https://news.ycombinator.com/item?id=10311555 https://news.ycombinator.com/item?id=10311555 [3] https://news.ycombinator.com/item?id=10312333 https://news.ycombinator.com/item?id=10312333 (parts first posted here: https://news.ycombinator.com/item?id=13493407#13495482 https://news.ycombinator.com/item?id=13493407#13495482)
  - zrm 10y ago
    It seems like the problem is that you need to verify that the file actually exists there with the specified hash, but that isn't the same as having to download it. Is there a way to ask the server for just the hash of a file? You would still have the round trip to the server, but it would be a request for a 32 byte content hash rather than several orders of magnitude more data than that.
throwaway2048 10y ago
Like every cross site cacheing scheme this could be abused for tracking purposes.
deleted 10y ago
[deleted]
paulirish 10y ago
https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre... captures that general idea; but I don't know if it has been pursued farther.
- groby_b 10y ago
  It's being discussed, idly. No serious work AFAIK. There's a twitter thread or two... https://twitter.com/cramforce/status/849621456111624192 https://twitter.com/cramforce/status/849621456111624192 https://twitter.com/hillbrad/status/848627295208300544 https://twitter.com/hillbrad/status/848627295208300544
bugmen0t 10y ago
Yeah, it was discussed in the W3C WebAppSec group, but there are many unsolved challenges. This article sums it up really, really well: https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre...
edibleEnergy 10y ago
Like any feature, there's a lot of weird edge casey parts of SRI that can be abused. We blogged about Adblock detectors over here[1] a couple of months ago for BugReplay[2]. A major Adblock detector FAdBlock was using subresource integrity to detect whether it's payload was being blocked, ie when adblocker was blocking it from being loaded. [1]: https://blog.bugreplay.com/2016/11/fkadblock-how-publishers-are-defeating.html https://blog.bugreplay.com/2016/11/fkadblock-how-publishers-... [2]: https://www.bugreplay.com https://www.bugreplay.com

by yeldarb 10y ago

renesd 10y ago

Yeah, that would be cool. They could also even potentially save JIT typing, specialization, and even parsing. This is a big deal on mobile. There is Cache-Control: immutable https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/ https://hacks.mozilla.org/2017/01/using-immutable-caching-to... https://bitsup.blogspot.de/2016/05/cache-control-immutable.html https://bitsup.blogspot.de/2016/05/cache-control-immutable.h...

tetrep 10y ago

> It'd be cool if the browser used this to allow cross-origin caching as well. As a caveat, there's info leaking here depending on whether the cache hits/misses, so this would need to be opt-in from the cache source, e.g. You set up subresource integrity and also say "allow other domains to load this resource from the cache." Call it subresource sharing? Edit: opt-in would need to be on both "sides" (sharer and sharee).

throwaway2048 10y ago
This still wouldnt be enough, because you could still target the unique mix of script/script versions some specific site has, and have a high chance of being accurate, or at least high enough for statistical purposes.
- problems 10y ago
  Given the accumulation of scripts from many sites it might work out alright, those specific versions could come from anywhere - not like only 1 site around uses a specific version of jquery or something. It might be enough, but would need testing to prove it out either way.
- tetrep 10y ago
  Why is it insufficient? If the site doesn't want to leak that information, it doesn't participate in cache sharing. Since sharing is opt-in, sites won't unknowingly leak this information. Edit: whoops. I see what you mean. I missed an edit while modifying an earlier draft and left the opt-in only on one side, the sharer.

problems 10y ago

The potential problem I see with this is that it could be abused for a "have you loaded this resource" privacy leak. Simply pick a unique script on a website, if my server doesn't get a hit then I know you went there before.

cryptarch 10y ago
Save the load time and simulate it?
- cryptarch 10y ago
  Why do you think this would be a bad idea?
zrm 10y ago
Possible solution is to have a content hash proxy trusted by the user but shared between multiple users. Then the site can only get the data at the proxy-level rather than the user-level, and not even that if the proxy is large enough to justify crawling the web to pre-cache everything, or is behind a larger cache that does.
- nothrabannosir 10y ago
  That's not a solution but a work-around. The original privacy issue stands. browsers can't cache hashed content by default. :/
  - zrm 10y ago
    The browser would know if it had a content hash proxy configured and then could use it for all content hashed data. The issue becomes getting people to use one, but partial uptake is better than nothing. You could at least get most corporate and education environments with some equivalent to WPAD[1], and maybe even some consumer-level ISPs the same way if they want to reduce the traffic over their network. [1] https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Proto...

deleted 10y ago

[deleted]

michaelt 10y ago

Unfortunately this would break Content Security Policy. Not that many people use CSP, but that's the excuse I've heard for not allowing cross-origin caching.

niftich 10y ago
More detail on this: in a browser's current usage model, this is vulnerable to a 'cache origin confusion attack'. See this thread [1]. It's a bit hard to follow, so perhaps see these posts [2][3], which state the problem succinctly. Let me adapt the text from [3]: The problem is that www.victim.example/evil.js doesn't exist, and never did, but your browser won't know that if it's in the cache -- this gives you a way of faking files existing on other servers at the URL of your choice, and as long as they're in the cache you'll get away with it. and from [2]: 0. evil.example hosts evil.js, <script src=evil.js integrity=foo>. 1. you visit evil.example and the browser stores evil.js with the cache key "foo". 2. you visit victim.example which has an XSS vulnerability, but victim.example thinks it is safe because it uses Content Security Policy and does not allow inline scripts or scripts form evil domains. 3. the XSS attack is loading <script src=www.victim.example/evil.js hash=foo> 4. the browser detects that "foo" is a known hash key and loads the evil.js from cache. Thinking that the file is hosted on victim.example - when the file is in fact not even present. 5. the evil.js script executes in the context of victim.example, even though they use a Content Security Policy to prevent XSS from being exploitable. [1] https://news.ycombinator.com/item?id=10310594 https://news.ycombinator.com/item?id=10310594 [2] https://news.ycombinator.com/item?id=10311555 https://news.ycombinator.com/item?id=10311555 [3] https://news.ycombinator.com/item?id=10312333 https://news.ycombinator.com/item?id=10312333 (parts first posted here: https://news.ycombinator.com/item?id=13493407#13495482 https://news.ycombinator.com/item?id=13493407#13495482)
- zrm 10y ago
  It seems like the problem is that you need to verify that the file actually exists there with the specified hash, but that isn't the same as having to download it. Is there a way to ask the server for just the hash of a file? You would still have the round trip to the server, but it would be a request for a 32 byte content hash rather than several orders of magnitude more data than that.

throwaway2048 10y ago

Like every cross site cacheing scheme this could be abused for tracking purposes.

deleted 10y ago

[deleted]

paulirish 10y ago

https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre... captures that general idea; but I don't know if it has been pursued farther.

groby_b 10y ago
It's being discussed, idly. No serious work AFAIK. There's a twitter thread or two... https://twitter.com/cramforce/status/849621456111624192 https://twitter.com/cramforce/status/849621456111624192 https://twitter.com/hillbrad/status/848627295208300544 https://twitter.com/hillbrad/status/848627295208300544

bugmen0t 10y ago

Yeah, it was discussed in the W3C WebAppSec group, but there are many unsolved challenges. This article sums it up really, really well: https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre...

edibleEnergy 10y ago

Like any feature, there's a lot of weird edge casey parts of SRI that can be abused. We blogged about Adblock detectors over here[1] a couple of months ago for BugReplay[2]. A major Adblock detector FAdBlock was using subresource integrity to detect whether it's payload was being blocked, ie when adblocker was blocking it from being loaded. [1]: https://blog.bugreplay.com/2016/11/fkadblock-how-publishers-are-defeating.html https://blog.bugreplay.com/2016/11/fkadblock-how-publishers-... [2]: https://www.bugreplay.com https://www.bugreplay.com