Sec- prefix

[martinthomson]

If I had my way, the Sec- prefix would not be used as much as it is. It is not sufficient to say that because a value is populated by a user agent that a new header should use the prefix. There has to be a reason that a server might need to rely on the value in that narrow space where the user agent is honest, but the requester is not.

Here are the questions I would ask for this header:

• If I were to use fetch() to tell a server that I have storage access, but I didn't, what harm might be inflicted?
• If I were to lie about not having storage access, but I have it, what happens?

A cross-origin fetch with custom headers will have been preflighted and the works, so it's not clear that this field needs a prefix to protect servers from fetch callers who might want to make weird claims about storage access. As far as things go, this exists to allow a server to make a request or to adapt content to being in a cross-origin context where they don't have their unpartitioned cookies. Neither of those cases depends on the veracity of the value.

To that end, I would suggest a simpler design:

Requests say: Storage-Access: none|active|inactive
Responses say: Storage-Access: load|retry (plus parameters).

The set of valid values differ on each, but the symmetry would make this clearer for users.

[cfredric]

Hi Martin, thanks for the feedback. IIUC this is the same feedback you provided in the TAG review, which we discussed in #17 as well. The general opinions we expressed in that issue were:

• Since the value of the request header is virtually guaranteed to influence how servers handle security-relevant decisions involving credentials (or lack thereof), the request header is "close enough" to being security-sensitive, IMO. The prudent choice is to err on the side of safety, so IMO we ought to make the header name forbidden, regardless of whether it starts with the Sec- prefix.
  • FWIW, I tried to make that argument in the README as well; the specific scenario I described is an answer to the "if I were to lie about not having storage access, but I have it, what happens?" question you posed above.
• Considering "storage access" seems like a relatively common concept, I would be surprised if there weren't existing client/server deployments that rely on setting their own Storage-Access header, and which would break if the UA started supplying its own values for those header.

Using the Sec- prefix solves both of the above issues.

---

Since this is the second time you've raised this feedback, though, I'm wondering what downsides you see with the current spelling.

You implied above that the asymmetry between Sec-Fetch-Storage-Access and Activate-Storage-Access is a pain point that complicates the design. On the contrary, I think the fact that the two headers have different requirements and different sets of valid values is a good reason to spell them differently. I'd expect users to be more confused if the request/response headers were spelled the same; that seems like it would lead to mixups and misinterpreted documentation. So I'm not convinced that the implied benefits of identical spellings outweigh the benefits of using Sec-.

I'll point out, in addition, that we create consistency between the Fetch Metadata headers and Sec-Fetch-Storage-Access by using the Sec-Fetch- prefix. It's logical to make this request header consistent with the Fetch Metadata headers, since this header also conveys metadata about the fetch.

So, I'm curious to learn why you feel differently about using the Sec- prefix. What other problems do you anticipate due to the spelling?

[martinthomson]

I was tagged in #17, and had forgotten, sorry. I didn't participate in that conclusion, so maybe we can address the points now:

1. I don't agree that "close enough" qualifies. The value of credentials (cookies) has to be what a server uses to decide whether to authorize or not. The flows we're talking about all end when the server is sure that it has cookies.

There are cases where another site can make a credentialed request, spoofing a non-Sec- field, but I don't believe that any situation exists where the final decision does not depend on cookies or credentials.

So if someone spoofs a request and claims that storage access is active, when it is not, then the server will look at cookies, decide that the cookies are not there, because the request cannot include them, then stop. Claiming that storage access is inactive just puts a server into a loop if it wants to get storage access. Claiming that storage access is denied just hits a rejection.

You claim that a server might assume that it has already assessed the security context. HTTP is stateless, so you can't carry that decision forward. At least not safely. You might pass it via a client and a URL if you used the "retry" mode, but you can't trust clients to hold secrets like that.

2. If servers are using a header called storage-access without registering it, that's a risk they take. I don't see one registered. That argument doesn't wash with me. (I consider it more likely that they set a cookie to track that sort of thing anyway.)

Fundamentally, the idea that a browser adding Sec- to something magically confers some protection for servers is a mistake I don't like seeing repeated. Most of the value that a server derives from Sec- comes from the fact that only honest browsers are given credentials (presumably). Decisions are therefore made on the basis of the credentials that are presented, with supplementary signals (like Sec-Fetch-*) being used after that point.

