Intent to Prototype: CORS non-wildcard request-header

[Yutaka Hirano]

Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

API spec

Yes

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Blink component

Blink>SecurityFeature>CORS

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.03% websites would be affected. To mitigate the risk, we show a deprecation message for a few milestones, and add an enterprise policy to keep the current behavior. 2: https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard

Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Web developers: No signals

Goals for experimentation

Ongoing technical constraints

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Not yet

Flag name

Tracking bug

https://crbug.com/1176753

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5742041264816128

[Yoav Weiss]

On Tue, Jul 6, 2021 at 3:56 PM Yutaka Hirano <yhi...@chromium.org> wrote:

Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

A short explainer outlining what this feature does would be helpful in reviewing.

IIUC, currently a site that send Access-Control-Allow-Headers: * response headers would be able to get cross-origin CORS-protected requests with the Authorization request header, which is contrary to the spec, and the proposed change is to block requests that contain such headers in that case. Is that correct?

   

API spec

Yes

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Blink component

Blink>SecurityFeature>CORS

TAG review

I agree that a TAG review is not necessary, as this is a small spec alignment with security implications and no API shape changes.

It'd be better to spell this out (e.g. in a future I2S).

 

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.03% websites would be affected. To mitigate the risk, we show a deprecation message for a few milestones, and add an enterprise policy to keep the current behavior. 2: https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard

Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Web developers: No signals

Goals for experimentation

Ongoing technical constraints

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Not yet

Flag name

Tracking bug

https://crbug.com/1176753

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5742041264816128

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HPqOj%2BSh0nsZKoT8jmzg6krOE%2BxNjdVH8SwOFwwD8u4g%40mail.gmail.com.

[Mike Taylor]

Hi Yutaka,

On 7/6/21 8:56 AM, Yutaka Hirano wrote:

Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Do we know if bugs have been filed against Firefox or WebKit bugzillas yet? I tried to look but didn't find anything.

thanks,
Mike

[Eric Lawrence]

If this is going to require cross-browser coordination, does the implementation bug (https://crbug.com/1176753 ) need to remain private? 

Beyond the lack of clarity about what " Implement it, and change the current behavior " means (presumably, "start following the spec and block requests that attempt to set the header"), I'm not sure the Motivation section makes a lot of sense. If an attacker has stolen or guessed authentication credentials, it's not at all clear why they'd bother using a CORS-implementing client to try to abuse them when they could instead use an unrestricted HTTP client.

[Yutaka Hirano]

Thank you!

On Thu, Jul 8, 2021 at 6:49 AM Eric Lawrence <bay...@gmail.com> wrote:

If this is going to require cross-browser coordination, does the implementation bug (https://crbug.com/1176753 ) need to remain private? 

We talked about opening up the discussion at the private thread, and we concluded it would be OK to make it public. I have made the bug public.

 

Beyond the lack of clarity about what " Implement it, and change the current behavior " means (presumably, "start following the spec and block requests that attempt to set the header"), I'm not sure the Motivation section makes a lot of sense. If an attacker has stolen or guessed authentication credentials, it's not at all clear why they'd bother using a CORS-implementing client to try to abuse them when they could instead use an unrestricted HTTP client.

That sounds reasonable - Anne, do you have any comments?

 

On Wednesday, July 7, 2021 at 11:20:39 AM UTC-5 mike...@google.com wrote:

Hi Yutaka,

On 7/6/21 8:56 AM, Yutaka Hirano wrote:

Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Do we know if bugs have been filed against Firefox or WebKit bugzillas yet? I tried to look but didn't find anything.

thanks,
Mike

https://bugzilla.mozilla.org/show_bug.cgi?id=1687364 is the bug for Firefox. I don't know if there is a bug for WebKit.

[Yutaka Hirano]

On Wed, Jul 7, 2021 at 2:44 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Tue, Jul 6, 2021 at 3:56 PM Yutaka Hirano <yhi...@chromium.org> wrote:

Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

A short explainer outlining what this feature does would be helpful in reviewing.

IIUC, currently a site that send Access-Control-Allow-Headers: * response headers would be able to get cross-origin CORS-protected requests with the Authorization request header, which is contrary to the spec, and the proposed change is to block requests that contain such headers in that case. Is that correct?

Yes.

   

API spec

Yes

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Blink component

Blink>SecurityFeature>CORS

TAG review

I agree that a TAG review is not necessary, as this is a small spec alignment with security implications and no API shape changes.

It'd be better to spell this out (e.g. in a future I2S).

I see, thank you for the suggestion.

[Yutaka Hirano]

On Thu, Jul 8, 2021 at 3:20 PM Yutaka Hirano <yhi...@chromium.org> wrote:

Thank you!

On Thu, Jul 8, 2021 at 6:49 AM Eric Lawrence <bay...@gmail.com> wrote:

If this is going to require cross-browser coordination, does the implementation bug (https://crbug.com/1176753 ) need to remain private? 

We talked about opening up the discussion at the private thread, and we concluded it would be OK to make it public. I have made the bug public.

 

Beyond the lack of clarity about what " Implement it, and change the current behavior " means (presumably, "start following the spec and block requests that attempt to set the header"), I'm not sure the Motivation section makes a lot of sense. If an attacker has stolen or guessed authentication credentials, it's not at all clear why they'd bother using a CORS-implementing client to try to abuse them when they could instead use an unrestricted HTTP client.

That sounds reasonable - Anne, do you have any comments?

It is possible that both the server to be attacked and the victim user are in a protected network. In such a case it is impossible for the attacker to send an HTTP request to the server with an unrestricted HTTP client.

[Anne van Kesteren]

On Fri, Jul 9, 2021 at 12:53 PM Yutaka Hirano <yhi...@chromium.org> wrote:
> On Thu, Jul 8, 2021 at 3:20 PM Yutaka Hirano <yhi...@chromium.org> wrote:
>> On Thu, Jul 8, 2021 at 6:49 AM Eric Lawrence <bay...@gmail.com> wrote:
>>> Beyond the lack of clarity about what " Implement it, and change the current behavior " means (presumably, "start following the spec and block requests that attempt to set the header"), I'm not sure the Motivation section makes a lot of sense. If an attacker has stolen or guessed authentication credentials, it's not at all clear why they'd bother using a CORS-implementing client to try to abuse them when they could instead use an unrestricted HTTP client.
>>>
>> That sounds reasonable - Anne, do you have any comments?
>>
> It is possible that both the server to be attacked and the victim user are in a protected network. In such a case it is impossible for the attacker to send an HTTP request to the server with an unrestricted HTTP client.

Right, allowing Authorization when all the server says is * also makes
it easier to perform and distribute a dictionary attack.