Security Issues That Aren’t – Part 1


My name is Patrick Mann and I’m a security tester on the IE team. A big part of my job is to research potential IE security vulnerabilities reported to Microsoft by 3rd parties: security vendors, site developers, or simply observant users. These folks do the browsing public a great service by working with us to eliminate vulnerabilities before they can be exploited. However, I’ve also noticed that there are some misconceptions about IE security that lead people to worry about perceived security issues that are not actually vulnerabilities, or in fact expected behavior. I’d like to discuss some of the more common cases.

Today’s topic is status bar “spoofing” – using the status bar to trick users into believing they are on a trusted site, when they are not. Users typically rely on multiple cues to make trust decisions: the address bar, the page content, the lock icon, and also the URL displayed in the status bar when hovering over a link. But not all of these are equally good indicators.

The address bar and lock icon are completely under the control of IE; these are reliable indicators. Now I know this will provoke comments about address bar spoofs in the past – rest assured that we treat those as high priority security issues for the very reason that users should be able to trust the address bar content. However, I want to focus on security misconceptions here, so let’s get back on track… The page content is obviously controlled by the web site, so it is not a good basis for making a trust decision. What about the status bar text?

Here’s where things become a bit tricky, because status bar text is used both by IE and the web site. It is not necessarily obvious who is responsible for a given status message. To compound things: by providing the ability for web sites to have control over the status bar text, it becomes impossible for the browser itself to guarantee trustworthiness of the status bar’s messages. Sites can display arbitrary content in response to user interaction that by default would result in an IE status bar message: a user cannot tell whether a URL displayed in response to hovering over a link is generated by IE or by the web page.

In short, status bar text is not helpful in making trust decisions. Spoofing it or otherwise causing it to display false information doesn’t give rise to an actual security vulnerability, since the website hosting the status bar can pretty much make it behave the way it wants to.

So why did we make the status bar behave this way? And why wouldn’t we turn it off now? Fact is, that this functionality is used legitimately by a huge number of sites. Given that there are good ways of making trust decisions, it does not seem warranted to break all those sites.

What are the good ways of establishing trust? Always look at the address bar first. To be absolutely safe, check that the site certificate (double-click the lock icon) was issued to the site you think you are on before submitting any sensitive information. You can read more about protecting yourself against spoofing at http://www.microsoft.com/security/incident/spoof.mspx.

Hopefully this has clarified things. At the same time I urge you to report any potential security issues to secure@microsoft.com. I would much rather investigate 100 false positives than miss 1 real issue. You can read more about the Microsoft policy of working with and publicly acknowledging responsible reporters at http://www.microsoft.com/technet/security/bulletin/policy.mspx. For general security tips visit http://www.microsoft.com/protect.

To be continued …

– Patrick