That these headers will appear on every request and waste "Sec-Fetch-Storage-Access: none" bytes at a minimum is a secondary concern. That's a lot of bytes for this feature.

[cfredric]

The flows we're talking about all end when the server is sure that it has cookies.

So if someone spoofs a request and claims that storage access is active, when it is not, then the server will look at cookies, decide that the cookies are not there, because the request cannot include them, then stop.

I don't think it's as straightforward as that. A server cannot tell anything about the cookies it receives other than their names and values; in particular the server doesn't know whether a given cookie it received is Partitioned or not.

So "receiving cookies" isn't a binary signal; a server might receive no cookies, or just partitioned cookies, or both partitioned cookies and unpartitioned cookies. Since user auth cookies are (typically) unpartitioned, but there's no trustworthy signal that says "this cookie is unpartitioned", the trustworthiness of the "unpartitioned cookies are (un)available" signal is useful as a fallback.

The value of credentials (cookies) has to be what a server uses to decide whether to authorize or not. The flows we're talking about all end when the server is sure that it has cookies.

Most of the value that a server derives from Sec- comes from the fact that only honest browsers are given credentials (presumably). Decisions are therefore made on the basis of the credentials that are presented, with supplementary signals (like Sec-Fetch-*) being used after that point.

If I'm interpreting this correctly, you're basically saying "if the server receives valid auth cookies, the server ought to rely principally on those cookies, and if possible avoid relying on other trustworthiness signals to decide if the request is authorized". Am I understanding your point correctly?

If so, I think this point largely ignores CSRF attacks, and in particular CSRF attacks that abuse partitioned cookies. We should expect attackers to abuse any non-UA-controlled inputs that are available -- including setting partitioned cookies that masquerade as auth cookies. Sure, there are plenty of existing best practices for servers to avoid being vulnerable to CSRF, but providing another tool for that toolbox is a good thing.

That these headers will appear on every request and waste "Sec-Fetch-Storage-Access: none" bytes at a minimum is a secondary concern. That's a lot of bytes for this feature.

That doesn't match my understanding of https://www.mnot.net/blog/2018/11/27/header_compression. In particular:

Knowing how HPACK works, it’s easy to understand what header would compress best with it; it’s a header that, for the duration of a connection, never changes in any way. It can occur on some messages in one direction, all messages in that direction, or just a few messages, but when it occurs, it doesn’t change.
...
It’d be even better if it was small; that means that it won’t take up a lot of space in the dynamic table, so that other headers have a chance of being compressed too. This isn’t hyper-important; if it’s 20 or even 100 bytes, that’s fine, since it’s going to save a lot more on the wire.

If you think about it, this isn’t surprising; some of the most voluminous headers in requests are those that get repeated a number of times over the course of a connection; things like User-Agent, Cookie, and Referer. It makes sense that HPACK was optimised for them.

Sec-Fetch-Storage-Access fits the above description: it will rarely change, and when it does, there are still only possible 3 values that it can take, so it's likely to still be in the dynamic table (and therefore it won't actually be sent on the wire again).

HTTP/2 is 10 years old by now; it and HTTP/3 collectively comprise over 90% of Chrome's traffic (and I imagine this metric bears out for other browsers), so the perf concern about sending 10 bytes over HTTP/1.1 seems relatively minor.

[martinthomson]

I don't think it's as straightforward as that.

I do. You seem to be thinking that the storage access headers are relevant to the security decision that a server makes. I'm asserting that what is relevant is the cookies and - for XSRF - the Origin header, which tells you who is making the request.

My argument is that the storage access headers are not relevant to security decisions, they exist at a different layer entirely. They help a server determine whether the cookies they are receiving are the "right" set to start looking at. But if those cookies don't match what the header claims (and that header comes from an untrusted source, so maybe don't rely so much on that) then a server should fail closed, either by asking the client to switch cookie sets or just by sending a 4xx response. With this header, a server probably will do that before even looking at cookies and making the security decision.

Maybe there's a specific example you can share where XSRF relies on poorly-implemented servers doing something, but I simply cannot conceive of one. Can you perhaps give me an example that you think is convincing?

As for size, we'll have to disagree. Compression is often pointed to as a useful fix, but size still matters. First requests cost more. And larger fields mean higher rotation through the dynamic table.

[cfredric]

