Re: [CORS] Review of CORS and WebAppSec prior to LCWD

thanks for the attention and reposting to public-webappsec.

i agree the relevant scope is this list but as this review\comments
was prompted by explicitly trying to keep within process milestones of
CORS i thought to keep the response to the list where notification was
sent. glad it has found the right audience.

thanks,
Cameron Jones

On Wed, Mar 7, 2012 at 1:39 PM, Arthur Barstow <art.barstow@nokia.com> wrote:
> [ + 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 14:32:22 UTC