4 ms·

For security reasons pushed resources have to be treated as a special case until they're claimed by the page, amongst other things this means they need a separa

For security reasons pushed resources have to be treated as a special case until they're claimed by the page, amongst other things this means they need a separate cache until they're claimed

paulddraper 2y ago
Explain why security demands a separate cache?
- bawolff 2y ago
  Cache poisioning attacks.
  - paulddraper 2y ago
    Oh I see. Push was not limited to the same host. Which would have been an easy fix.
    - bawolff 2y ago
      Connections arent limited to the same (virtual) host. Additionally, to prevent cross page tracking, browsers use a separate cache for subresources loaded from different top level domains. Anyways, it is trickier than it sounds at first glance.
      - paulddraper 2y ago
        > Connections arent limited to the same (virtual) host. Huh? Doesn't HTTPS and SNI effectively require that?
        bawolff 2y ago
        Its a minor point, since the rules are quite strict so its probably not a security issue, but no, due to connection coalescing, one connection can serve multiple virtual hosts. See https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ https://daniel.haxx.se/blog/2016/08/18/http2-connection-coal...
_heimdall 2y ago
That's an interesting challenge. Is the Push header being included on the document request not enough to consider it a secure resource? I could see this being a concern with secondary requests that haven't been claimed by the document, say a stylesheet with Push headers to preload font files. I'm not quite sure how it would get into that state with the stylesheet being requested without the page having claimed the request, but is that the security concern?
- youngtaff 2y ago
  Jake mentions one of the reasons in his post (that's linked elsewhere) Push is on a connection (not request) basis so if the connection is authoritative for multiple hosts i.e. they share a cert in the way low cost Cloudflare plans used to (perhaps still do?) then you can push resources for another site Even without that issue you wouldn't want every resource that gets pushed to end up in the browser cache by default as it leaves open all sorts of malicious behavior e.g. just keep pushing until the browser cache is full of crap etc.
  - jauntywundrkind 2y ago
    Push_promise frame includes an optional stream identifier (as well as the promise stream identifier). https://httpwg.org/specs/rfc9113.html#PUSH_PROMISE https://httpwg.org/specs/rfc9113.html#PUSH_PROMISE Not only is it possible to associate a push with a request, but this is crucial to Web Push Protocol (which powers the Push API in browsers). https://datatracker.ietf.org/doc/html/draft-ietf-webpush-protocol#section-6 https://datatracker.ietf.org/doc/html/draft-ietf-webpush-pro... I don't place a ton credence in the malicious behavior assertions. A web page can already request a colossal number of large resources, flood the cache. Yes the browser gets to dispatch requests as it pleases. But having push limit it's cache size also seems not absurdly hard, and like something that wouldn't impede healthy usage much.
    - hedora 2y ago
      I wonder if you can use this to implement cross-site-cookies. (A pushes cookie data to B’s cache with a well known name, then B fetches A data from local cache).

For security reasons pushed resources have to be treated as a special case until they're claimed by the page, amongst other things this means they need a separate cache until they're claimed

paulddraper 2y ago

Explain why security demands a separate cache?

bawolff 2y ago
Cache poisioning attacks.
- paulddraper 2y ago
  Oh I see. Push was not limited to the same host. Which would have been an easy fix.
  - bawolff 2y ago
    Connections arent limited to the same (virtual) host. Additionally, to prevent cross page tracking, browsers use a separate cache for subresources loaded from different top level domains. Anyways, it is trickier than it sounds at first glance.
    - paulddraper 2y ago
      > Connections arent limited to the same (virtual) host. Huh? Doesn't HTTPS and SNI effectively require that?
      - bawolff 2y ago
        Its a minor point, since the rules are quite strict so its probably not a security issue, but no, due to connection coalescing, one connection can serve multiple virtual hosts. See https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ https://daniel.haxx.se/blog/2016/08/18/http2-connection-coal...

_heimdall 2y ago

That's an interesting challenge. Is the Push header being included on the document request not enough to consider it a secure resource? I could see this being a concern with secondary requests that haven't been claimed by the document, say a stylesheet with Push headers to preload font files. I'm not quite sure how it would get into that state with the stylesheet being requested without the page having claimed the request, but is that the security concern?

youngtaff 2y ago
Jake mentions one of the reasons in his post (that's linked elsewhere) Push is on a connection (not request) basis so if the connection is authoritative for multiple hosts i.e. they share a cert in the way low cost Cloudflare plans used to (perhaps still do?) then you can push resources for another site Even without that issue you wouldn't want every resource that gets pushed to end up in the browser cache by default as it leaves open all sorts of malicious behavior e.g. just keep pushing until the browser cache is full of crap etc.
- jauntywundrkind 2y ago
  Push_promise frame includes an optional stream identifier (as well as the promise stream identifier). https://httpwg.org/specs/rfc9113.html#PUSH_PROMISE https://httpwg.org/specs/rfc9113.html#PUSH_PROMISE Not only is it possible to associate a push with a request, but this is crucial to Web Push Protocol (which powers the Push API in browsers). https://datatracker.ietf.org/doc/html/draft-ietf-webpush-protocol#section-6 https://datatracker.ietf.org/doc/html/draft-ietf-webpush-pro... I don't place a ton credence in the malicious behavior assertions. A web page can already request a colossal number of large resources, flood the cache. Yes the browser gets to dispatch requests as it pleases. But having push limit it's cache size also seems not absurdly hard, and like something that wouldn't impede healthy usage much.
  - hedora 2y ago
    I wonder if you can use this to implement cross-site-cookies. (A pushes cookie data to B’s cache with a well known name, then B fetches A data from local cache).