You seem to be thinking that the storage access headers are relevant to the security decision that a server makes. I'm asserting that what is relevant is the cookies and - for XSRF - the Origin header, which tells you who is making the request.

Right, my thinking is that it's a useful part of a defense-in-depth strategy. I agree with you that the Origin header is also in that toolbox (indeed, it's in OWASP's list of mitigation strategies), but it's not always present so sites cannot rely on it as the sole protection.

[Storage access headers] help a server determine whether the cookies they are receiving are the "right" set to start looking at.

This is only true if the storage access header is trustworthy. If the header isn't trustworthy, then the server cannot safely infer anything from it; the server certainly cannot infer that it's looking at the "right" set of credentials.

Maybe there's a specific example you can share where XSRF relies on poorly-implemented servers doing something, but I simply cannot conceive of one. Can you perhaps give me an example that you think is convincing?

Here's a sketch of a possible attack, if the header is not forbidden:

1. User logs into their account on mail.google.com.
   • For this example, we'll assume that google.com never sets partitioned auth cookies.
2. User clicks a link and visits evil.com in a top-level context.
3. evil.com steals the user's google.com auth cookie somehow (e.g. XSS).
4. evil.com uses some vuln to set a partitioned cookie for google.com that mimics the auth cookie.
5. evil.com sends a request to some CSRF-vulnerable google.com endpoint, and overwrites the Storage-Access header value (either to remove it, or set it to "active").
   • That request doesn't include unpartitioned cookies, but does include the partitioned fake auth cookie.
6. The google.com auth server checks the Storage-Access header and determines that the value makes sense (isn't "none" or "inactive"); then checks the auth cookie, which appears valid. The server then serves the forged request as normal.

If the Storage-Access header request header were trustworthy, then the server could have detected and halted this CSRF at the last step. (Note that we never assumed that the victim server used the Storage Access API (or any other means) to make unpartitioned cookies available in cross-site contexts. The victim was only vulnerable because the attacker created a forged partitioned credential, via a compromised iframe and a stolen "real" credential.)

(Maybe you consider that to be too contrived since it relies on multiple vulns; if so, maybe it would be good to clarify the web platform's threat model re: defense in depth vs. assuming sites are well-defended. XSS was still in the OWASP top ten in 2021, so it seems reasonable to assume victim sites still have room for improvement w.r.t security.)

---

Re: size, we can easily make the request header trustworthy without adding any additional bytes, just by adding to the list in Fetch. So if size is your sole concern, that's solvable and is separable from the security aspect.

But it seems like you consider this to be inappropriate use of the "forbidden header" mechanism, so I'd like to separate that from the size concern and understand why you think the header ought not to be forbidden. Can you explain that point in more detail?

[johannhof]

Yeah, +1 to what Chris says, I have a more blunt take on this: If I'm an origin that holds a permission state for "storage-access", another origin shouldn't be able to tell me that the permission state is really something else through the channel that the browser would use to communicate this to me. That feels like a SOP violation. We also don't allow other origins to override the result of document.hasStorageAccess() even though I can't come up with an example of how it would be abused in this moment.

cc @annevk @bvandersloot-mozilla

[martinthomson]

Chris' example reminds me of a paper I read recently. In that paper, the attacker was given access to the private key that was in a certificate for the target domain name. There was some interesting work in terms of achieving that state, but in terms of hardening the rest of the system against that, once you give the attacker omnipotency, I find the argument totally uninteresting.

The attack is a problem because the attacker has the ability to use the cookie. That you would then put a check on Storage-Access as the only defense that remains really doesn't motivate the use of Sec- to prevent that. After all, with the described capabilities, the attacker is able to make the request directly -- without a browser being involved at all -- and circumvent the protection here.

I think our disconnect here is that you are insisting that I prove that removing Sec- is safe. Whereas I'm asking whether there is a security-relevant decision that might be made using this particular header, such that adding Sec- also improves security. I'm not looking for fanciful examples.

I agree that defense-in-depth is a useful thing, but this is not a security-relevant mechanism. Sites will use this header as a shortcut to decide whether they need to ask for the "useful" cookies. I cannot see how a site might use this field as part of its decision-making, except perhaps as part of some more general WAF controls that might look for aberrant activity (i.e., we have a model that says that good cookies always have Storage-Access: active, therefore any request without that is suspicious enough to warrant a second look).