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/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>
Note: See TracChangeset for help on using the changeset viewer.