Effectiveness of ASVS-4.0.1-3.4.5

[timhemel]

| 3.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. (C6) | ✓ | ✓ | ✓ | 16 | 7.1.1 |

1. If I understand the semantics of the path attribute correctly, the strictest value is realized by not specifying it at all. Of course if a scripts sets a cookie that applies to a parent path, you will need to specify it explictly.

2. Setting the path attribute would only protect against disclosing the cookie, not against overriding it, as any path on a host can set a cookie for any other path. According to RFC 6265:

   Even though the Set-Cookie header supports the Path attribute, the
   Path attribute does not provide any integrity protection because the
   user agent will accept an arbitrary Path attribute in a Set-Cookie
   header.  For example, an HTTP response to a request for
   http://example.com/foo/bar can set a cookie with a Path attribute of
   "/qux".  Consequently, servers SHOULD NOT both run mutually
   distrusting services on different paths of the same host and use
   cookies to store security-sensitive information.

[jmanico]

The poster here is making a good point. Path has minimal value. 1) A subdomain can CSRF the main domain 2) Any path on the host can set a cookie for any other path, as the posted described I suggest we just delete this requirement. It's not helpful. - Jim

[elarlang]

First priority - use __Host- prefix.

IF this is not possible AND there are many applications on the same domain which all may want to use JSESSIONID for example, you need to specify as precise Path attribute as possible to avoid value leakage to another paths and to keep applications working.

Similar discussion, see: #555 (comment)

Till we don't have requirement like "one application per domain", we need to have this requirement.

[Sjord]

other applications that set or use session cookies
that might override or disclose the session cookies

This requirement only applies in the specific case if multiple applications use session cookies and could overwrite each other's session cookie. This seems more of an integrity issue where applications have accidental interaction. The goal of this requirement does not seem to block access between applications.

[elarlang]

If a cookie has path /path1/, then how you can access it from application in /path2/ folder?

Integrity problem exists here - you can overwrite cookie with /path1/ by application in /path2/. But if there
are no nice tricks available, then you can not access it. So it's vice versa, precise path parameter requirement is for confidentiality, not for (cookie) integrity.

[jmanico]

An application in /path1/ can still CSRF the root site even if the root site uses SameSite cookies. This is not a perfect defense (or even a good defense). Subdomains controlled by an adversary are a problem. So @timhemel I suggest a PR to get rid of this requirement and then create a new one for now. We can re-address the larger issue of adversarial subdomain's in different issues and PR's.

And per @elarlang I do agree using the cookie prefix __Host- does bind the cookie to that specific host only and is a better solution. So perhaps set a new requirement in that direction instead?

[elarlang]

I suggest we have problems covered with proposals in opened issue before PR.

Multi-site situation: If you have XSS in /pathX, then yes, you can CSRF all sites on the same domain. Agree with that. It does not mean, that setting precise path to avoid session id leakage from path1 program to path2 program. Effect is minimum, but it's there.

One-site situation: let's say we have only one application per domain, __Host- does not give too much effect in this situation, just forces to use Path=/, no Domain attribute and use Secure attribute.

NIST 7.1.1

Cookies:
2. SHALL be accessible to the minimum practical set of hostnames and paths.

Let's say we have setup:

• / - static HTML
• /api/
• /static/

If you can use Path=/api/ here, browser don't need to send cookie with every request to access content from /static/. In case some JWT format in use, it may take quite a overhead in HTTP traffic.

And per @elarlang I do agree using the cookie prefix __Host- does bind the cookie to that specific host only and is a better solution. So perhaps set a new requirement in that direction instead?

Additionally, what is the "new requirement" in this direction? We have 3.4.4 asking to use __Host- prefix.

For me it seems, that @timhemel was addressing the word "override in current requirement, and I agree with that:

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.

My current proposal is to fix this requirement to technically correct one:

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 disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible.

[jmanico]

hey @timhemel does the proposal from @elarlang work for you? I like the clarification.

[timhemel]

@elarlang was correct in that I was addressing the word override. There is a minimal effect of restricting the path, and it might just make some applications a little more secure. Removing the requirement from the ASVS will make it less complete, but perhaps more practical to apply. I will leave that decision to the ASVS team. Personally I like completeness.

I have two remarks on the proposal, that could be useful for letting someone understand the requirement:

1. Restricting Path will only be relevant if there are two applications on the same host, but in different trust zones. The word domain name is a bit ambiguous and can mean an internet domain name (and not the host name), or (as done in the SOP) mean the host part of a URL. Two applications on different hosts of course do not need to restrict Path to be protected from each other. It would help to clarify how to interpret 'domain name'.
2. Not specifying Path automatically restricts it to the current directory and everything below it (default-path in RFC6265). Therefore, you generally do not need to set Path, but it does not hurt to be explicit. The case where you would need to specify Path explicitly is if you would set the cookie from a different path. For example, in the above structure, if the main page on / would set a cookie intended for /api/.

