Changeset 2070 for draft-ietf-httpbis


Ignore:
Timestamp:
30/12/12 09:19:07 (10 years ago)
Author:
fielding@…
Message:

(editorial) move p1 security considerations regarding semantics to p2

Location:
draft-ietf-httpbis/latest
Files:
4 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>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2069 r2070  
    34953495</t>
    34963496
    3497 <section title="Personal Information" anchor="personal.information">
    3498 <t>
    3499    HTTP clients are often privy to large amounts of personal information,
    3500    including both information provided by the user to interact with resources
    3501    (e.g., the user's name, location, mail address, passwords, encryption
    3502    keys, etc.) and information about the user's browsing activity over
    3503    time (e.g., history, bookmarks, etc.). HTTP implementations need to
    3504    prevent unintentional leakage of this information.
    3505 </t>
    3506 </section>
    3507 
    3508 <section title="Abuse of Server Log Information" anchor="abuse.of.server.log.information">
    3509 <t>
    3510    A server is in the position to save personal data about a user's
    3511    requests which might identify their reading patterns or subjects of
    3512    interest.  In particular, log information gathered at an intermediary
    3513    often contains a history of user agent interaction, across a multitude
    3514    of sites, that can be traced to individual users.
    3515 </t>
    3516 <t>
    3517    HTTP log information is confidential in nature; its handling is often
    3518    constrained by laws and regulations.  Log information needs to be securely
    3519    stored and appropriate guidelines followed for its analysis.
    3520    Anonymization of personal information within individual entries helps,
    3521    but is generally not sufficient to prevent real log traces from being
    3522    re-identified based on correlation with other access characteristics.
    3523    As such, access traces that are keyed to a specific client should not
    3524    be published even if the key is pseudonymous.
    3525 </t>
    3526 <t>
    3527    To minimize the risk of theft or accidental publication, log information
    3528    should be purged of personally identifiable information, including
    3529    user identifiers, IP addresses, and user-provided query parameters,
    3530    as soon as that information is no longer necessary to support operational
    3531    needs for security, auditing, or fraud control.
    3532 </t>
    3533 </section>
    3534 
    3535 <section title="Attacks Based On File and Path Names" anchor="attack.pathname">
    3536 <t>
    3537    Origin servers &SHOULD; be careful to restrict
    3538    the documents sent in response to HTTP requests to be only those that were
    3539    intended by the server administrators. If an HTTP server translates
    3540    HTTP URIs directly into file system calls, the server &MUST; take
    3541    special care not to serve files that were not intended to be
    3542    delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
    3543    other operating systems use ".." as a path component to indicate a
    3544    directory level above the current one. On such a system, an HTTP
    3545    server &MUST; disallow any such construct in the request-target if it
    3546    would otherwise allow access to a resource outside those intended to
    3547    be accessible via the HTTP server. Similarly, files intended for
    3548    reference only internally to the server (such as access control
    3549    files, configuration files, and script code) &MUST; be protected from
    3550    inappropriate retrieval, since they might contain sensitive
    3551    information.
    3552 </t>
    3553 </section>
    3554 
    35553497<section title="DNS-related Attacks" anchor="dns.related.attacks">
    35563498<t>
    … …  
    36453587   user to distinguish between a complete and incomplete response message
    36463588   (<xref target="incomplete.messages"/>) when such verification is desired.
     3589</t>
     3590</section>
     3591
     3592<section title="Server Log Information" anchor="abuse.of.server.log.information">
     3593<t>
     3594   A server is in the position to save personal data about a user's requests
     3595   over time, which might identify their reading patterns or subjects of
     3596   interest.  In particular, log information gathered at an intermediary
     3597   often contains a history of user agent interaction, across a multitude
     3598   of sites, that can be traced to individual users.
     3599</t>
     3600<t>
     3601   HTTP log information is confidential in nature; its handling is often
     3602   constrained by laws and regulations.  Log information needs to be securely
     3603   stored and appropriate guidelines followed for its analysis.
     3604   Anonymization of personal information within individual entries helps,
     3605   but is generally not sufficient to prevent real log traces from being
     3606   re-identified based on correlation with other access characteristics.
     3607   As such, access traces that are keyed to a specific client should not
     3608   be published even if the key is pseudonymous.
     3609</t>
     3610<t>
     3611   To minimize the risk of theft or accidental publication, log information
     3612   should be purged of personally identifiable information, including
     3613   user identifiers, IP addresses, and user-provided query parameters,
     3614   as soon as that information is no longer necessary to support operational
     3615   needs for security, auditing, or fraud control.
    36473616</t>
    36483617</section>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2069 r2070  
    766766         </li>
    767767         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    768                <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
    769                <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
    770                <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
    771                <li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4">Security Considerations for CONNECT</a></li>
    772                <li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li>
     768               <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
     769               <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
     770               <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
     771               <li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
     772               <li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
     773               <li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.6">Misuse of CONNECT</a></li>
     774               <li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li>
    773775            </ul>
    774776         </li>
    … …  
    14051407      <p id="rfc.section.4.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    14061408      </p>
    1407       <p id="rfc.section.4.3.1.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;9.2</a> for security considerations when used for forms.
     1409      <p id="rfc.section.4.3.1.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;9.4</a> for security considerations when used for forms.
    14081410      </p>
    14091411      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
    … …  
    19801982      </div>
    19811983      <p id="rfc.section.5.3.5.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
    1982          preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section&nbsp;9.5</a>.
     1984         preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section&nbsp;9.7</a>.
    19831985      </p>
    19841986      <p id="rfc.section.5.3.5.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
    … …  
    20772079</pre><p id="rfc.section.5.5.2.p.5">Example:</p>
    20782080      <div id="rfc.figure.u.37"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
    2079 </pre><p id="rfc.section.5.5.2.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;9.2</a> for security considerations.
     2081</pre><p id="rfc.section.5.5.2.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;9.4</a> for security considerations.
    20802082      </p>
    20812083      <div id="rfc.iref.u.1"></div>
    … …  
    37483750         semantics and its use for transferring information over the Internet.
    37493751      </p>
    3750       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
    3751       <p id="rfc.section.9.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
     3752      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
     3753      <p id="rfc.section.9.1.p.1">HTTP clients are often privy to large amounts of personal information, including both information provided by the user to
     3754         interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information
     3755         about the user's browsing activity over time (e.g., history, bookmarks, etc.). HTTP implementations need to prevent unintentional
     3756         leakage of this information.
     3757      </p>
     3758      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
     3759      <p id="rfc.section.9.2.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.
     3760         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
     3761         Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
     3762         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
     3763         to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access
     3764         control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information.
     3765      </p>
     3766      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
     3767      <p id="rfc.section.9.3.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
    37523768         a priori method of determining the sensitivity of any particular piece of information within the context of any given request.
    37533769         Therefore, applications ought to supply as much control over this information as possible to the provider of that information.
    37543770         Four header fields are worth special mention in this context: <a href="#header.server" class="smpl">Server</a>, <a href="p1-messaging.html#header.via" class="smpl">Via</a>, <a href="#header.referer" class="smpl">Referer</a> and <a href="#header.from" class="smpl">From</a>.
    37553771      </p>
    3756       <p id="rfc.section.9.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
     3772      <p id="rfc.section.9.3.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    37573773         against software that is known to contain security holes. Implementers <em class="bcp14">SHOULD</em> make the <a href="#header.server" class="smpl">Server</a> header field a configurable option.
    37583774      </p>
    3759       <p id="rfc.section.9.1.p.3">Proxies that serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that might identify hosts behind the firewall. In particular,
     3775      <p id="rfc.section.9.3.p.3">Proxies that serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that might identify hosts behind the firewall. In particular,
    37603776         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any <a href="p1-messaging.html#header.via" class="smpl">Via</a> fields generated behind the firewall.
    37613777      </p>
    3762       <p id="rfc.section.9.1.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can
     3778      <p id="rfc.section.9.3.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can
    37633779         be abused if user details are not separated from the information contained in the Referer. Even when the personal information
    37643780         has been removed, the Referer header field might indicate a private document's URI whose publication would be inappropriate.
    37653781      </p>
    3766       <p id="rfc.section.9.1.p.5">The information sent in the <a href="#header.from" class="smpl">From</a> field might conflict with the user's privacy interests or their site's security policy, and hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
    3767       </p>
    3768       <p id="rfc.section.9.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
     3782      <p id="rfc.section.9.3.p.5">The information sent in the <a href="#header.from" class="smpl">From</a> field might conflict with the user's privacy interests or their site's security policy, and hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
     3783      </p>
     3784      <p id="rfc.section.9.3.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
    37693785         of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information.
    37703786      </p>
    3771       <p id="rfc.section.9.1.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;5.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.4.2</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
     3787      <p id="rfc.section.9.3.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;5.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.4.2</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
    37723788         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
    37733789         no better mechanism.
    37743790      </p>
    3775       <p id="rfc.section.9.1.p.8">Furthermore, the <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough entropy to be used, possibly in conjunction with other material, to uniquely identify the
     3791      <p id="rfc.section.9.3.p.8">Furthermore, the <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough entropy to be used, possibly in conjunction with other material, to uniquely identify the
    37763792         user.
    37773793      </p>
    3778       <p id="rfc.section.9.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;4.3.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
     3794      <p id="rfc.section.9.3.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;4.3.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
    37793795         to collect data from the client.
    37803796      </p>
    3781       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
    3782       <p id="rfc.section.9.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
     3797      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
     3798      <p id="rfc.section.9.4.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
    37833799         recommended that the user be able to select whether or not the <a href="#header.referer" class="smpl">Referer</a> field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively
    37843800         enable/disable the sending of Referer and From information.
    37853801      </p>
    3786       <p id="rfc.section.9.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a <a href="#header.referer" class="smpl">Referer</a> header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
    3787       </p>
    3788       <p id="rfc.section.9.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
     3802      <p id="rfc.section.9.4.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a <a href="#header.referer" class="smpl">Referer</a> header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
     3803      </p>
     3804      <p id="rfc.section.9.4.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
    37893805         servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties.
    37903806         Such services can use POST-based form submission instead.
    37913807      </p>
    3792       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
    3793       <p id="rfc.section.9.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of <a href="#header.location" class="smpl">Location</a> and <a href="#header.content-location" class="smpl">Content-Location</a> header fields in responses that are generated under control of said organizations to make sure that they do not attempt to
     3808      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
     3809      <p id="rfc.section.9.5.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of <a href="#header.location" class="smpl">Location</a> and <a href="#header.content-location" class="smpl">Content-Location</a> header fields in responses that are generated under control of said organizations to make sure that they do not attempt to
    37943810         invalidate resources over which they have no authority.
    37953811      </p>
    3796       <p id="rfc.section.9.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a <a href="#header.location" class="smpl">Location</a> header field might leak confidential information to the target server — although the fragment identifier is not transmitted
     3812      <p id="rfc.section.9.5.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a <a href="#header.location" class="smpl">Location</a> header field might leak confidential information to the target server — although the fragment identifier is not transmitted
    37973813         in the final request, it might be visible to the user agent through other means, such as scripting.
    37983814      </p>
    3799       <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;Security Considerations for CONNECT
     3815      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;Misuse of CONNECT
    38003816      </h2>
    3801       <p id="rfc.section.9.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
     3817      <p id="rfc.section.9.6.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
    38023818         An HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports.
    38033819      </p>
    3804       <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
    3805       <p id="rfc.section.9.5.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding
     3820      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
     3821      <p id="rfc.section.9.7.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding
    38063822         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
    38073823         the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
    38083824         to let the configuration process include a message which makes the user aware of the loss of privacy involved.
    38093825      </p>
    3810       <p id="rfc.section.9.5.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
     3826      <p id="rfc.section.9.7.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
    38113827         by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
    38123828         looking for any <a href="#header.vary" class="smpl">Vary</a> header fields generated by the server, that such sending could improve the quality of service.
    38133829      </p>
    3814       <p id="rfc.section.9.5.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
     3830      <p id="rfc.section.9.7.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
    38153831         used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers
    38163832         to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions
    … …  
    47164732                  <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>4.2.1</b></a></li>
    47174733                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.7"><b>7.2</b></a></li>
    4718                   <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">C</a></li>
     4734                  <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.3</a>, <a href="#rfc.xref.header.server.4">C</a></li>
    47194735                  <li>Status Codes Classes&nbsp;&nbsp;
    47204736                     <ul>
    … …  
    47304746            </li>
    47314747            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    4732                   <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.xref.TRACE.4">9.1</a>, <a href="#rfc.extref.t.48">C</a>, <a href="#rfc.xref.TRACE.5">C</a></li>
     4748                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.xref.TRACE.4">9.3</a>, <a href="#rfc.extref.t.48">C</a>, <a href="#rfc.xref.TRACE.5">C</a></li>
    47334749               </ul>
    47344750            </li>
    47354751            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    4736                   <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">7.4.2</a>, <a href="#rfc.xref.header.user-agent.3">8.3.2</a>, <a href="#rfc.xref.header.user-agent.4">9.1</a></li>
     4752                  <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">7.4.2</a>, <a href="#rfc.xref.header.user-agent.3">8.3.2</a>, <a href="#rfc.xref.header.user-agent.4">9.3</a></li>
    47374753               </ul>
    47384754            </li>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2069 r2070  
    46514651</t>
    46524652
     4653<section title="Personal Information" anchor="personal.information">
     4654<t>
     4655   HTTP clients are often privy to large amounts of personal information,
     4656   including both information provided by the user to interact with resources
     4657   (e.g., the user's name, location, mail address, passwords, encryption
     4658   keys, etc.) and information about the user's browsing activity over
     4659   time (e.g., history, bookmarks, etc.). HTTP implementations need to
     4660   prevent unintentional leakage of this information.
     4661</t>
     4662</section>
     4663
     4664<section title="Attacks Based On File and Path Names" anchor="attack.pathname">
     4665<t>
     4666   Origin servers &SHOULD; be careful to restrict
     4667   the documents sent in response to HTTP requests to be only those that were
     4668   intended by the server administrators. If an HTTP server translates
     4669   HTTP URIs directly into file system calls, the server &MUST; take
     4670   special care not to serve files that were not intended to be
     4671   delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
     4672   other operating systems use ".." as a path component to indicate a
     4673   directory level above the current one. On such a system, an HTTP
     4674   server &MUST; disallow any such construct in the request-target if it
     4675   would otherwise allow access to a resource outside those intended to
     4676   be accessible via the HTTP server. Similarly, files intended for
     4677   reference only internally to the server (such as access control
     4678   files, configuration files, and script code) &MUST; be protected from
     4679   inappropriate retrieval, since they might contain sensitive
     4680   information.
     4681</t>
     4682</section>
     4683
    46534684<section title="Transfer of Sensitive Information" anchor="security.sensitive">
    46544685<t>
    … …  
    47594790</section>
    47604791
    4761 <section title="Security Considerations for CONNECT">
     4792<section title="Misuse of CONNECT">
    47624793<t>
    47634794   Since tunneled data is opaque to the proxy, there are additional
Note: See TracChangeset for help on using the changeset viewer.