7 ms·

Going to also spawn a whole new class of semi-persistent malicious pages (say created via XSS) that once signed and captured can be continuously replayed to cli

by jhhh 6y ago

Going to also spawn a whole new class of semi-persistent malicious pages (say created via XSS) that once signed and captured can be continuously replayed to clients until expiration.

CGamesPlay 6y ago
What? The signing allows the content to be mirrored in other locations with guarantees about consistency. It doesn't imply anything more about the content than SSL does.
- 8organicbits 6y ago
  If Google AMP is acts like a cache of content, then cache poisoning attacks are a concern. How those cached items expire will determine how long an attacker who poisons the cache can serve malicious content.
  - CGamesPlay 6y ago
    Why does Archive.org get a pass on this one? Signed responses mean that there's a very clear way to leverage the browser's domain blacklisting technology to stop the spread of malware, which isn't presently possible for any content mirrors on the web.
    - 8organicbits 6y ago
      Archive.org makes it clear you are on archive.org. The URL shows archive.org. The page content shows archive.org at the top. [1] Google AMP doesn't show Google on the page. Google is pushing for the URL to show the origin site's URL instead of Google[2]. If an attacker poisons a nytimes.com article served by Google AMP, how does a browser's domain blacklisting help? Block google? Block nytimes.com? Neither makes sense. 1. https://web.archive.org/web/20050401090916/http://www.google.com/ https://web.archive.org/web/20050401090916/http://www.google... 2. https://9to5google.com/2019/04/18/apple-mozilla-google-amp-signed-exchanges/ https://9to5google.com/2019/04/18/apple-mozilla-google-amp-s...
      - CGamesPlay 6y ago
        I believe you might be misunderstanding the idea behind signed exchanges. To be clear, Signed Exchanges are how AMP should have worked all along. example.com generates a content bundle and signs it. Google.com downloads the bundle and decides to mirror it from their domain. Your browser downloads the bundle from google.com, and verifies that the signature comes from example.com. Your browser is now confident that the content did originate from example.com, and so can freely say that the "canonical URL" for the content is example.com. Malicious.org does the same thing, and the browser spots that malicious.org is blocked. At this point it doesn't matter if the content came from google.com, because the browser knows that the content is signed by malicious.org and so it originated from there. Hope this helps clarify. Obviously blacklisting isn't a great security mechanism; my point is just that signed exchanges don't really open any NEW vectors for attack.
        remexre 6y ago
        I think the concern was more that if I can XSS example.com, Google is now serving that for some period of time after example.com's administrators notice + fix this. (In the absence of a mechanism to force AMP to immediately decache the affected page(s), that is.)
        dillonmckay 6y ago
        Yes, at what point does example.com lose control of their content and for how long?
        8organicbits 6y ago
        I'm following. Imagine that example.com builds the bundle by pulling data from a database. If an attacker can find a way to store malicious content in that database (stored XSS) and that content ends up in a signed bundle that Google AMP serves (similar to cache poisoning) then users will see malicious content. When the stored XSS is removed from the database, Google AMP may continue to serve the malicous signed bundle. So an extra step may be needed to clear the malicious content from Google AMP. How exactly the attacker influences the bundle is going to be implementation dependent, so some sites may be safe while others are exploitable.
  - entire-name 6y ago
    At that point, wouldn't the approach be to defend from the client side? Namely, we can instruct the client to not trust any content sign by such-and-such keys. This can be done by pushing out a certificate revocation, etc.
    - judge2020 6y ago
      This would be pretty cool (remotely revoking signed exchanges), however it's not part of Google's proposal - Unless every previous security consideration about caches is accounted for in SX's, it's probably not safe to start faking the URL bar.
    - gregable 6y ago
      Certificate revocations do apply to signed exchanges.
- vinay_ys 6y ago
  Along with signing, we need explicit content cache busting and explicit allowed mirrors list (which can be revoked instantly). Then it would be at par with TLS + current cache busting mechanisms on top of TLS.
  - londons_explore 6y ago
    As long as javascript on the page has some way to inspect the signatures and where it was delivered from, you can implement cache busting, allowed mirrors, and invalidation yourself however you please.
realusername 6y ago
I don't see how this tech would further help to make malicious pages created with XSS, any thoughts? It sounds like it's the same issue with or without signed exchanges.
- sk5t 6y ago
  Parent considers that the feature could be used to turn a temporary problem into a long-term problem. Sort of like how certificate pinning could be twisted to ransom an entire domain.
- jhhh 6y ago
  The point wasn't that this technology would uniquely enable XSS attacks, but rather that it could allow malicious actors to persist particular attacks for the duration of the validity of the signed content. Any brief vulnerability in a website now becomes serializable. They considered this already. Look in the draft "6.3. Downgrades": "Signing a bad response can affect more users than simply serving a bad response, since a served response will only affect users who make a request while the bad version is live, while an attacker can forward a signed response until its signature expires. Publishers should consider shorter signature expiration times than they use for cache expiration times."
  - realusername 6y ago
    I see indeed, I don't think they are going with the right approach here, there should be an automatic way to upgrade signed content / check for updates, short signatures just destroys the benefits of the feature.
    - foepys 6y ago
      It's the only way to do it. TLS has shown that OCSP and the likes are not adding significant security and short certificate expiration is the only way to go. The serving nodes are not necessarily under control of a well intended party that complies with upgrade requests.
