#549: augmented security considerations in p1

I have proposed the following text as new security considerations
sections for p1 in response to several IESG comments.  Please review.

A diff can be found at

  http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2609#file1

which includes the additional references (to and from these sections).

....Roy

=========

9.1.  Establishing Authority

   HTTP relies on the notion of an authoritative response: a response
   that has been determined by (or at the direction of) the authority
   identified within the target URI to be the most appropriate response
   for that request given the state of the target resource at the time
   of response message origination.  That is the essence of what a user
   is looking for when they make any HTTP request, especially when it is
   a request to an authority trusted by that user to provide a specific
   service.  Providing a response from a non-authoritative source, such
   as a shared cache, is often useful to improve performance and
   availability, but only to the extent that the source can be trusted
   or that a distrusted response can be safely used.

   Unfortunately, establishing authority can be difficult.  For example,
   phishing is an attack on the user's perception of authority, where
   that perception can be misled by presenting similar branding in
   hypertext, possibly aided by userinfo obfuscating the authority
   component (see Section 2.7.1).  User agents can reduce the impact of
   phishing attacks by enabling users to easily inspect a target URI
   prior to making an action, by prominently distinguishing (or
   rejecting) userinfo when present, and by not sending stored
   credentials and cookies when the referring document is from an
   unknown or untrusted source.

   When a registered name is used in the authority component, the "http"
   URI scheme (Section 2.7.1) relies on the user's local name resolution
   service to determine where it can find authoritative responses.  This
   means that any attack on a user's network host table, cached names,
   or name resolution libraries becomes an avenue for attack on
   establishing authority.  Likewise, the user's choice of server for
   Domain Name Service (DNS), and the hierarchy of servers from which it
   obtains resolution results, could impact the authenticity of address
   mappings; DNSSEC ([RFC4033]) is one way to improve authenticity.

   Furthermore, after an IP address is obtained, establishing authority
   is vulnerable to attacks on Internet Protocol routing.

   The "https" scheme (Section 2.7.2) is intended to prevent (or at
   least reveal) many of these potential attacks on establishing
   authority, assuming the negotiated TLS connection is secured in a way
   that verifies the communicating server's identity matches the target
   URI's authority component (see [RFC2818] and [Georgiev]).

9.2.  Risks of Intermediaries

   By their very nature, HTTP intermediaries are men-in-the-middle, and
   thus represent an opportunity for man-in-the-middle attacks.
   Compromise of the systems on which the intermediaries run can result
   in serious security and privacy problems.  Intermediaries might have
   access to security-related information, personal information about
   individual users and organizations, and proprietary information
   belonging to users and content providers.  A compromised
   intermediary, or an intermediary implemented or configured without
   regard to security and privacy considerations, might be used in the
   commission of a wide range of potential attacks.

   Intermediaries that contain a shared cache are especially vulnerable
   to cache poisoning attacks, as described in Section 8 of [Part6].

   Implementers need to consider the privacy and security implications
   of their design and coding decisions, and of the configuration
   options they provide to operators (especially the default
   configuration).

   Users need to be aware that intermediaries are no more trustworthy
   than the people who run them; HTTP itself cannot solve this problem.

9.3.  Attacks via Protocol Element Length

   Because HTTP uses mostly textual, character-delimited fields, parsers
   are often vulnerable to attacks based on sending very long (or very
   slow) streams of data, particularly where an implementation is
   expecting a protocol element with no predefined length.

   To promote interoperability, specific recommendations are made for
   minimum size limits on request-line (Section 3.1.1) and header fields
   (Section 3.2).  These are minimum recommendations, chosen to be
   supportable even by implementations with limited resources; it is
   expected that most implementations will choose substantially higher
   limits.

   A server can reject messages that have request-targets that are too
   long (Section 6.5.12 of [Part2]) or request entities that are too
   large (Section 6.5 of [Part2]).  Additional status codes related to
   capacity limits have been defined by extensions to HTTP [RFC6585].

   Recipients ought to carefully limit the extent to which they process
   other protocol elements, including (but not limited to) request
   methods, response status phrases, header field-names, numeric values,
   and body chunks.  Failure to limit such processing can result in
   buffer overflows, arithmetic overflows, or increased vulnerability to
   denial of service attacks.

9.4.  Response Splitting

   Response splitting (a.k.a, CRLF injection) is a common technique,
   used in various attacks on Web usage, that exploits the line-based
   nature of HTTP message framing and the ordered association of
   requests to responses on persistent connections [Klein].  This
   technique can be particularly damaging when the requests pass through
   a shared cache.

   Response splitting exploits a vulnerability in servers (usually
   within an application server) where an attacker can send encoded data
   within some parameter of the request that is later decoded and echoed
   within any of the response header fields of the response.  If the
   decoded data is crafted to look like the response has ended and a
   subsequent response has begun, the response has been split and the
   content within the apparent second response is controlled by the
   attacker.  The attacker can then make any other request on the same
   persistent connection and trick the recipients (including
   intermediaries) into believing that the second half of the split is
   an authoritative answer to the second request.

   For example, a parameter within the request-target might be read by
   an application server and reused within a redirect, resulting in the
   same parameter being echoed in the Location header field of the
   response.  If the parameter is decoded by the application and not
   properly encoded when placed in the response field, the attacker can
   send encoded CRLF octets and other content that will make the
   application's single response look like two or more responses.

   A common defense against response splitting is to filter requests for
   data that looks like encoded CR and LF (e.g., "%0D" and "%0A").
   However, that assumes the application server is only performing URI
   decoding, rather than more obscure data transformations like charset
   transcoding, XML entity translation, base64 decoding, sprintf
   reformatting, etc.  A more effective mitigation is to prevent
   anything other than the server's core protocol libraries from sending
   a CR or LF within the header section, which means restricting the
   output of header fields to APIs that filter for bad octets and not
   allowing application servers to write directly to the protocol
   stream.

9.5.  Request Smuggling

   Request smuggling ([Linhart]) is a technique that exploits
   differences in protocol parsing among various recipients to hide
   additional requests (which might otherwise be blocked or disabled by
   policy) within an apparently harmless request.  Like response
   splitting, request smuggling can lead to a variety of attacks on HTTP
   usage.

   This specification has introduced new requirements on request
   parsing, particularly with regard to message framing in
   Section 3.3.3, to reduce the effectiveness of request smuggling.

[...]

9.7.  Message Confidentiality

   HTTP relies on underlying transport protocols to provide message
   confidentiality when that is desired.  HTTP has been specifically
   designed to be independent of the transport protocol, such that it
   can be used over many different forms of encrypted connection, with
   the selection of such transports being identified by the choice of
   URI scheme or within user agent configuration.

   The "https" scheme can be used to identify resources that require a
   confidential connection, as described in Section 2.7.2.

=========

Received on Friday, 31 January 2014 05:25:31 UTC