The whole page should be replaced by a Safe Browsing warning when a frame or sub-resource is blocked
Categories
(Toolkit :: Safe Browsing, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox63 | --- | wontfix |
firefox64 | --- | wontfix |
firefox65 | --- | wontfix |
firefox66 | --- | wontfix |
firefox67 | --- | wontfix |
firefox68 | --- | wontfix |
firefox69 | --- | wontfix |
firefox70 | --- | wontfix |
firefox72 | --- | wontfix |
firefox73 | --- | wontfix |
firefox74 | --- | wontfix |
firefox75 | --- | wontfix |
firefox76 | --- | wontfix |
firefox77 | --- | wontfix |
firefox78 | --- | wontfix |
People
(Reporter: pavel, Unassigned)
References
()
Details
(Keywords: sec-want, Whiteboard: [sb-backlog] [sb-moderate])
Attachments
(4 files)
Reporter | ||
Comment 1•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Updated•9 years ago
|
Comment 3•9 years ago
|
||
Reporter | ||
Comment 4•9 years ago
|
||
Comment 5•9 years ago
|
||
Reporter | ||
Comment 6•9 years ago
|
||
Comment 7•9 years ago
|
||
Comment 8•9 years ago
|
||
Updated•9 years ago
|
Comment 9•9 years ago
|
||
Comment 10•9 years ago
|
||
Comment 11•9 years ago
|
||
Comment 12•9 years ago
|
||
Comment 13•9 years ago
|
||
Comment 14•9 years ago
|
||
Comment 15•9 years ago
|
||
Comment 16•9 years ago
|
||
Comment 17•9 years ago
|
||
Comment 18•9 years ago
|
||
Comment 19•9 years ago
|
||
Comment 20•9 years ago
|
||
Comment 21•9 years ago
|
||
Comment 22•9 years ago
|
||
Comment 23•9 years ago
|
||
Comment 24•9 years ago
|
||
Comment 25•9 years ago
|
||
Comment 26•9 years ago
|
||
Comment 27•9 years ago
|
||
Comment 28•9 years ago
|
||
Updated•9 years ago
|
Comment 29•9 years ago
|
||
Comment 30•9 years ago
|
||
Comment 31•9 years ago
|
||
Comment 32•9 years ago
|
||
Comment 33•9 years ago
|
||
Comment 34•9 years ago
|
||
Comment 35•9 years ago
|
||
Comment 36•9 years ago
|
||
Comment 37•9 years ago
|
||
Comment 38•9 years ago
|
||
Comment 39•9 years ago
|
||
Updated•9 years ago
|
Updated•9 years ago
|
Updated•8 years ago
|
Updated•8 years ago
|
Updated•8 years ago
|
Comment 43•8 years ago
|
||
Updated•7 years ago
|
Comment 45•6 years ago
|
||
Comment 46•6 years ago
|
||
I can still reproduce this on Mac OS X 10.13, Windows 10 and Ubuntu 16.04 with FF Nightly 68.0a1(2019-04-02), FF Beta 67 and Release 66.
Comment 48•6 years ago
|
||
https://testsafebrowsing.appspot.com/ links to handy testcases for various situations including this one, possibly from the Chrome or SafeBrowsing team.
Comment 49•6 years ago
|
||
I think we should WONTFIX this bug in favor of disallowing adding an exception for iframe-based SafeBrowsing pages instead, here's why:
- The spoofing case highlighted in bug 1546695 already works with other necessarily embeddable about: pages, such as about:certerror, so we can't fix it.
- I don't think any user, even experienced ones, can make a trust decision for malicious.com when well-trusted.com embeds it based on the limited information they have on the SafeBrowsing page. It's just not possible to correctly assess the security situation here, I can hardly imagine a scenario where I would want the outcome of this to be that the user whitelists malicious.com based on seeing a warning about well-trusted.com.
- Isn't this a DOS vector? Any frame with script-executing capabilities (which I guess is most of them) on your site can trivially escape their boundary and block your page by navigating to a known blocked domain.
This breakage really seems like an edge case that we could live with. We could consider spawning the red notification bar with a text saying something like "Malicious code was detected and blocked on this page. Proceed with caution".
Let me know what you think. Dan and Gijs, maybe you have an opinion on this?
Comment 50•6 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #49)
I think we should WONTFIX this bug in favor of disallowing adding an exception for iframe-based SafeBrowsing pages instead, here's why:
- The spoofing case highlighted in bug 1546695 already works with other necessarily embeddable about: pages, such as about:certerror, so we can't fix it.
We disallow exceptions in framed about:cert/neterror, right? Per bug 442929 (duped to here), do we also disallow exceptions for framed safebrowsing pages already, or not?
I think it's conceivable that about:blocked/about:cert/neterror have different phishing characteristics, ie there may be a "point" to phishing one but not the others. If, as a user, I see a "we blocked this dangerous page" warning that has some UI on it that suggests I click it, and afterwards I get another block page, I might be inclined to unblock. I'm less convinced that'd work with certificate or network error pages (and also, I'm not sure I see a point in doing it - it implies you have a reachable site with valid TLS credentials but need to go out of your way to get someone to add an exception for some other site with invalid credentials?).
In other words, even if we can't do this for neterror/certerror, I'm not convinced that that means we shouldn't do it for about:blocked.
- I don't think any user, even experienced ones, can make a trust decision for malicious.com when well-trusted.com embeds it based on the limited information they have on the SafeBrowsing page. It's just not possible to correctly assess the security situation here, I can hardly imagine a scenario where I would want the outcome of this to be that the user whitelists malicious.com based on seeing a warning about well-trusted.com.
I'm happy to disallow adding an exception, but that doesn't fix this bug as filed, or the duped spoofing bug.
- Isn't this a DOS vector? Any frame with script-executing capabilities (which I guess is most of them) on your site can trivially escape their boundary and block your page by navigating to a known blocked domain.
That doesn't seem like a strong motivation not to do this to me; iframe sandboxing can prevent navigation and should be used by sites that embed content they don't trust, irrespective of this bug. If the embedding site is directly embedding a blocked domain, showing the warning across the entire page seems better than having a potentially half-broken site (e.g. because postMessage etc. aren't doing what the parent page expects) without clear info for the user.
This breakage really seems like an edge case that we could live with.
I mean, we've lived with it for (at least) 4 years now so clearly yes, but IMHO this is not ideal.
We could consider spawning the red notification bar with a text saying something like "Malicious code was detected and blocked on this page. Proceed with caution".
And do what with the page? Still allow the parent to be embedding it, potentially adding confusing/spoofing UI to it?
Comment 51•6 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #49)
I think we should WONTFIX this bug in favor of disallowing adding an exception for iframe-based SafeBrowsing pages instead
If we're showing User Interface (error pages, in this case) in a frame we most certainly should be disallowing any actions taken from them. Way too easy to clickjack. If the user wants to make an exception they can use the context menu to show the frame as a new tab and add the exception from there. The user has no way of safely knowing to whom they're granting the exception when it's in a frame.
That aspect of this should go without question, but was this bug ever really about "should there be exceptions in the frame"? It was about not showing the user the page tried to do something malicious because the malicious stuff was running in a tiny frame.
I can hardly imagine a scenario where I would want the outcome of this to be that the user whitelists malicious.com based on seeing a warning about well-trusted.com.
Agreed.
- Isn't this a DOS vector? Any frame with script-executing capabilities (which I guess is most of them) on your site can trivially escape their boundary and block your page by navigating to a known blocked domain.
You don't need script: you can use a meta-refresh or even just a 30x from the server when the browser requests the frame document.
There are a lot of permutations here. Is it a phishing block? Hard to phish if you can't see the content so blocking just in the framed content should be sufficient. What if it's malicious content? If it's "social engineering" you need to see it, and again blanking the frame should work. But if it's some kind of malware attempt, or a download which iirc was the original case in this bug, what then? We blocked it, does the user need to know? The framing site's author?
We could consider spawning the red notification bar with a text saying something like "Malicious code was detected and blocked on this page. Proceed with caution".
That might be a good compromise. Notification of badness is really what I'm interested in and that would do it, without blocking the content of the innocent (presumably) framing site.
Comment 52•6 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #49)
- I don't think any user, even experienced ones, can make a trust decision for malicious.com when well-trusted.com embeds it based on the limited information they have on the SafeBrowsing page.
NOTE: That is NOT the original scenario here. The top-level site itself had links to malicious downloads. The only reason frames come into the picture is because links targeting hidden frames is one common way to do download links without the user navigating away from your page. Putting the "malicious download" warning in an invisible frame is exactly the wrong thing. Silent failure of an expected download might also encourage the user to do unwise things, like right-click to copy the URL and download it in another tool (if they open it in another Firefox tab we get the chance to show the warning, of course).
In any of these scenarios we don't actually know the top-level site is fine, all we know is it's not on the SafeBrowsing list. Could be reputable-but-hacked, could be reputable-but-adframe-hacked, could be a typosquatting domain where the user thinks it's reputable but it's a not-yet-blocked scam (e.g. searchfox.COM was recently offering Firefox-branded fake-flash and other malware).
I also worry that the SafeBrowsing team will make decisions about which domains to put on the list based on Chrome behavior. If there are a bunch of evil sites all pushing the same common malware for Chrome they can just list the common bit and all the sites will be blocked -- no need (for them) to bloat the list with each variant that pops up. We've seen (anecdata) examples of this in the past where the containing page was obviously bogus but not on the SafeBrowsing list, but of course we don't know exactly why the containing page wasn't added. Maybe it was just too new? testcases hosted at https://testsafebrowsing.appspot.com/ show some of the Chrome/Firefox differences.
Comment 53•5 years ago
|
||
Hi,
Then issue is reproducible in latest Nightly version 70.0a1 (2019-07-16) , on Windows 8.
Comment 54•5 years ago
|
||
Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.
Comment 55•5 years ago
|
||
The work in bug 1591474 to make this infrastructure work under fission will help with making per-frame decisions.
Comment 56•5 years ago
|
||
I was able to reproduce this issue on latest Nightly version 74.0a1 (2020-02-05) on Windows 10
Updated•5 years ago
|
Comment 57•5 years ago
|
||
This issue is reproducible on latest Nightly version 76.0a1 on Ubuntu 18. Change flags accordingly.
Comment 58•5 years ago
|
||
Updating affected flags for FX78 and Fx77.
Updated•2 years ago
|
Comment 59•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:dimi, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Comment 60•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Updated•2 years ago
|
Description
•