The IE Patch (MS04-004) demystified


Many people have asked what the scoop is on the recent IE update– and why did Microsoft disable passwords over HTTP? First, the change only affects URLs of the type:



http://username:password@www.microsoft.com


Now, one thing many people are not aware of, is this format is not a supported URL format, as per the RFC 1738:



3.3. HTTP

   The HTTP URL scheme is used to designate Internet resources
   accessible using HTTP (HyperText Transfer Protocol).

   The HTTP protocol is specified elsewhere. This specification only
   describes the syntax of HTTP URLs.

   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>


In fact, in my very first book, “Designing Secure Web-Based Applications for Microsoft Windows 2000“ I made a comment about the username:pwd format:



Please also note that this method has been tested in Internet Explorer 5 and Netscape Navigator 4.7, but that there’s no guarantee it will work in any other browser.


Next, the change in MS04-004, does not affect people building apps that embed an identifier in the querystring. And finally, it does not affect the FTP case, where username:pwd is totally valid.


You should also read the KB article about this, as it includes a registry key if you wish to enable the username:pwd format for HTTP.


 

Comments (28)

  1. Dana Epp's ramblings at the Sanctuary says:

    Michael has written a post demystifying what went into the latest IE patch. He also pointed out Microsoft’s on the subject, with a registry setting to renable this "feature". Interesting to note that in his first book entitled "Designing Secure Web-Based Applications for Microsoft Windows 2000", he even talked about the fact that developers should not rely on this functionality. Guess those scambling to deal with a work around to the fix should have listened more closely. More interesting is the fact he points to the exact reference in which the RFC specs do NOT support this hacked format… which means Microsoft was right in removing it. (Although they should never have had it in there to begin with… but thats another story)…

  2. Dumky says:

    It’s been discussed on http://simon.incutio.com/archive/2004/01/30/noMoreUsernames

    Basically a more RFC superseeds the RFC you mention, and defines this url format…

  3. Dumky says:

    a more [recent] RFC …

    sorry

  4. Just a Developer says:

    After applying the patch..My .NET application refuses to launch Microsoft Word…do you know if this relates to the patch?

    ClassFactory Cannot Supply Requested Class ! !

    I know it was working because I was working on the project while I downloaded the patch..

    Rebooted, bam, ran the app and this error pops up..whats up with that

  5. Just a Developer says:

    The Code in question is this:

    wapp = new Microsoft.Office.Interop.Word.ApplicationClass();

  6. Michael Howard says:

    RFC 2396 is a little vague, it has the following text: Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used.

    Note, the words, "Some URL schemes"

  7. Peter Torr says:

    Just a Developer:

    For a start, you should not use "ApplicationClass" – just use "Application". (Yes, I know it’s an interface, but you can ‘new’ it because the CLR is smart… IntelliSence is less so…)

  8. Peter Torr says:

    Also make sure you are using a PIA and not a private assembly – the "Strong Name" property of the reference in VS should be true. on and only Office XP and 2003 are officially supported with managed code.

    For the record, I (obviously) have the patch installed and have no trouble creating Word through C#

    using Word=Microsoft.Office.Interop.Word;

    // —–

    Word.Application app;

    app = new Word.Application();

    app.Visible = true;

  9. moo says:

    Ok so you filter out the @ symbol in the URL? What if I use a different way of representing the @ character, is that filtered also?

    For example once on yahoo a chat room, they filter the < character for coding the page.

    I got around this by using a 2 byte encoding that wasnt filtered out and managed to embed an image and flash object and could scale this as I see fit even to 99999999999999% (you can imagine the CPU burn this can do on home computers mevermind executing code or annoyance factors when using audio flashs :D).

    Is it possible to do the same in the URL using a different encoding?

  10. Alun Jones says:

    http://fred@www.microsoft.com and http://fred%40www.microsoft.com give the same answer – invalid syntax. It’s possible that Microsoft considered carefully where they ought to place this fix.

  11. Dana Epp's ramblings at the Sanctuary says:

    Since my original entry pointing to Michaels post about "The IE Patch (MS04-004) demystified" I have seen a lot of ridiculous and ludicrous comments in the midst of some great insight. I am only thankful that none of those idiots seem to visit my blog, as I am not sure I would appreciate such dim-witted statements here. Yes, Im venting. Mostly because in the midst of Microsoft doing something right as it relates to security, people complain. It wasnt even a month ago that these same people complained about the IE vulnerabilities… only to find something else to complain about after the recent IE patches. Yesterday on one private mailing list I am on I actually heard people discuss "class action" lawsuits against Microsoft for "loss of profits". Idiots. The moderator of that list sure got a piece of my mind on that one….

  12. Manoj says:

    Michael, RFC 1738 has been marked obsolete by the W3 Consortium. RFC 2396 is considered to be the replacement for RFC 1738 as stated in RFC 2396.

    "This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces

    the generic definitions in RFC 1738 and RFC 1808."

  13. Mike Dimmick says:

    From RFC 2396:

    "[This document] excludes those portions of RFC 1738 that defined the specific syntax of individual URL schemes; those portions will be updated as separate documents, as will the process for registration of new URI schemes."

    RFC 3305 [Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations] notes that the URI schemes are registered with IANA at http://www.iana.org/assignments/uri-schemes. This notes that the ‘http’ URI scheme’s authoritative reference is the HTTP 1.1 specification, RFC 2616.

    The W3C’s HTML version of RFC 2616 covers HTTP URIs at http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2. This makes it clear that username and password are non-standard.

    Frankly I don’t really care whether it’s standard or not. It’s a minor feature that’s only vaguely useful, and whose operation was long ago replaced by HTTP Basic Authentication. Few people – even experienced web developers – recognise that it’s a username and password, which allows users to be fooled. The user’s privacy and security concerns override this redundant feature, IMO.

  14. Philippe says:

    Ok, the old the syntax wasn’t really official, and the patch corrects a possible security problem.

    I understand all that.

    What I’d like now is the Registry setting I need to add to DISABLE that functionnality. At the beginning of the discussion that was mentionned something of the sort would exist… Considering I understand the "risks" that would pose, I’d really like to be able to keep the possibility to access the sites directly from the shortcuts I have on my Desktop.

  15. Philippe says:

    Answering my question (for the record).

    MS has updated the info:

    To disable the new default behavior in Windows Explorer and Internet Explorer, create iexplore.exe and explorer.exe DWORD values in one of the following registry keys and set their value data to 0.

    * For all users of the program, set the value in the following registry key:

    HKEY_LOCAL_MACHINESoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_HTTP_USERNAME_PASSWORD_DISABLE

    * For the current user of the program only, set the value in the following registry key:

    HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_HTTP_USERNAME_PASSWORD_DISABLE

  16. Jeff says:

    Unfortunately disabling via the registry doesn’t completely solve the problem, you get prompted with the username and password dialogue box after you insert the url with the uasername:password@mysite.it?!?!?!? Any info on this?

  17. Michael Howard says:

    that seems ok to me!! what threat worries you?

  18. kuki says:

    Believe you, support you, I believe that you are right! ! ! I will make great efforts to look like your study! ! !

  19. kuki says:

    Believe you, support you, I believe that you are right! ! ! I will make great efforts to look like your study! ! !

  20. marals says:

    quero senha pra entrar nesse site, tem como me arranjar???? please

Skip to main content