Changeset 2078 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 02/01/13 09:41:34 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r2077 r2078 1271 1271 subsequent GET and HEAD requests (see &caching;). 1272 1272 </t> 1273 <t>1274 See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.1275 </t>1276 1273 </section> 1277 1274 … … 1541 1538 <iref primary="true" item="CONNECT method" x:for-anchor=""/> 1542 1539 <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. 1548 1550 </t> 1549 1551 <t> … … 1562 1564 the request-target or, if configured to use another proxy, by forwarding 1563 1565 the CONNECT request to the next inbound proxy. 1564 Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT requestindicates1565 that the sender (and a nyinbound proxies) will switch to tunnel mode1566 Any <x:ref>2xx (Successful)</x:ref> response indicates 1567 that the sender (and all inbound proxies) will switch to tunnel mode 1566 1568 immediately after the blank line that concludes the successful response's 1567 1569 header block; data received after that blank line is from the server 1568 1570 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. 1569 1573 </t> 1570 1574 <t> … … 1575 1579 </t> 1576 1580 <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. 1579 1589 </t> 1580 1590 <t> … … 1599 1609 connections. If there is outstanding data left undelivered, 1600 1610 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 connection1605 is established. However, most origin servers do not implement CONNECT.1606 1611 </t> 1607 1612 </section> … … 2161 2166 specifically configured to do so, because a detailed list of supported 2162 2167 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"/>). 2164 2169 </t> 2165 2170 <t> … … 2285 2290 It might be contrary to the privacy expectations of the user to send 2286 2291 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"/>). 2289 2293 </t> 2290 2294 <t> … … 2414 2418 <x:ref>Referer</x:ref> header field in an unsecured HTTP request if the 2415 2419 referring page was received with a secure protocol. 2416 See <xref target=" encoding.sensitive.information.in.uris"/> for additional2420 See <xref target="sensitive.information.in.uris"/> for additional 2417 2421 security considerations. 2418 2422 </t> … … 4690 4694 </t> 4691 4695 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 4692 4722 <section title="Personal Information" anchor="personal.information"> 4693 4723 <t> 4694 HTTP clients are often privy to large amounts of personal information,4724 Clients are often privy to large amounts of personal information, 4695 4725 including both information provided by the user to interact with resources 4696 4726 (e.g., the user's name, location, mail address, passwords, encryption 4697 4727 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"> 4791 4734 <t> 4792 4735 URIs are intended to be shared, not secured, even when they identify secure 4793 resources. 4736 resources. URIs are often shown on displays, added to templates when a page 4794 4737 is printed, and stored in a variety of unprotected bookmark lists. 4795 4738 It is therefore unwise to include information within a URI that … … 4797 4740 </t> 4798 4741 <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 4807 4743 sensitive data because that data will be placed in the request-target. Many 4808 4744 existing servers, proxies, and user agents log or display the request-target … … 4810 4746 to use POST-based form submission instead. 4811 4747 </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 — 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> 4880 4846 </section> 4881 4847
Note: See TracChangeset
for help on using the changeset viewer.