[elarlang]

Restricting Path will only be relevant if there are two applications on the same host, but in different trust zones.

Not that simple with cookies - we can not watch Path attribute separately, it all depends, is Domain attribute set or is it "host-only" cookie. If Domain is set to main domain (like .example.com), not subdomain (like api.example.com), then it leakes to another Host (another subdomain for the main domain). Domain vs Host is really underestimated problem in my opinion and that's why I see "forcing" usage of __Host- prefix as a good solution.

Prefer "host-only" over setting a Domain attribute is not covered by ASVS at the moment (if do not take __Host- requirement in account). Maybe we should address this one here also.

Not specifying Path automatically restricts it to the current directory

If you don't specify Path attribute, it depends on software which writes the cookie - I would not relay on "assumptions" and recommend always to specify path "manually".

[timhemel]

What I meant is that restricting the Path will only offer good protection in the case of multiple applications on the same host. IMO, that is what they intended Path for. For two applications on different hosts in the same domain, with the Domain attribute set on the cookie, Path will not protect against disclosure if both hosts happen to use that particular path. To protect cookie disclosure on different hosts on the same domain, restrict cookie access to just these hosts (by not setting Domain). Generally, if you intend to allow cookie access to hosts within a certain domain, you would not want to have Path restrictions. The authorization model for cookie access is indeed a bit coarse, and that is why we see newer mechanisms such as __Host- prefixes.

The semantics of Path are documented in RFC6265 and therefore not so much an assumption. Also it is the code receiving the cookie attribute that is responsible for sending the cookie to the correct paths. Then again, it seems not widely known, as this not-so-old change in .NET Core's http client software shows.

What is most important is that someone applying the ASVS gets a clear understanding of what to do: a developer needs to know what techniques to apply, a verifier needs to know whether what has been implemented is secure.

The general strategy would be:

Protect cookies from disclosure and overwriting

1. Prevent disclosure to other hosts in the same domain by leaving out the Domain attribute.
2. Prevent overwriting by other hosts in the same domain by using the __Host- prefix. (This also takes care of point 1)
3. Prevent disclosure to other applications on the same hosts by specifying Path.
4. It's impossible to protect overwriting by other applications on the same host, so avoid this situation if you can.

[elarlang]

Goals to achieve with this requirement:

• this requirement is important only when __Host- prefix can not be used.
  • situation 1 - for some reason cookie must match to multiple subdomains with Domain attribute set
  • situation 2 - there are many applications on the same host/on the main domain which may use the same cookie name
• Domain vs host
  • "host-only" is preferred over Domain attribute
  • if Domain attribute is set, use the value as precise as possible, to avoid leakage to another subdomains or to avoid to be overwrite by another subdomain (possibility to set cookie with the same name with alternative domain still stays)
• Path must be as precise as possible
  • in "many application on the same domain" situation avoid value leakage and extra traffic
  • otherwise avoid extra traffic
• to be sure that cookie was written by secure connection __Secure- prefix should be used.

... or there is material to 2-3 different requirements

[jmanico]

*Domain* is a formal term and it only means the "registerable domain" such as manicode.com *Host* is also a formal term which means everything after the protocol and before the first slash such as www.manicode.com or report.manicode.com The *origin* is the protocol + host + port such as https://www.manicode.com:443 Aloha, Jim

[elarlang]

Your definitions are not correct in cookie context.

