1555609 - text/plain URL Spoof via data scheme

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

Description

[Khalil Zhani]

Attachment: testcase.html

1. Lunch the test case
2. Click on the link
3. Observe

Comment 1

[Khalil Zhani]

Attachment: Screen Shot 2019-05-30 at 07.51.10.png

Comment 2

[:Gijs (he/him)]

Khalil: What do you think should be done differently here, and why?

Christoph: AFAICT this is a result of bug 1415612.

Comment 3

[Daniel Veditz [:dveditz]]

iiuc this is limited to plain text spoofing which doesn't seem very effective. Bug 1394554 was rated a sec-low spoof and this isn't even that good so I'm not sure if we even need to keep this hidden.

Comment 4

[Daniel Veditz [:dveditz]]

The content-type is "//www.facebook.com" followed by tons of spaces. Why are we interpreting that as "text/plain"? maybe we should fall back to "unknown == binary" instead. What breaks if we do that?

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

(In reply to :Gijs (he/him) from comment #2)

Christoph: AFAICT this is a result of bug 1415612.

Right, plain text spoofing doesn't seem like a high priority fix to me. Let's wait what Anne replies, but most likely we will just have to put that in the backlog.

Comment 6

[Anne (:annevk)]

There's a couple of things here:

1. data://facebook followed by a space/ does not parse as a URL per the URL Standard (and indeed fails to parse in Safari). (Not sure what is happening in Chrome; perhaps top-level data: URL navigations are disallowed?)
2. I think we could have better UX for different URL schemes. E.g., we could only display the scheme here and also, we could (finally) stop displaying https:// and the path normally, so users would expect to only see the domain when the address bar is not focused.
3. The default MIME type for data URLs is text/plain as per https://fetch.spec.whatwg.org/#data-urls and I don't think we should focus on changing that as it's been the default ever since they were added.

Comment 7

[Daniel Veditz [:dveditz]]

#1 would be a change in networking, #2 would be a front-end change. #2 also seems like a large project to ask of a team with a lot of other UX concerns, for practically no improvement for 99.99% of the legitimate web experience.

#1 seems like the best way forward.

Comment 8

[Christoph Kerschbaumer [:ckerschb]]

Jonas, can you please take a look at this one? I think we should fix #1 from comment 6 to make sure our data: URI phishing filter is not bypassed.

Dragana, can you guide us to the right code where data: URI parsing is happening?

Comment 9

[:Gijs (he/him)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #8)

Dragana, can you guide us to the right code where data: URI parsing is happening?

https://searchfox.org/mozilla-central/source/netwerk/protocol/data/nsDataHandler.cpp#53 etc.

Comment 10

[BugBot [:suhaib / :marco]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:ckerschb, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 12

[Daniel Veditz [:dveditz]]

This doesn't seem to be a problem any more

1. primarily it was fixed in bug 1627944 where the behavior in regressing bug 1415612 was changed to only allow PDF and JSON, not text/plain
2. if you paste the URL to open it all the former spoofing blanks are now displayed as "%20" which ruins the spoof attempt

Comment 13

[Daniel Veditz [:dveditz]]

Under current bounty program rules this spoofing bug would not qualify for a bounty, but applying the standards of when this bug was filed/fixed it would have so we are honoring that.