Request for Reevaluation of ASVS Item 10.3.3 Related to Subdomain Takeovers

[ImanSharaf]

I am writing to address an issue in the ASVS, specifically section 10.3.3, which concerns protections against subdomain takeovers. While the intent of ensuring security is commendable, I believe this particular item is more pertinent to the domain of infrastructure security rather than application security.

• ASVS Item 10.3.3 currently mandates verification that applications have protection from subdomain takeovers, focusing on elements such as DNS entries, expired domain names, outdated DNS pointers, CNAMEs, etc.
• This requirement extends into the realm of infrastructure management, involving elements typically beyond the control or scope of application-level security measures.

Recommendation:

I propose that section 10.3.3 be revisited and potentially moved to a more appropriate set of standards focused on infrastructure security.

[csfreak92]

I want to add something to ponder about: isn't database-related stuff also similar to this in some way that it is beyond the realm of the application and could be considered borderline infrastructure security? I believe I saw some database column/field-level encryption proposal before.

[ImanSharaf]

Most of the time field-level encryption is being implemented on the application side.

[elarlang]

Current 10.3.3:	#	Description	L1	L2	L3	CWE
10.3.3	Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.	✓	✓	✓	350

(as we probably going to move things around, please always copy-paste current requirement as it is)

[elarlang]

From content wise, I agree that the requirement text is beyond the application responsibility and scope. One application can not defend itself against subdomain takeover.

What an application can do, is using trusted DNS solution. Should we cover it somehow in this or separate requirement?

[jmanico]

"Trusted DNS" is not a solution to subdomain takeover; no security protocol can address this issue. The responsibility lies with teams managing DNS to disable subdomains no longer utilized by service providers.

This issue arises when a subdomain is configured for a service like AWS and, following the expiration of the AWS subscription, the subdomain continues to point to AWS. This leaves it vulnerable to takeover by others.

[tghosth]

Ooh this is a tricky one.

By the simple definition of ASVS scope, this is not in scope for ASVS. Generally, application developers don't have direct control over this. See how we removed the backup requirements: https://github.com/OWASP/ASVS/issues/1462

On the other hand, it is quite a widespread problem...

[danielcuthbert]

100% agree, this is not part of the application scope and wanders into others lanes. It is a problem but it isn't an appsec problem.

[jmanico]

The thing is, developers often manage the service accounts (like AWS) that expire and then causes this issue. They might not manage the DNS, but it is allowing the 3rd party account to expire that causes this problem in the first place, since the DNS team rarely has access to the service account that expired...

[ImanSharaf]

Most of the time, when I ask developers, they don't have any idea and they refer me to devops (AWS, Azure,...) or infrastructure teams. That's one of the reasons that I believe this is out of scope.

[csfreak92]

@ImanSharaf, maybe you can add this subdomain takeover solution/requirement in an OWASP cheatsheet or guide somewhere if we will remove this in ASVS since it is kind of out of scope, but since it is a widespread problem as mentioned by @tghosth it is a good idea to keep it somewhere so that the good information isn't lost.

I am not sure where it is, but don't we have an infrastructure guide somewhere?

[elarlang]

Like I said, this requirement as it is written at the moment, is clearly out of scope.

The question is, should we cover any points or problem it from other point of view. Like "if the application relies" - should the application rely on mentioned things and maybe we need to cover this part somehow (or to be sure, it is already covered)

[csfreak92]

I think I have answered that by recommending to cover it somewhere (but not in ASVS) like in a cheatsheet or any other OWASP guides out there since if it is something the application relies on such as infrastructure-related matters it should be out of scope of ASVS. Don't you agree?

[elarlang]

I pointed out "the application relies" topic, and if application relies on wrong things, then it should not to. This is kind of in topic, as you can choose maybe some different solution for the application.

[ImanSharaf]

Even with "if the application relies upon DNS entries or DNS subdomains", application would not have any control over any DNS or subdomain misconfigurations.

[EnigmaRosa]

100% agree, this is not part of the application scope and wanders into others lanes. It is a problem but it isn't an appsec problem.

I do believe it is, to some extent, an appsec problem. Mostly because subdomain takeover can allow an attacker to get access to an application's resources such as user session cookies.

Is this perhaps something that would be worthwhile changing the associated verification level?

[elarlang]

100% agree, this is not part of the application scope and wanders into others lanes. It is a problem but it isn't an appsec problem.

I do believe it is, to some extent, an appsec problem. Mostly because subdomain takeover can allow an attacker to get access to an application's resources such as user session cookies.

Some clarifications for this.

To access session cookies from other subdomain, it means application cookie setup must be clearly wrong - to use Domain value to common (effective) domain name and it is already against ASVS requirement 3.4.4 which does not allow to use Domain attribute and forces using "host-only" solution for cookies:	#	Description	L1	L2	L3	CWE	NIST §
3.4.4	Verify that cookie-based session tokens use the "__Host-" prefix so cookies are only sent to the host that initially set the cookie.	✓	✓	✓	16	7.1.1

This __Host- prefix solution also takes away option to override cookie with the same name from another subdomain. Even if the __Host- is not used and overriding the cookie from another sub-domain is possible then against session fixation we have another requirement:	#	Description	L1	L2	L3	CWE	NIST §
3.2.1	[MODIFIED] Verify the application generates a new session token on user authentication, including re-authentication, and terminates the current session token. (C6)	✓	✓	✓	384	7.1

To address site-isolation problem from browser communication perspective new requirement is proposed via https://github.com/OWASP/ASVS/issues/1299:	#	Description	L1	L2	L3	CWE
50.1.1	[ADDED] Verify that separate applications are hosted on different hostnames so as to benefit from the protections provided by the "same origin policy" and the hostname restrictions on cookies.	✓	✓	✓	668

Is this perhaps something that would be worthwhile changing the associated verification level?

So based on explanation above, maybe the base for the argument was not valid or is just already covered/addressed in ASVS.

[elarlang]

I try to conclude that at the moment - DNS is out of application control and I agree with @ImanSharaf proposal to remove this requirement as out of scope.

To arguments like "but application relies on DNS" - yes, that's true, but it's out of application's responsibility to fix it. The same way an application relies on internet connection but we don't put this to ASVS.

My current vision is: in ASVS we have only requirements for the components, which are responsible to produce the HTTP responses and process the data - which means application itself, load-balancers/WAF (only if they do some extra defense, modify request and/or response or provide HTTP responses themselves (error situations).

Ping @tghosth @jmanico @EnigmaRosa - does it make sense for you or you have some arguments against this move?

[tghosth]

To be clear, whilst the impact relates to the application, practically speaking the control is probably not with the developers control which is why we want to remove it @EnigmaRosa.

@csfreak92 do we have enough content to justify a cheatsheet?

[csfreak92]

do we have enough content to justify a cheatsheet?

@tghosth, if this subdomain takeover control can be bundled with other infrastructure-level requirements/controls then I would say that is a good idea to justify a cheatsheet, in case. Aren't we considering removing/have removed other infra-level controls in ASVS? Maybe they can go together as one cheatsheet as an idea.

[elarlang]

If @ImanSharaf want to go for PR, the line for 10.3.3 want to be:

| **10.3.3** | [DELETED, NOT IN SCOPE] | | | | |

[ImanSharaf]

Done. https://github.com/OWASP/ASVS/pull/1792

[EnigmaRosa]

To be clear, whilst the impact relates to the application, practically speaking the control is probably not with the developers control which is why we want to remove it @EnigmaRosa.

Yup, I see. Thanks for clarification.

[elarlang]

So, the requirement is removed now.

The question for me is - should we have requirement for addressing the issue from another perspective like "Verify that the application should not rely on x-y-z".

Similar like we have in section V14.2 Dependency.

[jmanico]

The problem is not the application relying on some tech, the problem is just bad DNS management. When a service expires and the DNS team doesn't bother to remove that subdomain DNS entry....

... there are tools that scan for this now. And this is more of a problem for an enterprise vs an app-specific problem.

[elarlang]

I close this now. If there is a need to cover it from some other angle that is in ASVS scope, then we can open a new issue.

[tghosth]

do we have enough content to justify a cheatsheet?

@tghosth, if this subdomain takeover control can be bundled with other infrastructure-level requirements/controls then I would say that is a good idea to justify a cheatsheet, in case. Aren't we considering removing/have removed other infra-level controls in ASVS? Maybe they can go together as one cheatsheet as an idea.

@csfreak92 perhaps but a cheatsheet can also start quite small. Alternatively, maybe it can be added here: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html