- From: Cameron Jones <cmhjones@gmail.com>
- Date: Wed, 7 Mar 2012 14:31:41 +0000
- To: Arthur Barstow <art.barstow@nokia.com>
- Cc: ext Adam Barth <w3c@adambarth.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, public-webapps@w3c.org
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