Re: #549: augmented security considerations in p1

My only comment is that here and in 2.7.2 we are referencing RFC 2818, but that reference is informative.

Shouldn't we be normatively referencing RFC 2818 since we are only updating it and not obsoleting it?


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

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair