Re: Classifying potentially hostile URLs

A "fetch scheme"[1] includes lots of things we want to avoid here (data,
blob, ..) and the navigation algorithm includes a superset that has even
more avoidable schemes (e.g., javascript).

I think we might re-use the HTML "safelisted schemes"[2] here?

(They are used during scheme-normalization for in
`navigator.registerProtocolHandlers`[3]. The normalization algorithm
allows a set of safelisted schemes plus web-handled protocols that were
registered through sites.

The registered URL schemes themselves aren't sharable, AFAIU the
scheme+target association that comes through `registerProtocolHandlers`
is not globally unique.)


Is there anything in the "safelisted schemes" that looks wrong?




[1] https://fetch.spec.whatwg.org/#fetch-scheme
[2]
https://html.spec.whatwg.org/multipage/system-state.html#safelisted-scheme
[3]
https://html.spec.whatwg.org/multipage/system-state.html#normalize-protocol-handler-parameters


On 17.08.21 08:03, Martin Thomson wrote:
> https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate
> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate>
> seems like a good entrypoint into a lot of this discussion.  I find that
> spec mind-numbingly arcane, but I'm sure that there is something at Step
> 21 that might help ("fetch scheme" seems like a useful concept to
> explore more).
> 
> On Tue, Aug 17, 2021 at 3:03 PM Marcos Caceres <marcos@marcosc.com
> <mailto:marcos@marcosc.com>> wrote:
> 
>     Hi WebAppSec Folks,
> 
>     I'm writing to you in my capacity as WebApps WG Chair, formally
>     seeking a liaison with WebAppSec's on a security matter described
>     below.
> 
>     ## What happened... 
> 
>     About 2 years ago, the Web Share API was found to have a
>     vulnerability whereby "file://" could be used to "steal local files
>     using Safari Web Share API" [1]. In particular, passwords could be
>     stolen. 
> 
>     As part of that, we patched up various browsers to disallow anything
>     that was not "http", "https", plus any schemes the user agent deems
>     unsafe to navigate. In Firefox, for instance, this includes "blob:"
>     URLs, as they don't make sense outside the browser - and you can
>     imagine other URLS that might be unsafe to "share" (e.g.,
>     "javascript:", "data:" and so on). You can see how Gecko handles
>     this at [2].
> 
>     Over in the Github issue related to this [3], Martin Thompson wrote:
> 
>     > it might be worth examining principles a little closer to
>     determine whether a looser set of constraints can be made to work.
>     @dveditz suggested that we block URLs if we might not permit both
>     navigation or redirection. I think that is a reasonable starting
>     point here. We don't allow navigation or redirects to file:// and so
>     sharing that seems to be primarily a means of circumventing that policy.
> 
>     ## Do we need "a thing..."?
> 
>     So, generally for the platform, should we try to define some kind of
>     primitive or concept around these kinds of URLs (i.e., those that
>     "those whereby we allow navigation or redirection")? Or, should we
>     just leave it to each implementer to determine what set of URLs are
>     safe to "share"?
> 
>     Would like to hear your thoughts over at [3] or here. Right now, the
>     Web Share API is leaning towards just leaving it to implementers -
>     but maybe there is something we can formalize here for the platform
>     at large (or perhaps something exists already which we hadn't
>     considered)? 
> 
>     Thanks in advance your thoughts an input!
>     Marcos 
> 
>     [1]
>     https://blog.redteam.pl/2020/08/stealing-local-files-using-safari-web.html
>     <https://blog.redteam.pl/2020/08/stealing-local-files-using-safari-web.html>
>     [2]
>     https://searchfox.org/mozilla-central/source/dom/base/Navigator.cpp#1415
>     <https://searchfox.org/mozilla-central/source/dom/base/Navigator.cpp#1415>
>     [3] https://github.com/w3c/web-share/issues/178
>     <https://github.com/w3c/web-share/issues/178>
>

Received on Tuesday, 17 August 2021 07:22:31 UTC