W3C home > Mailing lists > Public > public-web-security@w3.org > February 2013

RE: CORS question

From: Hill, Brad <bhill@paypal-inc.com>
Date: Sun, 10 Feb 2013 21:20:13 +0000
To: John Wilander <john.wilander@owasp.org>
CC: Brandon Sterne <brandon@hackmill.com>, "public-web-security@w3.org" <public-web-security@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27914AB7@DEN-EXDDA-S12.corp.ebay.com>
John,

It may well be easier to write client-side code to orchestrate a complex CSRF attack, but preventing that was not the goal.  The goal was that existing servers/resources would not be exposed to new types of credentialed cross-origin requests that could not already be made by legacy user agents.  Resources are vulnerable to CSRF or they are not, and we don’t want CORS to make things that are not vulnerable today suddenly so, attacker effort not considered.

-Brad

From: John Wilander [mailto:john.wilander@owasp.org]
Sent: Tuesday, February 05, 2013 10:52 PM
To: Hill, Brad
Cc: Brandon Sterne; public-web-security@w3.org
Subject: Re: CORS question

I would argue that CSRF has become more convenient with CORS. The attacker previously had to open invisible iframes with tailored forms for each HTTP POST he/she wanted to send. Now the attacker can just parameterize and send it via Ajax.


Do you agree? Or am I missing a more convenient CSRF POST method for legacy browsers?


   Regards, John

--
My music http://www.johnwilander.com

Twitter https://twitter.com/johnwilander

CV or Résumé http://johnwilander.se


5 feb 2013 kl. 23:37 skrev "Hill, Brad" <bhill@paypal-inc.com<mailto:bhill@paypal-inc.com>>:
Brandon,

The requirement is that CORS does not introduce any new Cross-Site Request Forgery attack capabilities not present in legacy user agents.  Therefore, all requests that cannot be generated by pre-CORS user agents through methods like GET, POST and HEAD that are available through legacy HTML+JS must be anonymous or pre-authorized.

The user agent should not send requests with credentials on non-simple HTTP methods unless and until the server indicates it is prepared to accept such by responding to the pre-flight request.

Does this answer your question?

-Brad

From: brandon.sterne@gmail.com<mailto:brandon.sterne@gmail.com> [mailto:brandon.sterne@gmail.com] On Behalf Of Brandon Sterne
Sent: Tuesday, February 05, 2013 1:38 PM
To: public-web-security@w3.org<mailto:public-web-security@w3.org>
Subject: CORS question

Hey guys,

Co-workers of mine were trying to understand the treat model of CORS, and I was having trouble articulating some of the particular risks that the spec attempts to avoid.  Why does the OPTIONS pre-flight request never carry credentials?
Thanks,
Brandon
Received on Sunday, 10 February 2013 21:20:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 10 February 2013 21:20:43 GMT