Review of CORS and WebAppSec prior to LCWD

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 14:07:26 UTC