Allow to mark properties that do not allow security testing ("Permission")

[koto]

Organizations running bug bounty programs often have vendor- or partner- owned properties that are not in scope of such programs for organizational/legal reasons. It's not trivial for the bughunters to identify such properties - sometimes they are branded as the main company, hosted in their IP space, and/or share the DNS domain space. A common example is e.g. a vendor-operated ticketing system, webmail system, or a marketing site hosted in a 3rd party. See this for a better description of this issue.

While it's not trivial to enumerate such sites for large organizations, it might be feasible to use the security.txt field to express that a given property is not "covered" by a bug bounty/VRP i.e. the owner of the application does not grant permissions for unauthorized security testing it. Something like Get-Off-My-Lawn: please setting (of course the naming would need to change). This is much easier to manage, as the domain names for various partner-owned services change constantly, and usually without sync with the teams managing BB/VRP (after all, they're not covered by such programs in the first place).

Note that this is different situation from just not exposing a security.txt file. Security contact might exist for the web property, but there's no upfront permission given for the testing, for whatever reason.

This would help the companies running large BB/VRP programs annotate such properties, and bughunters would be able to confirm the scope before starting their tests.

[hackerfactor]

I understand what you're proposing. However, this kind of detail could be included in the URL pointed to by the "Disclosure:" field. I assume that this revised field (with the URL) will be for instructions about how to submit, what to submit, response times, etc.

[koto]

Disclosure means just that - a pointer to instruction on how one would go about disclosing a security issue found in a website.

The intention of the proposed field is different - to be able to specify if security testing is even permitted by the website owners. For example, this might be a pointer to a BB program rules, but I'd prefer if it was possible to also specify null rules of engagement i.e. no testing unless it's been pre-authorized as part of e.g. a pentesting contract.

It is possible to have both a 'null' rules of engagement and a contact field for disclosure. In fact, that's usually a default for most websites. There is no bug bounty program i.e. they don't technically allow one to test, but in case you found something, they'd probably rather want to know about the issue to fix it.

[austinheap]

Maybe a Scope directive similar to the Contact directive where there can be one or many? For example:

Scope: mysite.com
Scope: *.mysite.com
Scope: !google-apps.mysite.com

[hackerfactor]

The "Scope" idea assumes that the disclosure are related to web servers and not products.

consider the bug bounty system offered by United Airlines. Web sites were fair game, but exploits impacting aircraft or other people's personal information were out of bounds. This can't be captured by a "Scope" directive. It's best to leave the scope up to the description at the 'Disclosure' url.

[austinheap]

The "Scope" idea assumes that the disclosure are related to web servers and not products.

I would suggest that "Scope" would be related to any type of server (not just web) but agree that it cannot cover 'real world' or physical scopes. Despite the inability for a "Scope" directive to cover 100% of possible scopes, I'd still argue that it covers what the majority of bug bounty programs need when defining the scope of their program.

To me disclosure policies are != scope of security program. On the receiving end (i.e.: those running bug bounty programs) providing a quick and easy way to understand what hostnames are and are not in scope is of huge benefit. I can't even tell you the number of HackerOne reports I've had to close because they weren't in scope which was already clearly laid out in the long form disclosure policy.

TLDR 1) I agree that a 'Scope' directive can't cover everything 2) I'd suggest it can cover the vast majority of needs despite the edge cases and 3) adding a Scope directive provides a structured way to better inform consumers of security.txt as to what it does and does not apply to.

Edit: it also appears re: #32 that the Disclosure directive is going away.

[koto]