Comments (82)

  1. Anonymous says:

    I would like to see both. I think it would be beneficial to find some way to split up the status bar so that I can see what the site wants me to see, as well was IE wants to me see. For example hovering over a link could display "Click here for our products" followed by a non-editable message of "http://www.example.com/products" so I know where I am going.

  2. Anonymous says:

    Simple enough to solve then – provide a double status bar. Either split it into two areas side by side (one for the site and one for the browser), or stack two on top of each other. It gives minimal loss of screen space, but I think the benefits would far outweigh that.

  3. Anonymous says:

    I agree with the above comments, although I’d say to only show the url when it points to an external site. Internal links I trust, because I trust the site I am on (using the address bar).

  4. Anonymous says:

    > In short, status bar text is not helpful in making trust decisions. Spoofing it or otherwise causing it to display false information doesn’t give rise to an actual security vulnerability, since the website hosting the status bar can pretty much make it behave the way it wants to.

    > To be absolutely safe, check that the site certificate (double-click the lock icon) was issued to the site you think you are on before submitting any sensitive information.

    Remind me again where the padlock is located? Oh right, on the status bar :).

    I know that there is a world of difference between the padlock icon and the status bar text, but do casual users? From the average person’s point of view, why should they trust the bit on the right of the status bar any more than the bit on the left of the status bar?

    Or, for that matter, why should they not trust information given to them by the browser – as opposed to the document itself? I dislike it when a browser lets documents take it over – the same applies to Mozilla’s XUL, status bar updates, and Internet Explorer’s CSS extensions letting sites control browser chrome. I think that if there was a clear boundary between browser and document, a lot of these spoofing issues wouldn’t be an issue.

    As things stand, browsers typically let untrusted information into an area that, by all rights, the user expects to be able to trust. That’s the fundamental security issue, and telling people that they can trust some parts of the browser but not others is an education issue – and education is rarely effective in fighting security holes.

    Firefox and Mozilla are better and worse in this regard. There are XUL spoofing bugs that give a pretty good impression of mimicking the default UI, but at the same time, they allow you to switch off things like status bar text being controlled by websites. Is there a registry entry that lets you do the same thing for Internet Explorer?

  5. Anonymous says:

    Just stop using IE. Case solve.

  6. Anonymous says:

    Newer versions of Firefox highlight the address bar in yellow for secure sites, this is a useful visual indicator, one more visible than a small padlock icon.

  7. Anonymous says:

    Jim hits the nail on the head…it should be obvious which bits are the browser, which you could say ‘I own’, and which bits the bad guys own.

    Microsoft talks about sandboxing code…well if we could see the ‘browser sandbox’ we would know what was inside (danger) and what was outside (safe).

  8. Anonymous says:

    I don’t see why a site needs to be able to control the status bar at all. Any information they wish to provide should be on the webpage itself. Has anyone got any legitimate examples of a website needing to control the status bar?

  9. Anonymous says:

    There is desire to control the status bar. That’s good enough.

    But it’s an easy thing to fix. Do two things.

    1) make the status bar have a visual cue to let the user know that it’s been set by javascript, rather than by hovering over something with an href.

    So, for example, if a user hovers over

    <a href="http://bad-site.example.com/"”>http://bad-site.example.com/" onhover="window.status=’https://good-site.example.com‘">…

    then the status bar should offer an indication that the fake "good-site" text in the status bar is, in fact, not the standard copy of the href.

    Possible visual cues:

    * change the status bar color

    * change the status bar font

    * put a prefix on the text ("status set by javascript: …")

    2) If a link has an onclick event, offer a visual cue to the user – this will help catch things like

    <a href="https://good-site.example.com/" onclick="location.href=’http://bad-site.example.com‘">…

    Possible visual cues:

    * beats me. I defer to the UI team.

  10. Anonymous says:

    Quote: "What are the good ways of establishing trust? Always look at the address bar first. To be absolutely safe, check that the site certificate (double-click the lock icon) was issued to the site you think you are on before submitting any sensitive information."

    I think you miss the point — an user needs to make a decision on if he/she needs to click on the link _BEFORE_ clicking on it.

  11. Anonymous says:

    Hmmm… reminds me of SpoofStick:

    http://www.corestreet.com/spoofstick/

    Not an all ends solution, but is useful at times.

  12. Anonymous says:

    > Has anyone got any legitimate examples of a website needing to control the status bar?

    Some people use redirector scripts to avoid people leaving comments merely to increase their Google Pagerank. In this case, the status bar text would read "http://www.example.com/redirector?someothersite&quot;, where a more friendly site would show the other site’s address in the status bar.

    It’s an edge case though, and I agree that it’s not a feature I want in a browser.

    > There is desire to control the status bar. That’s good enough.

    There is desire to install spyware and read your passwords. Just because people want to do something with your web browser, it doesn’t mean the web browser should let them do it. Letting untrusted information into what would normally be considered a trusted area is not something you can justify with "people want to do it, so let them".

  13. Anonymous says:

    If I might render a humble suggestion: You see that silly little ie logo in the bottom left of the page? It’d be nice if it changed color (or had some other visual indicator) that the page has drawn the status bar text – that way you have a totally unobtrusive visual indicator that it’s been changed.

    THe address bar is totally useless when it comes to determining if a LINK is pointing to a hostile (or otherwise undesirable) site – when I make the decision to click on a link is when I want to decide where its going – for that I only have the tooltip and the status bar.

  14. Anonymous says:

    The first step in determining if you trust the link you’re about click is "do I trust the page I’m currently on to not lead me to a bad place?"

    The address bar is somewhat useful for that.

    I think the link target via status text is nearly useless for determining if the link is trustworthy. The ability for the status text to be set by the website makes possible for bad sites to spoof the text to look like a good site. That’s only slightly worse than a bad site using a "good sounding but not really" URL as a target.

    IMO, changing color or other visual cues to indicate "that’s not IE, it’s the website text!" is appealing, although those kinds of changes tend to be obscure to some users ("why is the status bar sometimes one color and sometimes another?").

    We’re giving this whole area – UI elements for trust decisions – a lot of attention as we plan out the next IE.

  15. Anonymous says:

    Just to add my 2 cents in. I do a lot of Internet training for totally non technical end users. I think education can work and I think most of them don’t even look at the status bar. Most eyes are trained to look at the address bar. I would like to put a word in for not letting web sites change status bar content or getting rid of the status bar all together.

  16. Anonymous says:

    I think that the way Firefox handles it is quite effective. Seeing the domain that is secure is quite effective in determining that I’m on the right secure server. But it doesn’t highlight if I’m on the right insecure server or highlight the fact that a link may take me somewhere unexpected.

    The idea of some indicator that the status bar has been changed by the site, as suggested by Maurits, is an interesting idea. One, it would certainly get my attention as I may not actually be paying attention to it at the time.

    Although, I also agree that a web site isn’t made any more ‘useful’ by being able to access the status bar. Just because you ‘can’ doesn’t mean you ‘should’.

  17. Anonymous says:

    As another poster mentioned, the fact the SSL padlock is in the status bar makes users believe its a trusted authority. After all, pre-SP2, that padlock was the ONLY way to determine if SSL was being used.

    Personally, I’d like to see both the set status text and the original link target. Also, for the life of me, I can’t think of why you should be allowed to put any status bar message starting with "http:", "https:", "ftp:", etc in the status bar.

    From a UI perspective, personally I’d say ditch the status bar and put that info elsewhere – Its been a decade now, and my eyes still aren’t used to look at the 2 pixels on the very bottom of my monitor for useful information, when everything else is up top.

  18. Anonymous says:

    Amazing how all these people missed the one other way to tell where a link is going (one I use if I’m in doubt). Right click on the link and select properties, it will show the actual href destination

  19. Anonymous says:

    When the status bar text is set by a JavaScript in an onhover or onblur event, place an icon next to the text indicating that it is not the default. When the status bar is overridden, a tool tip should appear that contains the actual href.

  20. Anonymous says:

    A lot of people above are drawing attention to the excellent anti-spoofing work that Mozilla have put into Firefox, and to be honest it’s one area where regardless of biased advocacy, people do seem to agree that they’ve done a good job.

    — They’ve also disallowed changing status bar text by default, of course.

    In some respect, since the next few years are going to see a rise in alternate browser usage until Longhorn hits and people re-evaluate IE, why not use that to change the IE behaviour? Any site that wants to remain fully functional in Firefox will have to stop using the status bar and replace it with something else. Since this is likely to be the base, there’s far less need for IE to continue to support this confusing feature.

    It’s a common feeling I think, that a web page has no business telling the user how their browser should look. It’s been a criticism of IE’s scrollbar CSS and also stands for the status bar. When malicious people are trying harder and harder to confuse the user into their traps, the distinction between browser and web page needs to be drawn much thicker than it already is.

    I think colour indications are a good start (and provides clearer distinction outside of the sites control in Firefox), but visual indicators are not enough in a situation where the web page can also insert content – i.e. the status bar.

    Sure, you could make "Browser messages" yellow and not "web page messages", but users wouldn’t appreciate the difference. They’d still an address (probably an address they were expected, too) and carry on. Text indication will be spoofed itself, if not exactly then close enough to trick people. I think the only clear way is to make it clear – the chrome is not for sale. The browser belongs to the user, not the page and that needs to be enforced. By all means allow it to be enabled again in "trusted zones" where longer term Intranet applications might still depend on it, but on the open Internet it should be locked down on principal.

    … and as an added bonus, it would dispose of that bloody scrolling status bar text some sites insist on 😉

  21. Anonymous says:

    Absolutely safe by double-clicking the lock icon? Well, you can spoof the whole status bar – including this icon, and the certificate window – in any non-XPSP2 IE. Not _that_ trustworthy.

  22. Anonymous says:

    > In some respect, since the next few years are going to see a rise in alternate browser usage until Longhorn hits and people re-evaluate IE, why not use that to change the IE behaviour?

    What I would like to see is the Internet Explorer developers post a list of things that they think are likely to be "unsafe" for web developers to rely upon. It needn’t be very accurate, but it would alleviate some of the pressure they seem to feel they are under to preserve absolutely every behaviour no matter how absurd.

    For instance, if they wanted to fix up HTTP support but felt too many people relied on the incorrect behaviour, one of the items on the list might be "Relying on a browser to override the server-supplied media type is unsafe as we might want to conform to the HTTP specification in future. Make sure you are transmitting the correct Content-Type header and you will be safe from this possible future change breaking anything."

    Such a list can be overly-cautious – throw hundreds of things on there that Internet Explorer works around that it might not in future, and even if they don’t get around to implementing that, it won’t matter as they will still be more free to make those changes in subsequent versions.

    The trouble is, they are now feeling the burden other browser developers have felt in the past when trying to emulate Internet Explorer’s behaviour in the name of interoperability. They not only need to develop a web browser, but they also need to cater to the myriad ways in which somebody writes bad code and expects it to work. They have a head-start of course – Internet Explorer’s current code base already deals with lots of these issues – but preserving this behaviour must be difficult. It would be a lot easier if they could simply say "look, non-standard things are likely to break, standard things are less likely to break, and it’s your job to deal with that and we’ll do the best we can, but you should plan accordingly."

    Random web developers telling people that relying on non-standard behaviour doesn’t carry a lot of weight, even when Microsoft’s actions subsequently vindicate them by breaking non-standard stuff. Microsoft themselves saying so might be a bit more convincing.

    Things like unsolicited popups and changing the status bar text would fall into this category. You say to yourselves "hey, this isn’t a good idea, but a lot of people are expecting it to work". Then you say to everyone "hey, this isn’t a good idea, we might change this in future", everyone gets a chance to find alternative methods to do what they want, and then you are more free to actually build the browser you want.

    As an example, virtually every use of window.status I have seen has been either illegitimate, utterly useless gimmickry, or better accomplished by alternative means – e.g. supplementary information about a link belongs in the title attribute, not hidden down somewhere that I’m not expecting it, which is usually used for other purposes.

    If Microsoft actually came out and said "look, it’s not a good idea to let websites alter the status bar, so this functionality might be restricted in Longhorn", then the people who this mattered to would pay attention and fix their sites accordingly.

  23. Anonymous says:

    > What I would like to see is the Internet Explorer developers post a list of things

    > that they think are likely to be "unsafe" for web developers to rely upon. It needn’t

    > be very accurate, but it would alleviate some of the pressure they seem to feel they

    > are under to preserve absolutely every behaviour no matter how absurd.

    Jim, we did a lot of that sort of thing before we released XPSP2, and I expect we’ll do the same in the future. I wouldn’t say we feel pressure to "preserve absolutely every behavior no matter how absurd"; instead I think we feel a responsibility to maintain compatibility and today’s functionality. The often misunderstood Compatiblity post (http://blogs.msdn.com/ie/archive/2004/10/15/243074.aspx) expressed our position.

    Even if IE disabled window.status from doing anything, it’s trivial to get the status bar to display the "wrong" target of a link via other methods. Simply use an onclick or similar handler on the anchor tag. This "spoof" will work in browsers like Firefox that don’t respond to window.status. So we could disallow event handlers like that on anchor tag and deal with compatibility issues of that decision.

    Again, I believe that if you can’t trust the page, you can’t trust the links on the page. Even in browsers that don’t let the page set the status bar text.

  24. Anonymous says:

    Patrick Mann: "I’m a security tester on the IE team." [via Scripting News]…

  25. Anonymous says:

    I agree with Bruce. If you don’t trust the page to begin with, then why are you worried about the damn status bar?

    James Summerlin

  26. Anonymous says:

    Apple fixed a URL spoofing vulnerability in Safari with this release. (The URL shown in the status bar when you click on a link was not necessarily where you were going to be taken)

    Just today, a MSFT IE secutity tester posted an entry on the IE Blog that dismisses the vulnerabilty. He feels that allowing web sites to display arbitrary text on the status bar is a feature and that users need to learn that they can only trust the address bar URL field, and the lock icon in the status bar. IE users need to know that "the status bar text is not helpful in making trust decisions."

    I’m amazed that is the mindset of an security tester and even more amazed that he feels comfortable posting that viewpoint publicly on the IE blog. No wonder they have so many security problems!

    Here is the link to the blog:

    http://blogs.msdn.com/ie/archive/2004/12/03/274330 .aspx

  27. Anonymous says:

    "So why did we make the status bar behave this way? And why wouldn’t we turn it off now? Fact is, that this functionality is used legitimately by a huge number of sites."

    A huge number? Can you give me a list of 100? Will all those 100 sites become unusable if you switched the status bar off? Will all the 100 owners of those sites go bankrupt?

    Allowing sites to mix custom messages with legitimate system messages is one of the most confusing things you can subject your users to. Don’t you think a little more motivation is needed for sustaining this behaviour?

  28. Anonymous says:

    "Again, I believe that if you can’t trust the page, you can’t trust the links on the page. Even in browsers that don’t let the page set the status bar text."

    I agree. The real problem is figuring out how to help users know what to trust, which is a decidedly harder problem. Someone does a google search while looking for info on industrial meat packing for a term paper; they see a site that looks like it has the info they need, so they visit it. It’s got a bunch of ads, some pop-ups, but seems to have reasonably good information. Who serves the ads? Are they legit even if the site itself is? Do you trust its links to be accurate? Trust is much less black and white. Particularly if you offer value for the user; it’s much easier to get people to throw their security out the window if they think there’s something in it for them.

  29. Anonymous says:

    So, when a user see’s a link, how is he expected to know that he can trust that the destination will not wreck havoc with his operating system, again? The address bar is not an indicator of the destination of the link. And the status bar cannot be trusted in IE. Does the user have to go through a "Right-click-Properties" to know if the link can be trusted?

    Isn’t the status bar meant exactly for purposes like this?

    By letting sites alter the status-bar, isn’t a bad browser even making users lose trust in the Internet itself, making the Net seem almost hostile sometimes, especially considering the integration of IE with Windows?

    Is there ONE example of a site that absolutely cannot do without displaying a status bar message, as opposed to, say, a tooltip?

    Again, what is IE’s prority here? Supporting old outdated non-standards code that cannot possibly be very useful, though in the wrong hands can be a leathal tool? Or is the priority to make a good user-friendly trust-worthy browser that tries to do something about the tarnished image IE has been acquiring lately?

  30. Anonymous says:

    Users should be able to trust their browsers implicitly. Period.

    If there is a feature that causes this trust to slip it should be reworked or removed. And no, it doesn’t matter what you or anyone else on the Internet Explorer team thinks for that matter. It doesn’t matter what I think. It doesn’t matter what most of the people replying to this topic think. If there’s one user out there who isn’t sure what page they’re on, or from whom it originated, there’s a problem.

  31. Anonymous says:

    Rakesh, you simply can’t trust that target of a link is what’s shown in the address bar.

    Even if window.status is disabled (as it is in browsers such as Firefox), it’s trivial to have the wrong target URL show in the status text. Simply use an onclick handler to redirect the target of an anchor tag.

  32. Anonymous says:

    Sorry, I meant "status bar" when I said address bar above. Doh.

  33. Anonymous says:

    Bruce: "Even if window.status is disabled (as it is in browsers such as Firefox), it’s trivial to have the wrong target URL show in the status text"

    And that’s an excuse to confuse the user on purpose? I say on purpose, because the default behaviour of showing the target url tricks the user into thinking that he can use the status bar as a source of trusted information.

    Is it that hard to show the target url unless there’s an onclick-handler? Would be a good way for a ‘honest’ site to earn trust. (Look, our links are simple, transparent links, no hidden tricks!)

    We are still waiting for the sites that absolutely need this window.status. I’m really curious, I use Opera myself and I switched the status bar off because I thougth it was a useless waste of real estate. I never missed it.

  34. Anonymous says:

    Oh, and for the people that are wondering, Opera shows the target url in a tooltip. Which is nice, because in most cases you are looking at your mouse pointer anyway.

  35. Anonymous says:

    Marcus,

    <quote>

    Absolutely safe by double-clicking the lock icon? Well, you can spoof the whole status bar – including this icon, and the certificate window – in any non-XPSP2 IE. Not _that_ trustworthy.

    </quote>

    Any evidence to back this up?

  36. Anonymous says:

    > Even if window.status is disabled (as it is in browsers such as Firefox), it’s trivial to have the wrong target URL show in the status text. Simply use an onclick handler to redirect the target of an anchor tag.

    Are there any situations in which displaying "[Javascript link]" (or the equivalent javascript: URL) for links with onclick handlers would be incorrect behaviour? It seems a lot better than displaying an incorrect URL.

  37. Anonymous says:

    Jim, there are more ways to redirect the target of a link than a handler on the link itself. For example, you could use a body onunload handler to reset the location.href.

  38. Anonymous says:

    So? That means you have to check for an onclick handler and an unonload handler.

    It can’t be that hard. If it was, that would mean that you are writing a browser that has no clue about what to do after I click somewhere on a page. I find that difficult to believe.

  39. Anonymous says:

    > For example, you could use a body onunload handler to reset the location.href.

    I hadn’t thought of that, mostly because I assumed that was one of the things browsers didn’t let you do – browsers won’t _read_ the new location.href in a body onunload handler, so it seems odd that they would be allowed to _write_ it.

    > It can’t be that hard. If it was, that would mean that you are writing a browser that has no clue about what to do after I click somewhere on a page.

    Not necessarily, remember that the browser would have to evaluate the onunload handler. So, for example, if you had an onunload handler that used the xmlhttprequest object to send a request to the server before deciding what to do, the browser would have to send that request simply to determine whether outgoing links should be displayed. That changes the semantics in a significant way, as the onunload event would appear to be triggered on page load.

  40. Anonymous says:

    In any case, is there any merit in the attitude of "we can’t fix [x], so we might as well leave [y] and [z] wide open too"?

  41. Anonymous says:

    > Not necessarily, remember that the browser would have to evaluate the onunload handler.

    I meant something simpler. I did not propose to execute al the scripting to find out where the request eventually would go, but to just evaluate whether the href attribute in the a tag is going to be used directly or not.

    Show the target url on a plain link, show "[ javascript ]" or something more userfriendly when scripts are going to be executed.

    This would work on both sites. Users get more information that they really can trust. Webdevelopers are encouraged to build sites in a transparent, straightforward way.

  42. Anonymous says:

    work on both siDes!

    English is not my native language, as you all probabely had guessed by now.

  43. Anonymous says:

    Is thinking that deleting the text of a password control provides security (when in fact undo will continue to work) an example of what you’re talking about? People with the wrong expectations – a security issue that isn’t?

    Thinking your data is gone when you can’t see it is no worse than trusting an untrustworthy part of the interface. Is Microsoft’s line on this that people should know better, so you won’t help avoid the situation?

    How can I prevent web pages from using JavaScript to set the status bar text? As a user, am I able to make the decision that I want to be secure more than I want to see whatever junk the site wants to display, as I can with other browsers? If there is an option – or even a registry setting – that does just this without disabling JS completely, why didn’t you mention it in the article?

    I was reminded of this entry when I read that the Mozilla "bug" about the password issue (271154) was fixed yesterday. To me, it seems legitimate: *I* know people should close all browser windows when they’re done, but most users don’t, in the same way that they trust the bar that has the lock icon on it – they’re supposed to trust the padlock!

    I like having a browser where things like this are thought about and the security of the majority if users is considered more important than testing whether copy and paste still works for some BHO that assumes things about desktop integration under Win95 😛

    I’m confident that other browser developers would do much better than you if they had as much ‘help’ as you guys have had identifying your security holes and weak architecture (that’s what you said you improved with XP SP2, right?). Meanwhile, I’m fairly glad they don’t receive the attention.

  44. Anonymous says:

    Security Issues That ARE:

    Currently Internet Exploiter has 18 not fixed security holes, including 4 HIGHLY critical holes. The oldest holes is from March 2003.

    One of the holes is actually "a feature", which is spying IE users and sending "secure" informations like passwords to microsoft.com ( http://secunia.com/advisories/8955/ )

    Source of information: secunia.com

  45. Anonymous says:

    Internet Exploder 6 had 70 secuity vulnerabilities, 18 of them are not fixed, though some of them are veeery old. 15% of all vulnerabilities were extremely criticala and 30% were highly critical, making Internet Exploiter one of the most dangerous software on the world.

    If you had viruses, spyware, dialers, worms etc, it probably came through one of the IE holes.

  46. Anonymous says:

    Changing the status bar text is more pertinent to web based applications than the general internet. In such cases it can serve the same helpful purpose as in standard desktop applications.

    It seems to me that such features are acceptable in trusted environments (i.e. within an intranet, using an online banking site, etc) but not acceptable in an untrusted environment (i.e. the rest of the public internet).

    As IE supports different zones for security, you should be able to specify what javascript can and cannot do within the relevant security zone.

  47. Anonymous says:

    From the perspective of someone who has worked in Tech support for Gateway, the University of Alabama, and now doing work for a local free clinic – this whole argument is a bit dispiriting.

    Almost every week I see someone’s computer who has been taken advantage of by the current state of the Internet. In fact, I just recieved parts today to overhaul my grandfather’s computer – which has been rendered inoperable by spyware and malware. (It will need a formatting, so might as well do some upgrading while everythings torn apart 😉 )

    Now – it is from this perspective that I offer this report from ‘The Front’. It sucks. Big time. And one more newsflash — Its not all Internet Explorer’s fault.

    We have collectively done a horrible job in educating the average consumer about the technology that they are investing in so heavily. BTW, the investment I am speaking of includes both money, and time and aggrivation spent trying to maintain system usability.

    This being said – this debate on ‘status bar text’ is a bit like trudging into headquarters from the warfield to find out the top-generals are busy bogged down with what color to paint the military jeeps, so that people can tell them apart from their civilian counterparts.

    PEOPLE!

    The security problems we should be discussing are how to keep Internet Explorer from being a distribution point for everything ‘bad’ out there.

    To be quite blunt – who cares about "Security problems that aren’t" – we have too many security problems that ARE to be worried about.

    To any and all IE developers: I stated above that the current shape of the internet is not entirely the fault of IE, and I stand by that. However, it IS your fault for not being able to respond in the face of worsening conditions. SP2 is no response, because it leaves *many, many* users locked out who don’t use XP. Also, what about the users (and I have encountered many) who have rather cheap dial-up plans that connect at approx. 20-30k? No downloads for them of SP2’s size. Sure, they could order a cd for it, but most dont even know what a Service Pack is, much less how to get one off of a website.

    If you really want to improve how secure things are, try putting updates on cd’s and distributing them in supermarkets right beside all of those round, silver AOL abominations. You do it in Europe. Why not the United States?

    All this talk of an update to IE in Longhorn is also troubling. That update is quite awhile away. Anything in the meantime?

    You know – there are alot of people that work hard to try to carry your banner in the face of competition from new technologies like Firefox, but you are making it increasingly difficult to continue without being a detriment to the very people who IE-supporters are attempting to assist.

    My roomates grandmother, for instance, had a computer with Mozilla on it. Over Thanksgiving, one of the relatives announced that he was putting things back the way they were ‘supposed to be’ and restored IE and Outlook as their primary outlet to the internet. Now their computer is unusable. The first thing it does upon boot is fire up dial-up networking (why can adware do this, anyway)and connect to the internet. Once on the internet, the computer gets slower and slower until it finally locks up the computer entirely.

    General Patrick – these are your people, your customers, your grandmothers, aunts and uncles – all being taken advantage of by an increasingly hostile internet through your technology, with your blessing. Can’t you do something more constructive than talk about status bars?

  48. Anonymous says:

    Speaking of Secunia and Internet Explorer security, the following item on window injection seemed pertinant.

    http://secunia.com/advisories/13402/

  49. Anonymous says:

    > This being said – this debate on ‘status bar text’ is a bit like trudging into headquarters from the warfield to find out the top-generals are busy bogged down with what color to paint the military jeeps, so that people can tell them apart from their civilian counterparts.

    Hehe, you have a point, but I suggest you forget it.

    Even for this minor issue the people of the IE team can’t be bothered to explain things a bit, or to give us statistics or examples.

    I don’t think they are ready to handle outside world input for any of the real security issues. Off course things can’t be changed! A huge number of businesses depend on current behaviour, changing things would bankrupt all of them!

  50. Anonymous says:

    The bottom line here is that most users are uneducated and will remain so. Our industry has worked very diligently to bridge the ‘digital divide’ and introduce computers into every business and household. People expect computers to work as easily as any other appliance, even if that’s not realistic.

    <em> It is the duty of the developers to design a trustworthy UI — and that means that it should never be unclear whether it is the browser or the web page that is in control. </em>

    As people have pointed out, there are many ways to spoof the UI, and not all of them depend on IE’s design in order to work. Ok, then, perhaps it is time to reassess the DHTML object model in terms of security and draft a new version that rules out access to objects (such as the status bar) that an untrusted web page should NEVER have access to.

  51. Anonymous says:

    Of course, "window.status" isn’t actually part of the DOM specification.

    Perhaps we have here a good case for focusing on conformity to the standards, which have been subject to much scrutiny and debate during their development, rather than adding extensions willy nilly.

    At the very least, perhaps those extensions which go beyond the DOM (e.g. control of the browser UI) should be clearly controlled within the browser settings so they can be limited to trusted sites only.

  52. Anonymous says:

    An example of a security problem that ‘is’ (from OddTodd.com)…

    "Spyware used to be an annoyance. A sneaky mosquito. Something that piggybacked on other programs and served popups and cr*p. A bit of a pain to uninstall but nothing major. But recently I noticed spyware has gotten downright vicious. And heartless. Just this morning I was poking around the web looking for a Daily Fun Link and I stumbled across some game site. It informed me that I needed to install some cr*p program or whatever to ‘view the content’. I clicked the ‘X’ in the box to close the window and I saw a flash of a toolbar install on my machine. Uch! I felt it and it made me shiver. It didn’t ask. It didn’t need my approval. It just went. My cr*p ZoneAlarm firewall sat there like a dope and did nothing. Internet Explorer is like a spaghetti strainer with this cr*p now. I felt like someone just sneezed all over the back of my neck in the movies.

    So I busted out AdAware and HijackThis (spyware removal stuff. good programs.). But this time round neither AdAware nor HijackThis was able to clear off this new cr*p. So I had to go online to research. I was already annoyed that I had to do stuff and doubley so because my browser now had a new filthy unwanted toolbar installed and my google toolbar was gone. Every search came along with a redirect to their own garbage dump sites. AND to add insult to injury I was pummeled with ads for spyware removal programs."

  53. Anonymous says:

    I’ve done some thinking about the case where href=goodsite but there’s an onclick or an onunload or an onmousedown or other javascript chicanery that then sets location.href = badsite

    It seems to me that this is a much larger issue than just status-bar-obfuscation – if a site can use javascript, then a simple onmouseover on the body could send the user anywhere the site wants.

    This seems to be particularly dangerous.

    I’d like to suggest the following algorithm in response to any attempt to set location.href…

    * If the new href is on the same site, fine, allow it

    * If the current href is running in a Local or Trusted zone, fine, allow it

    * If the current href is running in a Restricted Zone, javascript is probably turned off

    * If the current href is running in the Internet Zone, prompt the user:

    "Site is redirecting to (real URL) … is this OK?" and allow a (OK/Cancel/Always OK [for this site])

  54. Anonymous says:

    On the other hand a <meta http-equiv="refresh"> tag could accomplish the same thing so maybe it’s a lost cause

  55. Anonymous says:

    Mary,

    How many of those secunia "unpatched" vulnerabilities are fixed in SP2? I know that the one you quoted explicitly (the "phone home" vulnerability, which really isn’t a vulnerability).

    About that last one: The only way that it works is if you enable search, then use the find related tag. It’s a potential privacy issue (and a significant one, don’t get me wrong), but it’s not a mainstream item. From reading the alert, it looks like turning off the "phone home" portion of find related doesn’t turn it off until you restart IE.

  56. Anonymous says:

    I’m not going to spend my money on XP (nor on Longhorn). It’s skinned Windows 2000 with a few enhancements and 2x larger hardware requirements.

  57. Anonymous says:

    The issue arises because peeps are led to the false site, invariably by an email. These peeps are suckers. If one choses the url of the site one visits, the issue doesn’t arise. The obvious answer of not responding to phishing emails won’t occur to a sucker, so there’s little one can do to help them.

  58. Anonymous says:

    Mary,

    XP’s a heck of a lot more than just a skinned Win2K (and the hardware reqs aren’t significantly different).

    And XP SP2’s a heck of a lot more than just a recompilation of XP.

    But you’ve made up your mind, and you’re not going to be swayed by any logic.

  59. Anonymous says:

    I see a new IE problem every week on isc.sans.org…

    It’s rediculous.

    http://toadstool.se/journal/images/friends-dont-let-friends-use-ie.jpg

  60. Anonymous says:

    "About that last one: The only way that it works is if you enable search, then use the find related tag. It’s a potential privacy issue (and a significant one, don’t get me wrong), but it’s not a mainstream item. From reading the alert, it looks like turning off the "phone home" portion of find related doesn’t turn it off until you restart IE."

    If it’s only a bug in the IE, why Microsoft didn’t fix it? How can we trust them??? So called "Secure" personal informations are send to msn.com FFS!

  61. Anonymous says:

    @#$@#$ My response got lost…

    Mary, they DID fix it. The Secunia advisory clearly said that it was fixed in XP SP2.

  62. Anonymous says:

    Larry: In fairness to Mary, when she made her post on 12/6, the Secunia advisory at http://secunia.com/advisories/8955/ didn’t have the "fixed in XPSP2" part. That page said it had last been updated on 2003-06-09, long before the release of SP2.

    When I read her post and then followed the link, I said "hey, we fixed that in SP2 by removing Alexa" and set in motion a chain of events that seems to have led to Secunia updating that page.

  63. Anonymous says:

    Bruce: Fair ‘nuf – I didn’t chase down the comment history… My apologies.

  64. Anonymous says:

    Monetary and ownership issues asside…

    Bruce, do you think IE could be made better if you let the web development community look at and fix the buggy IE code? Don’t you guys want to appeal to coders? Coders won’t be satisfied unless they can see the inner-workings of the browser. You won’t have a browser that coders will choose unless their input can be directly addressed citing the faulty code, character for character.

    I’m not asking for an open-source IE, I’m asking for an Public Beta.

  65. Anonymous says:

    Hi Fiery,

    Public betas are something we’ve undertaken on the Internet Explorer team in the past for every major release and also earlier this year with Windows XP SP2. I’d fully expect us to have public betas of future versions as well. We certainly want everyone to take a look at the betas and previews we make available and give us feedback. While we clearly can’t promise to address every issue we do look at all the feedback that comes in during a beta and feedback early in a beta is obviously better.

    Thanks

    -Dave

  66. Anonymous says:

    Are you expecting us to drill you guys hard as soon as the first IE7 builds are released and/or leaked?

    BTW, what is the build number for IE in the current Longhorn alphas?

  67. Anonymous says:

    The issue isn’t about spoofing when you have javascript disabled, any web savvy websurfer is fully aware that you can’t trust the status bar under those circumstances, and it’s definantly a nice feature under various circumstances.

    Recent exploits allow you to change status bar text even when scripting is disabled, as well as hijack windows from trusted sites in order to collect sensitive information. SP2 didn’t fix these bugs, which get around user preferences that explicitly turn features off. That’s the security issue, not if making javascript status bar text with javascript is a problem.

    I realize there’s a big muggy divide between microsoft and users, but making it clear to us what you’re working on and are fixing would help a lot. Right now us web site developers and admins are in the dark, so we have to speculate wildly and it doesn’t always turn out very well.

  68. Anonymous says:

    I’m probably too late in this thread to get read <sigh>. Ah well.

    I’ve found with XP that the Status bar often disappears. In my knowledge I’ve never turned it off, but for some reason, some days: "bing" it’s gone.

    Very odd behaviour. Is this intentional or a bug?

    When it comes to spoofing status bars, my preferred method would be to pop a window without one, and show a simple image at the bottom of the web page imitating the status bar – complete with security padlock. Not hard.

    The padlock is a misnomer anyway. We believe it means something when it does not. It means we have a secure connection – and should mean that the site is ‘trusted’. However, many certificate authorities are quite liberal with their distribution.

    I doubt there’s much you can do about the security lock Patrick, because as soon as you move it, you’ll spook us and we’ll complain – but if I were starting from scratch, I’d keep the status bar for messages and download progress, and move the security stuff to the top left close button, which as far as I know is always visible (except for full-screen mode and Modal/Modeless Dialogs which frankly are still a massive security hazard).

  69. Anonymous says:

    IE supports the wrong things and doesn’t support the right things. Time for Firefox.

  70. Anonymous says:

    I tried to think of one valid and useful use of the status bar by a website and could not.

    The fact that you can’t trust it almost implicitly makes it useless. Savvy users ignore it, and casual users are mislead by it.

    Disable the ability of websites to manipulate the content of the status bar.

    Simple problem, simple solution.

  71. Anonymous says:

    Opera shows link address and title as a tooltip, and precedes text with its source:

    [Title: good-site.com ]

    [Address: bad-site.com ]

    As you said, statusbar is wrong thing and bad for security, that’s why good and secure browser has it invisible and additionally blocked from js by default.

  72. Anonymous says:

    I not real sure what the author of this post is rambling about anyhow. I am sure everyone by now has went here (http://secunia.com/internet_explorer_cross-site_scripting_vulnerability_test/) where not only is the address bar and status bar spoofed, but so is your happy little padlock. I have been extremely adament at not removing IE from my machines, but after seeing this, I have now. And this works in XP SP2 and the current build of Windows 2003 SP1. Where is my next version of IE? This plug and patch mentality of continually rewriting 3 lines of ie at a time is *obviously* not working. You call yourselved the IE team? I call you a disgrace.

  73. Anonymous says:

    Very interesting discussion. I’ll try to squeeze in 2 more cents:

    In Windows, a lot of applications are configurable via Group Policies. Some policies overlap with options available to the end user via a "Options" dialog and enforce specific options, others are not available for end-users. In both cases, administrators can enforce specific settings.

    Why not ship Internet Explorer with a few extra policies, available only to sysadmins, to control the behaviours discussed above?

    For end-users, you would ship a very locked-down version of IE, not allowing web sites to control the status bar, for example. Most end users won’t go into Group Policy to make their IE more insecure than it already is.

    Document the feature; if you have corporate intranet apps that rely on insecure features, allow sysadmins to change the policies at their own risk (you could make the settings apply at zone level, so that they would not make accessing Internet sites less secure). This way, you make the bulk mass of end users happy and keep the big customers happy as well.

  74. Anonymous says:

    You live in Chicago, you go to LA for week.

    You need some cash, so you go the ATM machine. You put your card in, you punch some numbers…

    How do you kow that you just stuck your card and password in a real ATM, and not a spoof?

    You dont, and most people would go someplace just by habit to where they are more than certain that the machine is real, and they are safe.

    Its a browser. Nothing more, nothing less. Its written by man, its flawed. It always will be. Each person still has the responsiblity to make sure that they are not in a bad neighborhood.

    Yes its easy to spoof your bank and the like – but how did you get to a site that spoofed it? (short of ebay that is – that site, regardless of browser is a disaster waiting to happen, they still to this day do nothing to stop a person from loading external javascript into the page)

    Personally – The only thing different I would like to see is a shared system setup, that updates like antivirus to the browsers. Put a filter on front of the browser, and filter out most of the garbage that way – and also be able to alert the user that they are on known domain/IP for BS. (There would be no privacy issues as it would not have to transmit back where you are – though users would need to be able to send in bad locations voluntarily).

    Something like that, fully developed and expanded upon could stop all this garbage in its tracks.

    The last thing I have to say is people need to quit transfering the blame. Microsoft is just as much of a victim in this as you are. Maybe they didnt do their part 100% in providng the most secure browser, you also did not do your part 100% as you got to where ever you got however you got there, and did not verify your location before entering sensitive data. But neither you nor the company that makes the software you use is to blame. The people behind the exploit – they are the problem. If the Microsoft haters would spend just a tenth less energy hating Microsoft and instead devoted that to figuring out how to stop the bad guys – I am sure that in a week and a half that much energy would solve the problem, and probably find the answer for world peace and figure out a way for the Cubs to win the World Series.

  75. Anonymous says:

    Comments like the one above annoy me because they are delivered, smugly, as gospel — or sermon on the mount. Drop the attitude and maybe I can get through your post, Zach.