4. Possible Security Issues

Cette section conserve le texte RFC pour optimistic HTTP/1.1 protocol transitions, y compris request smuggling risks, parser exploit risks, existing Upgrade tokens, HTTP CONNECT requirements et IANA status.

4.  Possible Security Issues

   When there are only two distinct parties involved in an HTTP/1.1
   connection (i.e., the client and the server), protocol transitions
   introduce no new security issues: Each party must already be prepared
   for the other to send arbitrary data on the connection at any time.
   However, HTTP connections often involve more than two parties if the
   requests or responses include third-party data.  For example, a
   browser (party 1) might send an HTTP request to an origin (party 2)
   with the path, headers, or content controlled by a website from a
   different origin (party 3).  Post-transition protocols, such as
   WebSocket [WEBSOCKET], are also frequently used to convey data chosen
   by a third party.

   If the third-party data source is untrusted, then the data it
   provides is potentially "attacker-controlled".  The combination of
   attacker-controlled data and optimistic protocol transitions results
   in two significant security issues.

4.1.  Request Smuggling

   In a Request Smuggling attack ([HTTP/1.1], Section 11.2), the
   attacker-controlled data is chosen in such a way that it is
   interpreted by the server as an additional HTTP request.  These
   attacks allow the attacker to speak on behalf of the client while
   bypassing the client's own rules about what requests it will issue.
   Request Smuggling can occur if the client and server have distinct
   interpretations of the data that flows between them.

   If the server accepts a protocol transition request, it interprets
   the subsequent bytes in accordance with the new protocol.  If it
   rejects the request, it interprets those bytes as HTTP/1.1.  However,
   the client cannot know which interpretation the server will take
   until it receives the server's response status code.  If it uses the
   new protocol optimistically, this creates a risk that the server will
   interpret attacker-controlled data in the new protocol as an
   additional HTTP request issued by the client.

   As a trivial example, consider an HTTP CONNECT client providing
   connectivity to an untrusted application.  If the client is
   authenticated to the proxy server using a connection-level
   authentication method such as TLS Client Certificates ([TLS],
   Section 4.4.2), the attacker could send an HTTP/1.1 POST request
   ([HTTP], Section 9.3.3) for the proxy server at the beginning of its
   TCP connection.  If the client delivers this data optimistically, and
   the CONNECT request fails, the server would misinterpret the
   application's data as a subsequent authenticated request issued by
   the client.

 ## REQUESTS ##

 # The malicious application requests a TCP connection to a nonexistent
 # destination, which will fail.
 CONNECT no-such-destination.example:443 HTTP/1.1
 Host: no-such-destination.example:443

 # Before connection fails, the malicious application sends data on the
 # proxied TCP connection that forms a valid POST request to the proxy.
 # The vulnerable client optimistically forwards this data to the proxy.
 POST /upload HTTP/1.1
 Host: proxy.example
 Content-Length: 123456

 <POST body controlled by the malicious application>

 ## RESPONSES ##

 # When TCP connection establishment fails, the proxy responds by
 # rejecting the CONNECT request, but the client has already forwarded
 # the malicious TCP payload data to the proxy.
 HTTP/1.1 504 Gateway Timeout
 Content-Length: 0

 # The proxy interprets the smuggled POST request as coming from the
 # client.  If connection-based authentication is in use (e.g., using
 # TLS client certificate authentication), the proxy treats this
 # malicious request as authenticated.
 HTTP/1.1 200 OK
 Content-Length: 0

     Figure 1: Example Request Smuggling Attack Using HTTP CONNECT

4.2.  Parser Exploits

   A related category of attacks use protocol disagreement to exploit
   vulnerabilities in the server's request parsing logic.  These attacks
   apply when the HTTP client is trusted by the server, but the post-
   transition data source is not.  If the server software was developed
   under the assumption that some or all of the HTTP request data is not
   attacker-controlled, optimistic transmission can cause this
   assumption to be violated, exposing vulnerabilities in the server's
   HTTP request parser.