Reject non-http URLs for url member

[marcoscaceres]

Closes #173

For normative changes, the following tasks have been completed:

• Modified Web platform tests - incoming with Gecko patch.

Implementation commitment:

• WebKit (https://bugs.webkit.org/show_bug.cgi?id=215823)
• Chromium (https://chromium-review.googlesource.com/c/chromium/src/+/2425977)
• Gecko - Secure bug.

[whsieh]

It looks like https://github.com/web-platform-tests/wpt/blob/master/web-share/canShare.tentative.https.html still checks that we're able to share data URLs. Would that test need to be updated as well?

[ewilligers]

The webkit patch allows data urls.

@marcoscaceres do you also consider them problematic?

[martinthomson]

I think that this needs more treatment than this alone. It needs to acknowledge the risk that share targets could retrieve content from the URL, and that they might follow redirects (or be subject to DNS tweaking) in order to exploit their position in the network to access information that might otherwise be protected by firewalls and similar. If the application also passes on that information, that leads to an unexpected information leakage.

I don't think that it is appropriate to say that this is sufficient to address #173.

[marcoscaceres]

@ericwilligers, about data: URLs, yes, as if they get dereferenced and previewed, then you can get into a situation like:

data:text/html;<meta http-equiv="refresh" content="1;url=file:///here/we/go/again">

@whsieh, what was the rationale for still allowing data: on the Webkit side? Also, you are right about canShare(), but that's a different matter. It's not supposed to leave the browser... but will address. I'm still hopeful we can fix canShare() by doing what I proposed in #108. Maybe with more urgency now?

@martinthomson agree, definitely need to add a security considerations section for apps ingesting these URLs. As you suggested, we are just one link a weak chain here and OSs and apps able to inject need to be more careful.

[marcoscaceres]

@martinthomson, I added your comment above more or less verbatim as they capture the risk quite nicely from a bunch of different angles. Please feel free to suggest additional changes.

[marcoscaceres]

I file w3ctag/security-questionnaire#96 to capture our cautionary tale of trusting URLs and thinking receiving parties will be careful with what they are receiving.

[whsieh]

@whsieh, what was the rationale for still allowing data: on the Webkit side? Also, you are right about canShare(), but that's a different matter. It's not supposed to leave the browser... but will address. I'm still hopeful we can fix canShare() by doing what I proposed in #108. Maybe with more urgency now?

I believe the rationale for still allowing the data protocol in the change was just to keep the existing web platform tests passing.

[ewilligers]

@whsieh, for the share targets you tested, is sharing a http(s) url that redirects a problem?

If not, is sharing the following simply equivalent to sharing a http(s) url that redirects, and not equivalent to sharing a file:// url?

data:text/html;<meta http-equiv="refresh" content="1;url=file:///here/we/go/again">

[whsieh]

@whsieh, for the share targets you tested, is sharing a http(s) url that redirects a problem?

If not, is sharing the following simply equivalent to sharing a http(s) url that redirects, and not equivalent to sharing a file:// url?

data:text/html;<meta http-equiv="refresh" content="1;url=file:///here/we/go/again">

This is not a problem (at least, on Cocoa platforms) because neither the share targets (Messages and Mail in this case) nor the UA attempt to load the data URL as web content and then send the web content to the recipient.