text/plain URL Spoof via data scheme
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
People
(Reporter: chromium.khalil, Unassigned, NeedInfo)
References
(Depends on 1 open bug, Regression)
Details
(Keywords: csectype-spoof, regression, sec-low, Whiteboard: [domsecurity-backlog1])
Attachments
(2 files)
- Lunch the test case
- Click on the link
- Observe
Reporter | ||
Comment 1•5 years ago
|
||
Comment 2•5 years ago
|
||
Khalil: What do you think should be done differently here, and why?
Christoph: AFAICT this is a result of bug 1415612.
Comment 3•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
There's a couple of things here:
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?)- 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. - 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•5 years ago
|
||
#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•5 years ago
|
||
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•5 years ago
|
||
(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.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•4 years ago
|
Updated•3 years ago
|
Comment 10•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 12•2 years ago
|
||
This doesn't seem to be a problem any more
- 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
- if you paste the URL to open it all the former spoofing blanks are now displayed as "%20" which ruins the spoof attempt
Description
•