Changeset 2565
- Timestamp:
- 21/01/14 12:09:19 (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2563 r2565 448 448 } 449 449 @bottom-center { 450 content: "Expires July 2 3, 2014";450 content: "Expires July 25, 2014"; 451 451 } 452 452 @bottom-right { … … 493 493 <meta name="dct.creator" content="Reschke, J. F."> 494 494 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 495 <meta name="dct.issued" scheme="ISO8601" content="2014-01- 19">495 <meta name="dct.issued" scheme="ISO8601" content="2014-01-21"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 497 497 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 521 521 <tr> 522 522 <td class="left">Intended status: Standards Track</td> 523 <td class="right">January 19, 2014</td>523 <td class="right">January 21, 2014</td> 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: July 2 3, 2014</td>526 <td class="left">Expires: July 25, 2014</td> 527 527 <td class="right"></td> 528 528 </tr> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on July 2 3, 2014.</p>555 <p>This Internet-Draft will expire on July 25, 2014.</p> 556 556 </div> 557 557 <div id="rfc.copyrightnotice"> … … 764 764 <li><a href="#rfc.section.9">9.</a> <a href="#security.considerations">Security Considerations</a><ul> 765 765 <li><a href="#rfc.section.9.1">9.1</a> <a href="#attack.pathname">Attacks Based On File and Path Names</a></li> 766 <li><a href="#rfc.section.9.2">9.2</a> <a href="#personal.information">Personal Information</a></li> 767 <li><a href="#rfc.section.9.3">9.3</a> <a href="#sensitive.information.in.uris">Sensitive Information in URIs</a></li> 768 <li><a href="#rfc.section.9.4">9.4</a> <a href="#sensitive.information.in.product">Product Information</a></li> 769 <li><a href="#rfc.section.9.5">9.5</a> <a href="#fragment.leakage">Fragment after Redirects</a></li> 770 <li><a href="#rfc.section.9.6">9.6</a> <a href="#fingerprinting">Browser Fingerprinting</a></li> 766 <li><a href="#rfc.section.9.2">9.2</a> <a href="#attack.injection">Attacks Based On Command, Code, or Query Injection</a></li> 767 <li><a href="#rfc.section.9.3">9.3</a> <a href="#personal.information">Personal Information</a></li> 768 <li><a href="#rfc.section.9.4">9.4</a> <a href="#sensitive.information.in.uris">Sensitive Information in URIs</a></li> 769 <li><a href="#rfc.section.9.5">9.5</a> <a href="#sensitive.information.in.product">Product Information</a></li> 770 <li><a href="#rfc.section.9.6">9.6</a> <a href="#fragment.leakage">Fragment after Redirects</a></li> 771 <li><a href="#rfc.section.9.7">9.7</a> <a href="#fingerprinting">Browser Fingerprinting</a></li> 771 772 </ul> 772 773 </li> … … 2053 2054 <p id="rfc.section.5.3.3.p.6">A request without any Accept-Charset header field implies that the user agent will accept any charset in response. Most general-purpose 2054 2055 user agents do not send Accept-Charset, unless specifically configured to do so, because a detailed list of supported charsets 2055 makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (<a href="#fingerprinting" title="Browser Fingerprinting">Section 9. 6</a>).2056 makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (<a href="#fingerprinting" title="Browser Fingerprinting">Section 9.7</a>). 2056 2057 </p> 2057 2058 <p id="rfc.section.5.3.3.p.7">If an Accept-Charset header field is present in a request and none of the available representations for the response has a … … 2130 2131 </p> 2131 2132 <p id="rfc.section.5.3.5.p.9">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic 2132 preferences of the user in every request (<a href="#fingerprinting" title="Browser Fingerprinting">Section 9. 6</a>).2133 preferences of the user in every request (<a href="#fingerprinting" title="Browser Fingerprinting">Section 9.7</a>). 2133 2134 </p> 2134 2135 <p id="rfc.section.5.3.5.p.10">Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic … … 2239 2240 is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource 2240 2241 that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user 2241 agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent <em class="bcp14">MUST NOT</em> send a <a href="#header.referer" class="smpl">Referer</a> header field in an unsecured HTTP request if the referring page was received with a secure protocol. See <a href="#sensitive.information.in.uris" title="Sensitive Information in URIs">Section 9. 3</a> for additional security considerations.2242 agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent <em class="bcp14">MUST NOT</em> send a <a href="#header.referer" class="smpl">Referer</a> header field in an unsecured HTTP request if the referring page was received with a secure protocol. See <a href="#sensitive.information.in.uris" title="Sensitive Information in URIs">Section 9.4</a> for additional security considerations. 2242 2243 </p> 2243 2244 <p id="rfc.section.5.5.2.p.8">Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the … … 4140 4141 routing are discussed in <a href="p1-messaging.html#security.considerations" title="Security Considerations">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 4141 4142 </p> 4142 <p id="rfc.section.9.p.2">The list of considerations below is not exhaustive — security analysis in an ongoing activity. Various organizations, such 4143 as the "Open Web Application Security Project" (OWASP, <<a href="https://www.owasp.org/">https://www.owasp.org/</a>>), provide information about current research. 4143 <p id="rfc.section.9.p.2">The list of considerations below is not exhaustive. Most security concerns related to HTTP semantics are about securing server-side 4144 applications (code behind the HTTP interface), securing user agent processing of payloads received via HTTP, or secure use 4145 of the Internet in general, rather than security of the protocol. Various organizations maintain topical information and links 4146 to current research on Web application security (e.g., <a href="#OWASP" id="rfc.xref.OWASP.1"><cite title="A Guide to Building Secure Web Applications and Web Services">[OWASP]</cite></a>). 4144 4147 </p> 4145 4148 <div id="attack.pathname"> … … 4160 4163 </p> 4161 4164 </div> 4165 <div id="attack.injection"> 4166 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a href="#attack.injection">Attacks Based On Command, Code, or Query Injection</a></h2> 4167 <p id="rfc.section.9.2.p.1">Origin servers often use parameters within an effective request URI as a means of identifying system services, selecting database 4168 entries, or choosing a data source. However, data received in a request cannot be trusted. An attacker could construct any 4169 of the request data elements (method, request-target, header fields, or body) to contain data that might be misinterpreted 4170 as a command, code, or query when passed through a command invocation, language interpreter, or database interface. 4171 </p> 4172 <p id="rfc.section.9.2.p.2">For example, SQL injection is a common attack wherein additional query language is inserted within a part of the URI. If that 4173 same part is directly used by the resource implementation within a SELECT statement, the query language will be interpreted 4174 as a database command instead of a simple string value. This type of implementation vulnerability is extremely common, in 4175 spite of being easy to prevent. 4176 </p> 4177 <p id="rfc.section.9.2.p.3">In general, resource implementations ought to avoid use of request data in contexts that are processed or interpreted as instructions. 4178 Parameters ought to be compared to fixed strings and acted upon as a result of that comparison, rather than passed through 4179 an interface that is not prepared for untrusted data. Received data that isn't based on fixed parameters ought to be carefully 4180 filtered or encoded to avoid being misinterpreted. 4181 </p> 4182 <p id="rfc.section.9.2.p.4">Similar considerations apply to request data when it is stored and later processed, such as within log files, monitoring tools, 4183 or when included within a data format that allows embedded scripts. 4184 </p> 4185 </div> 4162 4186 <div id="personal.information"> 4163 <h2 id="rfc.section.9. 2"><a href="#rfc.section.9.2">9.2</a> <a href="#personal.information">Personal Information</a></h2>4164 <p id="rfc.section.9. 2.p.1">Clients are often privy to large amounts of personal information, including both information provided by the user to interact4187 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a href="#personal.information">Personal Information</a></h2> 4188 <p id="rfc.section.9.3.p.1">Clients are often privy to large amounts of personal information, including both information provided by the user to interact 4165 4189 with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information about the 4166 user's browsing activity over time (e.g., history, bookmarks, etc.). Implementations need to prevent unintentional leakage4190 user's browsing activity over time (e.g., history, bookmarks, etc.). Implementations need to prevent unintentional disclosure 4167 4191 of personal information. 4168 4192 </p> 4169 4193 </div> 4170 4194 <div id="sensitive.information.in.uris"> 4171 <h2 id="rfc.section.9. 3"><a href="#rfc.section.9.3">9.3</a> <a href="#sensitive.information.in.uris">Sensitive Information in URIs</a></h2>4172 <p id="rfc.section.9. 3.p.1">URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added4195 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a href="#sensitive.information.in.uris">Sensitive Information in URIs</a></h2> 4196 <p id="rfc.section.9.4.p.1">URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added 4173 4197 to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include 4174 4198 information within a URI that is sensitive, personally identifiable, or a risk to disclose. 4175 4199 </p> 4176 <p id="rfc.section.9. 3.p.2">Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in4200 <p id="rfc.section.9.4.p.2">Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in 4177 4201 the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might 4178 4202 be visible to third parties. Such services ought to use POST-based form submission instead. 4179 4203 </p> 4180 <p id="rfc.section.9. 3.p.3">Since the <a href="#header.referer" class="smpl">Referer</a> header field tells a target site about the context that resulted in a request, it has the potential to reveal information4204 <p id="rfc.section.9.4.p.3">Since the <a href="#header.referer" class="smpl">Referer</a> header field tells a target site about the context that resulted in a request, it has the potential to reveal information 4181 4205 about the user's immediate browsing history and any personal information that might be found in the referring resource's URI. 4182 4206 Limitations on Referer are described in <a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 5.5.2</a> to address some of its security considerations. … … 4184 4208 </div> 4185 4209 <div id="sensitive.information.in.product"> 4186 <h2 id="rfc.section.9. 4"><a href="#rfc.section.9.4">9.4</a> <a href="#sensitive.information.in.product">Product Information</a></h2>4187 <p id="rfc.section.9. 4.p.1">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 5.5.3</a>), <a href="p1-messaging.html#header.via" class="smpl">Via</a> (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), and <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.4.2</a>) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier4210 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a href="#sensitive.information.in.product">Product Information</a></h2> 4211 <p id="rfc.section.9.5.p.1">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 5.5.3</a>), <a href="p1-messaging.html#header.via" class="smpl">Via</a> (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), and <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.4.2</a>) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier 4188 4212 for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the 4189 4213 apparent software versions being used. 4190 4214 </p> 4191 <p id="rfc.section.9. 4.p.2">Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header4215 <p id="rfc.section.9.5.p.2">Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header 4192 4216 information that might identify hosts behind the firewall. The <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field allows intermediaries to replace sensitive machine names with pseudonyms. 4193 4217 </p> 4194 4218 </div> 4195 4219 <div id="fragment.leakage"> 4196 <h2 id="rfc.section.9. 5"><a href="#rfc.section.9.5">9.5</a> <a href="#fragment.leakage">Fragment after Redirects</a></h2>4197 <p id="rfc.section.9. 5.p.1">Although fragment identifiers used within URI references are not sent in requests, implementers ought to be aware that they4220 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a href="#fragment.leakage">Fragment after Redirects</a></h2> 4221 <p id="rfc.section.9.6.p.1">Although fragment identifiers used within URI references are not sent in requests, implementers ought to be aware that they 4198 4222 will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a 4199 4223 redirect occurs and the original request's fragment identifier is inherited by the new reference in <a href="#header.location" class="smpl">Location</a> (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 7.1.2</a>), this might have the effect of leaking one site's fragment to another site. If the first site uses personal information … … 4203 4227 </div> 4204 4228 <div id="fingerprinting"> 4205 <h2 id="rfc.section.9. 6"><a href="#rfc.section.9.6">9.6</a> <a href="#fingerprinting">Browser Fingerprinting</a></h2>4206 <p id="rfc.section.9. 6.p.1">Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics.4229 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a href="#fingerprinting">Browser Fingerprinting</a></h2> 4230 <p id="rfc.section.9.7.p.1">Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics. 4207 4231 These characteristics might include information related to its TCP behavior, feature capabilities, and scripting environment, 4208 4232 though of particular interest here is the set of unique characteristics that might be communicated via HTTP. Fingerprinting … … 4211 4235 Web browsers) have taken steps to reduce their fingerprints. 4212 4236 </p> 4213 <p id="rfc.section.9. 6.p.2">There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable4237 <p id="rfc.section.9.7.p.2">There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable 4214 4238 fingerprinting. The <a href="#header.from" class="smpl">From</a> header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by 4215 4239 the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so fingerprinting concerns 4216 4240 only apply to situations where cookies are disabled or restricted by the user agent's configuration. 4217 4241 </p> 4218 <p id="rfc.section.9. 6.p.3">The <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics,4242 <p id="rfc.section.9.7.p.3">The <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, 4219 4243 particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique 4220 4244 information that is least expected by users is <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> (<a href="#request.conneg" title="Content Negotiation">Section 5.3</a>), including the <a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-charset" class="smpl">Accept-Charset</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, and <a href="#header.accept-language" class="smpl">Accept-Language</a> header fields. 4221 4245 </p> 4222 <p id="rfc.section.9. 6.p.4">In addition to the fingerprinting concern, detailed use of the <a href="#header.accept-language" class="smpl">Accept-Language</a> header field can reveal information the user might consider to be of a private nature, because the understanding of particular4246 <p id="rfc.section.9.7.p.4">In addition to the fingerprinting concern, detailed use of the <a href="#header.accept-language" class="smpl">Accept-Language</a> header field can reveal information the user might consider to be of a private nature, because the understanding of particular 4223 4247 languages is often strongly correlated to membership in a particular ethnic group. An approach that limits such loss of privacy 4224 4248 would be for a user agent to omit the sending of Accept-Language except for sites that have been whitelisted, perhaps via 4225 4249 interaction after detecting a <a href="#header.vary" class="smpl">Vary</a> header field that would indicate language negotiation might be useful. 4226 4250 </p> 4227 <p id="rfc.section.9. 6.p.5">In environments where proxies are used to enhance privacy, user agents ought to be conservative in sending proactive negotiation4251 <p id="rfc.section.9.7.p.5">In environments where proxies are used to enhance privacy, user agents ought to be conservative in sending proactive negotiation 4228 4252 header fields. General-purpose user agents that provide a high degree of header field configurability ought to inform users 4229 4253 about the loss of privacy that might result if too much detail is provided. As an extreme privacy measure, proxies could filter … … 4324 4348 <td class="reference"><b id="BCP90">[BCP90]</b></td> 4325 4349 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 4350 </td> 4351 </tr> 4352 <tr> 4353 <td class="reference"><b id="OWASP">[OWASP]</b></td> 4354 <td class="top">“<a href="https://www.owasp.org/">A Guide to Building Secure Web Applications and Web Services</a>”, The Open Web Application Security Project (OWASP) 2.0.1, July 2005, <<a href="https://www.owasp.org/">https://www.owasp.org/</a>>. 4326 4355 </td> 4327 4356 </tr> … … 4948 4977 </li> 4949 4978 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 4950 <li>Location header field <a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">9. 5</a>, <a href="#rfc.xref.header.location.6">B</a></li>4979 <li>Location header field <a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">9.6</a>, <a href="#rfc.xref.header.location.6">B</a></li> 4951 4980 </ul> 4952 4981 </li> … … 4958 4987 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 4959 4988 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1.2</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.11">B</a>, <a href="#rfc.xref.OPTIONS.4">B</a>, <a href="#rfc.extref.o.12">B</a></li> 4989 <li><em>OWASP</em> <a href="#rfc.xref.OWASP.1">9</a>, <a href="#OWASP"><b>11.2</b></a></li> 4960 4990 </ul> 4961 4991 </li> 4962 4992 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 4963 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.1.1</a>, <a href="#rfc.xref.Part1.22">5.5.3</a>, <a href="#rfc.xref.Part1.23">6.2.2</a>, <a href="#rfc.xref.Part1.24">6.3.4</a>, <a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.26">6.5.10</a>, <a href="#rfc.xref.Part1.27">6.5.12</a>, <a href="#rfc.xref.Part1.28">6.5.15</a>, <a href="#rfc.xref.Part1.29">6.6.6</a>, <a href="#rfc.xref.Part1.30">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.1.2</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.38">8.3.1</a>, <a href="#rfc.xref.Part1.39">8.4</a>, <a href="#rfc.xref.Part1.40">8.4.1</a>, <a href="#rfc.xref.Part1.41">8.4.1</a>, <a href="#rfc.xref.Part1.42">9</a>, <a href="#rfc.xref.Part1.43">9. 4</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">B</a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">D</a><ul>4993 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.1.1</a>, <a href="#rfc.xref.Part1.22">5.5.3</a>, <a href="#rfc.xref.Part1.23">6.2.2</a>, <a href="#rfc.xref.Part1.24">6.3.4</a>, <a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.26">6.5.10</a>, <a href="#rfc.xref.Part1.27">6.5.12</a>, <a href="#rfc.xref.Part1.28">6.5.15</a>, <a href="#rfc.xref.Part1.29">6.6.6</a>, <a href="#rfc.xref.Part1.30">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.1.2</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.38">8.3.1</a>, <a href="#rfc.xref.Part1.39">8.4</a>, <a href="#rfc.xref.Part1.40">8.4.1</a>, <a href="#rfc.xref.Part1.41">8.4.1</a>, <a href="#rfc.xref.Part1.42">9</a>, <a href="#rfc.xref.Part1.43">9.5</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">B</a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">D</a><ul> 4964 4994 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.57">D</a></li> 4965 4995 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> … … 4983 5013 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">5.1</a></li> 4984 5014 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a></li> 4985 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.43">9. 4</a></li>5015 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.43">9.5</a></li> 4986 5016 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.24">6.3.4</a></li> 4987 5017 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.37">8.3.1</a></li> … … 5047 5077 </li> 5048 5078 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 5049 <li>Referer header field <a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9. 3</a>, <a href="#rfc.xref.header.referer.4">B</a></li>5079 <li>Referer header field <a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9.4</a>, <a href="#rfc.xref.header.referer.4">B</a></li> 5050 5080 <li>representation <a href="#rfc.iref.r.1"><b>3</b></a></li> 5051 5081 <li><em>REST</em> <a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>11.2</b></a></li> … … 5129 5159 <li>safe <a href="#rfc.iref.s.2"><b>4.2.1</b></a></li> 5130 5160 <li>selected representation <a href="#rfc.iref.s.1"><b>3</b></a>, <a href="#rfc.iref.s.8">7.2</a></li> 5131 <li>Server header field <a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.9"><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. 4</a></li>5161 <li>Server header field <a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.9"><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.5</a></li> 5132 5162 <li>Status Codes Classes 5133 5163 <ul> … … 5147 5177 </li> 5148 5178 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 5149 <li>User-Agent header field <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. 4</a></li>5179 <li>User-Agent header field <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.5</a></li> 5150 5180 </ul> 5151 5181 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2563 r2565 4921 4921 </t> 4922 4922 <t> 4923 The list of considerations below is not exhaustive — security 4924 analysis in an ongoing activity. Various organizations, such as the 4925 "Open Web Application Security Project" (OWASP, 4926 <eref target="https://www.owasp.org/"/>), provide information about current 4927 research. 4923 The list of considerations below is not exhaustive. Most security concerns 4924 related to HTTP semantics are about securing server-side applications (code 4925 behind the HTTP interface), securing user agent processing of payloads 4926 received via HTTP, or secure use of the Internet in general, rather than 4927 security of the protocol. Various organizations maintain topical 4928 information and links to current research on Web application security 4929 (e.g., <xref target="OWASP"/>). 4928 4930 </t> 4929 4931 … … 4954 4956 </section> 4955 4957 4958 <section title="Attacks Based On Command, Code, or Query Injection" anchor="attack.injection"> 4959 <t> 4960 Origin servers often use parameters within an effective request URI as a 4961 means of identifying system services, selecting database entries, or 4962 choosing a data source. However, data received in a request cannot be 4963 trusted. An attacker could construct any of the request data elements 4964 (method, request-target, header fields, or body) to contain data that might 4965 be misinterpreted as a command, code, or query when passed through a 4966 command invocation, language interpreter, or database interface. 4967 </t> 4968 <t> 4969 For example, SQL injection is a common attack wherein additional query 4970 language is inserted within a part of the URI. If that same part is 4971 directly used by the resource implementation within a SELECT statement, the 4972 query language will be interpreted as a database command instead of a 4973 simple string value. This type of implementation vulnerability is extremely 4974 common, in spite of being easy to prevent. 4975 </t> 4976 <t> 4977 In general, resource implementations ought to avoid use of request data 4978 in contexts that are processed or interpreted as instructions. Parameters 4979 ought to be compared to fixed strings and acted upon as a result of that 4980 comparison, rather than passed through an interface that is not prepared 4981 for untrusted data. Received data that isn't based on fixed parameters 4982 ought to be carefully filtered or encoded to avoid being misinterpreted. 4983 </t> 4984 <t> 4985 Similar considerations apply to request data when it is stored and later 4986 processed, such as within log files, monitoring tools, or when included 4987 within a data format that allows embedded scripts. 4988 </t> 4989 </section> 4990 4956 4991 <section title="Personal Information" anchor="personal.information"> 4957 4992 <t> … … 4961 4996 keys, etc.) and information about the user's browsing activity over 4962 4997 time (e.g., history, bookmarks, etc.). Implementations need to 4963 prevent unintentional leakage of personal information.4998 prevent unintentional disclosure of personal information. 4964 4999 </t> 4965 5000 </section> … … 5761 5796 </reference> 5762 5797 5798 <reference anchor="OWASP" target="https://www.owasp.org/"> 5799 <front> 5800 <title abbrev="OWASP">A Guide to Building Secure Web Applications and Web Services</title> 5801 <author fullname="Mark Curphey, et al."/> 5802 <date month="July" day="27" year="2005"/> 5803 </front> 5804 <seriesInfo name="The Open Web Application Security Project (OWASP)" value="2.0.1"/> 5805 </reference> 5763 5806 </references> 5764 5807
Note: See TracChangeset
for help on using the changeset viewer.