CORS Content-Type "bypass" 2

[annevk]

@MattMenke2 made me think of another "bypass", though it would only affect naïve parsers:

• text/plain;,application/json
• text/plain;charset=utf-8,application/json

These would only be successful with a server that splits on , and uses the last value, which isn't compliant per HTTP. An easy fix would be to ban 0x2C ,.

I thought I'd raise it here so it can be considered. I'm sorry for all the recent changes to this and that not everything was considered at once. Hopefully the bugs and tests help mitigate the churn annoyance.

cc @yutakahirano @youennf

[annevk]

@whatwg/security thoughts? Shall I make patches for banning ,?

[antosart]

I like the idea of banning ,, meaning we would always issue a preflight in that case.

[annevk]

Yeah, that seems by far the most straightforward. I suppose the alternative would be something like this:

In https://fetch.spec.whatwg.org/#cors-safelisted-request-header under content-type, replace step 2-4 with:

1. Let splitValues be the result of getting, decoding, and splitting Content-Type from « header ». (This syntax is somewhat confusing maybe, but turns header back into a header list, which "getting, decoding, and splitting" needs. An alternative might be to make "decode and split" its own algorithm separate from getting.)
2. If splitValues is null, then return false.
3. For each splitValue of splitValues:
   1. Let mimeType be the result of parsing splitValue.
   2. If mimeType is failure, then return false.
   3. If mimeType’s essence is not "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain", then return false.