Re: [cors] JAX-RS and preflight

On Thu, Dec 1, 2011 at 4:14 PM, Benson Margulies <bimargulies@gmail.com> wrote:
> On Thu, Dec 1, 2011 at 6:53 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Thu, Dec 1, 2011 at 12:20 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>>> There's a problem with REST-ful services, as exemplified by the JAX-RS
>>> standard, and CORS as drafted.
>>>
>>> A JAX-RS server names a resource, in part, via the content-type of a
>>> request. A POST with content-type of application/json names a
>>> different resource (in as much as it selects a different method to
>>> call) that a POST with content-type text/plain.
>>>
>>> The problem here is that a preflight OPTIONS is defined to *not* pass
>>> the content type unless it is simple. Thus, the service implementation
>>> can't reliably tell what resource is under discussion.
>>>
>>> As things are, a service would have to take a common posture for all
>>> preflights given the URL and Accept(-*) headers, and ignoring the
>>> content type.
>>>
>>> Would you consider defining an Ac-Request-Content-Type header to pass
>>> a non-simple content type on a preflight?
>>
>> You can always allow the OPTIONS request and make the security
>> decision once you get the actual request.
>
> Sure, if the server is the concerned party .... but ....
>
>>
>> The main point of the OPTIONS request is to protect servers that
>> aren't aware of CORS at all. Clearly a CORS+JAX-RS doesn't fall into
>> this category.
>
> As a superannuated security person, I thought that the point of CORS
> was to protect clients from cross-scripting pranks of web pages, not
> to protect servers from anything. Nothing in CORS involves returning a
> 401. Wouldn't the actual access decision be made on the server instead
> of on the client if we were protecting the server? Why return all this
> stuff to the client instead of failing requests or censoring headers?
>
> Something tells me that there's a theory here that I haven't read yet.

CORS isn't intended to fix "cross-scripting pranks" at all. At least
if you are referring to the traditional meaning of XSS attacks.

The intent of CORS is to allow websites to communicate with other
servers without exposing existing web servers to new attack vectors.
Specifically to CSRF-like attacks.

So CORS is very much designed to "protect" (or rather "not harm")
servers. Not to do anything related to XSS.

However, in allowing websites to talk to other servers in a safe
manner, it removes the need to use <script> elements to do so. This
use of <script> elements has traditionally opened up websites to XSS
attack vectors. So while CORS isn't designed to protect against XSS
attacks, it does obsolete XSS sensitive technology.

I hope that makes sense?

/ Jonas

Received on Friday, 2 December 2011 00:25:04 UTC