4 ms·

Not defending the standard, but I guess since this is a shared secret you don't want to put it at a well known location. There's a (slight) attack vector from h

Not defending the standard, but I guess since this is a shared secret you don't want to put it at a well known location. There's a (slight) attack vector from having an attacker know the secret, since they can "launch" a crawl against a site. Maybe could get a crawler to access private URLs or something? Another interesting feature I saw in the standard is that you can host keys in subdirectories too. "the location of a key file determines the set of URLs that can be included with this key. A key file located at http://example.com/catalog/key12457EDd.txt http://example.com/catalog/key12457EDd.txt can include any URLs starting with http://example.com/catalog/ http://example.com/catalog/ but cannot include URLs starting with http://example.com/help/ http://example.com/help/."

orf 4y ago
This wouldn’t be in a place like “.well-known/secret-key”, the key would still be part of the path. It’s just a well known prefix to put exactly this kind of thing.
- richdougherty 4y ago
  I was going to say that well-known is only for stable paths, where you want to avoid collisions, not for paths with random keys... but you're right: https://www.rfc-editor.org/rfc/rfc8615#section-3 https://www.rfc-editor.org/rfc/rfc8615#section-3 Registrations MAY also contain additional information, such as the syntax of additional path components, query strings, and/or fragment identifiers to be appended to the well-known URI, or protocol- specific details (e.g., HTTP [RFC7231] method handling). So it could be: /.well-known/index-now/<key> IndexNow would need to change the semantics of how they handle directories, as a key authorises only subdirectories. I also notice there is an option for changing the filename of the IndexNow key file, but there is less flexibility about the directory it's hosted: https://<searchengine>/indexnow?url=http://www.example.com/product.html&key=af4c4e043c7d42afad6bdeeda948527d&keyLocation=http://www.example.com/myIndexNowKey63638.txt This seems like a potential vulnerability as if an attacker knows a text file path that contains a known (hex?) string it looks they could use it as a key?

orf 4y ago

This wouldn’t be in a place like “.well-known/secret-key”, the key would still be part of the path. It’s just a well known prefix to put exactly this kind of thing.

richdougherty 4y ago
I was going to say that well-known is only for stable paths, where you want to avoid collisions, not for paths with random keys... but you're right: https://www.rfc-editor.org/rfc/rfc8615#section-3 https://www.rfc-editor.org/rfc/rfc8615#section-3 Registrations MAY also contain additional information, such as the syntax of additional path components, query strings, and/or fragment identifiers to be appended to the well-known URI, or protocol- specific details (e.g., HTTP [RFC7231] method handling). So it could be: /.well-known/index-now/<key> IndexNow would need to change the semantics of how they handle directories, as a key authorises only subdirectories. I also notice there is an option for changing the filename of the IndexNow key file, but there is less flexibility about the directory it's hosted: https://<searchengine>/indexnow?url=http://www.example.com/product.html&key=af4c4e043c7d42afad6bdeeda948527d&keyLocation=http://www.example.com/myIndexNowKey63638.txt This seems like a potential vulnerability as if an attacker knows a text file path that contains a known (hex?) string it looks they could use it as a key?