Re: #549: augmented security considerations in p1

Generally this looks good; a few comments inline. [editorial] comments should be treated just as that; no on-list response necessary.


On 31 Jan 2014, at 4:25 pm, Roy T. Fielding <fielding@gbiv.com> wrote:

> 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.

[editorial] What does this sentence add?

> 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

[editorial] add — "for "http” URIs"

>   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]).

Given the state of the world, this seems like a huge assumption — can we at least acknowledge that here be dragons as well?

> 
> 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.
> 
> =========
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Saturday, 1 February 2014 04:36:49 UTC