Slashdot Mirror
Microsoft To Remove Support For http(s) auth URLs
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."
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?
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
According to the Microsoft KB article itself, this is actually a fix for the IE spoofing problem reported in late 2003:
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.
A computer is a valuable tool, so use it and stop whining.
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...
...note that slashdot doesn't allow them either, and for similar reasons. :)
http://goatse.cx%01%00@microsoft.com/ <-- I wonder why?
pb Reply or e-mail; don't vaguely moderate.
The reason they are doing this is due to the security hole 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."
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread
And you think its a reasonable work-around for an end user to be editing registry entries in order to get functionality that is specified in the RFCs?
"When I grow up, I want to be a weirdo"
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.
Gates' Law: Every 18 months, the speed of software halves.
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...
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).
.. best get rid of it now (and not get hit with a similar exploit).
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 matter of time before the other browsers fix their systems to work in the same way - the feature is not standards compliant, so
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 1und1 "@-domains" are not one of those however, these idiots deserve to suffer (and the morons who paid for this... well, a fool and his money...)
Programming can be fun again. Film at 11.
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.
Most writers regard truth as their most valuable possession, and therefore are most economical in its use - Mark Twain
Yes, there is a bug. 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.
No, you are incorrect.
the URL standad allows for a username and password, but it is not required. However, the HTTP and HTTPS section of the URL standard specifically disallow the use of a username and password
URL RFC
read section 3 : (some of the text below is garbled, because I dont feel like escaping out all the > and < in the text below, however that does not change the important bits.)
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://>:/?
where and are as described in Section 3.1. If : is omitted, the port defaults to 80. No user name or password is allowed. is an HTTP selector, and is a query string. The is optional, as is the and its preceding "?". If neither nor is present, the "/" may also be omitted.
Within the and components, "/", ";", "?" are reserved. The "/" character may be used within HTTP to designate a hierarchical structure.