gregable 6y ago
Not continuously. The signed content includes an expiration date, which the publisher controls. This expiration can also never be set more than 7 days in the future.

by jhhh 6y ago

Going to also spawn a whole new class of semi-persistent malicious pages (say created via XSS) that once signed and captured can be continuously replayed to clients until expiration.

CGamesPlay 6y ago

What? The signing allows the content to be mirrored in other locations with guarantees about consistency. It doesn't imply anything more about the content than SSL does.

8organicbits 6y ago
If Google AMP is acts like a cache of content, then cache poisoning attacks are a concern. How those cached items expire will determine how long an attacker who poisons the cache can serve malicious content.
- CGamesPlay 6y ago
  Why does Archive.org get a pass on this one? Signed responses mean that there's a very clear way to leverage the browser's domain blacklisting technology to stop the spread of malware, which isn't presently possible for any content mirrors on the web.
  - 8organicbits 6y ago
    Archive.org makes it clear you are on archive.org. The URL shows archive.org. The page content shows archive.org at the top. [1] Google AMP doesn't show Google on the page. Google is pushing for the URL to show the origin site's URL instead of Google[2]. If an attacker poisons a nytimes.com article served by Google AMP, how does a browser's domain blacklisting help? Block google? Block nytimes.com? Neither makes sense. 1. https://web.archive.org/web/20050401090916/http://www.google.com/ https://web.archive.org/web/20050401090916/http://www.google... 2. https://9to5google.com/2019/04/18/apple-mozilla-google-amp-signed-exchanges/ https://9to5google.com/2019/04/18/apple-mozilla-google-amp-s...
    - CGamesPlay 6y ago
      I believe you might be misunderstanding the idea behind signed exchanges. To be clear, Signed Exchanges are how AMP should have worked all along. example.com generates a content bundle and signs it. Google.com downloads the bundle and decides to mirror it from their domain. Your browser downloads the bundle from google.com, and verifies that the signature comes from example.com. Your browser is now confident that the content did originate from example.com, and so can freely say that the "canonical URL" for the content is example.com. Malicious.org does the same thing, and the browser spots that malicious.org is blocked. At this point it doesn't matter if the content came from google.com, because the browser knows that the content is signed by malicious.org and so it originated from there. Hope this helps clarify. Obviously blacklisting isn't a great security mechanism; my point is just that signed exchanges don't really open any NEW vectors for attack.
      - remexre 6y ago
        I think the concern was more that if I can XSS example.com, Google is now serving that for some period of time after example.com's administrators notice + fix this. (In the absence of a mechanism to force AMP to immediately decache the affected page(s), that is.)
        dillonmckay 6y ago
        Yes, at what point does example.com lose control of their content and for how long?
      - 8organicbits 6y ago
        I'm following. Imagine that example.com builds the bundle by pulling data from a database. If an attacker can find a way to store malicious content in that database (stored XSS) and that content ends up in a signed bundle that Google AMP serves (similar to cache poisoning) then users will see malicious content. When the stored XSS is removed from the database, Google AMP may continue to serve the malicous signed bundle. So an extra step may be needed to clear the malicious content from Google AMP. How exactly the attacker influences the bundle is going to be implementation dependent, so some sites may be safe while others are exploitable.
- entire-name 6y ago
  At that point, wouldn't the approach be to defend from the client side? Namely, we can instruct the client to not trust any content sign by such-and-such keys. This can be done by pushing out a certificate revocation, etc.
  - judge2020 6y ago
    This would be pretty cool (remotely revoking signed exchanges), however it's not part of Google's proposal - Unless every previous security consideration about caches is accounted for in SX's, it's probably not safe to start faking the URL bar.
  - gregable 6y ago
    Certificate revocations do apply to signed exchanges.
vinay_ys 6y ago
Along with signing, we need explicit content cache busting and explicit allowed mirrors list (which can be revoked instantly). Then it would be at par with TLS + current cache busting mechanisms on top of TLS.
- londons_explore 6y ago
  As long as javascript on the page has some way to inspect the signatures and where it was delivered from, you can implement cache busting, allowed mirrors, and invalidation yourself however you please.

realusername 6y ago

I don't see how this tech would further help to make malicious pages created with XSS, any thoughts? It sounds like it's the same issue with or without signed exchanges.

sk5t 6y ago
Parent considers that the feature could be used to turn a temporary problem into a long-term problem. Sort of like how certificate pinning could be twisted to ransom an entire domain.
jhhh 6y ago
The point wasn't that this technology would uniquely enable XSS attacks, but rather that it could allow malicious actors to persist particular attacks for the duration of the validity of the signed content. Any brief vulnerability in a website now becomes serializable. They considered this already. Look in the draft "6.3. Downgrades": "Signing a bad response can affect more users than simply serving a bad response, since a served response will only affect users who make a request while the bad version is live, while an attacker can forward a signed response until its signature expires. Publishers should consider shorter signature expiration times than they use for cache expiration times."
- realusername 6y ago
  I see indeed, I don't think they are going with the right approach here, there should be an automatic way to upgrade signed content / check for updates, short signatures just destroys the benefits of the feature.
  - foepys 6y ago
    It's the only way to do it. TLS has shown that OCSP and the likes are not adding significant security and short certificate expiration is the only way to go. The serving nodes are not necessarily under control of a well intended party that complies with upgrade requests.

gregable 6y ago

Not continuously. The signed content includes an expiration date, which the publisher controls. This expiration can also never be set more than 7 days in the future.