1818212 - Popup-based injection of Mixed active content leading to MITM attacks.

Status: RESOLVED DUPLICATE of bug 1801501

(Firefox :: Security, defect)

Description

[Shaheen Fazim]

In Firefox, loading mixed active content is blocked as a security measure, safeguarding its users from most sniffers and man-in-the-middle attacks

However, an attacker could exploit sites with allowed popup to open an about:blank page and request active insecure content, leading to MITM attacks.

Steps to reproduce:

1. Load an HTTPS site, for example: https://www.google.com

2. Open the console on the same site and paste the following poc code to test:

var newWindow = window.open('about:blank');
setTimeout(function() {
    var iframe = newWindow.document.createElement('iframe');
    iframe.src = 'http://neverssl.com/';
    newWindow.document.body.appendChild(iframe);
  }, 1000);

The above code will successfully load insecure active content over the parent origin.

This vulnerability is similar to https://bugs.chromium.org/p/chromium/issues/detail?id=957002 . Both Safari and Chrome have fixed it, Mozilla is still vulnerable to this type of attacks.

Comment 2

[Daniel Veditz [:dveditz]]

A large reason for preventing the loading of mixed content frames is because users can see the lock icon on the top-level site and there's no separate indicator for framed content. Indeed, the user might not even realize some of the content is in a frame depending on how it's incorporated into the site. Users will see the lock at the top and assume all the content on that page was loaded securely. It's not generically about protecting users from MITM attacks; if that were the case we would never let users load http: content.

In this case there's no promise to the user that the popup content was loaded securely: the address bar says "about:blank" and does not have a lock icon. It's still definitely a bug, and (for example) the top level content could check window.isSecureContext and makes its own wrong assumptions. But this isn't really "leading to MITM attacks" any more than loading any top-level http: page.

You could argue the users knows the popup was loaded from a trusted site (google, in your description) and therefore will trust it despite the lack of a lock icon. But in that case you're arguing that the trusted site has been hacked which seems like a worse problem than the potential for an active MITM attack on the framed content.