-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scope field #213
Comments
We must be very careful which domain names are capable of extending their scope to which other domain names. We must avoid this sort of attack:
which would allow the attacker to harvest vulnerability reports intended for the victim site. |
I think other domains and IP addresses should probably be left out of the Scope field (fetching a security.txt over HTTPS using an IP address URL shouldn't work anyway). It would be sufficient to declare that the security.txt is applicable to subdomains also. |
I would like to bring this issue to the attention again. Since the RFC currently states that a security.txt record only applies to the domain from the URL it was retrieved from (i.e. https://example.com/.well-known/security.txt only applies to example.com but not to subdomain.example.com) this causes major overhead for organizations (in my opinion). Why this is a problem?Let's say we have an organization with a domain containing X sub-domains that all point to different systems with a different IP address. Since the current RFC states that security.txt file only applies to the exact domain being queried, this means that for each of these sub-domains to be covered by a security.txt record, each of those X systems behind these sub-domains would need to set up a webserver to either serve the security.txt itself or to do any redirection. There are many systems within organizations that do not always run a webserver, so the extra overhead on setting up these webservers solely to serve a security.txt is quite a lot. These systems also have to be maintained, and the security.txt records would have to be updated as well, which creates an extra burden on the organization and might increase the attack surface of an organization as well. Depending on how large the number X is (amount of sub-domains and systems) this can become quite hard to manage. Proposed Solution 1: Change the RFC and make security.txt cover sub-domains.The most simple solution would be to change the RFC to specify that a security.txt record applies to it's sub-domains as well, unless the sub-domain specifies a security.txt record on it's own (this would then override the security.txt record of the parent). Advantage:
Downside:
Proposed Solution 2: Extend the RFC and add a "scope" field.Another solution would be to extend the RFC with a "scope" field which specifies if sub-domains are covered as well. Security.txt file from: https://example.com/.well-known/security.txt
Advantage:
Downside:
Proposed Solution 3: Extend the RFC and add a "cover-subdomains" field.Another option would be to add a Security.txt file from: https://example.com/.well-known/security.txt
Advantage:
Downside:
I am looking forward to feedback, and whether or not other people recognize this as a problem! |
The most appropriate option for extending the original RFC is via a new field. Changing the RFC itself will take too long, so options 2 or 3 would be the best fit |
Thank you DevQps for pointing this out and bring it to attention again, since we also think this should be improved in the RFC. Proposed solution 1 would be the easiest and most preferable in our opinion, however we are not fully aware of what kind of change process and time this would take to get it changed in the RFC. If solution 1 cannot be implemented solution 3 would be the next best of your proposed solutions. But you could also think of a solution 4 and 5 which is a combination of the solutions that you did suggest. Solution 4: Combine solution 1 and 2. Solution 1 to cover all subdomains by default under security.txt of the first level domain name. The scope field is added as optional, and allows you to to specify the scope if you want so. Solution 5: Combine solution 2 and 3. In that case you could make the field "cover-subdomains" required and the "scope" key field optional. I can imagine that some organizations with specific use cases do want to make a distinction, in that case they are free to use the optional field. Which ever solution you take, the RFC should also specify the prioritization in which security.txt has the most authority above other. For example test.example.com has a own security.txt and example.com has a security.txt. I would say that for test.example.com, the priority security.txt is the one on test.example.com. If security.txt is missing from test.example.com, the one on example.com should be used for test.example.com. The priority of the security.txt is the one on the most specific domain name (the one including the subdomain(s)) to the least specific domain name. |
@DigitalTrustCenter @nightwatchcyber Are you both interested in holding a meeting about this to try to work toward an extension for this? |
good idea! let's wait for the response of nightwatchcyber. |
Feel free to put together a proposal, however, the security concerns regarding a domain impacting its subdomains are not trivial and this is the reason why we dropped this functionality from the RFC |
In my opinion there is added complexity when dealing with subdomains that are delegated to a different zone by for example a CNAME record. Ideally, I think, a security.txt url would be bound to the domain by dns, either as a txt record for a given domain or subdomain, or by rdns or whois/rdap for a given ip-address or range. N.B. it is possible to obtainan ssl cert for ip-addresses. but its very uncommon. |
The text was updated successfully, but these errors were encountered: