I believe there used to be an older bug which relied on the user to navigate from say
However, I managed to circumvent this fix to an older bug by having the user instead of going to a normal
'http://trusted.ltd' website the user would instead go to an invalid one, we do this by inserting an invalid char at the end of the address.
For example, going to
'http://facebook.com;' (notice the semicolon) will result in a 'Server not found' error page, that looks like this:
The downside of this type of bug is that I don't actually get any information from the spoofed domain, this is purely to trick the victim into assuming they are in a trusted domain.
Now if we go to an error page and navigate back to a
spoof any URL with a resulting error page.
The only time we could spoof a domain char per char without adding invalid char is if the domain does not implement a valid cert, or if the targeted domain does not have https capabilities but we have the user go to an https url.
Here is the original proof of concept code reported to Mozilla.
'http://facebook.com;'(note the semicolon again), despite the URL address displaying the invalid link, you're not actually on that URL in the back end. (not as far as the documents concerned)
'document.documentURI'which in this case equals
'about:neterror?e=dnsNotFound&u=http%3A//www.facebook.com%3B/&c=UTF-8&f=regular&d=Firefox%20can%27t%20find%20the%20server%20at%20www.facebook.com%3B.'I believe this is how it was possible to bypass the existing security, as the security measures only took into account http/s urls and not about: urls.