- From: David Benjamin <notifications@github.com>
- Date: Wed, 26 Apr 2023 12:30:40 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1189/1523936516@github.com>
Got reminded of this recently and noticed there was this discussion point that is worth touching on: >> Is it reasonable to require CORS preflights for requests to non-allow-listed ports? > > If we wanted to go this route, I think we could more simply require TLS for non-allowlisted ports. It seems to me that encryption would substantially mitigate the Slipstream style of attack. CORS preflights and TLS limit the space significantly, but they don't fully solve the problem. They still assume that you and the other side are speaking the same protocol. When we send a preflight, we'll send `OPTIONS /attacker/controlled/path HTTP/1.1`, or a TLS ClientHello with attacker-controlled server_name or session ticket. That those are attacker-controlled works because the syntaxes have defined meaning and we can assume the other side will correctly interpret those bytes as the path or server_name or whatever. But when we don't even know we're speaking the same protocol as the other side, that breaks down. E.g. maybe your protocol is just newline-separated and you ignore unrecognized commands. While goofy, that's a perfectly well-defined protocol. (AIUI that's what memcached does.) Then any attacker-controlled field that can fit a newline (e.g. TLS session tickets) is an avenue for attack. Or if you use space-separated commands, `OPTIONS /attacker/controlled/path HTTP/1.1` is a problem Essentially the meaning of the port allowlist/blocklist is: anyone deploying anything on those ports must use protocols that cannot be confused with an HTTP-related protocol (that is, TLS and HTTP/1.1) in a cross-protocol attack. Browsers have squatted practically the whole port space, so we've rather constrained everyone else. An allowlist means we relinquish part of that space so other applications don't need to worry about HTTP. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1189#issuecomment-1523936516 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/issues/1189/1523936516@github.com>
Received on Wednesday, 26 April 2023 19:30:47 UTC