Ignore:
Timestamp:
Dec 30, 2012, 1:19:07 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) move p1 security considerations regarding semantics to p2

File:
1 edited

Legend:

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

    r2069 r2070  
    672672         </li>
    673673         <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    674                <li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
    675                <li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
    676                <li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
    677                <li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
    678                <li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#attack.intermediaries">Intermediaries and Caching</a></li>
    679                <li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Buffer Overflows</a></li>
    680                <li><a href="#rfc.section.8.7">8.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li>
     674               <li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
     675               <li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#attack.intermediaries">Intermediaries and Caching</a></li>
     676               <li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Buffer Overflows</a></li>
     677               <li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li>
     678               <li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#abuse.of.server.log.information">Server Log Information</a></li>
    681679            </ul>
    682680         </li>
     
    14061404      </p>
    14071405      <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
    1408          an HTTP payload, recipients <em class="bcp14">SHOULD</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;8.6</a>).
     1406         an HTTP payload, recipients <em class="bcp14">SHOULD</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;8.3</a>).
    14091407      </p>
    14101408      <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,
     
    24562454         message syntax, parsing, and routing.
    24572455      </p>
    2458       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
    2459       <p id="rfc.section.8.1.p.1">HTTP clients are often privy to large amounts of personal information, including both information provided by the user to
    2460          interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information
    2461          about the user's browsing activity over time (e.g., history, bookmarks, etc.). HTTP implementations need to prevent unintentional
    2462          leakage of this information.
    2463       </p>
    2464       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
    2465       <p id="rfc.section.8.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects
    2466          of interest. In particular, log information gathered at an intermediary often contains a history of user agent interaction,
    2467          across a multitude of sites, that can be traced to individual users.
    2468       </p>
    2469       <p id="rfc.section.8.2.p.2">HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information
    2470          needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within
    2471          individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation
    2472          with other access characteristics. As such, access traces that are keyed to a specific client should not be published even
    2473          if the key is pseudonymous.
    2474       </p>
    2475       <p id="rfc.section.8.2.p.3">To minimize the risk of theft or accidental publication, log information should be purged of personally identifiable information,
    2476          including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary
    2477          to support operational needs for security, auditing, or fraud control.
    2478       </p>
    2479       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
    2480       <p id="rfc.section.8.3.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents sent in response to HTTP requests to be only those that were intended by the server administrators.
    2481          If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft
    2482          Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
    2483          such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the request-target if it would otherwise allow access to a resource outside those intended
    2484          to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access
    2485          control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information.
    2486       </p>
    2487       <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
    2488       <p id="rfc.section.8.4.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the
     2456      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
     2457      <p id="rfc.section.8.1.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the
    24892458         deliberate misassociation of IP addresses and DNS names not protected by DNSSEC. Clients need to be cautious in assuming the
    24902459         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>).
    24912460      </p>
    2492       <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="attack.intermediaries" href="#attack.intermediaries">Intermediaries and Caching</a></h2>
    2493       <p id="rfc.section.8.5.p.1">By their very nature, HTTP intermediaries are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks.
     2461      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="attack.intermediaries" href="#attack.intermediaries">Intermediaries and Caching</a></h2>
     2462      <p id="rfc.section.8.2.p.1">By their very nature, HTTP intermediaries are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks.
    24942463         Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries
    24952464         have access to security-related information, personal information about individual users and organizations, and proprietary
     
    24972466         without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
    24982467      </p>
    2499       <p id="rfc.section.8.5.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks.</p>
    2500       <p id="rfc.section.8.5.p.3">Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration
     2468      <p id="rfc.section.8.2.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks.</p>
     2469      <p id="rfc.section.8.2.p.3">Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration
    25012470         options they provide to operators (especially the default configuration).
    25022471      </p>
    2503       <p id="rfc.section.8.5.p.4">Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve
     2472      <p id="rfc.section.8.2.p.4">Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve
    25042473         this problem.
    25052474      </p>
    2506       <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Buffer Overflows</a></h2>
    2507       <p id="rfc.section.8.6.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform
     2475      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Buffer Overflows</a></h2>
     2476      <p id="rfc.section.8.3.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform
    25082477         a Denial of Service against implementations that accept fields with unlimited lengths.
    25092478      </p>
    2510       <p id="rfc.section.8.6.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 blocks of 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
     2479      <p id="rfc.section.8.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 blocks of 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
    25112480         that most implementations will choose substantially higher limits.
    25122481      </p>
    2513       <p id="rfc.section.8.6.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.27"><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.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    2514       </p>
    2515       <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
     2482      <p id="rfc.section.8.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.27"><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.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2483      </p>
     2484      <p id="rfc.section.8.3.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
    25162485         phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.
    25172486      </p>
    2518       <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="message.integrity" href="#message.integrity">Message Integrity</a></h2>
    2519       <p id="rfc.section.8.7.p.1">HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of
     2487      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="message.integrity" href="#message.integrity">Message Integrity</a></h2>
     2488      <p id="rfc.section.8.4.p.1">HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of
    25202489         underlying transport protocols and the use of length or chunk-delimited framing to detect completeness. Additional integrity
    25212490         mechanisms, such as hash functions or digital signatures applied to the content, can be selectively added to messages via
     
    25242493         increasing use within environments where verification of message integrity is crucial.
    25252494      </p>
    2526       <p id="rfc.section.8.7.p.2">User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such
     2495      <p id="rfc.section.8.4.p.2">User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such
    25272496         that those means can be enabled within environments for which integrity is necessary. For example, a browser being used to
    25282497         view medical history or drug interaction information needs to indicate to the user when such information is detected by the
     
    25302499         extensions or the presence of message integrity metadata in a response. At a minimum, user agents ought to provide some indication
    25312500         that allows a user to distinguish between a complete and incomplete response message (<a href="#incomplete.messages" title="Handling Incomplete Messages">Section&nbsp;3.4</a>) when such verification is desired.
     2501      </p>
     2502      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Server Log Information</a></h2>
     2503      <p id="rfc.section.8.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
     2504         or subjects of interest. In particular, log information gathered at an intermediary often contains a history of user agent
     2505         interaction, across a multitude of sites, that can be traced to individual users.
     2506      </p>
     2507      <p id="rfc.section.8.5.p.2">HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information
     2508         needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within
     2509         individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation
     2510         with other access characteristics. As such, access traces that are keyed to a specific client should not be published even
     2511         if the key is pseudonymous.
     2512      </p>
     2513      <p id="rfc.section.8.5.p.3">To minimize the risk of theft or accidental publication, log information should be purged of personally identifiable information,
     2514         including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary
     2515         to support operational needs for security, auditing, or fraud control.
    25322516      </p>
    25332517      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     
    32723256            </li>
    32733257            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3274                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.7</a>, <a href="#rfc.xref.Part2.26">7.4</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#rfc.xref.Part2.28">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3258                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.7</a>, <a href="#rfc.xref.Part2.26">7.4</a>, <a href="#rfc.xref.Part2.27">8.3</a>, <a href="#rfc.xref.Part2.28">8.3</a>, <a href="#Part2"><b>10.1</b></a><ul>
    32753259                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    32763260                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.26">7.4</a></li>
     
    32863270                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    32873271                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.7</a></li>
    3288                         <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">8.6</a></li>
    3289                         <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.6</a></li>
     3272                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">8.3</a></li>
     3273                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.3</a></li>
    32903274                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    32913275                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.2</a></li>
     
    33613345                     </ul>
    33623346                  </li>
    3363                   <li><em>RFC4033</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4033.1">8.4</a>, <a href="#RFC4033"><b>10.2</b></a></li>
     3347                  <li><em>RFC4033</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4033.1">8.1</a>, <a href="#RFC4033"><b>10.2</b></a></li>
    33643348                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li>
    33653349                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a>, <a href="#RFC5226"><b>10.2</b></a><ul>
Note: See TracChangeset for help on using the changeset viewer.