3 ms·
As someone who has not read the HTTP/1.1 spec, what are some pitfalls that could actually become security issues?
by arjvik 4y ago
As someone who has not read the HTTP/1.1 spec, what are some pitfalls that could actually become security issues?
- pwdisswordfish9 4y agoBeing text-based. Which leads to people constructing protocol messages by printf and therefore tons of injection bugs.
- chrismorgan 4y agoThe most common proximate cause of security issues in format handling (parsing and emitting) comes from implementations differing in their parsing, or implementations emitting invalid values in a way that will be parsed differently. Probably the most common type of security issue then comes from smuggling values through, bypassing checks or triggering injection. (This is the essence of injection attacks as a broad class.) One of the easiest demonstrations of this in HTTP specifically is called HTTP request smuggling: https://portswigger.net/web-security/request-smuggling https://portswigger.net/web-security/request-smuggling. And the solution for that is pretty much: “stop using a text protocol, they’re too hard to use correctly”.
- jefftk 4y agoOne of the simplest issues is that headers end with a newline. Most code will not generate a header with an embedded new line, so it's common that software doesn't handle this case, and passes the new line through unmodified. This means that if someone is able to set a custom value for part of a header they can often use that to inject their own custom response header. Or even their own customer response body, since that is also set off with newlines.