Ignore:
Timestamp:
02/01/13 09:41:34 (9 years ago)
Author:
fielding@…
Message:

(editorial) rearrange CONNECT and rewrite Security Considerations; partly addresses #419

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2077 r2078  
    12711271   subsequent GET and HEAD requests (see &caching;).
    12721272</t>
    1273 <t>
    1274    See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.
    1275 </t>
    12761273</section>
    12771274
    … …  
    15411538  <iref primary="true" item="CONNECT method" x:for-anchor=""/>
    15421539<t>
    1543    The CONNECT method is only applicable as a request to a proxy.
    1544    A CONNECT requests that the recipient establish a tunnel to the destination
    1545    origin server identified by the request-target and, if successful,
    1546    thereafter restrict its behavior to blind forwarding of packets, in
    1547    both directions, until the connection is closed.
     1540   The CONNECT method requests that the recipient establish a tunnel to the
     1541   destination origin server identified by the request-target and, if
     1542   successful, thereafter restrict its behavior to blind forwarding of
     1543   packets, in both directions, until the connection is closed.
     1544</t>
     1545<t>
     1546   CONNECT is intended only for use in requests to a proxy.
     1547   An origin server that receives a CONNECT request for itself &MAY;
     1548   respond with a <x:ref>2xx</x:ref> status code to indicate that a connection
     1549   is established.  However, most origin servers do not implement CONNECT.
    15481550</t>
    15491551<t>
    … …  
    15621564   the request-target or, if configured to use another proxy, by forwarding
    15631565   the CONNECT request to the next inbound proxy.
    1564    Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request indicates
    1565    that the sender (and any inbound proxies) will switch to tunnel mode
     1566   Any <x:ref>2xx (Successful)</x:ref> response indicates
     1567   that the sender (and all inbound proxies) will switch to tunnel mode
    15661568   immediately after the blank line that concludes the successful response's
    15671569   header block; data received after that blank line is from the server
    15681570   identified by the request-target.
     1571   Any response other than a successful response indicates that the tunnel
     1572   has not yet been formed and that the connection remains governed by HTTP.
    15691573</t>
    15701574<t>
    … …  
    15751579</t>
    15761580<t>
    1577    Any response other than a successful response indicates that the tunnel
    1578    has not yet been formed and that the connection remains governed by HTTP.
     1581   There are significant risks in establishing a tunnel to arbitrary servers,
     1582   particularly when the destination is a well-known or reserved TCP port that
     1583   is not intended for Web traffic. For example, a CONNECT to a request-target
     1584   of "example.com:25" would suggest that the proxy connect to the reserved
     1585   port for SMTP traffic; if allowed, that could trick the proxy into
     1586   relaying spam email. Proxies that support CONNECT &SHOULD; restrict its
     1587   use to a limited set of known ports or a configurable whitelist of safe
     1588   request targets.
    15791589</t>
    15801590<t>
    … …  
    15991609   connections. If there is outstanding data left undelivered,
    16001610   that data will be discarded.
    1601 </t>
    1602 <t>
    1603    An origin server that receives a CONNECT request for itself &MAY;
    1604    respond with a <x:ref>2xx</x:ref> status code to indicate that a connection
    1605    is established.  However, most origin servers do not implement CONNECT.
    16061611</t>
    16071612</section>
    … …  
    21612166   specifically configured to do so, because a detailed list of supported
    21622167   charsets makes it easier for a server to identify an individual by virtue
    2163    of the user agent's request characteristics (a.k.a., fingerprinting).
     2168   of the user agent's request characteristics (<xref target="fingerprinting"/>).
    21642169</t>
    21652170<t>
    … …  
    22852290   It might be contrary to the privacy expectations of the user to send
    22862291   an Accept-Language header field with the complete linguistic preferences of
    2287    the user in every request. For a discussion of this issue, see
    2288    <xref target="privacy.issues.connected.to.accept.header.fields"/>.
     2292   the user in every request (<xref target="fingerprinting"/>).
    22892293</t>
    22902294<t>
    … …  
    24142418   <x:ref>Referer</x:ref> header field in an unsecured HTTP request if the
    24152419   referring page was received with a secure protocol.
    2416    See <xref target="encoding.sensitive.information.in.uris"/> for additional
     2420   See <xref target="sensitive.information.in.uris"/> for additional
    24172421   security considerations.
    24182422</t>
    … …  
    46904694</t>
    46914695
     4696<section title="Attacks Based On File and Path Names" anchor="attack.pathname">
     4697<t>
     4698   Origin servers frequently make use of their local file system to manage the
     4699   mapping from effective request URI to resource representations.
     4700   Implementors need to be aware that most file systems are not designed to
     4701   protect against malicious file or path names, and thus depend on the
     4702   origin server to avoid mapping to file names, folders, or directories that
     4703   have special significance to the system.
     4704</t>
     4705<t>
     4706   For example, UNIX, Microsoft Windows, and other operating systems use ".."
     4707   as a path component to indicate a directory level above the current one,
     4708   and use specially named paths or file names to send data to system devices.
     4709   Similar naming conventions might exist within other types of storage
     4710   systems. Likewise, local storage systems have an annoying tendency to
     4711   prefer user-friendliness over security when handling invalid or unexpected
     4712   characters, recomposition of decomposed characters, and case-normalization
     4713   of case-insensitive names.
     4714</t>
     4715<t>
     4716   Attacks based on such special names tend to focus on either denial of
     4717   service (e.g., telling the server to read from a COM port) or disclosure
     4718   of configuration and source files that are not meant to be served.
     4719</t>
     4720</section>
     4721
    46924722<section title="Personal Information" anchor="personal.information">
    46934723<t>
    4694    HTTP clients are often privy to large amounts of personal information,
     4724   Clients are often privy to large amounts of personal information,
    46954725   including both information provided by the user to interact with resources
    46964726   (e.g., the user's name, location, mail address, passwords, encryption
    46974727   keys, etc.) and information about the user's browsing activity over
    4698    time (e.g., history, bookmarks, etc.). HTTP implementations need to
    4699    prevent unintentional leakage of this information.
    4700 </t>
    4701 </section>
    4702 
    4703 <section title="Attacks Based On File and Path Names" anchor="attack.pathname">
    4704 <t>
    4705    Origin servers &SHOULD; be careful to restrict
    4706    the documents sent in response to HTTP requests to be only those that were
    4707    intended by the server administrators. If an HTTP server translates
    4708    HTTP URIs directly into file system calls, the server &MUST; take
    4709    special care not to serve files that were not intended to be
    4710    delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
    4711    other operating systems use ".." as a path component to indicate a
    4712    directory level above the current one. On such a system, an HTTP
    4713    server &MUST; disallow any such construct in the request-target if it
    4714    would otherwise allow access to a resource outside those intended to
    4715    be accessible via the HTTP server. Similarly, files intended for
    4716    reference only internally to the server (such as access control
    4717    files, configuration files, and script code) &MUST; be protected from
    4718    inappropriate retrieval, since they might contain sensitive
    4719    information.
    4720 </t>
    4721 </section>
    4722 
    4723 <section title="Transfer of Sensitive Information" anchor="security.sensitive">
    4724 <t>
    4725    Like any generic data transfer protocol, HTTP cannot regulate the
    4726    content of the data that is transferred, nor is there any a priori
    4727    method of determining the sensitivity of any particular piece of
    4728    information within the context of any given request. Therefore,
    4729    applications ought to supply as much control over this information as
    4730    possible to the provider of that information. Four header fields are
    4731    worth special mention in this context: <x:ref>Server</x:ref>,
    4732    <x:ref>Via</x:ref>, <x:ref>Referer</x:ref> and <x:ref>From</x:ref>.
    4733 </t>
    4734 <t>
    4735    Revealing the specific software version of the server might allow the
    4736    server machine to become more vulnerable to attacks against software
    4737    that is known to contain security holes. Implementers &SHOULD; make the
    4738    <x:ref>Server</x:ref> header field a configurable option.
    4739 </t>
    4740 <t>
    4741    Proxies that serve as a portal through a network firewall &SHOULD;
    4742    take special precautions regarding the transfer of header information
    4743    that might identify hosts behind the firewall. In particular, they
    4744    &SHOULD; remove, or replace with sanitized versions, any <x:ref>Via</x:ref>
    4745    fields generated behind the firewall.
    4746 </t>
    4747 <t>
    4748    The <x:ref>Referer</x:ref> header field allows reading patterns to be
    4749    studied and reverse links drawn. Although it can be very useful, its power
    4750    can be abused if user details are not separated from the information
    4751    contained in the Referer. Even when the personal information has been
    4752    removed, the Referer header field might indicate a private document's URI
    4753    whose publication would be inappropriate.
    4754 </t>
    4755 <t>
    4756    The information sent in the <x:ref>From</x:ref> field might conflict with
    4757    the user's privacy interests or their site's security policy, and hence it
    4758    &SHOULD-NOT;  be transmitted without the user being able to disable,
    4759    enable, and modify the contents of the field. The user &MUST; be able
    4760    to set the contents of this field within a user preference or
    4761    application defaults configuration.
    4762 </t>
    4763 <t>
    4764    We suggest, though do not require, that a convenient toggle interface
    4765    be provided for the user to enable or disable the sending of
    4766    <x:ref>From</x:ref> and <x:ref>Referer</x:ref> information.
    4767 </t>
    4768 <t>
    4769    The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>) or
    4770    <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields can
    4771    sometimes be used to determine if a specific client or server is more
    4772    likely to be vulnerable to a known security hole. Unfortunately, this same
    4773    information is often used for other valuable purposes for which HTTP
    4774    currently has no better mechanism.
    4775 </t>
    4776 <t>
    4777    Furthermore, the <x:ref>User-Agent</x:ref> header field might contain enough
    4778    entropy to be used, possibly in conjunction with other material, to uniquely
    4779    identify the user.
    4780 </t>
    4781 <t>
    4782    Some request methods, like TRACE (<xref target="TRACE"/>), expose information
    4783    that was sent in request header fields within the body of their response.
    4784    Clients &SHOULD; be careful with sensitive information, like Cookies,
    4785    Authorization credentials, and other header fields that might be used to
    4786    collect data from the client.
    4787 </t>
    4788 </section>
    4789 
    4790 <section title="Encoding Sensitive Information in URIs" anchor="encoding.sensitive.information.in.uris">
     4728   time (e.g., history, bookmarks, etc.). Implementations need to
     4729   prevent unintentional leakage of personal information.
     4730</t>
     4731</section>
     4732
     4733<section title="Sensitive Information in URIs" anchor="sensitive.information.in.uris">
    47914734<t>
    47924735   URIs are intended to be shared, not secured, even when they identify secure
    4793    resources.  URIs are often shown on displays, added to templates when a page
     4736   resources. URIs are often shown on displays, added to templates when a page
    47944737   is printed, and stored in a variety of unprotected bookmark lists.
    47954738   It is therefore unwise to include information within a URI that
    … …  
    47974740</t>
    47984741<t>
    4799    Since the Referer header field tells a target site about the context that
    4800    resulted in a request, it has the potential to reveal information about the
    4801    user's immediate browsing history and any personal information that might
    4802    be found in the referring resource's URI. Further discussion of Referer
    4803    considerations can be found in <xref target="header.referer"/>.
    4804 </t>
    4805 <t>
    4806    Authors of services &SHOULD-NOT; use GET-based forms for the submission of
     4742   Authors of services ought to avoid GET-based forms for the submission of
    48074743   sensitive data because that data will be placed in the request-target. Many
    48084744   existing servers, proxies, and user agents log or display the request-target
    … …  
    48104746   to use POST-based form submission instead.
    48114747</t>
    4812 </section>
    4813 
    4814 <section title="Location Header Fields: Spoofing and Information Leakage" anchor="location.spoofing-leakage">
    4815 <t>
    4816    If a single server supports multiple organizations that do not trust
    4817    one another, then it &MUST; check the values of <x:ref>Location</x:ref> and
    4818    <x:ref>Content-Location</x:ref> header fields in responses that are
    4819    generated under control of said organizations to make sure that they do not
    4820    attempt to invalidate resources over which they have no authority.
    4821 </t>
    4822 <t>
    4823    Furthermore, appending the fragment identifier from one URI to another
    4824    one obtained from a <x:ref>Location</x:ref> header field might leak
    4825    confidential information to the target server &mdash; although the fragment
    4826    identifier is not transmitted in the final request, it might be visible to
    4827    the user agent through other means, such as scripting.
    4828 </t>
    4829 </section>
    4830 
    4831 <section title="Misuse of CONNECT">
    4832 <t>
    4833    Since tunneled data is opaque to the proxy, there are additional
    4834    risks to tunneling to other well-known or reserved ports.
    4835    An HTTP client CONNECTing to port 25 could relay spam
    4836    via SMTP, for example. As such, proxies &SHOULD; restrict CONNECT
    4837    access to a small number of known ports.
    4838 </t>
    4839 </section>
    4840 
    4841 <section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
    4842 <t>
    4843    Accept header fields can reveal information about the user to all
    4844    servers that are accessed. The <x:ref>Accept-Language</x:ref> header field
    4845    in particular can reveal information the user would consider to be of a
    4846    private nature, because the understanding of particular languages is often
    4847    strongly correlated to the membership of a particular ethnic group.
    4848    User agents that offer the option to configure the contents of an
    4849    Accept-Language header field to be sent in every request are strongly
    4850    encouraged to let the configuration process include a message which
    4851    makes the user aware of the loss of privacy involved.
    4852 </t>
    4853 <t>
    4854    An approach that limits the loss of privacy would be for a user agent
    4855    to omit the sending of Accept-Language header fields by default, and to ask
    4856    the user whether or not to start sending Accept-Language header fields to a
    4857    server if it detects, by looking for any <x:ref>Vary</x:ref> header fields
    4858    generated by the server, that such sending could improve the quality
    4859    of service.
    4860 </t>
    4861 <t>
    4862    Elaborate user-customized accept header fields sent in every request,
    4863    in particular if these include quality values, can be used by servers
    4864    as relatively reliable and long-lived user identifiers. Such user
    4865    identifiers would allow content providers to do click-trail tracking,
    4866    and would allow collaborating content providers to match cross-server
    4867    click-trails or form submissions of individual users. Note that for
    4868    many users not behind a proxy, the network address of the host
    4869    running the user agent will also serve as a long-lived user
    4870    identifier. In environments where proxies are used to enhance
    4871    privacy, user agents ought to be conservative in offering accept
    4872    header field configuration options to end users. As an extreme privacy
    4873    measure, proxies could filter the accept header fields in relayed requests.
    4874    General purpose user agents that provide a high degree of header field
    4875    configurability &SHOULD; warn users about the loss of privacy which can
    4876    be involved.
    4877 </t>
    4878 </section>
    4879 
     4748<t>
     4749   Since the <x:ref>Referer</x:ref> header field tells a target site about the
     4750   context that resulted in a request, it has the potential to reveal
     4751   information about the user's immediate browsing history and any personal
     4752   information that might be found in the referring resource's URI.
     4753   Limitations on Referer are described in <xref target="header.referer"/> to
     4754   address some of its security considerations.
     4755</t>
     4756</section>
     4757
     4758<section title="Product Information" anchor="sensitive.information.in.product">
     4759<t>
     4760   The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>),
     4761   <x:ref>Via</x:ref> (&header-via;), and
     4762   <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields often
     4763   reveal information about the respective sender's software systems.
     4764   In theory, this can make it easier for an attacker to exploit known
     4765   security holes; in practice, attackers tend to try all potential holes
     4766   regardless of the apparent software versions being used.
     4767</t>
     4768<t>
     4769   Proxies that serve as a portal through a network firewall ought to take
     4770   special precautions regarding the transfer of header information that might
     4771   identify hosts behind the firewall. The <x:ref>Via</x:ref> header field
     4772   allows intermediaries to replace sensitive machine names with pseudonyms.
     4773</t>
     4774</section>
     4775
     4776<section title="Fragment after Redirects" anchor="fragment.leakage">
     4777<t>
     4778   Although fragment identifiers used within URI references are not sent
     4779   in requests, implementers ought to be aware that they will be visible to
     4780   the user agent and any extensions or scripts running as a result of the
     4781   response. In particular, when a redirect occurs and the original request's
     4782   fragment identifier is inherited by the new reference in
     4783   <x:ref>Location</x:ref> (<xref target="header.location"/>), this might
     4784   have the effect of leaking one site's fragment to another site.
     4785   If the first site uses personal information in fragments, it ought to
     4786   ensure that redirects to other sites include a (possibly empty) fragment
     4787   component in order to block that inheritance.
     4788</t>
     4789</section>
     4790
     4791<section title="Browser Fingerprinting" anchor="fingerprinting">
     4792<t>
     4793   Browser fingerprinting is a set of techniques for identifying a specific
     4794   user agent over time through its unique set of characteristics. These
     4795   characteristics might include information related to its TCP behavior,
     4796   feature capabilities, and scripting environment, though of particular
     4797   interest here is the set of unique characteristics that might be
     4798   communicated via HTTP. Fingerprinting is considered a privacy concern
     4799   because it enables tracking of a user agent's behavior over time without
     4800   the corresponding controls that the user might have over other forms of
     4801   data collection (e.g., cookies). Many general-purpose user agents
     4802   (i.e., Web browsers) have taken steps to reduce their fingerprints.
     4803</t>
     4804<t>
     4805   There are a number of request header fields that might reveal information
     4806   to servers that is sufficiently unique to enable fingerprinting.
     4807   The <x:ref>From</x:ref> header field is the most obvious, though it is
     4808   expected that From will only be sent when self-identification is desired by
     4809   the user. Likewise, Cookie header fields are deliberately designed to
     4810   enable re-identification, so we can assume that fingerprinting concerns
     4811   only apply to situations where cookies are disabled or restricted by
     4812   browser configuration.
     4813</t>
     4814<t>
     4815   The <x:ref>User-Agent</x:ref> header field might contain enough information
     4816   to uniquely identify a specific device, usually when combined with other
     4817   characteristics, particularly if the user agent sends excessive details
     4818   about the user's system or extensions. However, the source of unique
     4819   information that is least expected by users is
     4820   <x:ref>proactive negotiation</x:ref> (<xref target="request.conneg"/>),
     4821   including the <x:ref>Accept</x:ref>, <x:ref>Accept-Charset</x:ref>,
     4822   <x:ref>Accept-Encoding</x:ref>, and <x:ref>Accept-Language</x:ref>
     4823   header fields.
     4824</t>
     4825<t>
     4826   In addition to the fingerprinting concern, detailed use of the
     4827   <x:ref>Accept-Language</x:ref> header field can reveal information the
     4828   user might consider to be of a private nature, because the understanding of
     4829   particular languages is often strongly correlated to membership in a
     4830   particular ethnic group.
     4831   An approach that limits such loss of privacy would be for a user agent
     4832   to omit the sending of Accept-Language except for sites that have been
     4833   whitelisted, perhaps via interaction after detecting a <x:ref>Vary</x:ref>
     4834   header field that would indicate language negotiation might be useful.
     4835</t>
     4836<t>
     4837   In environments where proxies are used to enhance privacy, user agents
     4838   ought to be conservative in sending proactive negotiation header fields.
     4839   General-purpose user agents that provide a high degree of header field
     4840   configurability ought to inform users about the loss of privacy that might
     4841   result if too much detail is provided. As an extreme privacy measure,
     4842   proxies could filter the proactive negotiation header fields in relayed
     4843   requests.
     4844</t>
     4845</section>
    48804846</section>
    48814847
Note: See TracChangeset for help on using the changeset viewer.