HTTP Response Splitting relies on a web browsers interpreting an unrequested response from a webserver as if it were requested. Part of the vulnerability stems from the fact that the HTTP protocol does not include request identifiers so that a client can match up a response to a request it made. Partly this is because the HTTP protocol is assumed to be ordered from the client and server's perspective. The protocol is purely synchronous, requests and responses happen in order and consequently there is no need to sequence, things are assumed to be in order.
Certain communication protocols include session identifiers and/or request identifiers so that an endpoint application/server can tell what responses belong to what requests and/or session.
- TCP has sequence IDs
- DNS has a request identifier
There have been proposals to make HTTP asynchronous. The only one I was able to find without a lot of digging actually relied on a lower-level sequencing of packets/events, looks like it dates back many years.
A potential solution to performing async HTTP would be for a browser to include extra HTTP headers indicating both that it can support async HTTP, as well as a request-id. A webserver would then be able to reply asynchronously to a client over a single TCP connection for multiple requests. Depending on configurations and/or standards a client could issue a maximum number of simultaneous requests over the same TCP connection asynchronously. The webserver could respond asynchronously as well, putting the same request-id into the HTTP response headers so that the browser can understand the sequencing.
I'm guessing that this isn't ideal performance wise for a lot of apps, but there are others where it would make a lot of sense. With respect to timeouts for each HTTP request the browser doesn't need to change its policy. It can wait the same amount of time, but it allows the server to process things in a more async fashion than it does currently.
Additionally, if we match response Ids to request Ids, then we prevent HTTP response splitting except in cases where we can do header injection and predict the request-id the browser will generate.
I agree that this is a lot of work to do to prevent response splitting attacks. I haven't tried to model out the performance impacts server or client side for this. I'm guessing in many cases it would be a wash and in others it would result in pretty significant performance improvements without as many network sockets being involved, and perhaps smarter scheduling algorithms on the server side.