• There is no "port" limitation for cookies. Cookie set on port 80 matching also for port 443, 8080 etc.
• There is no "schema" limitation for cookies. Cookie set over http connection matching to https connection (that's why we have Secure flag and __Secure- prefix to fix that.
• Domain in cookie context (Domain parameter) is always "opened for subdomains with wildcard". Domain=.example.com is matching for HTTP requests to deep.inside.example.com

For that reason Origin / SOP with cookie context is a bit different.

[jmanico]

Those definitions are universal. Cookies are *not* bound to the origin or protocol, they are bound to the registerable domain and path as you rightly stated! The point I am making is that a domain is a domain and a host is a host. - Jim

[timhemel]

I would like to agree with @jmanico, but RFC6265 uses domain for complete hostnames too, for example in:

             The cookie's host-only-flag is true and the canonicalized
             request-host is identical to the cookie's domain.

Therefore, it is possible to bind a cookie to a host name via the Domain attribute (but only to host names, not IP addresses), and not only to registerable domains.

The same happens in the SOP standard, where domain means the complete host part of the URL. Very confusing that they have deviated from the original meaning. That's why I think these specific ASVS requirements should make it clear. My suggestion would be to use "host" when we mean a host, and "host or domain" when we mean both. I think it will give little confusion. Not every reader of the ASVS will be familiar with the RFC jargon.

[jmanico]

My definitions of host, domain and origin above are correct according to rfc6454 section 3.2

Quoting https://datatracker.ietf.org/doc/html/rfc6454#section-3.2

Origin:

"All of the following resources have the same origin:

http://example.com/
http://example.com:80/
http://example.com/path/file

Each of the URIs has the same scheme, host, and port components."

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. It's everything between the protocol and port.

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

And PS: As @ThunderSon mentioned above, the cookie domain property can be set to a domain or a host. Keep in mind cookies came on the scene way before origin was defined in 2011, so the domain property of a cookie is really not a clear name as you rightfully pointed out.

[maizuka]

This is my opinion, which makes no changes to the current suggestion.

• this requirement is important only when __Host- prefix can not be used.

  • situation 1 - for some reason cookie must match to multiple subdomains with Domain attribute set
  • situation 2 - there are many applications on the same host/on the main domain which may use the same cookie name

I believe that in the situation 2, it maybe can protect leakage but cannot protect use of cookie from other applications, due to lack of same-origin policy. XSS at /pathX/ on the host can cause make same-origin requests to /pathY/ and take the responses out or bypass CSRF protections. This is somehow architectural point, but we should recommend different hosts (or subdomains) for different apps.

The prefix __Secure- is a good solution for the situation 1, although the cookie has the remaining integrity risks by any subdomains.

[Sjord]

@maizuka __Host- is not about multiple applications on the same origin, but about multiple applications on the same site. An application on a.example.com can set cookies for example.com, which are also sent to b.example.com. So a.example.com can forge cookies for b.example.com. But not if they have a __Host- prefix.

[maizuka]

@Sjord You are right and the __Host- prefix is available even in the situation 2 (although name duplication causes trouble). The attack surface of XSS by the same-origin apps is independent problem from cookie. I confused between using cookies among apps and getting access to cookies across apps. Thank you.

[elarlang]

Quick-fix for v4.0.3 (#978 (comment)):

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 disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible.

[tghosth]

@elarlang was this issue addressed by the PRs above?

[elarlang]

Need to re-work it through. PR's were quickfixes to remove incorrection. Discussion was a bit wider here, but did not see any potential direction for improvement.

[tghosth]

So do we need to close this for now?

[tghosth]

Hi all, I will probably close this mid-May if I don't get any further feedback.

[elarlang]

Probably we can not solve anything with "improving" this requirement - we can create many more new requirements to cover all the possible edge cases and at the end there is just more confusion.

Only way to go from here is to create requirement "one application per domain (edit) Origin".

From #978 (comment)

Till we don't have requirement like "one application per domain", we need to have this requirement.

[Sjord]

Only way to go from here is to create requirement "one application per domain".

I agree. Every application should be on its own (sub)domain, and the situation "if the application is published under a domain name with other applications" should not even be allowed.

We probably should define "application" somewhat. In this case this seems to determined by authentication and session cookie usage. For some use cases, it may be benificial to use multiple domains for the same application. E.g. host user content on another domain, so that any XSS there does not impact the main application.

I don't think it is sufficient to host every application on its own origin. Specifically, hosting different applications on different ports does not provide cookie separation. Different subdomains are needed.

[elarlang]

I was thinking Origin, when I wrote Domain. Fixed in my comment.

Using application per Origin and __Host- prefix for session cookie, it provides separation.

[elarlang]

Actually, I propose to got for it. Maybe not for Level 1 (when we talk about risk-based levels).

Need to think about wording, but idea is - there should be only one application which can read and write session cookie.

It can be achieved:

• only one application per domain
• OR one application per host + using __Host- prefix.

[Sjord]

• only one application per domain
• OR one application per host + using __Host- prefix.

Is there a significant difference between these two? Is it OK to host one app on a.example.com and another app on b.example.com, with or without __Host- prefix?

[elarlang]

Yes. the difference comes with __Host- prefix.

Let's say session cookie name is "SID". From host a.example.com it is possible to write cookie with Domain attribute value .example.com and it is matching for b.example.com. If __Host- prefix is used (cookie name __Host-SID), you can not use Domain attribute (need to use "host-only" cookies) and you can not write cookie from one subdomain for matching to another subdomain.

But this is something you also described yourself: #978 (comment)

So maybe I misunderstood the question...

[Sjord]

I would like to see a requirement to host every application on its own (sub)domain, such as marketing.example.com and customerportal.example.com. The __Host- prefix adds additional security to that, but that already has its own requirement (3.4.4).

Hosting each application on its own site (examplemarketing.com, examplecustomerportal.com) would improve cookie security, but makes also makes phishing easier. I wouldn't recommend this.

[tghosth]

@elarlang can you open a PR?

[elarlang]

As we are not going to change this requirement - it stays till we have new requirement (one application per host/origin/site). For new requirement I created separate issue (#1299) and we can close this one out.