Changeset 2567
- Timestamp:
- 23/01/14 08:51:09 (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2566 r2567 448 448 } 449 449 @bottom-center { 450 content: "Expires July 2 6, 2014";450 content: "Expires July 27, 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-2 2">495 <meta name="dct.issued" scheme="ISO8601" content="2014-01-23"> 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 2 2, 2014</td>523 <td class="right">January 23, 2014</td> 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: July 2 6, 2014</td>526 <td class="left">Expires: July 27, 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 6, 2014.</p>555 <p>This Internet-Draft will expire on July 27, 2014.</p> 556 556 </div> 557 557 <div id="rfc.copyrightnotice"> … … 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 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>767 <li><a href="#rfc.section.9.3">9.3</a> <a href="#personal.information">Disclosure of Personal Information</a></li> 768 <li><a href="#rfc.section.9.4">9.4</a> <a href="#sensitive.information.in.uris">Disclosure of Sensitive Information in URIs</a></li> 769 <li><a href="#rfc.section.9.5">9.5</a> <a href="#fragment.disclosure">Disclosure of Fragment after Redirects</a></li> 770 <li><a href="#rfc.section.9.6">9.6</a> <a href="#disclosure.product.information">Disclosure of Product Information</a></li> 771 771 <li><a href="#rfc.section.9.7">9.7</a> <a href="#fingerprinting">Browser Fingerprinting</a></li> 772 772 </ul> … … 2240 2240 is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource 2241 2241 that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user 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 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="Disclosure of Sensitive Information in URIs">Section 9.4</a> for additional security considerations. 2243 2243 </p> 2244 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 … … 4165 4165 <div id="attack.injection"> 4166 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 database4168 entries, or choosing a data source. However, data received in a request cannot be trusted. An attacker could construct any4169 of the request data elements (method, request-target, header fields, or body) to contain data that might be misinterpreted4170 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 that4173 same part is directly used by the resource implementation within a SELECT statement, the query language will be interpreted4174 as a database command instead of a simple string value. This type of implementation vulnerability is extremely common, in4175 spite of beingeasy to prevent.4167 <p id="rfc.section.9.2.p.1">Origin servers often use parameters within the URI as a means of identifying system services, selecting database entries, 4168 or choosing a data source. However, data received in a request cannot be trusted. An attacker could construct any of the request 4169 data elements (method, request-target, header fields, or body) to contain data that might be misinterpreted as a command, 4170 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 some part of the request-target 4173 or header fields (e.g., <a href="p1-messaging.html#header.host" class="smpl">Host</a>, <a href="#header.referer" class="smpl">Referer</a>, etc.). If the received data is used directly within a SELECT statement, the query language might be interpreted as a database 4174 command instead of a simple string value. This type of implementation vulnerability is extremely common, in spite of being 4175 easy to prevent. 4176 4176 </p> 4177 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. … … 4185 4185 </div> 4186 4186 <div id="personal.information"> 4187 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a href="#personal.information"> Personal Information</a></h2>4187 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a href="#personal.information">Disclosure of Personal Information</a></h2> 4188 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 4189 4189 with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information about the … … 4193 4193 </div> 4194 4194 <div id="sensitive.information.in.uris"> 4195 <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>4195 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a href="#sensitive.information.in.uris">Disclosure of Sensitive Information in URIs</a></h2> 4196 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 4197 4197 to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include … … 4207 4207 </p> 4208 4208 </div> 4209 <div id="sensitive.information.in.product"> 4210 <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 4209 <div id="fragment.disclosure"> 4210 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a href="#fragment.disclosure">Disclosure of Fragment after Redirects</a></h2> 4211 <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 they 4212 will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a 4213 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 disclosing one site's fragment to another site. If the first site uses personal information 4214 in fragments, it ought to ensure that redirects to other sites include a (possibly empty) fragment component in order to block 4215 that inheritance. 4216 </p> 4217 </div> 4218 <div id="disclosure.product.information"> 4219 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a href="#disclosure.product.information">Disclosure of Product Information</a></h2> 4220 <p id="rfc.section.9.6.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 4212 4221 for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the 4213 4222 apparent software versions being used. 4214 4223 </p> 4215 <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 header4224 <p id="rfc.section.9.6.p.2">Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header 4216 4225 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. 4217 </p>4218 </div>4219 <div id="fragment.leakage">4220 <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 they4222 will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a4223 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 information4224 in fragments, it ought to ensure that redirects to other sites include a (possibly empty) fragment component in order to block4225 that inheritance.4226 4226 </p> 4227 4227 </div> … … 4352 4352 <tr> 4353 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>>.4354 <td class="top">van der Stock, A., Ed., “<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>>. 4355 4355 </td> 4356 4356 </tr> … … 4977 4977 </li> 4978 4978 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 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>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.5</a>, <a href="#rfc.xref.header.location.6">B</a></li> 4980 4980 </ul> 4981 4981 </li> … … 4991 4991 </li> 4992 4992 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></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>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.6</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> 4994 4994 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.57">D</a></li> 4995 4995 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> … … 5013 5013 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">5.1</a></li> 5014 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> 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>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.6</a></li> 5016 5016 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.24">6.3.4</a></li> 5017 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> … … 5159 5159 <li>safe <a href="#rfc.iref.s.2"><b>4.2.1</b></a></li> 5160 5160 <li>selected representation <a href="#rfc.iref.s.1"><b>3</b></a>, <a href="#rfc.iref.s.8">7.2</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>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.6</a></li> 5162 5162 <li>Status Codes Classes 5163 5163 <ul> … … 5177 5177 </li> 5178 5178 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 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>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.6</a></li> 5180 5180 </ul> 5181 5181 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2566 r2567 4958 4958 <section title="Attacks Based On Command, Code, or Query Injection" anchor="attack.injection"> 4959 4959 <t> 4960 Origin servers often use parameters within an effective requestURI as a4960 Origin servers often use parameters within the URI as a 4961 4961 means of identifying system services, selecting database entries, or 4962 4962 choosing a data source. However, data received in a request cannot be … … 4968 4968 <t> 4969 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 4970 language is inserted within some part of the request-target or header 4971 fields (e.g., <x:ref>Host</x:ref>, <x:ref>Referer</x:ref>, etc.). 4972 If the received data is used directly within a SELECT statement, the 4973 query language might be interpreted as a database command instead of a 4973 4974 simple string value. This type of implementation vulnerability is extremely 4974 4975 common, in spite of being easy to prevent. … … 4989 4990 </section> 4990 4991 4991 <section title=" Personal Information" anchor="personal.information">4992 <section title="Disclosure of Personal Information" anchor="personal.information"> 4992 4993 <t> 4993 4994 Clients are often privy to large amounts of personal information, … … 5000 5001 </section> 5001 5002 5002 <section title=" Sensitive Information in URIs" anchor="sensitive.information.in.uris">5003 <section title="Disclosure of Sensitive Information in URIs" anchor="sensitive.information.in.uris"> 5003 5004 <t> 5004 5005 URIs are intended to be shared, not secured, even when they identify secure … … 5025 5026 </section> 5026 5027 5027 <section title="Product Information" anchor="sensitive.information.in.product"> 5028 <section title="Disclosure of Fragment after Redirects" anchor="fragment.disclosure"> 5029 <t> 5030 Although fragment identifiers used within URI references are not sent 5031 in requests, implementers ought to be aware that they will be visible to 5032 the user agent and any extensions or scripts running as a result of the 5033 response. In particular, when a redirect occurs and the original request's 5034 fragment identifier is inherited by the new reference in 5035 <x:ref>Location</x:ref> (<xref target="header.location"/>), this might 5036 have the effect of disclosing one site's fragment to another site. 5037 If the first site uses personal information in fragments, it ought to 5038 ensure that redirects to other sites include a (possibly empty) fragment 5039 component in order to block that inheritance. 5040 </t> 5041 </section> 5042 5043 <section title="Disclosure of Product Information" anchor="disclosure.product.information"> 5028 5044 <t> 5029 5045 The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>), … … 5040 5056 identify hosts behind the firewall. The <x:ref>Via</x:ref> header field 5041 5057 allows intermediaries to replace sensitive machine names with pseudonyms. 5042 </t>5043 </section>5044 5045 <section title="Fragment after Redirects" anchor="fragment.leakage">5046 <t>5047 Although fragment identifiers used within URI references are not sent5048 in requests, implementers ought to be aware that they will be visible to5049 the user agent and any extensions or scripts running as a result of the5050 response. In particular, when a redirect occurs and the original request's5051 fragment identifier is inherited by the new reference in5052 <x:ref>Location</x:ref> (<xref target="header.location"/>), this might5053 have the effect of leaking one site's fragment to another site.5054 If the first site uses personal information in fragments, it ought to5055 ensure that redirects to other sites include a (possibly empty) fragment5056 component in order to block that inheritance.5057 5058 </t> 5058 5059 </section> … … 5143 5144 <x:defines>Connection</x:defines> 5144 5145 <x:defines>Content-Length</x:defines> 5146 <x:defines>Host</x:defines> 5145 5147 <x:defines>Transfer-Encoding</x:defines> 5146 5148 <x:defines>Upgrade</x:defines> … … 5794 5796 <front> 5795 5797 <title abbrev="OWASP">A Guide to Building Secure Web Applications and Web Services</title> 5796 <author fullname="Mark Curphey, et al."/> 5798 <author role="editor" initials="A." surname="van der Stock" 5799 fullname="Andrew van der Stock"/> 5797 5800 <date month="July" day="27" year="2005"/> 5798 5801 </front>
Note: See TracChangeset
for help on using the changeset viewer.