Re: Improving CORS security

Yes, we do rely on it right now. We rely on a form of CSRF tokens to
protect the requests so that evil.com can't make the request; while any XSS
on the page can't affect the main origin.

My point is that the vulnerability that null allows is the same in impact
as the websites that just blindly reflect an origin. None of the proposals
for that are talking about breaking existing apps and I think we should
follow the same principle here.

-dev



On 10 May 2017 at 08:36, Mike West <mkwst@google.com> wrote:

> On Wed, May 10, 2017 at 5:27 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>
>> Hi
>>
>> That allow-credentials works with null is actually pretty useful to and
>> lets us more easily adopt CSP/Iframe sandbox. I am pretty strongly against
>> adding a  new limitation: first because backwards compatibility is
>> important and second because I think we should do more to encourage use of
>> sandbox. IMO, in terms of impact, trusting null is the same bug as
>> reflecting the origin header in Access-control-allow-origin, which is also
>> very common on the web.
>>
>
> You probably know this, but for clarity, the problem James is pointing out
> is that sandboxed frames all look the same. `https://evil.com` in a
> sandbox sends the same `Origin` header as `https://yay.com` in a sandbox.
> You might trust the latter, but not the former, but CORS gives you no
> mechanism of distinguishing between the two.
>
> Since `null` is basically `*` for sandboxed frames, applying similar
> restrictions with regard to credentials seems like it might be a reasonable
> thing to do.
>
> Is Dropbox making CORS requests from sandboxed frames that require
> credentials?
>
>
>>
>> Regards
>> Dev
>>
>>
>>
>>
>> On 10 May 2017 at 04:50, Mike West <mkwst@google.com> wrote:
>>
>>> On Wed, May 10, 2017 at 1:01 PM, Anne van Kesteren <annevk@annevk.nl>
>>> wrote:
>>>
>>>> On Wed, May 10, 2017 at 12:57 PM, Mike West <mkwst@google.com> wrote:
>>>> > I agree, but it's not clear to me that that would be fatal, since
>>>> browsers
>>>> > that support CSP already have code to deal with this kind of wildcard
>>>> > syntax.
>>>>
>>>> Dare I ask whether that is fully interoperable?
>>>
>>>
>>> Yup. 100%, probably. Maybe even 101%, because user agents wouldn't ship
>>> things that didn't comply to the spec!
>>>
>>> *cough*
>>>
>>>
>>>> Last I checked this
>>>> was defined with some ABNF which didn't inspire confidence. Also,
>>>> would this result in http://example/ matching HTTP://EXAMPLE/ whereas
>>>> it does not now?
>>>>
>>>
>>> I believe that the combination of the parsing and matching algorithms in
>>> the CSP spec are pretty solid (but, really, getting more eyes on the
>>> document would be better). But my point was less "Hey, let's reuse CSP!"
>>> and more "Wildcards are a problem that's totally possible to solve if we
>>> decide that we want to solve it."
>>>
>>> -mike
>>>
>>
>>
>