[CORS] Review of CORS and WebAppSec prior to LCWD

[ + public-webappsec ]

Below is a comment about CORS.

Given the original CfC for LCWD was started months ago, perhaps this 
comment should be considered as an LC comment.

Re whether to use p-webapps or p-webappsec, I don't recall any agreement 
on that question. I do note the latest ED says to use webappsec but the 
latest version in /TR/ says to use webapps. Since WebAppSec has taken 
the lead on this spec and the ED now uses webappsec, that list does seem 
like the better choice.

-AB

On 3/6/12 1:48 PM, ext Adam Barth wrote:
> 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 Wednesday, 7 March 2012 13:40:31 UTC