A security researcher who found a security hole in Safari says that Apple has still not fixed it, more than three months after he informed the company. The same vulnerability was present in Microsoft’s Edge browser, but the company issued a patch a month ago …
The flaw results in Safari showing the URL of a safe website like gmail.com while the user has in fact been sent to an attack site.
Rafay Baloch posted a video (below) with proof that the vulnerability could be exploited. It relies on a standard phishing technique, where an email presents a safe URL but the link itself sends you somewhere else. Usually, you’d be able to spot this from Safari’s address bar, but the exploit allows a bad site to ensure the safe URL is displayed despite the fact that you’re on a phishing site.
In the example given, Safari’s address bar displays the URL of a bank website while the visitor is actually on a completely different server.
The exploit is possible because Safari allows the address bar to be updated by Javascript while the page is still loading. So the attacker would direct you to their malicious site and then update the address bar to show the name of the safe one.
During my testing, it was observed that both Edge and Safari browser allowed javascript to update the address bar while the page was still loading. Upon requesting data from a non-existent port the address was preserved and hence a due to race condition over a resource requested from non-existent port combined with the delay induced by setInterval function managed to trigger address bar spoofing. It causes browser to preserve the address bar and to load the content from the spoofed page. The browser will however eventually load the resource, however the delay induced with setInterval function would be enough to trigger the address bar spoofing.
With Safari, there is one further challenge for an attacker to overcome, but Baloch’s video shows that this can be achieved.
Safari browser had one constraint which did not allow users to type information into the input boxes while the page was in the loading state. However, we were able to circumvent this restriction by injecting a fake keyboard (which happens to be a very common practice in banking websites).
The Register reports that Baloch waited the normal 90 days after advising Apple before releasing details of the exploit. This time window is designed to encourage companies to promptly close security holes once they have been informed of them.
FTC: We use income earning auto affiliate links. More.
Comments