Re: Review of CORS and WebAppSec prior to LCWD

This feedback is probably better addressed to public-webappsec, which
is the main forum for discussing these security-related specs.

Adam


On Tue, Mar 6, 2012 at 6:06 AM, Cameron Jones <cmhjones@gmail.com> wrote:
> Hello wg,
>
> I've been contemplating various aspects of web app security in review
> of CORS, UMP, CSP and resource protection and would like to bring some
> feedback to the group as a set of concerns over the combined proposed
> solution.
>
> While the pre-cfc calls for positive response i can only provide the
> review in the light that it is seen. I hereby highlight concerns, of
> which some have been previously raised, and some which have lead to
> further specification resulting in a combined solution which, i
> believe, has scope for conglomeration into a more concise set of
> recommendations for implementation.
>
> This review and feedback is predominantly related to CORS as a
> solution for resource sharing. To step back from this initially and
> scope the problem which it proposes to address, this specification is
> a solution to expanding XHR access control across origins due to the
> implied requirement that resources must be proactively protected from
> CSRF in combination with the exposure to 'ambient authority'.
>
> This premise requires examination due to its becoming existence
> through proprietary development and release further to wider
> acceptance and adoption over a number of years. To look at the history
> of XHR in this regard, the requirements for its mode of operation have
> been driven by proprietary specification and while there are no
> concerns over independent development and product offering, the
> expansion toward global recommendation and deployment garners greater
> scope and requirements for global integration within a more permanent
> and incumbent environment.
>
> The principal concerns over XHR, and which are in part being addressed
> within UMP, are in relation to the incurred requirement of CORS due to
> the imposed security policy. This security policy is in response to
> the otherwise unspecified functional requirement of 'ambient
> authority' within HTTP agents. Cookies and HTTP authentication, which
> comprise the 'authority', are shared within a single HTTP agent which
> supports multiple HTTP communication interaction through distinct user
> interface. This multi-faceted interface represents the 'ambient'
> environment. The question this raises with regards to the premise of
> XHR and CSRF protection is therefore; why does the HTTP agent
> introduce the problem of 'ambient authority' which must subsequently
> be solved?
>
> To examine this further we can look at the consequent definition of
> the 'origin' with respect to HTTP requests. This definition is
> introduced to resolve the problem that HTTP 'authority' was only
> intending to be granted to requests originating from same-origin
> sources. This extension to subsequent requests may be withdrawn back
> to the originating request and reframed by examining - why is HTTP
> 'authority' shared between cross-origin browsing contexts?
>
> To highlight this with a specific example, a user initiates a new
> browsing session with http://www.example.com whereby cookies are set
> and the user logs in using HTTP authentication. In a separate
> workflow, the user instructs the UA to open a new UI and initiate a
> new browsing session with http://www.test.com which happens to include
> resources (images, scripts etc) from the www.example.com domain. Where
> in these two separate user tasks has either the server of
> www.example.com, or the user, or even www.test.com, declared that they
> want to intertleave - or share - the independent browsing contexts
> consisting of HTTP authority? This is primary leak of security and
> privacy which is the root of all further breaches and vulnerabilities.
>
> When 'ambient authority' is removed from the definition of
> cross-origin requests, as in UMP, the potential for CSRF is
> eliminated, with the exception of public web services which are
> postulated to be at risk due to an assumption that the public web
> service was intended only for same-origin operation. This further
> premise is flawed due to its incompatibility with the architecture of
> the WWW and HTTP as a globally deployed and publicly accessible
> system.
>
> To summarize this review as a recommendation, it is viewed that the
> problem of CRSF is better addressed through the restriction of imposed
> sharing of 'ambient authority' which amounts to a breach of trust
> between the server and UA and the UA and the user.
>
> Further to this, the specification of cross-origin resource sharing
> should be targeted at the cross-origin site expressing the request for
> exposure to 'ambient authority' instead of the host site requiring to
> specify that it will accept cross-origin requests.
>
> I would further like to express grievous concern over some of the
> specific premise and implementation of CORS as it currently stands.
> The notion of 'pre-flight-requests' is too onerous on server
> implementations. It is unacceptable that well designed HTTP services
> must be encumbered with the overhead and latency of
> 'pre-flight-requests' when their intention is to provide publicly
> accessible resources regardless of origin and especially in the
> absence of authentication. The specification of HTTP does not
> discriminate based on origin and servers conforming to this
> specification should not be penalized for providing public services.
>
> This leads on to a principal point which is to be highlighted here -
> it must be to the onus and cost of the resource owner to protect and
> pay for the cost of protection of their services and assets. It is
> unacceptable for public services to pay the costs of 3rd party
> securities.
>
> This is directly related to one of the primary requirements of CORS -
> that unprotected or ip-protected intranet infrastructure (only
> protected by firewall) should be protected from attack vectors. As
> previously stated, it is unacceptable for the costs of private
> security to be imposed on public services. There are other means for
> internal resources to be protected and this should not be a
> requirement for the specification of public resource sharing. Of
> specific note, intranets use the set of restricted ip address ranges
> which frames their environment, and the means to protect them.
>
> I hope this review and feedback will be appreciated and considered
> with further advancement of web app security.
>
> Thanks,
> Cameron Jones
>

Received on Tuesday, 6 March 2012 18:49:37 UTC