task - define and check usage of host and domain

[elarlang]

Task from #978 (comment), pointed out by @timhemel

Define for ASVS what is meant by "Host", "Domain" or "Host or Domain" and check that entire document and every requirement follow it.

[danielcuthbert]

This is a good catch. I like the suggestion and I wonder the best way to do this? There's no appendix so is there a need to define it in the beginning or can we define it upon first use of the term?

[elarlang]

I just made the task to not forget it :)

I think it's enough to describe them both in: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x90-Appendix-A_Glossary.md

and just check and validate, that all requirements and entire document follow those definitions.

[elarlang]

Collecting sources:

https://developer.mozilla.org/en-US/docs/Web/API/Location

• host - Is a USVString containing the host, that is the hostname, a ':', and the port of the URL.
• hostname - Is a USVString containing the domain of the URL.

[jmanico]

Sources that show the variance over time when it comes to these terms: https://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces

[elarlang]

Seems mission impossible and close?

[jmanico]

Origin: Two URLs have the same origin if the protocol, port (if specified), and host are the same for both https://datatracker.ietf.org/doc/html/rfc6454#section-3.2

Host: The same RFC above also says: "If user agents did not include the scheme, there would be no isolation between http://example.com and https://example.com because the two have the same host." from this I think we can deduce what host is.

Domain: is just site.com - what you register.

[elarlang]

Found requirements:

Requirement contains "Host":

• V3.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.

Requirement contains "Domain":

• V1.12.2 Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file.
• V3.4.5 Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible.
• V5.2.6 Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.
• V10.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.
• V14.4.5 [MODIFIED] Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=31536000; includeSubdomains.
• V14.4.8 [ADDED] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains. Where "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information.
• V14.5.3 [MODIFIED] Verify that the Origin header is validated against defined list of allowed domains to meet the Cross-Origin Resource Sharing (CORS) policy.

Requirement contains "Origin":

• V4.2.3 [ADDED] Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid.
• V13.5.2 [ADDED] Verify that, during the initial HTTP WebSocket handshake, the Origin header is checked against an allow list of authorized origins.
• V14.4.8 [ADDED] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains. Where "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information.
• V14.5.2 Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker.
• V14.5.3 [MODIFIED] Verify that the Origin header is validated against defined list of allowed domains to meet the Cross-Origin Resource Sharing (CORS) policy.

From this list for me it seems, that 14.4.8 and 14.5.3 may need update.

Proposals:

• V14.4.8 [ADDED] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted origins. Where "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information.
• V14.5.3 [MODIFIED] Verify that the Origin header is validated against defined list of allowed origins to meet the Cross-Origin Resource Sharing (CORS) policy.

[jmanico]

My small edits:

V14.4.8 [ADDED] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information.

V14.5.3 [MODIFIED] Verify that the Origin header is validated against a defined list of allowed origins to match the desired Cross-Origin Resource Sharing (CORS) policy.