This post originated from an RSS feed registered with .NET Buzz
by David Cumps.
Original Post: Re-Enable user:pass@ IE functionality.
Feed Title: David Cumps
Feed URL: http://weblogs.asp.net/cumpsd/rss?containerid=12
Feed Description: A Student .Net Blog :p
On one side you want to keep your machine up to date with all latest patches, but then there is "Cumulative Security Update for Internet Explorer (832894)", which disables the user:pass@ way of authentication.
Now, do you update and loose this functionality (which can be handy), or don't apply it but have the other security it fixes unpatched?
Here's what I did:
I patched.
...
But I really, really wanted the user:pass back, and it's even in an RFC MS has linked.
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>
Some or all of the parts "<user>:<password>@", ":<password>", ":<port>", and "/<url-path>" may be excluded. The scheme specific data start with a double slash "//" to indicate that it complies with the common Internet scheme syntax. The different components obey the following rules:
user
An optional user name. Some schemes (e.g., ftp) allow the specification of a user name.
password
An optional password. If present, it follows the user name separated from it by a colon.
The user name (and password), if present, are followed by a commercial at-sign "@". Within the user and password field, any ":", "@", or "/" must be encoded.
The solution? Re-enable it!
Start regedit.
Go to: HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE to re-enable it for the entire machine,
or go to: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE to re-enable it for the logged in user.
Now create iexplore.exe and explorer.exe DWORD values and set their value data to 0.
Done, you just got the user:pass@ functionality back.
Update:
As Kent Sharkey writes, the RFC I quoted actually did not specifiy the user:pass possibilty for the HTTP protocol. I'm sorry for that, it's a 'feature' I guess :)
This registry tweak does however not undo the patch, it only reactivates this 'feature', the chr(0) exploit remains fixed with this tweak.
Previous Topic
