I've taken, out of curiosity, the Phishing Quiz by OpenDNS that tries to teach the general public about detecting phishing:

Ever wonder how good you are at telling the difference between a legitimate website and one that's a phishing attempt? Take this quiz to find out.

I did it mostly because my phishing detection process basically looks like this:

  1. Does the address bar look legit?

...and if it does I'll think the site is legit. That is most likely simplistic, but (spoiler alert!) you can get all 14 questions right just by looking at the address bar. "Yahoo!! is upgrading!!!" from "docs.google.com/spreadsheets"? Yeeeeah, that kind of barely smells like phishing.

Assuming the DNS server is not compromised, is the address bar really that bulletproof, though? If it isn't, how can I detect whether it's been tampered with or not?

  • 1
    I'm not interested really in exploits for Internet Explorer 6 or Firefox 3; I assume tricks like russian alphabet letters have been fixed in the latest versions of the major browsers.
    – badp
    Commented Nov 30, 2011 at 21:32
  • You do understand that quiz is meant for novices right? Its really simple, if you verify the domain of every website you visit, you will never visit a malicious website. Your assumption about those tricks would be wrong.
    – Ramhound
    Commented Dec 5, 2011 at 17:41
  • @Ramhound The quiz is meant for novices, but I was really looking forward to at least one example where the address bar looked actually legit.
    – badp
    Commented Dec 5, 2011 at 17:51
  • Here's a new (patched) vulnerability: blog.acrossecurity.com/2012/01/…
    – pdubs
    Commented Jan 4, 2012 at 20:08

5 Answers 5


The answer depends upon what kind of browser you are using, so I'll break it down.

Mobile browsers. You can't trust anything you see. Sorry. Life on a small screen sucks. That's just the way it is.

(Did you want an explanation why? Any web page can go full-screen, using mobile-specific tricks like scrolling the page down so that the address bar is not showing. Then, it can draw a fake address bar. As a user, there is no reasonable method you can use to detect this forgery by looking at the screen. See also the research paper iPhish: Phishing Vulnerabilities on Consumer Electronics, where the authors implemented this attack and tried it out; they learned that users could not detect it, not even computer science graduate students with knowledge of security, not even when they had been warned in advance of phishing attacks.)

So basically, there is no reliable way to detect phishing attacks on mobile browsers by looking at the screen. The only way to protect yourself is to go straight to the site yourself (e.g., by clicking on a bookmark) before entering your credentials: never get there via a link.

Older desktop browsers. On older browsers, like IE6 or Firefox 2, I don't know whether there is anything you can trust. They are so riddled with security holes that I would not count on them for security. The only way to protect yourself is to simply avoid those browsers: friends don't let friends use IE6. But you said you are not interested in them, so I think we can disregard them.

