Intent to Prototype: CORS non-wildcard request-header

123 views
Skip to first unread message

Yutaka Hirano

unread,
Jul 6, 2021, 9:56:28 AMJul 6
to blink-dev, Mike West, Anne van Kesteren

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


Yoav Weiss

unread,
Jul 7, 2021, 1:44:15 AMJul 7
to Yutaka Hirano, blink-dev, Mike West, Anne van Kesteren
On Tue, Jul 6, 2021 at 3:56 PM Yutaka Hirano <yhi...@chromium.org> wrote:

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


--
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

unread,
Jul 7, 2021, 12:20:39 PMJul 7
to Yutaka Hirano, blink-dev, Mike West, Anne van Kesteren

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

unread,
Jul 7, 2021, 5:49:09 PMJul 7
to blink-dev, mike...@google.com, blink-dev, mk...@chromium.org, ann...@annevk.nl, Yutaka Hirano
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

unread,
Jul 8, 2021, 2:21:14 AMJul 8
to Eric Lawrence, blink-dev, mike...@google.com, mk...@chromium.org, ann...@annevk.nl
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

unread,
Jul 8, 2021, 2:46:51 AMJul 8
to Yoav Weiss, blink-dev, Mike West, Anne van Kesteren
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:

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

unread,
Jul 9, 2021, 6:53:04 AMJul 9
to Eric Lawrence, blink-dev, mike...@google.com, mk...@chromium.org, ann...@annevk.nl
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

unread,
Jul 20, 2021, 12:08:05 PMJul 20
to Yutaka Hirano, Eric Lawrence, blink-dev, mike...@google.com, mk...@chromium.org
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.
Reply all
Reply to author
Forward
0 new messages