'Scope' is very bug-bounty-specific - it doesn't mean anything outside of that context, and may be a bit unclear to non-bughunters. We'd prefer something that clearly mentions testing is not welcome for this particular domain (it doesn't need to be granular like the scope). That said, we could leverage the Notes field for such purpose - our need just feels like a common thing across different security reward programs, hence I filed this issue.

I don't mind the presence of the Scope directive, but I don't think we'd use it. It's probably easier for us to use the security.txt more like a pointer to actual rules & contact information, than a machine-parsable representation of the program scope. Both rules and the scope change in time, sometimes more often then our ability to push the update to various servers throughout various companies, and having potential problems with out-of-sync rules benefits noone in the ecosystem :/

[austinheap]

It's not trivial for the bughunters to identify such properties - sometimes they are branded as the main company, hosted in their IP space, and/or share the DNS domain space.

I believe a Scope directive would cover this. It would allow the hoster of the security.txt file to differentiate between their properties, including those that are branded as the main company but hosted by third parties.

'Scope' is very bug-bounty-specific - it doesn't mean anything outside of that context, and may be a bit unclear to non-bughunters.

The original issue was -- correct me if I'm wrong -- how to inform bug bounty hunters of what is and is not in scope. Additionally it might be helpful to define what the security.txt file actually applies to.

Something like Get-Off-My-Lawn: please setting (of course the naming would need to change).

Getting third party vendors to add something to indicate they are not in scope is... I'd suggest... out of scope of this project. In my experience with third party vendors you can barely get them to do anything unless you're one of their whale customers. (Apologies if I'm misunderstanding your suggestion!)

Both rules and the scope change in time, sometimes more often then our ability to push the update to various servers throughout various companies, and having potential problems with out-of-sync rules benefits noone in the ecosystem :/

Part of the goal of security.txt (as I understand it) is to define via spec the parameters of a security program for a given domain. As a companies' security program changes, their security.txt should be updated to reflect those policies.

As clarified by @EdOverflow: "The current spec means that if a company updates their policy there is no need to update the security.txt file. Only if the destination changes does a company need to update the file."

I'm certainly not suggesting that Scope be a required declarative. It could be optional and tied to a previously accepted spec like RFC4501 (Domain Name System Uniform Resource Identifiers).

[koto]

I believe a Scope directive would cover this. It would allow the hoster of the security.txt file to differentiate between their properties, including those that are branded as the main company but hosted by third parties.

That assumes that a single file refers to multiple web properties (e.g. refers to all applications on subdomains or even other domains). I don't think we'd use it like that, as that only introduces more potential for conflicting rules. If security.txt mentions what are security-relevant rules for that particular origin, that's much more clear.

The original issue was -- correct me if I'm wrong -- how to inform bug bounty hunters of what is and is not in scope. Additionally it might be helpful to define what the security.txt file actually applies to.

Not how I understand it. It may be used by bounty hunters, but I think it needs to be defined in separation of bounty programs - it's about security response and security contacts for an origin. That's more generic and still allows bughunters to get the much needed info like a) can I test this site? b) what are the rules? c) where do I file a bug?

you can barely get them to do anything unless you're one of their whale customers.

Might be, might be not. That at least gives them the opportunity to inform the wide public they'd rather not be tested. I can assure you the sheer amount of unintended noisy and WAF-triggering traffic from bughunters & scanners might be the reason enough to add the file. Plus there's contractual agreements as well that might give some an upper hand.

Part of the goal of security.txt (as I understand it) is to define via spec the parameters of a security program for a given domain.

Again, not the way I see it. If companies would rather keep the security.txt for all their properties in-sync, that's fine with me, but I think it might be more practical to keep one instance of the canonical rules, and have the files refer to that. So any rules that describe the very details of the program (what vulns are OK to report, which subdomains are not OK to test etc.) would need to be optional.

[austinheap]

@kokto All fair points! I somewhat assume security.txt -- if located on the top level domain -- is supposed to apply to subdomains too. For example, if there's a non HTTP(S) service running on subdomain.mycompany.com , I would be able to put it into scope or out of scope via the security.txt located at mycompany.com/.well-known/security.txt.

Maybe @EdOverflow can clarify the relationship between a security.txt file hosted on the top level domain and how it applies to subdomains?

[nightwatchcyber]

