An update on `--disable-web-security`.

[Mike West]

Hello, security-dev@! (BCC chromium-dev@ and blink-dev@)

I think folks will probably agree that the `--disable-web-security` flag is more than somewhat dangerous. I'd like to mitigate the potential harm by weakening the flag in the short term, and replacing it in the long term with something more targeted.

When I asked about the flag on Twitter (https://twitter.com/mikewest/status/673819295634366464), the overwhelming feedback was from developers who use the flag to avoid setting up CORS for their test environments, or to avoid teaching production servers about the expected origins of test servers. Folks also noted that WebView exposes an API that applications depend on for `file:` URLs, which we need to support for some indefinite period.

With those use cases in mind, for Chrome ~49, I'd like to:

    * Lock the `--disable-web-security` flag to the `--user-data-dir` flag in order to ensure that users aren't unknowingly leaving themselves at the mercy of The Internets: https://codereview.chromium.org/1512843002 (just for Chrome; `content_shell` wouldn't be affected)

    * Marginally harden the Blink implementation with some asserts and minimal browser-side checks: https://codereview.chromium.org/1507023004

    * Introduce a `--disable-cors-for-origins` flag (also tied to `--user-data-dir`) which will accept a list of origins whose responses will always pass CORS checks. It might be worthwhile to merge this functionality with the existing `--unsafely-treat-insecure-origin-as-secure` flag somehow, as I expect the use cases to be fairly overlapping. Perhaps `--unsafe-dev-mode-for-origins` or something similar?

Once we help developers migrate to those flags, I'd like to remove `--disable-web-security` entirely, along with the various bits of plumbing it requires (on `SecurityOrigin` and `WebPreferences` and etc).

WDYT. folks? Are there use cases that I've missed which we really ought to support?

Thanks!

-mike

[PhistucK]

On Wed, Dec 9, 2015 at 12:51 PM, Mike West <mk...@chromium.org> wrote:

Introduce a `--disable-cors-for-origins` flag (also tied to `--user-data-dir`) which will accept a list of origins whose responses will always pass CORS checks

Please, make sure this accepts wildcards -

*://*.company.com:*/

☆PhistucK

[Mike West]

I'm not sure that's a great idea. It would certainly make it simpler for developers to use if they have large numbers of servers, but I think that might be a good outcome. There should be some reasonable amount of friction when turning off security.

I might be overreaching, of course. Happy to debate the pros and cons based on use cases.

-mike

[PhistucK]

Many test machines -

http://backendserver1.corp.google.com:12132

https://backendserver1.corp.google.com:23222

http://backendserver2.corp.google.com:33432

https://backendserver2.corp.google.com:23232

And much, much more...

Developers of big companies may get bugs from various sources, teams and testers and must connect (XMLHttpRequest) their front end server pages to the backend servers in order to debug.

☆PhistucK

[Mikhail Naganov]

Hi Mike,

For the record, WebView can toggle the following WebSettings in Blink:

setAllowDisplayOfInsecureContent

setAllowRunningOfInsecureContent

setAllowFileAccessFromFileURLs

setAllowUniversalAccessFromFileURLs

It doesn't ever use setWebSecurityEnabled.

[Mike West]

On Wed, Dec 9, 2015 at 5:56 PM, Mikhail Naganov <mnag...@chromium.org> wrote:

Hi Mike,

For the record, WebView can toggle the following WebSettings in Blink:

Thanks!

 

setAllowDisplayOfInsecureContent

setAllowRunningOfInsecureContent

setAllowFileAccessFromFileURLs

setAllowUniversalAccessFromFileURLs

Amusingly enough, I've bugged folks about unilaterally deprecating/disabling all of them. So far, they've refused. :) 

It doesn't ever use setWebSecurityEnabled.

Blink's current implementation uses the same flag for `--disable-web-security` and `setAllowUniversalAccessFromFileURLs()`. https://codereview.chromium.org/1507023004 splits them out so we can be a bit more paranoid with ASSERT()s.

-mike 

[Chris Palmer]

It's poor practice to have dev, staging, and prod have different configurations. If people are avoiding setting up CORS properly in dev, they're just headed for heartbreak in prod — and then they'll just set it to allow all of of frustration. And the cycle of not understanding CORS continues...

So I don't think we should enable that use case.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Mike West]

On Wed, Dec 9, 2015 at 11:51 AM, Mike West <mk...@chromium.org> wrote:

    * Lock the `--disable-web-security` flag to the `--user-data-dir` flag in order to ensure that users aren't unknowingly leaving themselves at the mercy of The Internets: https://codereview.chromium.org/1512843002 (just for Chrome; `content_shell` wouldn't be affected)

FYI: This landed in https://codereview.chromium.org/1512843002. If you wish to use `--disable-web-security`, you'll need to specify a `--user-data-dir` going forward.

Dru, are you the right person to talk to about getting this note into the next set of release notes? :)

-mike 

[Dru Knox]

Yup! I'll send out a call for M49 features next week. The most important part is to make sure that there's a Chromestatus entry before then. If you don't see this on the list when I send out the email, just ping me :)

--

-Dru

[PhistucK]

I am not sure chromestatus.com is appropriate for that... It is not a web platform feature, it is a flag - that should actually not be publicized, even if users will be blindingly copying two flags instead of one now.

A stackoverflow.com answer may be more appropriate for that.

I am not sure even a blog post is appropriate. Remember, this is a very dangerous flag, --user-data-dir or not.

☆PhistucK

--

[Dru Knox]

I agree with phistuck - if we don't feel that this should have a chromestatus entry, we probably don't want to include it in the release blog either. Stack Overflow seems appropriate.

--

-Dru

[Mike West]

On Thu, Jan 7, 2016 at 9:14 PM, Dru Knox <dk...@google.com> wrote:

I agree with phistuck - if we don't feel that this should have a chromestatus entry, we probably don't want to include it in the release blog either. Stack Overflow seems appropriate.

Up to you, I suppose. It's a flag that folks use, and its behavior is changing. I suspect there will be some bugs coming in (e.g. https://crbug.com/574356) that we might be able to avoid if we communicate the change, but if the release notes aren't the right place for that communication, I'm fine with that.

-mike

[Robert Sesek]

FYI, it appears the presence of "--user-data-dir", even with no value specifying an alternate profile path, will suffice. If the intent is to prevent users from running with --disable-web-security on their primary profiles, then maybe this should be prevented?

Context: https://code.google.com/p/chromium/issues/detail?id=575690

rsesek / @chromium.org

[Dru Knox]

I suppose the safest thing for now is to include it and then see if anyone says to take it out of the release blog!

--

-Dru

[PhistucK]

Even though people use this flag, it is not a supported configuration. You should not be afraid to break unsupported configurations, especially dangerous ones - without any warning.

☆PhistucK