Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Microsoft Science

Microsoft To Remove Support For http(s) auth URLs 79

Posted by timothy from the was-sonst dept.
damohasi writes "According to Microsoft Knowledge Base, MS "plans to release a software update that removes support for handling user names and passwords in HTTP and HTTP with Secure Sockets Layer (SSL) or HTTPS URLs in Microsoft Internet Explorer". Whether this will break rfc 1738 or not, it might get webspace provider in trouble who offer @-domains like the German 1und1."
This discussion has been archived. No new comments can be posted.

Microsoft To Remove Support For http(s) auth URLs More

Microsoft To Remove Support For http(s) auth URLs

Comments Filter:

  • Alternate solutions (Score:5, Insightful)

    by jtheory ( 626492 ) on Wednesday January 28, 2004 @10:58AM (#8113153) Homepage Journal
    I understand why they'd want to disable that format... but it is a standard, after all -- why not just pop up a warning showing the site you're really going to?
    • Because the problem is also with the web server that supplied the credientials. I worked with a portal package that logged into a downstream web server, got some aggreagate data, then supplied drill-down links that linked directly to the downstream server that had the authentication information in the URL. The downstream web server was a package that we couldn't modify. Technically, it's the only way (short of exotic technology like Kerberos) to do this with three different computers that shouldn't trust

      • Technically, it's the only way (short of exotic technology like Kerberos) to do this with three different computers that shouldn't trust each other.

        Well, maybe you consider https user certificates exotic, but even so, you could always use HTTP GET, which is certainly not exotic.

        We were willing to live with that, out out big hang up was that when your mouse hovered over the link, the status bar displayed the full URL with the plaintext authentication information.

        So why use plaintext? Encrypt it.

        • No, the downstream server (An off-the-shelf timeclock system) was a canned product. It used BASIC authentication. There is a portal product which is a little bit client, and a little bit server. And, of course, the end users' browser. The user logs into the portal site and gets a summary of hours worked. (among other things.) The timeclock system released the hours because the portal site impersonated the end user and provided the data to be scrapped be the portal. Both the portal and timeclock syste

    • Re:Alternate solutions (Score:4, Insightful)

      by spitzak ( 4019 ) on Wednesday January 28, 2004 @12:48PM (#8114307) Homepage
      After reading all the comments here, I agree that MS's "solution" is bogus. A far better one would be:

      1. Fix the status preview. But instead of showing the full path, show the actual URL with the usernae and password stripped, or show it with a leading '@'. This will hide the username/password from casual viewing, something a reply to this same comment said is a problem to his actual use of this scheme in browsers other than IE.

      2. If the user clicks on such a link, pop up a box asking if the user really wants to do this. However a relative link (ie from one location with the same name&password to another) does not pop up the box.

      3. To be really clever the box can also let the user choose a different name or password, prefilled with the URL values. Be careful to design it so a novice user is absolutely certain to cancel the box rather than hit ok.

      • Just to play devil's advocate, let's suppose I were a Microsoft programmer, considering the following two options:

        1. Make the following changes to Internet Explorer and related software:
          • Change the display code to recognize a special class of URLs which should be treated differently from other URL's.
          • Create a special function and associated UI elements to deal with such URL's.
          • Test and refine the implementation until computer novices do the right thing automatically.
        2. Disable a feature that has caused n
        • 1.1 Part of the problem with IE is that it already treats a class of URL's specially and displays them with the text after the '@' deleted. If it showed then entire text it would be better (though as a lot of people pointed out it won't be that much better). But anyway the test is there already.

          1.2 Detecting and somehow dealing with such URL's must be done to "disable" it as well. The parsing is done by the server that IE talks to, not IE. So whatever is done (either not sending it, or popping up a dialog)
      • Konqueror does this... well, it actually hides the password only, so you still have the form:

        http://username@domain.ext/path/

        If you use username:password, the password goes away when the URL is parsed and stored and used for future hits to the same username/domain pair (for that session).

        --
        Evan

    • What we need is a setting that default to off, for turning this ability back on.

  • According to the Microsoft KB article itself, this is actually a fix for the IE spoofing problem reported in late 2003:

    A malicious user could also use this URL syntax to create a hyperlink that appears to open a legitimate Web site but actually opens a deceptive (spoofed) Web site. For example, the following URL appears to open http://www.wingtiptoys.com but actually opens http://example.com: http://www.wingtiptoys.com@example.com

    Despite the negative side-effect, this update is actually a fix for a large security issue in IE. Phishing has become a big problem recently, especially since Microsoft acknowledged the bug in IE. Now if users actually run the update, and then check to see the actual address to which they are giving information, phishing may not be as big of a problem.

    • Comment removed based on user account deletion
      • There Is No Bug. URLs with username/password parts work as they should in IE - but this, technically proper, behaviour is exploitable. It is not a technical problem, more like a way of social engineering - uneducated users or users that don't pay much attention to the URL may interpret it differently that the Browser does. So it is pretty much impossible to "fix it properly".

        This "solution" still sucks, there are good reasons to use such URLs, and for many of them, you explicitly do not want a popup. The

        • Of course it is possible to fix it properly. All other browsers do it just fine.

          And of course it is a bug. It is a bug, because it is not the behavior that the programmers expected when they wrote the browser software.
        • Yes, there is a bug [cert.org]. If the phisher puts a special character before the @ sign, then the url bar in the browser doesn't display the true destination. So educated or not, the user has no idea that they aren't really talking to citibank, fdic, etc.

  • Of Course... (Score:4, Insightful)

    by alexpage ( 210348 ) on Wednesday January 28, 2004 @11:01AM (#8113195)
    Because breaking standards compliance is a much better solution than fixing your fucking software in the first place!

    There are several browsers which implement this feature without it being a security hole or risk. This is yet more evidence of Microsoft's inadequate attempts to provide a decent product, and yet more reason to advocate for unbundling IE - what incentive to M$ have to create a decent browser if their POS is installed on most desktops by default?

    Then again, it's more reason for people to switch away to a proper web browser, so I guess it's not all bad news...

    • Re:Of Course... (Score:5, Informative)

      by drnlm ( 533500 ) on Wednesday January 28, 2004 @11:16AM (#8113344) Homepage
      To quote the RFC:

      An HTTP URL takes the form:
      http://<host>:<port>/<path>? <searchpart>
      where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed.

      The allowing of username, password in http urls is a convention, but is certainly not the standard. If Microsoft does this, they'll actually be able to claim that IE is more standards-compliant than other browsers that allow the syntax.

      Whether allowing this syntax is a good or bad idea is a completely different debate (and slashdot is arguably the wrong forum to discuss it :) ).

      • You could always take the M$ line and claim that http://user:password@host:port/ is a "standard" just because it's so widely used... ;)
      • Interesting to note that the only thing at issue is the change they made to IE6 that simply displayed the part of the URL after the '@' sign - previous versions displayed the whole URL, username, password and all.
        No-one cared before that change.

      • Re:Of Course... (Score:4, Informative)

        by EvilJohn ( 17821 ) on Wednesday January 28, 2004 @12:08PM (#8113855) Homepage
        and to Continue Quoting the RFC [faqs.org]:
        3.1. Common Internet Scheme Syntax While the syntax for the rest of the URL may vary depending on the particular scheme selected, URL schemes that involve the direct use of an IP-based protocol to a specified host on the Internet use a common syntax for the scheme-specific data:

        //<user>:<password>@<host>:<port>/<url-path>
        ...and so on. The RFC seems to allow indicate this indeed is a valid URL contruction.

        • I was beginning to wonder - so the RFC says that HTTP(S) is an EXCEPTION to the RFC-Standard
          proto://(user):(password)@(host):(port)/(url)
          scheme?

          Personally, I've gotten used to "fish://(user):(password)@(host)" and "webdav://(user):(password)@(host)" and "ftp://(user):(password)@(host)" and so on...It'd annoy me to have it removed. I suppose just removing it from http(s) wouldn't be TOO bad...

        • Re:Of Course... (Score:3, Informative)

          by gbjbaanb ( 229885 )
          its not terribly clear, but HTTP is not part of the 'Common Internet Scheme'. Look at section 3.3 where it gives the scheme for HTTP fully.

          The only ones that do make use of user:passwd are ftp and telnet.
        • The grand-parent post was quoting section 3.3, so saying "To continue Quoting" is a little bit misleading.

          The way I see it, 3.1 describes in a very general way what might be acceptable in a url. It sort makes sense that not all schemes will need/support all varieties. So 3.3 points our clearly what a url for the http/https scheme is.

          But it was a nice try ;)

  • darn. (Score:5, Interesting)

    by pb ( 1020 ) on Wednesday January 28, 2004 @11:02AM (#8113205)
    ...note that slashdot doesn't allow them either, and for similar reasons. :)

    http://goatse.cx%01%00@microsoft.com/ <-- I wonder why?

  • What a crap way around fixing the security hole (Score:5, Interesting)

    by a.koepke ( 688359 ) on Wednesday January 28, 2004 @11:02AM (#8113206)
    The reason they are doing this is due to the security hole [zapthedingbat.com] that was found in IE recently.

    Instead of fixing the bug that is causing they security hole they remove the feature. How stupid and dumb is that? It is more-or-less saying, "We have got no idea how to program and cannt make enough sense of our own code to fix a security issue."
    • No, what they're saying is that the people making the decisions are not the people who understand the problem. Instead they're being made by people with a bigger paycheck that base the decision on "risk assessments" and personal hot buttons. That type of thing happens in amost every organization that grows to over 50 people.

      What probably happened here is that some manager found out that the risk of the feature being exploitable was practically non existent if they fixed the bug, but completely non existent

  • ROFL (Score:5, Insightful)

    by Imperator ( 17614 ) <{slashdot2} {at} {omershenker.net}> on Wednesday January 28, 2004 @11:12AM (#8113297)

    This is hilarious. There's a bug in IE that's being exploited to steal credit card information. MS evidently hasn't figured out how to fix it so they'll remove support for a whole feature of HTTP.

    I'm starting to see a pattern here. IE has standards-compliance issues and MS doesn't seem to be making any moves to increase standards support or support additional standards. The IE rendering engine hasn't really changed in years now and there aren't any plans on the horizon either. A bug that should be simple to fix hasn't been fixed in weeks (months?) and before they release a fix, they're releasing a workaround to one of the (several) problems that the bug is causing.

    My conclusion? The IE code base is a mess. Like Netscape 4, it's grown too fast and with too little control from competent engineers. Forget things like proper CSS2 support: the IE team can't even wrestle the code to fix a simple bug. I wouldn't be surprised if MS has for some time now been in the process of rewriting IE (or substantial parts of it) from scratch. After all, it worked for the Mozilla Project.

    • Get a clue before posting please. The problem is that IE is *not* standards compliant because it allows URLs with the user:passwd@host scheme.

      Other browsers that do this are similarly broken. This is the bug, that and IE6 doesn't display the user/passwd in the title bar (which you'd expect really - really want your password displayed for all to see?).

      So, if other browsers support this URL scheme, and hide the parts before the @ sign, then they're ready for exploitation too.


      • The problem is that IE is *not* standards compliant because it allows URLs with the user:passwd@host scheme.

        No, that's part of RFC 1738 [faqs.org] (as linked to above). Look at section 3.1 for that exact scheme. This is a case where they are (soon: were) standards compliant.

        -- MarkusQ

      • Get a clue yourself. RFC1738 [ietf.org] lists it as a valid syntax. See section 3.1 if you don't believe me.

        Other RFC's list this syntax as "NOT RECOMMENDED" as it exposes the account information in plaintext, a sentiment I agree with. On the other hand, I realize that sometimes it needs to be used or security isn't that much of an issue and it is part of the standard.

        • Section 3.1 is the common section. Each scheme is further specified in its own section.
          For HTTP, from RFC1738 [ietf.org], we have (emphasis added by me):

          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>,

          where <host> a

    • Re:ROFL (Score:3, Insightful)

      by imr ( 106517 )
      I think the situation is even worse than that:
      they tied the browser to the os and now they cant fix the browser without breaking everything that is tied to it. And that means all software, not only redmond's, that is based upon those components.
      Therefore, they can't apply one patch without tons of tests and that means time. So for a quick fix, they can't do anything but nerf the feature.
      But don't worry, with .net and longhorn, things will get integrated even thighter into the os. Welcome to .netmare.

      Meanwh
      • Yes, the illegally commingled code, which was delibarately done in such a way that the court could not make them untangle it, is the root of the problem.

        Sound programming practice, as used by everyone everywhere (except in Redmond) who develops serious programs is to have a modular layout with diverse things separated, in separate dlls for example, and not all mixed up the way it currently is. It is a true reflection of Bill's random mind.

        As for Longhorn, they are cutting down the APIs drastically so it wil

    • Breaking standards is just part of their bigger strategy -
      dividing the internet in two.

      I think they are trying to create a Microsoft internet, and a non-Microsoft internet. I'm finding more and more places where Microsoft is becoming "standardized" in places of importance (US Post office "offical" stamps that REQUIRE Microsoft Office software anyone?).

      What happened to the RFC's? ANSI, IETF, etc?

      In fact, now that I think about it, virtually all of the new Microsoft-only technologies are linked to DRM
  • Well, if they want to do it logically, they could remove ambiguity by auto-reformating URLs so that www.citibank.com@hax0rheaven.com gets displayed as something like

    hax0rheaven.com username:www.citibank.com .

    With username as a seperate field adjacent to the URL bar. Or whatever their UI gurus come up with as long as it is distinctly seperated from the domain.

    They could even have it look for things like an URL as a username or password. It won't break the standards; it'll just change the presentation of t

  • More sensible solution (Score:4, Insightful)

    by Ianoo ( 711633 ) on Wednesday January 28, 2004 @11:32AM (#8113504) Journal
    A far more sensible solution that I would propose is to do the following:

    When a URL such as http://user:pass@www.domain/ is entered, display http://www.domain/ in the Address Bar and put "Logged in as user" in the status bar. This work just as well with https URLs, and would also give people a better sense of security since their passwords wouldn't be displayed in the address bar when viewing pages on an authenticated site.

    It makes me wonder how much they are paying people to come up with solutions which involve breaking standards in the name of "security" when I can come up with a better idea in under 30 seconds...
  • This may not be as bad as it initially looks.
    This only affects IE and not the servers so that any scripts you write to connect to servers using user:pass@domain will still be properly authenticated by the server.

    From the user point of view if a site requires authentication, IE will popup a dialogue asking for a username and password like it already does if you haven't already specified the details in the URL.

    What you'll lose is the ability to send someone one link that automatically authenticates.

    In fact
    • I'm not sure that's correct. The browser relies on the inet dlls to make connections - and they will be the bits that are changed. (ie. the edit field in the browser will not parse the text, it'll pass it on to the comms subsystem).

      If MS alters the inet dlls then, all http communications will be affected by the change, and so the server will never see any packets even if you connect via scripts. (which is a good thing, you don't want a vbs script to auto-open hackers.com@www.ebay.com)

      I think its only a ma
  • It's not hip anymore, unless you work for a company that is still in the pre-dot-com-hype-cycle, but there used to be a time when putting an @ (at) sign in a name or a brand would create this e-internet feeling. corry even started the //dont abuse the at sign compaign [camathome.nl] somewhere in 2000.

    During the rise of this @buse (atbuse?), a Dutch TV show for kids called z@ppelin started out. It's primary a TV show, but like any multi-channel-format thingy, they ought to have a website as well.

    When they first aired th

Slashdot Top Deals

The 11 is for people with the pride of a 10 and the pocketbook of an 8. -- R.B. Greenberg [referring to PDPs?]

Close