See also: https://tools.ietf.org/html/draft-foudil-spss-00

[EdOverflow]

@nightwatchcyber and I have decided to go with Permission: none in version -04 of the draft.

[EdOverflow]

Done in https://github.com/securitytxt/security-txt/commit/a6df9ca990c05d5040081ff1affdd5f70f12709a.

[RobertKosten]

Hi, I brought this up in #132: As far as I understand the permission property, the only allowed value (none) has the exact same meaning as the absence of the property, namely 'no permission'. Until there are more values for the property I'd advocate dropping it from the RFC, as its presence currently has no meaning over its absence.

That said: I'd be very much in favour of adding more values to it, but only if they have some legal value to the security researcher, so they can point to it in court should they end up there; otherwise it would be useless to them. And usefulness to the researches is what this whole thing is about, right? That also means that adding that property will require discussions between the legal and security departments, but so do bug bounties and a million other things we do.

[davidmays]

I do not believe a single permission attribute value can sufficiently convey anything of a legal nature.

Maybe this could be a URL to a document describing the permission policy of the organization. Or it could be a URL to a form where permission may be sought by a researcher.

On Wed, Dec 5, 2018, 22:49 RobertKosten <notifications@github.com wrote:

Hi, I brought this up in #132 https://github.com/securitytxt/security-txt/issues/132: As far as I understand the permission property, the only allowed value (none) has the exact same meaning as the absence of the property, namely 'no permission'. Until there are more values for the property I'd advocate dropping it from the RFC, as its presence currently has no meaning over its absence.

That said: I'd be very much in favour of adding more values to it, but only if they have some legal value to the security researcher, so they can point to it in court should they end up there; otherwise it would be useless to them. And usefulness to the researches is what this whole thing is about, right? That also means that adding that property will require discussions between the legal and security departments, but so do bug bounties and a million other things we do.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/securitytxt/security-txt/issues/30#issuecomment-444756148, or mute the thread https://github.com/notifications/unsubscribe-auth/ABcK_LIww0s2JEVJnLFhO30PyolEz2eSks5u2K_NgaJpZM4PxSea .

[RobertKosten]

@davidmays Fair point. I do think it could be done, if we could get a legal specialist to craft the equivalent of Creative Commons for this situation, but a link always works :+1:

My main criticism however is that as currently specified permission serves no useful purpose and should be removed until sufficient consensus on how it can provide value is achieved. As it is it is pointless at best and very confusing at worst.

[nightwatchcyber]

For IETF standards, we are using the values defined in RFC 2119: https://tools.ietf.org/html/rfc2119

I think what may make the most sense is the language of "SHOULD NOT" or "NOT RECOMMENDED:

This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

What this would mean is that if the field is present, people who read the file SHOULD NOT do any testing unless they understand the full implications of what they are doing. The intent is for publishers to signal to consumers of the file that testing is not recommended. Absence of the directive only means that the publisher isn't providing any guidance around testing at all. We specifically excluded legal implications since those can get the entire effort buried pretty quickly.

The closest equivalent to this would be the DNT - Do Not Track header in the HTTP protocol, which also signals the intent of the user but is more of a recommendation rather than an absolute; and also has no legal value: https://w3c.github.io/dnt/drafts/tracking-dnt.html#dnt-header-field

The DNT header field is a mechanism for expressing the user's tracking preference in an HTTP request

In the absence of regulatory, legal, or other requirements, servers MAY interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances. Likewise, servers might make use of other preference information outside the scope of this protocol, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol.

Now, I do agree that the way the Permission field and its value is currently written isn't great, perhaps a better approach would be along what the DNT field is doing with valid values of "yes", and "no" or "true" and "false".

[nightwatchcyber]

Because there is no consensus on the behavior of this field, @EdOverflow and myself agreed to remove this from the -05 draft. If consensus is reached in the future, it can go back into the draft if it is not yet published as RFC, or be registered in the IANA registry.