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