Ignore:
Timestamp:
31/01/14 04:57:35 (6 years ago)
Author:
fielding@…
Message:

Augment security considerations with pointers to current research and explanation of the considerations specific to HTTP message parsing and routing; see #531 and #549

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2607 r2609  
    448448  }
    449449  @bottom-center {
    450        content: "Expires August 2, 2014";
     450       content: "Expires August 3, 2014";
    451451  }
    452452  @bottom-right {
     
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2014-01-29">
     492      <meta name="dct.issued" scheme="ISO8601" content="2014-01-30">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    519519            <tr>
    520520               <td class="left">Intended status: Standards Track</td>
    521                <td class="right">January 29, 2014</td>
     521               <td class="right">January 30, 2014</td>
    522522            </tr>
    523523            <tr>
    524                <td class="left">Expires: August 2, 2014</td>
     524               <td class="left">Expires: August 3, 2014</td>
    525525               <td class="right"></td>
    526526            </tr>
     
    551551            in progress”.
    552552         </p>
    553          <p>This Internet-Draft will expire on August 2, 2014.</p>
     553         <p>This Internet-Draft will expire on August 3, 2014.</p>
    554554      </div>
    555555      <div id="rfc.copyrightnotice">
     
    691691         </li>
    692692         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    693                <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
    694                <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#attack.intermediaries">Intermediaries and Caching</a></li>
    695                <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Buffer Overflows</a></li>
    696                <li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li>
    697                <li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#abuse.of.server.log.information">Server Log Information</a></li>
     693               <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#establishing.authority">Establishing Authority</a></li>
     694               <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#risks.intermediaries">Risks of Intermediaries</a></li>
     695               <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.length">Attacks via Protocol Element Length</a></li>
     696               <li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.splitting">Response Splitting</a></li>
     697               <li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.smuggling">Request Smuggling</a></li>
     698               <li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li>
     699               <li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.confidentiality">Message Confidentiality</a></li>
     700               <li><a href="#rfc.section.9.8">9.8</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.of.server.log.information">Privacy of Server Log Information</a></li>
    698701            </ul>
    699702         </li>
     
    11221125                  to respond authoritatively to requests that target the identified resource. The delegated nature of registered names and IP
    11231126                  addresses creates a federated namespace, based on control over the indicated host and port, whether or not an HTTP server
    1124                   is present.
     1127                  is present. See <a href="#establishing.authority" title="Establishing Authority">Section&nbsp;9.1</a> for security considerations related to establishing authority.
    11251128               </p>
    11261129               <p id="rfc.section.2.7.1.p.7">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
     
    13941397                  semantics.
    13951398               </p>
    1396                <p id="rfc.section.3.2.5.p.2">A server that receives a request header field, or set of fields, larger than it wishes to process <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks.
     1399               <p id="rfc.section.3.2.5.p.2">A server that receives a request header field, or set of fields, larger than it wishes to process <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (<a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>).
    13971400               </p>
    13981401               <p id="rfc.section.3.2.5.p.3">A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such
     
    15231526               </p>
    15241527               <p id="rfc.section.3.3.2.p.11">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
    1525                   a payload, a recipient <em class="bcp14">MUST</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section&nbsp;9.3</a>).
     1528                  a payload, a recipient <em class="bcp14">MUST</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.length" title="Attacks via Protocol Element Length">Section&nbsp;9.3</a>).
    15261529               </p>
    15271530               <p id="rfc.section.3.3.2.p.12">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value,
     
    15621565                     </p>
    15631566                     <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request
    1564                         or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an
    1565                         error. A sender <em class="bcp14">MUST</em> remove the received Content-Length field prior to forwarding such a message downstream.
     1567                        smuggling (<a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>) or response splitting (<a href="#response.splitting" title="Response Splitting">Section&nbsp;9.4</a>) and ought to be handled as an error. A sender <em class="bcp14">MUST</em> remove the received Content-Length field prior to forwarding such a message downstream.
    15661568                     </p>
    15671569                  </li>
    15681570                  <li>
    15691571                     <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field having an invalid value, then the message
    1570                         framing is invalid and the recipient <em class="bcp14">MUST</em> treat it as an unrecoverable error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, the user agent <em class="bcp14">MUST</em> close the connection to the server and discard the received response.
     1572                        framing is invalid and the recipient <em class="bcp14">MUST</em> treat it as an unrecoverable error. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, the user agent <em class="bcp14">MUST</em> close the connection to the server and discard the received response.
    15711573                     </p>
    15721574                  </li>
     
    16351637               SP octet, recipients <em class="bcp14">MAY</em> instead parse on whitespace-delimited word boundaries and, aside from the CRLF terminator, treat any form of whitespace as
    16361638               the SP separator while ignoring preceding or trailing whitespace; such whitespace includes one or more of the following octets:
    1637                SP, HTAB, VT (%x0B), FF (%x0C), or bare CR.
     1639               SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can result in security vulnerabilities if there are multiple
     1640               recipients of the message and each has its own unique interpretation of robustness (see <a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>).
    16381641            </p>
    16391642            <p id="rfc.section.3.5.p.5">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request
     
    28632866            HTTP message syntax, parsing, and routing. Security considerations about HTTP semantics and payloads are addressed in <a href="#Part2" id="rfc.xref.Part2.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    28642867         </p>
    2865          <div id="dns.related.attacks">
    2866             <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></h2>
    2867             <p id="rfc.section.9.1.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the
    2868                deliberate misassociation of IP addresses and DNS names not protected by DNSSEC. Clients need to be cautious in assuming the
    2869                validity of an IP number/DNS name association unless the response is protected by DNSSEC (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>).
    2870             </p>
    2871          </div>
    2872          <div id="attack.intermediaries">
    2873             <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a href="#attack.intermediaries">Intermediaries and Caching</a></h2>
    2874             <p id="rfc.section.9.2.p.1">By their very nature, HTTP intermediaries are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks.
     2868         <div id="establishing.authority">
     2869            <div id="rfc.iref.a.6"></div>
     2870            <div id="rfc.iref.p.2"></div>
     2871            <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a href="#establishing.authority">Establishing Authority</a></h2>
     2872            <p id="rfc.section.9.1.p.1">HTTP relies on the notion of an <dfn>authoritative response</dfn>: a response that has been determined by (or at the direction of) the authority identified within the target URI to be the
     2873               most appropriate response for that request given the state of the target resource at the time of response message origination.
     2874               That is the essence of what a user is looking for when they make any HTTP request, especially when it is a request to an authority
     2875               trusted by that user to provide a specific service. Providing a response from a non-authoritative source, such as a shared
     2876               cache, is often useful to improve performance and availability, but only to the extent that the source can be trusted or that
     2877               a distrusted response can be safely used.
     2878            </p>
     2879            <p id="rfc.section.9.1.p.2">Unfortunately, establishing authority can be difficult. For example, <dfn>phishing</dfn> is an attack on the user's perception of authority, where that perception can be misled by presenting similar branding in
     2880               hypertext, possibly aided by userinfo obfuscating the authority component (see <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). User agents can reduce the impact of phishing attacks by enabling users to easily inspect a target URI prior to making
     2881               an action, by prominently distinguishing (or rejecting) userinfo when present, and by not sending stored credentials and cookies
     2882               when the referring document is from an unknown or untrusted source.
     2883            </p>
     2884            <p id="rfc.section.9.1.p.3">When a registered name is used in the authority component, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) relies on the user's local name resolution service to determine where it can find authoritative responses. This means that
     2885               any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing
     2886               authority. Likewise, the user's choice of server for Domain Name Service (DNS), and the hierarchy of servers from which it
     2887               obtains resolution results, could impact the authenticity of address mappings; DNSSEC (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>) is one way to improve authenticity.
     2888            </p>
     2889            <p id="rfc.section.9.1.p.4">Furthermore, after an IP address is obtained, establishing authority is vulnerable to attacks on Internet Protocol routing.</p>
     2890            <p id="rfc.section.9.1.p.5">The "https" scheme (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) is intended to prevent (or at least reveal) many of these potential attacks on establishing authority, assuming the negotiated
     2891               TLS connection is secured in a way that verifies the communicating server's identity matches the target URI's authority component
     2892               (see <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a> and <a href="#Georgiev" id="rfc.xref.Georgiev.1"><cite title="The Most Dangerous Code in the World: Validating SSL Certificates in Non-browser Software">[Georgiev]</cite></a>).
     2893            </p>
     2894         </div>
     2895         <div id="risks.intermediaries">
     2896            <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a href="#risks.intermediaries">Risks of Intermediaries</a></h2>
     2897            <p id="rfc.section.9.2.p.1">By their very nature, HTTP intermediaries are men-in-the-middle, and thus represent an opportunity for man-in-the-middle attacks.
    28752898               Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries
    2876                have access to security-related information, personal information about individual users and organizations, and proprietary
     2899               might have access to security-related information, personal information about individual users and organizations, and proprietary
    28772900               information belonging to users and content providers. A compromised intermediary, or an intermediary implemented or configured
    28782901               without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
    28792902            </p>
    2880             <p id="rfc.section.9.2.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks.</p>
     2903            <p id="rfc.section.9.2.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in <a href="p6-cache.html#security.considerations" title="Security Considerations">Section 8</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     2904            </p>
    28812905            <p id="rfc.section.9.2.p.3">Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration
    28822906               options they provide to operators (especially the default configuration).
     
    28862910            </p>
    28872911         </div>
    2888          <div id="attack.protocol.element.size.overflows">
    2889             <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a href="#attack.protocol.element.size.overflows">Buffer Overflows</a></h2>
    2890             <p id="rfc.section.9.3.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform
    2891                a Denial of Service against implementations that accept fields with unlimited lengths.
    2892             </p>
    2893             <p id="rfc.section.9.3.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>) and header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
     2912         <div id="attack.protocol.element.length">
     2913            <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a href="#attack.protocol.element.length">Attacks via Protocol Element Length</a></h2>
     2914            <p id="rfc.section.9.3.p.1">Because HTTP uses mostly textual, character-delimited fields, parsers are often vulnerable to attacks based on sending very
     2915               long (or very slow) streams of data, particularly where an implementation is expecting a protocol element with no predefined
     2916               length.
     2917            </p>
     2918            <p id="rfc.section.9.3.p.2">To promote interoperability, specific recommendations are made for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>) and header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
    28942919               that most implementations will choose substantially higher limits.
    28952920            </p>
    2896             <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
    2897             </p>
    2898             <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods,
    2899                response status phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.
     2921            <p id="rfc.section.9.3.p.3">A server can reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
     2922            </p>
     2923            <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they process other protocol elements, including (but not limited to)
     2924               request methods, response status phrases, header field-names, numeric values, and body chunks. Failure to limit such processing
     2925               can result in buffer overflows, arithmetic overflows, or increased vulnerability to denial of service attacks.
     2926            </p>
     2927         </div>
     2928         <div id="response.splitting">
     2929            <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a href="#response.splitting">Response Splitting</a></h2>
     2930            <p id="rfc.section.9.4.p.1">Response splitting (a.k.a, CRLF injection) is a common technique, used in various attacks on Web usage, that exploits the
     2931               line-based nature of HTTP message framing and the ordered association of requests to responses on persistent connections <a href="#Klein" id="rfc.xref.Klein.1"><cite title="Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics">[Klein]</cite></a>. This technique can be particularly damaging when the requests pass through a shared cache.
     2932            </p>
     2933            <p id="rfc.section.9.4.p.2">Response splitting exploits a vulnerability in servers (usually within an application server) where an attacker can send encoded
     2934               data within some parameter of the request that is later decoded and echoed within any of the response header fields of the
     2935               response. If the decoded data is crafted to look like the response has ended and a subsequent response has begun, the response
     2936               has been split and the content within the apparent second response is controlled by the attacker. The attacker can then make
     2937               any other request on the same persistent connection and trick the recipients (including intermediaries) into believing that
     2938               the second half of the split is an authoritative answer to the second request.
     2939            </p>
     2940            <p id="rfc.section.9.4.p.3">For example, a parameter within the request-target might be read by an application server and reused within a redirect, resulting
     2941               in the same parameter being echoed in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field of the response. If the parameter is decoded by the application and not properly encoded when placed in the response
     2942               field, the attacker can send encoded CRLF octets and other content that will make the application's single response look like
     2943               two or more responses.
     2944            </p>
     2945            <p id="rfc.section.9.4.p.4">A common defense against response splitting is to filter requests for data that looks like encoded CR and LF (e.g., "%0D"
     2946               and "%0A"). However, that assumes the application server is only performing URI decoding, rather than more obscure data transformations
     2947               like charset transcoding, XML entity translation, base64 decoding, sprintf reformatting, etc. A more effective mitigation
     2948               is to prevent anything other than the server's core protocol libraries from sending a CR or LF within the header section,
     2949               which means restricting the output of header fields to APIs that filter for bad octets and not allowing application servers
     2950               to write directly to the protocol stream.
     2951            </p>
     2952         </div>
     2953         <div id="request.smuggling">
     2954            <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a href="#request.smuggling">Request Smuggling</a></h2>
     2955            <p id="rfc.section.9.5.p.1">Request smuggling (<a href="#Linhart" id="rfc.xref.Linhart.1"><cite title="HTTP Request Smuggling">[Linhart]</cite></a>) is a technique that exploits differences in protocol parsing among various recipients to hide additional requests (which
     2956               might otherwise be blocked or disabled by policy) within an apparently harmless request. Like response splitting, request
     2957               smuggling can lead to a variety of attacks on HTTP usage.
     2958            </p>
     2959            <p id="rfc.section.9.5.p.2">This specification has introduced new requirements on request parsing, particularly with regard to message framing in <a href="#message.body.length" title="Message Body Length">Section&nbsp;3.3.3</a>, to reduce the effectiveness of request smuggling.
    29002960            </p>
    29012961         </div>
    29022962         <div id="message.integrity">
    2903             <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a href="#message.integrity">Message Integrity</a></h2>
    2904             <p id="rfc.section.9.4.p.1">HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of
     2963            <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a href="#message.integrity">Message Integrity</a></h2>
     2964            <p id="rfc.section.9.6.p.1">HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of
    29052965               underlying transport protocols and the use of length or chunk-delimited framing to detect completeness. Additional integrity
    29062966               mechanisms, such as hash functions or digital signatures applied to the content, can be selectively added to messages via
     
    29092969               increasing use within environments where verification of message integrity is crucial.
    29102970            </p>
    2911             <p id="rfc.section.9.4.p.2">User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such
     2971            <p id="rfc.section.9.6.p.2">User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such
    29122972               that those means can be enabled within environments for which integrity is necessary. For example, a browser being used to
    29132973               view medical history or drug interaction information needs to indicate to the user when such information is detected by the
     
    29172977            </p>
    29182978         </div>
    2919          <div id="abuse.of.server.log.information">
    2920             <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a href="#abuse.of.server.log.information">Server Log Information</a></h2>
    2921             <p id="rfc.section.9.5.p.1">A server is in the position to save personal data about a user's requests over time, which might identify their reading patterns
     2979         <div id="message.confidentiality">
     2980            <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a href="#message.confidentiality">Message Confidentiality</a></h2>
     2981            <p id="rfc.section.9.7.p.1">HTTP relies on underlying transport protocols to provide message confidentiality when that is desired. HTTP has been specifically
     2982               designed to be independent of the transport protocol, such that it can be used over many different forms of encrypted connection,
     2983               with the selection of such transports being identified by the choice of URI scheme or within user agent configuration.
     2984            </p>
     2985            <p id="rfc.section.9.7.p.2">The "https" scheme can be used to identify resources that require a confidential connection, as described in <a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>.
     2986            </p>
     2987         </div>
     2988         <div id="privacy.of.server.log.information">
     2989            <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a href="#privacy.of.server.log.information">Privacy of Server Log Information</a></h2>
     2990            <p id="rfc.section.9.8.p.1">A server is in the position to save personal data about a user's requests over time, which might identify their reading patterns
    29222991               or subjects of interest. In particular, log information gathered at an intermediary often contains a history of user agent
    29232992               interaction, across a multitude of sites, that can be traced to individual users.
    29242993            </p>
    2925             <p id="rfc.section.9.5.p.2">HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information
     2994            <p id="rfc.section.9.8.p.2">HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information
    29262995               needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within
    29272996               individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation
     
    29292998               the key is pseudonymous.
    29302999            </p>
    2931             <p id="rfc.section.9.5.p.3">To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information,
     3000            <p id="rfc.section.9.8.p.3">To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information,
    29323001               including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary
    29333002               to support operational needs for security, auditing, or fraud control.
     
    30793148         </tr>
    30803149         <tr>
     3150            <td class="reference"><b id="Georgiev">[Georgiev]</b></td>
     3151            <td class="top">Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., and V. Shmatikov, “<a href="http://doi.acm.org/10.1145/2382196.2382204">The Most Dangerous Code in the World: Validating SSL Certificates in Non-browser Software</a>”, In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS '12), pp. 38-49, October&nbsp;2012, &lt;<a href="http://doi.acm.org/10.1145/2382196.2382204">http://doi.acm.org/10.1145/2382196.2382204</a>&gt;.
     3152            </td>
     3153         </tr>
     3154         <tr>
    30813155            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
    30823156            <td class="top">International Organization for Standardization, “Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1”, ISO/IEC&nbsp;8859-1:1998, 1998.</td>
    30833157         </tr>
    30843158         <tr>
     3159            <td class="reference"><b id="Klein">[Klein]</b></td>
     3160            <td class="top">Klein, A., “<a href="http://packetstormsecurity.com/papers/general/whitepaper_httpresponse.pdf">Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics</a>”, March&nbsp;2004, &lt;<a href="http://packetstormsecurity.com/papers/general/whitepaper_httpresponse.pdf">http://packetstormsecurity.com/papers/general/whitepaper_httpresponse.pdf</a>&gt;.
     3161            </td>
     3162         </tr>
     3163         <tr>
    30853164            <td class="reference"><b id="Kri2001">[Kri2001]</b></td>
    30863165            <td class="top">Kristol, D., “<a href="http://arxiv.org/abs/cs.SE/0105018">HTTP Cookies: Standards, Privacy, and Politics</a>”, ACM Transactions on Internet Technology&nbsp;1(2), November&nbsp;2001, &lt;<a href="http://arxiv.org/abs/cs.SE/0105018">http://arxiv.org/abs/cs.SE/0105018</a>&gt;.
     3166            </td>
     3167         </tr>
     3168         <tr>
     3169            <td class="reference"><b id="Linhart">[Linhart]</b></td>
     3170            <td class="top">Linhart, C., Klein, A., Heled, R., and S. Orrin, “<a href="http://www.watchfire.com/news/whitepapers.aspx">HTTP Request Smuggling</a>”, June&nbsp;2005, &lt;<a href="http://www.watchfire.com/news/whitepapers.aspx">http://www.watchfire.com/news/whitepapers.aspx</a>&gt;.
    30873171            </td>
    30883172         </tr>
     
    32553339               transmission on the wire. (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>)
    32563340            </p>
    3257             <p id="rfc.section.A.2.p.4">The HTTPS URI scheme is now defined by this specification; previously, it was done in <a href="http://tools.ietf.org/html/rfc2818#section-2.4">Section 2.4</a> of <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. Furthermore, it implies end-to-end security. (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>)
     3341            <p id="rfc.section.A.2.p.4">The HTTPS URI scheme is now defined by this specification; previously, it was done in <a href="http://tools.ietf.org/html/rfc2818#section-2.4">Section 2.4</a> of <a href="#RFC2818" id="rfc.xref.RFC2818.4"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. Furthermore, it implies end-to-end security. (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>)
    32583342            </p>
    32593343            <p id="rfc.section.A.2.p.5">HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is
     
    34833567      </div>
    34843568      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    3485       <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a>
     3569      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a>
    34863570      </p>
    34873571      <div class="print2col">
     
    34923576                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>8.3.2</b></a></li>
    34933577                  <li>asterisk-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.3.4</a></li>
     3578                  <li>authoritative response&nbsp;&nbsp;<a href="#rfc.iref.a.6"><b>9.1</b></a></li>
    34943579                  <li>authority-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">5.3.3</a></li>
    34953580               </ul>
     
    35273612            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    35283613                  <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>2.3</b></a></li>
     3614                  <li><em>Georgiev</em>&nbsp;&nbsp;<a href="#rfc.xref.Georgiev.1">9.1</a>, <a href="#Georgiev"><b>11.2</b></a></li>
    35293615                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    35303616                     <ul>
     
    36373723            </li>
    36383724            <li><a id="rfc.index.K" href="#rfc.index.K"><b>K</b></a><ul>
     3725                  <li><em>Klein</em>&nbsp;&nbsp;<a href="#rfc.xref.Klein.1">9.4</a>, <a href="#Klein"><b>11.2</b></a></li>
    36393726                  <li><em>Kri2001</em>&nbsp;&nbsp;<a href="#rfc.xref.Kri2001.1">3.2.2</a>, <a href="#Kri2001"><b>11.2</b></a></li>
     3727               </ul>
     3728            </li>
     3729            <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
     3730                  <li><em>Linhart</em>&nbsp;&nbsp;<a href="#rfc.xref.Linhart.1">9.5</a>, <a href="#Linhart"><b>11.2</b></a></li>
    36403731               </ul>
    36413732            </li>
     
    36953786                  </li>
    36963787                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#Part5"><b>11.1</b></a></li>
    3697                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">3.4</a>, <a href="#rfc.xref.Part6.4">5.2</a>, <a href="#rfc.xref.Part6.5">5.7.2</a>, <a href="#rfc.xref.Part6.6">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a>, <a href="#Part6"><b>11.1</b></a><ul>
     3788                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">3.4</a>, <a href="#rfc.xref.Part6.4">5.2</a>, <a href="#rfc.xref.Part6.5">5.7.2</a>, <a href="#rfc.xref.Part6.6">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a>, <a href="#rfc.xref.Part6.8">9.2</a>, <a href="#Part6"><b>11.1</b></a><ul>
    36983789                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
    36993790                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.4</a></li>
    37003791                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a></li>
    37013792                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">5.7.2</a></li>
     3793                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">9.2</a></li>
    37023794                     </ul>
    37033795                  </li>
    37043796                  <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">1</a>, <a href="#rfc.xref.Part7.2">4.1.2</a>, <a href="#Part7"><b>11.1</b></a></li>
     3797                  <li>phishing&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>9.1</b></a></li>
    37053798                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
    37063799               </ul>
     
    37383831                     </ul>
    37393832                  </li>
    3740                   <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">1</a>, <a href="#rfc.xref.RFC2818.2">2.7.2</a>, <a href="#RFC2818"><b>11.2</b></a>, <a href="#rfc.xref.RFC2818.3">A.2</a><ul>
    3741                         <li><em>Section 2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.3">A.2</a></li>
     3833                  <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">1</a>, <a href="#rfc.xref.RFC2818.2">2.7.2</a>, <a href="#rfc.xref.RFC2818.3">9.1</a>, <a href="#RFC2818"><b>11.2</b></a>, <a href="#rfc.xref.RFC2818.4">A.2</a><ul>
     3834                        <li><em>Section 2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.4">A.2</a></li>
    37423835                     </ul>
    37433836                  </li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2607 r2609  
    1919  <!ENTITY caching-overview       "<xref target='Part6' x:rel='#caching.overview' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2020  <!ENTITY cache-incomplete       "<xref target='Part6' x:rel='#response.cacheability' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     21  <!ENTITY cache-poisoning        "<xref target='Part6' x:rel='#security.considerations' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2122  <!ENTITY payload                "<xref target='Part2' x:rel='#payload' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    22   <!ENTITY media-type            "<xref target='Part2' x:rel='#media.type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     23  <!ENTITY media-type             "<xref target='Part2' x:rel='#media.type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2324  <!ENTITY content-codings        "<xref target='Part2' x:rel='#content.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2425  <!ENTITY CONNECT                "<xref target='Part2' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    902903   and IP addresses creates a federated namespace, based on control over the
    903904   indicated host and port, whether or not an HTTP server is present.
     905   See <xref target="establishing.authority"/> for security considerations
     906   related to establishing authority.
    904907</t>
    905908<t>
     
    14341437   than it wishes to process &MUST; respond with an appropriate
    14351438   <x:ref>4xx (Client Error)</x:ref> status code. Ignoring such header fields
    1436    would increase the server's vulnerability to request smuggling attacks.
     1439   would increase the server's vulnerability to request smuggling attacks
     1440   (<xref target="request.smuggling"/>).
    14371441</t>
    14381442<t>
     
    17061710   recipient &MUST; anticipate potentially large decimal numerals and
    17071711   prevent parsing errors due to integer conversion overflows
    1708    (<xref target="attack.protocol.element.size.overflows"/>).
     1712   (<xref target="attack.protocol.element.length"/>).
    17091713</t>
    17101714<t>
     
    17711775     If a message is received with both a <x:ref>Transfer-Encoding</x:ref>
    17721776     and a <x:ref>Content-Length</x:ref> header field, the Transfer-Encoding
    1773      overrides the Content-Length. Such a message might indicate an attempt
    1774      to perform request or response smuggling (bypass of security-related
    1775      checks on message routing or content) and thus ought to be handled as
    1776      an error.  A sender &MUST; remove the received Content-Length field
    1777      prior to forwarding such a message downstream.
     1777     overrides the Content-Length. Such a message might indicate an attempt to
     1778     perform request smuggling (<xref target="request.smuggling"/>) or
     1779     response splitting (<xref target="response.splitting"/>) and ought to be
     1780     handled as an error. A sender &MUST; remove the received Content-Length
     1781     field prior to forwarding such a message downstream.
    17781782    </t></x:lt>
    17791783    <x:lt><t>
     
    17821786     differing field-values or a single Content-Length header field having an
    17831787     invalid value, then the message framing is invalid and
    1784      the recipient &MUST; treat it as an unrecoverable error to prevent
    1785      request or response smuggling.
     1788     the recipient &MUST; treat it as an unrecoverable error.
    17861789     If this is a request message, the server &MUST; respond with
    17871790     a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
     
    19161919   while ignoring preceding or trailing whitespace;
    19171920   such whitespace includes one or more of the following octets:
    1918    SP, HTAB, VT (%x0B), FF (%x0C), or bare CR.
     1921   SP, HTAB, VT (%x0B), FF (%x0C), or bare CR.
     1922   However, lenient parsing can result in security vulnerabilities if there
     1923   are multiple recipients of the message and each has its own unique
     1924   interpretation of robustness (see <xref target="request.smuggling"/>).
    19191925</t>
    19201926<t>
     
    38913897</t>
    38923898
    3893 <section title="DNS-related Attacks" anchor="dns.related.attacks">
    3894 <t>
    3895    HTTP clients rely heavily on the Domain Name Service (DNS), and are thus
    3896    generally prone to security attacks based on the deliberate misassociation
    3897    of IP addresses and DNS names not protected by DNSSEC. Clients need to be
    3898    cautious in assuming the validity of an IP number/DNS name association unless
    3899    the response is protected by DNSSEC (<xref target="RFC4033"/>).
    3900 </t>
    3901 </section>
    3902 
    3903 <section title="Intermediaries and Caching" anchor="attack.intermediaries">
    3904 <t>
    3905    By their very nature, HTTP intermediaries are men-in-the-middle, and
     3899<section title="Establishing Authority" anchor="establishing.authority">
     3900  <iref item="authoritative response" primary="true"/>
     3901  <iref item="phishing" primary="true"/>
     3902<t>
     3903   HTTP relies on the notion of an <x:dfn>authoritative response</x:dfn>: a
     3904   response that has been determined by (or at the direction of) the authority
     3905   identified within the target URI to be the most appropriate response for
     3906   that request given the state of the target resource at the time of
     3907   response message origination. That is the essence of what a user is looking
     3908   for when they make any HTTP request, especially when it is a request to an
     3909   authority trusted by that user to provide a specific service. Providing a
     3910   response from a non-authoritative source, such as a shared cache, is often
     3911   useful to improve performance and availability, but only to the extent that
     3912   the source can be trusted or that a distrusted response can be safely used.
     3913</t>
     3914<t>
     3915   Unfortunately, establishing authority can be difficult.
     3916   For example, <x:dfn>phishing</x:dfn> is an attack on the user's perception
     3917   of authority, where that perception can be misled by presenting similar
     3918   branding in hypertext, possibly aided by userinfo obfuscating the authority
     3919   component (see <xref target="http.uri"/>).
     3920   User agents can reduce the impact of phishing attacks by enabling users to
     3921   easily inspect a target URI prior to making an action, by prominently
     3922   distinguishing (or rejecting) userinfo when present, and by not sending
     3923   stored credentials and cookies when the referring document is from an
     3924   unknown or untrusted source.
     3925</t>
     3926<t>
     3927   When a registered name is used in the authority component, the "http" URI
     3928   scheme (<xref target="http.uri"/>) relies on the user's local name
     3929   resolution service to determine where it can find authoritative responses.
     3930   This means that any attack on a user's network host table, cached names, or
     3931   name resolution libraries becomes an avenue for attack on establishing
     3932   authority. Likewise, the user's choice of server for Domain Name Service
     3933   (DNS), and the hierarchy of servers from which it obtains resolution
     3934   results, could impact the authenticity of address mappings;
     3935   DNSSEC (<xref target="RFC4033"/>) is one way to improve authenticity.
     3936</t>
     3937<t>
     3938   Furthermore, after an IP address is obtained, establishing authority is
     3939   vulnerable to attacks on Internet Protocol routing.
     3940</t>
     3941<t>
     3942   The "https" scheme (<xref target="https.uri"/>) is intended to prevent
     3943   (or at least reveal) many of these potential attacks on establishing
     3944   authority, assuming the negotiated TLS connection is secured in a way that
     3945   verifies the communicating server's identity matches the target URI's
     3946   authority component (see <xref target="RFC2818"/> and
     3947   <xref target="Georgiev"/>).
     3948</t>
     3949</section>
     3950
     3951<section title="Risks of Intermediaries" anchor="risks.intermediaries">
     3952<t>
     3953   By their very nature, HTTP intermediaries are men-in-the-middle, and thus
    39063954   represent an opportunity for man-in-the-middle attacks. Compromise of
    39073955   the systems on which the intermediaries run can result in serious security
    3908    and privacy problems. Intermediaries have access to security-related
     3956   and privacy problems. Intermediaries might have access to security-related
    39093957   information, personal information about individual users and
    39103958   organizations, and proprietary information belonging to users and
     
    39163964<t>
    39173965   Intermediaries that contain a shared cache are especially vulnerable
    3918    to cache poisoning attacks.
     3966   to cache poisoning attacks, as described in &cache-poisoning;.
    39193967</t>
    39203968<t>
     
    39303978</section>
    39313979
    3932 <section title="Buffer Overflows" anchor="attack.protocol.element.size.overflows">
    3933 <t>
    3934    Because HTTP uses mostly textual, character-delimited fields, attackers can
    3935    overflow buffers in implementations, and/or perform a Denial of Service
    3936    against implementations that accept fields with unlimited lengths.
    3937 </t>
    3938 <t>
    3939    To promote interoperability, this specification makes specific
    3940    recommendations for minimum size limits on request-line
    3941    (<xref target="request.line"/>)
     3980<section title="Attacks via Protocol Element Length" anchor="attack.protocol.element.length">
     3981<t>
     3982   Because HTTP uses mostly textual, character-delimited fields, parsers are
     3983   often vulnerable to attacks based on sending very long (or very slow)
     3984   streams of data, particularly where an implementation is expecting a
     3985   protocol element with no predefined length.
     3986</t>
     3987<t>
     3988   To promote interoperability, specific recommendations are made for minimum
     3989   size limits on request-line (<xref target="request.line"/>)
    39423990   and header fields (<xref target="header.fields"/>). These are
    39433991   minimum recommendations, chosen to be supportable even by implementations
     
    39463994</t>
    39473995<t>
    3948    This specification also provides a way for servers to reject messages that
     3996   A server can reject messages that
    39493997   have request-targets that are too long (&status-414;) or request entities
    39503998   that are too large (&status-4xx;). Additional status codes related to
     
    39534001</t>
    39544002<t>
    3955    Recipients ought to carefully limit the extent to which they read other
    3956    fields, including (but not limited to) request methods, response status
    3957    phrases, header field-names, and body chunks, so as to avoid denial of
    3958    service attacks without impeding interoperability.
     4003   Recipients ought to carefully limit the extent to which they process other
     4004   protocol elements, including (but not limited to) request methods, response
     4005   status phrases, header field-names, numeric values, and body chunks.
     4006   Failure to limit such processing can result in buffer overflows, arithmetic
     4007   overflows, or increased vulnerability to denial of service attacks.
     4008</t>
     4009</section>
     4010
     4011<section title="Response Splitting" anchor="response.splitting">
     4012<t>
     4013   Response splitting (a.k.a, CRLF injection) is a common technique, used in
     4014   various attacks on Web usage, that exploits the line-based nature of HTTP
     4015   message framing and the ordered association of requests to responses on
     4016   persistent connections <xref target="Klein"/>. This technique can be
     4017   particularly damaging when the requests pass through a shared cache.
     4018</t>
     4019<t>
     4020   Response splitting exploits a vulnerability in servers (usually within an
     4021   application server) where an attacker can send encoded data within some
     4022   parameter of the request that is later decoded and echoed within any of the
     4023   response header fields of the response. If the decoded data is crafted to
     4024   look like the response has ended and a subsequent response has begun, the
     4025   response has been split and the content within the apparent second response
     4026   is controlled by the attacker. The attacker can then make any other request
     4027   on the same persistent connection and trick the recipients (including
     4028   intermediaries) into believing that the second half of the split is an
     4029   authoritative answer to the second request.
     4030</t>
     4031<t>
     4032   For example, a parameter within the request-target might be read by an
     4033   application server and reused within a redirect, resulting in the same
     4034   parameter being echoed in the <x:ref>Location</x:ref> header field of the
     4035   response. If the parameter is decoded by the application and not properly
     4036   encoded when placed in the response field, the attacker can send encoded
     4037   CRLF octets and other content that will make the application's single
     4038   response look like two or more responses.
     4039</t>
     4040<t>
     4041   A common defense against response splitting is to filter requests for data
     4042   that looks like encoded CR and LF (e.g., "%0D" and "%0A"). However, that
     4043   assumes the application server is only performing URI decoding, rather
     4044   than more obscure data transformations like charset transcoding, XML entity
     4045   translation, base64 decoding, sprintf reformatting, etc.  A more effective
     4046   mitigation is to prevent anything other than the server's core protocol
     4047   libraries from sending a CR or LF within the header section, which means
     4048   restricting the output of header fields to APIs that filter for bad octets
     4049   and not allowing application servers to write directly to the protocol
     4050   stream.
     4051</t>
     4052</section>
     4053
     4054<section title="Request Smuggling" anchor="request.smuggling">
     4055<t>
     4056   Request smuggling (<xref target="Linhart"/>) is a technique that exploits
     4057   differences in protocol parsing among various recipients to hide additional
     4058   requests (which might otherwise be blocked or disabled by policy) within an
     4059   apparently harmless request.  Like response splitting, request smuggling
     4060   can lead to a variety of attacks on HTTP usage.
     4061</t>
     4062<t>
     4063   This specification has introduced new requirements on request parsing,
     4064   particularly with regard to message framing in
     4065   <xref target="message.body.length"/>, to reduce the effectiveness of
     4066   request smuggling.
    39594067</t>
    39604068</section>
     
    39884096</section>
    39894097
    3990 <section title="Server Log Information" anchor="abuse.of.server.log.information">
     4098<section title="Message Confidentiality" anchor="message.confidentiality">
     4099<t>
     4100   HTTP relies on underlying transport protocols to provide message
     4101   confidentiality when that is desired. HTTP has been specifically designed
     4102   to be independent of the transport protocol, such that it can be used
     4103   over many different forms of encrypted connection, with the selection of
     4104   such transports being identified by the choice of URI scheme or within
     4105   user agent configuration.
     4106</t>
     4107<t>
     4108   The "https" scheme can be used to identify resources that require a
     4109   confidential connection, as described in <xref target="https.uri"/>.
     4110</t>
     4111</section>
     4112
     4113<section title="Privacy of Server Log Information" anchor="privacy.of.server.log.information">
    39914114<t>
    39924115   A server is in the position to save personal data about a user's requests
     
    50555178</reference>
    50565179
     5180<reference anchor="Klein" target="http://packetstormsecurity.com/papers/general/whitepaper_httpresponse.pdf">
     5181  <front>
     5182    <title>Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics</title>
     5183    <author initials="A." surname="Klein" fullname="Amit Klein">
     5184      <organization>Sanctum, Inc.</organization>
     5185    </author>
     5186    <date year="2004" month="March"/>
     5187  </front>
     5188</reference>
     5189
     5190<reference anchor="Georgiev" target="http://doi.acm.org/10.1145/2382196.2382204">
     5191  <front>
     5192    <title>The Most Dangerous Code in the World: Validating SSL Certificates in Non-browser Software</title>
     5193    <author initials="M." surname="Georgiev" fullname="Martin Georgiev"/>
     5194    <author initials="S." surname="Iyengar" fullname="Subodh Iyengar"/>
     5195    <author initials="S." surname="Jana" fullname="Suman Jana"/>
     5196    <author initials="R." surname="Anubhai" fullname="Rishita Anubhai"/>
     5197    <author initials="D." surname="Boneh" fullname="Dan Boneh"/>
     5198    <author initials="V." surname="Shmatikov" fullname="Vitaly Shmatikov"/>
     5199    <date year="2012" month="October"/>
     5200  </front>
     5201  <x:prose>In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS '12), pp. 38-49</x:prose>
     5202</reference>
     5203
     5204<reference anchor="Linhart" target="http://www.watchfire.com/news/whitepapers.aspx">
     5205  <front>
     5206    <title>HTTP Request Smuggling</title>
     5207    <author initials="C." surname="Linhart" fullname="Chaim Linhart"/>
     5208    <author initials="A." surname="Klein" fullname="Amit Klein"/>
     5209    <author initials="R." surname="Heled" fullname="Ronen Heled"/>
     5210    <author initials="S." surname="Orrin" fullname="Steve Orrin"/>
     5211    <date year="2005" month="June"/>
     5212  </front>
     5213</reference>
     5214
    50575215</references>
    50585216
Note: See TracChangeset for help on using the changeset viewer.