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 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 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 th
[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 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, t
Re: Review of CORS and WebAppSec prior to LCWD
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 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
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
