Paid Advertising
web application security lab

IE6.0 Protocol Guessing

SirDarckCat sent an interesting email this morning about IE6.0. Apparently it attempts to guess what you mean in certain circumstances allowing for rigid anti-XSS filters to fail when looking for precise terms like javascript: and vbscript: even after attempting to de-obfuscate. Rather than attempt to explain, take a look at this snippet from his email:

There are some characteristics in internet explorer that could aid
attackers when doing XSS attacks.

In IExplorer:




are translated to vbscript:
so, for example:




will be treated as:


and anything with:


will be treated as:




will be treated as:


I have not been able to test this myself as I don’t have 6.0 handy. However, if it works, I know a log of anti-XSS filters that would fail on this one. It’s a bad one, but anyone worried about it should simply upgrade to 7.0 which doesn’t appear to have this flaw in it. Very nice find by SirDarckCat.

20 Responses to “IE6.0 Protocol Guessing”

  1. yawnmoth Says:


    <a href=”testscript:alert(’test’)”>test</a>

    Neither work for me.

    Incidentally, you can have multiple versions of IE on the same machine:

  2. TarraDog52 Says:

    We use IE6 at work so I decided to test some scenarios by adding code to the address bar and hitting enter:



    Works as described by SirDarckCat

  3. sirdarckcat Says:


    There is one more vector I forgot:


    also translates to:



  4. Awesome AnDrEw Says:

    That’s pretty interesting, rsnake. Unfortunately (well not truly) I’m using Internet Explorer 7, and so it obviously does not work for me, but it’s an awesome concept.

  5. BK Says:

    I played around with this a while back, it’s really interesting. I’m certain that most versions of IE support this, but I could only get it to work when the values were entered directly into the address bar. I’m sure this will prove to be useful in the future, especially once I understand exactly what circumstances warrant a “spelling correction” on IE’s part.

  6. Spikeman Says:

    For me this only works when typed in the address bar. Also, it doesn’t work in IE tab.

  7. nitro2k01 Says:

    Test here too on IE6, with the same result as Spikeman. (Only works in address bar)
    I also tried using invalid language names in the script language=”…” which didn’t work either. However something I did during my experiments made IE6 quit spontaneously. (No error, no crash, just a sudden quit) However, I can’t reproduce it now.

  8. Wladimir Palant Says:

    Yes, this is not a security issue. This substitution only happens in the address bar and you actually see it make “javascript” out of “testscript”. So this is a feature of the user interface but not one of the rendering engine, web pages cannot trigger it.

  9. nitro2k01 Says:

    However (to almost contradict myself) it might still be a vulnerability. What if there’s some obscure way that page can actually trig this mechanism due to some bug? For example I remember bugs concerning IE’s infamous “Local zone” where untrusted scripts could get trusted access by an intricate bombing local zone protocols (file: and other protocols relating to help files and dll file resource extraction; I could possibly find the source doc about that vulnerability if you wish)

  10. Sergey Vzloman Says:

    few years ago i found such soutions. inside jscript.dll is defined some of “magic” script protocols:


  11. Anonymous Says:

    Is there is someone still using IE 6????
    I havent see one in a couple of months…

    Many old users now uses firefox or opera (many that still using 98se and windows me)

  12. Yodasan Says:

    So, I have IE6 and the following also worked:

    javascripx:alert(’hi’); became javascript:alert(’hi’);


    xtp:// became ftp://

    So, this seems to be something that works on all registered protocols. I tried others, as well ..

    xboxt:// became about://
    but xboxx:// did not become about://, so it seems to be that if greater than 50% of the letters exist and it’s the same length, then it renders it.

    A full list of protocols that are installed on a machine can be found at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\Handler, i think.

  13. Nemessis Says:

    Actually this is also known as ECMAScript ( and to be honest is useless in my oppinion if you want to use it in another way that putting manually in your browser address bar. If this kind of scripting cannot be used in another way, there should not be any concern about the filters bypass.

  14. h3xStream Says:

    httpscript: … that have potential because some site might filter link starting with “http” (should be “http://”)

  15. RSnake Says:

    Nice one… I’m still trying to figure out how this could actually be used in a vulnerability, other than perhaps telling someone to type in or cut and paste something that looks like a URL but is really JS… Seems like a stretch.

  16. Kyo Says:

    Wow, it works.
    Intresting nobody has ever found this before.
    This sure is a big issue.

  17. Kyo Says:

    Hey, here’s another thing:
    works as well. This is actually more of an issue as it doesn’t contain the word “script”.

  18. nitro2k01 Says:

    Well, no it’s a BIG thing. It can’t empasized enough that this bug/feature ONLY affects things written in the address field can be interpreted in this way. (Not anything invoked by links or javascript as far as anyone knows today)
    So it’s really a minor vulnerability since you have to trick the user into copying a string to the address field.

  19. nitro2k01 Says:

    I mean, It’s NOT, of course.

  20. Ray Says:

    This code works on IE7