Modern desktop browsers. This is the nub of the issue, and I suspect what you were most interested in. On modern desktop browsers, there are only a few things you can trust:

  • Domain name. You can trust the domain name in the address bar to indicate the site you are currently on.

  • Blue/green glow. You can trust the blue/green glow behind the name in the address bar to indicate the presence of SSL. You can also trust the `https://`` schema to indicate the use of SSL, but the glow may be easier to check for.

That's essentially it. You can not trust the icon next to the URL (the favicon), even if it looks like a padlock or something; you cannot trust anything below the address bar; you cannot trust the text in the status bar when you hover over a link before clicking on it. You should not rely upon anything in the URL after the domain name, as the same-origin policy makes no distinction between different URLs on the same domain.

How to protect yourself. Let's put it all together. If you want to be safe when visiting some site -- say, your bank -- there are two viable strategies you can use to protect yourself:

  • Prevention: use a bookmark. To prepare, make a bookmark to the login page for your bank. (Make sure it is a https page you are bookmarking.) Then, when you want to log in, click on the bookmark, then enter in your credentials and use the site. Never navigate to your bank's site by clicking on links; if you find yourself on your bank's site from some other source, then make sure you're on the right page by clicking on the bookmark before you use the site. This essentially prevents any opportunity for a phishing attack on your bank credentials.

  • Detection: check the address bar. Alternatively, you can try to detect phishing attacks. Every time you visit your bank web site, check to make sure that the domain name in the address bar matches your bank's domain name before entering your credentials or using the site. This will be a pretty reliable way to detect phishing attacks -- as long as you always remember to check the address bar. The primary shortcoming of the approach is the obvious one: you have to always remember to check the address bar. Apart from that caution, this is a viable strategy, too.

    Also, you may want to check that you are currently using SSL, by checking for the blue/green glow (this is especially important when using a wireless network); if you happen to know that your bank has had a green glow in the past, then on subsequent visits make sure the glow is still green. Alternatively, if you use Firefox, you could install HTTPS Everywhere and save yourself from having to check for SSL.

Caveats and attacks. I need to qualify the above remarks a bit. Checking the address bar is not a foolproof defense. There are some sophisticated presentation attacks that could potentially fool you, even if you look at the address bar. Let me outline the major ones:

  • Picture-in-picture attacks. Recall that a web page can completely control what pixels are drawn on the portion of the browser window where it is displayed (e.g., by providing a bitmap image, which will be displayed exactly as is). In a picture-in-picture attack, a malicious web page arranges to draw something inside its window, so visually it looks like there a second, smaller browser window has popped up on top (and its outline is completely contained within the outer window). This is hard to describe in words, so here is an example image:

    A picture-in-picture attack

    Credits: Fig.2 of An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks by Jackson, SImon, Tan, and Barth.

    In this example, the user is visiting a malicious web page: http://paypal.login.com, as shown in the outermost address bar. The malicious page controls the contents of all the pixels inside this outer window (except for the chrome around the border). In this area, the attacker has drawn an image that replicates the appearance of a second smaller browser window, popped up on top. Since the attacker controls all of the pixels of that image, the attacker can completely control the "address bar" of the "inner window". The attacker has chosen to spoof an "address bar" containing https://www.paypal.com. If you weren't careful, you might conclude that the inner "window" has focus, look at its address bar, conclude you are talking to Paypal, and enter your Paypal password or other personal details into the inner "window". If you do that, you've actually revealed your Paypal password to the attacker.

    This attack can be tricky to mount successfully. It relies upon the user not getting suspicious when a new browser window appears to pop up for no good reason, when they weren't trying to visit Paypal. It also requires significant engineering effort from the attacker to make it look and feel correct. For instance, the attacker would need to use Javascript to identify what browser and operating system you are using, then craft a spoofed image that matches your browser version, and for full fidelity, the attacker might need to implement Javascript handlers to let you drag the inner window around (you won't be able to drag it outside the confines of the outer window), interact with the spoofed chrome of the inner window, and so on.

    For more on this attack, read An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks by Jackson, SImon, Tan, and Bart. I'm only aware of one instance of this sort of attack in the wild.

  • Homograph attacks. See "The Homograph Attack" by Gabrilovich and Gontmakher, and "The methodology and an application to fight against unicode attacks" by Fu, Deng, Wenyin, and Little.

  • Full-screen attacks. (TBD)

To my knowledge, these attacks are rarely (if ever) seen in practice, and they might have only a partial chance of fooling users, but I wanted to outline them so you are aware of the ways in which browser security is not perfect.


Actually it is possible to programmatically alter the contents of the text in the URL bar with Javascript. The browser is supposed to prevent you from changing the domain name; but you can change the text to something big enough that it may imply some scrolling, so that the text in the URL bar is something like:

http://big.ugly.pirate.com/      https://www.paypal.com/login.html    (spaces...)  .

with enough "spaces" such that the left part "scrolls out" of the bar. I suppose some Javascript could use the window size to infer how many spaces to add so as to get the desired visual effect on a given browser version, assuming "standard" font settings.

Yes, with a keen eye you will spot it. But that might require some training.

(disclaimer: I have not tried it nor seen it done; I do not know whether such scrolling can really be forced. It is worth a try.)

  • Well, we have already seen you can do "games" in the addres bar so this doesn't sound impossible to do. (I wish URL Hunter wasn't down right now.)
    – badp
    Commented Nov 30, 2011 at 22:14
  • 3
    Thomas, How sure are you about this? Does this work on modern browsers? Have you tried it? I am pretty skeptical that this attack is possible on modern browsers. I wasn't aware that modern browsers scroll the domain name out of the address bar like that. They make a lot of efforts to highlight the domain name, so it would be surprising if true.
    – D.W.
    Commented Dec 1, 2011 at 4:29
  • 3
    Thomas, I just tried it in Firefox 3.6, and the attack you propose doesn't work: Javascript on the site can't scroll away the domain name (you can add lots of spaces, but the site doesn't scroll away). Typing stuff in manually is not a reasonable test; you have to test it with Javascript on the page, as stuff you type in manually is handled differently by browsers. You are welcome to try it on other browsers if you like, but I would be awfully surprised if any major modern desktop browser is vulnerable to this. Until someone shows an example of a vulnerable browser, I consider this debunked.
    – D.W.
    Commented Dec 2, 2011 at 9:51
  • 1
    I can give you some more evidence. Attacks similar to the one you propose have been reported publicly (in 2003, 2004, 2006, and 2008) and used to work against IE6 -- but they have long since been fixed. These bugs tend to get fixed rapidly when noticed, because they are a fundamental part of the browser security architecture.
    – D.W.
    Commented Dec 2, 2011 at 10:06
  • 1
    P.S. However, you might enjoy this presentation, which has examples of attacks on other browser user interfaces and some principles for design of secure user interfaces.
    – D.W.
    Commented Dec 2, 2011 at 10:07

Sort of. The address bar will show you the address of the page you are viewing, but a web page is not the monolithic object of the 1990's. Since web pages use content and code from other locations if the content or code is modified the appearance of items on the page may be modified even if the text in the address bar is the same. The most common example of this is Cross Site Scripting (XSS).


According to this StackOverflow answer, it is indeed possible to change the URL bar without reloading the page. This would make the URL bar not immune to phishing attempts.

Here's the catch: if you can run Javascript in general, or redirect a user to a malicious link that looks like a legitimate page, you can already do a lot with cross-site scripting and Javascript redirects. In other words, if you've already convinced a user to visit an untrustworthy page, lots of bad things could already be happening - whether it's content or URL redirect, Flash-based malware, drive-by downloads or other attack vectors.

Where this does become interesting is a crafted URL like <a href="http://bad.site">http://paypal.com</a> that then changes the URL bar to PayPal.com. If the user clicked without thinking, then checks the URL bar, he or she might be in for some trouble!

edit: I've been playing with HTML5 pushState, and it looks relatively simple to appear to be browsing a different page on the same host, but not necessarily on a different domain. I'll keep playing with it, but for now if you go to dshaw.net/xss.html, it will change the URL bar to "login.aspx". Note that login.aspx doesn't exist. This could prove useful in an attack scenario in which there is XSS on a page of a given domain, but not the login/enter credentials page. From this perspective, this is a very dangerous feature that could be leveraged to great use.

  • Well, I still appear to be in dshaw.net :)
    – badp
    Commented Dec 1, 2011 at 1:01
  • 2
    You have misinterpreted the StackOverflow answer, and as a result you have drawn incorrect conclusions. It is only talking about the part after the domain name. I'm pretty sure no modern browser will allow you to change/spoof the domain name in the address bar. Give it a try!
    – D.W.
    Commented Dec 1, 2011 at 4:31
  • D.W., I agree - it doesn't seem possible to change the domain. However, as I mentioned in my answer, if you find XSS on some page (say, searchresults.aspx), you could make that URL appear to be login.aspx to steal credentials.
    – dshaw
    Commented Dec 1, 2011 at 20:03
  • dshaw, I don't think you've thought this through adequately. Regardless of your answer, users should never be making decisions based upon the part of the URL after the domain. The browser same-origin policy means that there is no security boundary, and no meaningful security distinction, between different pages on the same site. If there's a XSS on /searchresults.aspx, then the Javascript payload can already get access to the entire site, including your cookies, including the /login.aspx page and anything you type into it. The Javascript doesn't need to mess with the address bar.
    – D.W.
    Commented Dec 2, 2011 at 9:35
  • 1
    What I'm saying is that if there is an XSS vulnerability on one page, then the user is screwed, even if the attacker does not attempt to mess with the address bar: once there's an XSS attack on one page, there are other ways that the attacker can redirect you to another page while retaining control. So the potential for an attacker to mess with the part of the address bar after the domain name does not seem to add any new risk, as far as I can see. For similar reasons, users should never base security decisions off of the part of the URL after the domain name.
    – D.W.
    Commented Dec 3, 2011 at 7:46

URLs can still be spoofed, but spoofing the entire URL altogether is a whole lot harder.. although possible. Obfuscation and things of the like can conceal an address completely (and turn it into hexadecimal jibberish or a dotless binary address, etc.), will still look odd to a user.

Things like Hosts file poisoning, however, can completely map the domain name to a new IP. When a computer tries to resolve an IP address the very first place it looks is in the HOSTS file. If the address is not in your HOSTS file, your computer automatically goes to the next step in the line to resolve the domain name.

If you have, say google.com, and map it to or localhost in your HOSTS file, instead of taking you to Google you will go to http://localhost or instead. This method, however, is very difficult to implement because in Windows 7 it takes Administrative rights to modify the HOSTS file. I am not able to confirm if it takes administrative rights in XP or Vista.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .