Ignore:
Timestamp:
23/01/14 08:51:09 (6 years ago)
Author:
fielding@…
Message:

(editorial) Use more specific headers in security section for clarity and put related sections next to each other; see #520 and #549

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2566 r2567  
    49584958<section title="Attacks Based On Command, Code, or Query Injection" anchor="attack.injection">
    49594959<t>
    4960    Origin servers often use parameters within an effective request URI as a
     4960   Origin servers often use parameters within the URI as a
    49614961   means of identifying system services, selecting database entries, or
    49624962   choosing a data source. However, data received in a request cannot be
     
    49684968<t>
    49694969   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
    49734974   simple string value. This type of implementation vulnerability is extremely
    49744975   common, in spite of being easy to prevent.
     
    49894990</section>
    49904991
    4991 <section title="Personal Information" anchor="personal.information">
     4992<section title="Disclosure of Personal Information" anchor="personal.information">
    49924993<t>
    49934994   Clients are often privy to large amounts of personal information,
     
    50005001</section>
    50015002
    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">
    50035004<t>
    50045005   URIs are intended to be shared, not secured, even when they identify secure
     
    50255026</section>
    50265027
    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">
    50285044<t>
    50295045   The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>),
     
    50405056   identify hosts behind the firewall. The <x:ref>Via</x:ref> header field
    50415057   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 sent
    5048    in requests, implementers ought to be aware that they will be visible to
    5049    the user agent and any extensions or scripts running as a result of the
    5050    response. In particular, when a redirect occurs and the original request's
    5051    fragment identifier is inherited by the new reference in
    5052    <x:ref>Location</x:ref> (<xref target="header.location"/>), this might
    5053    have the effect of leaking one site's fragment to another site.
    5054    If the first site uses personal information in fragments, it ought to
    5055    ensure that redirects to other sites include a (possibly empty) fragment
    5056    component in order to block that inheritance.
    50575058</t>
    50585059</section>
     
    51435144    <x:defines>Connection</x:defines>
    51445145    <x:defines>Content-Length</x:defines>
     5146    <x:defines>Host</x:defines>
    51455147    <x:defines>Transfer-Encoding</x:defines>
    51465148    <x:defines>Upgrade</x:defines>
     
    57945796        <front>
    57955797    <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"/>
    57975800    <date month="July" day="27" year="2005"/>
    57985801  </front>
Note: See TracChangeset for help on using the changeset viewer.