search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.19k stars 2.72k forks source link

Navigation to about:config is disallowed per spec #2414

Open bzbarsky opened 7 years ago

bzbarsky commented 7 years ago

If I read the spec correctly, when an attempt is made to navigate to "about:config" (e.g. via the URL bar) we land in https://html.spec.whatwg.org/multipage/browsers.html#navigate and in step 12 we have a "fetch scheme" so try to do a "navigate fetch".

Then in https://html.spec.whatwg.org/multipage/browsers.html#process-a-navigate-fetch step 6.1 we try to fetch the request, which results in a network error.

bzbarsky commented 7 years ago

/cc @annevk

domenic commented 7 years ago

As far as I can tell this is working as intended; see e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4914 and try to click the link.

The issue is in assuming that URL bar navigation is the same as regular navigation. I always thought the URL bar was allowed to have special powers, e.g. typing "about:config\<enter>" went down a different code path, not governed by specs.

bzbarsky commented 7 years ago

If it's not covered by specs, what is it covered by? Something needs to define what happens to the session history on URL bar navigation....

The way this is implemented in practice, in Gecko, is that there's a security check, akin to the one that prevents the "http: navigates to file:" situation, that blocks the about:config load. And clearly that check does not apply to loads via the URL bar.

I should also note that the fetch spec has an explicit note saying "about:config" is handled in navigation, so either that note or the navigation spec is wrong. ;)

domenic commented 7 years ago

Fair enough, that is probably a better model...

domenic commented 7 years ago

Let's note that related matters are being discussed in https://bugs.chromium.org/p/chromium/issues/detail?id=698559

annevk commented 7 years ago

If <a href=about:config>test</a> should work, the way we want to do this I think is to generally leave navigation to about:... undefined (though probably only for top-level?) and special case about:blank.

bzbarsky commented 7 years ago

If test should work

It shouldn't, in a web page. It should only work via the URL bar.

bzbarsky commented 7 years ago

Well, or other UA entrypoints (bookmarks, whatever). It should never work from any invocation of "navigate" from a web spec. But there needs to be a way of invoking "navigate" that does make it work, to explain how UAs actually work.

youennf commented 5 years ago

I did some tests recently with Chrome, Firefox and Safari when loading about:XX URLs. The behaviours are widely different.

  1. Top-level navigation of about:xx using window.location
    • Chrome is loading about:xx (empty content), window.location is about:xx but navigation bar shows about:blank#blocked
    • Firefox is denying access to about:xx
    • Safari is loading about:xx (empty content)
  2. iframe loading of about:xx
    • Chrome is loading about:xx as a same-origin iframe
    • Firefox is loading about:xx as if it was about:blank (probably it stays as about:blank).
    • Safari is loading about:xx as a cross-origin iframe
  3. Using window.open with about:xx
    • Chrome is loading about:xx, navigation bar shows about:blank#blocked. opener is considered same-origin.
    • Firefox is denying access to about:xx
    • Safari is loading about:xx. opener is considered cross-origin
  4. Top-level navigation of about:xx through the navigation bar
    • Chrome is loading about:xx but the navigation bar shows about:blank#blocked
    • Firefox is treating it as an invalid URL
    • Safari is not treating it as an URL

In Safari, we are contemplating processing about:xx as if it was about:blank from the start. This would align with Firefox behaviour for iframe, would be similar to Chrome behaviour, except for thins like window.location accessors which would return 'about:blank' instead of 'about:xx'. Is it something that other browsers could align to as well?

Any thoughts?

bzbarsky commented 5 years ago

Firefox is loading about:xx as if it was about:blank (probably it stays as about:blank).

Right, Firefox tries to do the about:xx load, that's blocked, and so the initial about:blank is what's in the iframe.

I'd like to understand the exact semantics being proposed here. In Firefox, a load of a url string generally works like this:

1) The string is converted to a URL object (not exactly the same as the web-exposed URL). This part can fail in various ways. Ideally the ways it can fail are covered by the URL standard, but we may have per-protocol checks that are not in that standard that could cause this to fail at this stage. Right now about:xx gets through this stage and produces a URL object that represents a URL with two pieces to it: about for the protocol and xx for "the rest". 2) In some cases (including window.open and location sets), but not in general, a security check is performed to see whether the entity that triggered the load is allowed to load the given URL object. This is the thing that ends up failing for about:xx in cases 1 and 3 above. These security checks are legacy ones that we are working on removing, fwiw, which might affect behavior here. 3) If the security check passes, an object representing the load is created from the URL object. This step can fail even if step 1 passed, in various ways. In particular, it fails for about:xx. 4) A security check is performed on the object created in step 3. If this passes, the load tries to happen; of course this can fail for various reasons.

So a few thoughts/questions:

youennf commented 5 years ago

I am mostly interested in improving consistency among browsers for about:xx JS navigation loads. Address bar about:xx loads are basically out of scope.

The most important thing to consider in my mind is web compatibility, Chrome/Safari/Firefox behaviours are all good starting points.

  • Now that I've written out that list and compared it to the cases that were tested, the lack of testing for <a href="about:xx"> jumps out. What do browsers do in that situation? I am pretty sure that the step-2 security check in Firefox happens for that case too, fwiw, so I expect its behavior to be much like the location case.

I think is similar to window.open and window.location. Firefox blocks the load when clicking or when right-clicking to 'open in a new tab'. Chrome treats the load as about:blank#blocked as well.

  • At what stage in that process would the remapping to about:blank conceptually inject.

This should be based on an URL, slightly before the call to fetch. Your step 3 proposal makes sense to me.

  • There are various privileged about: URLs in Firefox (like about:config). What is the proposed behavior in those cases?

The idea would be to treat them as any other about:xx JS navigation. This seems consistent with what I see in Chrome and Firefox: trying to load these specific URLs through JS navigations is 'blocked'.

bzbarsky commented 5 years ago

Address bar about:xx loads are basically out of scope.

OK.

The idea would be to treat them as any other about:xx JS navigation.

So they would load about:blank? Would they get the origin-and-CSP-inheriting behavior about:blank gets?

I'd honestly prefer to treat such loads, as well as about:xx as network errors, presumably async from the fetch start...

anforowicz commented 3 years ago

I just wanted to share that I learned today (see https://crbug.com/1220186#c9) that some old best-practices documents recommended navigating to "about:self" rather than to "about:blank". One specific example is/was the "IAB Best Practices for Rich Media Ads in Asynchronous Ad Environments" document from 2008 at https://www.iab.com/wp-content/uploads/2015/09/rich_media_ajax_best_practices.pdf