Sunday, January 16, 2005


Some notes on IE URL

Implementation of URL Search Hooks : Expediting search in IE4.0
By Sandeep Bhatia February 1, 1999

This article demonstrates the use of URL Search Hooks in IE 4.0. It has been implemented as a simple DLL which was created using ATL-COM AppWizard and has just one object called SrchHook. SrchHook implements the Translate function and has a property "srch".

This article also shows how to use the About URL protocols in IE40.

How does the browser attempt to open a site?
The browser jumps to a site using the protocol defined in the URL in the address bar. If it is not able to find the protocol, it tries to find protocol from the address. (trying to form site names prefixing www and/sufficing edu/com etc.) If it is not able to find them, the browser creates Search Hook objects and calls each of their Translate function.

I have created such a simple object(SrchHook) which implements this function.

SrchHook performs:

1) Address translation, and
2) Setting and getting of the search engine string from the registry. (This string is further passed as the final URL for the browser to jump to!!)
How is the POST method for search-sites used in this application?
It was observed that if someone types say "CodeGuru of the month" in the search text box of a search engine, say altavista, then the browser jumps to the following URL: of the month&text=yes
Similarly, for other search-engines there are different such POST queries. This implies that the browser attempts to open another site-URL using the string entered by the user. This is further used as follows.

Usage in the current application
1. Address Translation
Such a string is stored in the registry for the selected search engine. This is further used to form the final URL string passed to the browser by the Translate function: This function formats the search engine string(from Registry) and forms the final URL to move to. It returns S_OK for the case that browser will not form any further objects for performing address translation and presumes that the address has been interpreted correctly.

STDMETHODIMP CSrchHook::Translate(LPWSTR lpwszSearchURL, DWORD cchBufferSize)
// Copy the string entered by the user (which is not recognised by IE).
WCHAR *wpStr = new WCHAR[2048];
wcscpy(wpStr, lpwszSearchURL);

//Read the search engine from the registry.
HKEY hKey;
if(RegOpenKey(HKEY_LOCAL_MACHINE, _T(szMainKey), &hKey) != ERROR_SUCCESS)
return S_FALSE;

TCHAR szKeyBuf[2048];
long lSize;
if(RegQueryValue(hKey, NULL, szKeyBuf, &lSize)!= ERROR_SUCCESS)
return S_FALSE;

int nSize = MultiByteToWideChar(CP_ACP, MB_COMPOSITE, szKeyBuf, -1, NULL, 0);
WCHAR *wzKeyBuf = new WCHAR[nSize + 1];
MultiByteToWideChar(CP_ACP, MB_COMPOSITE, szKeyBuf, -1, wzKeyBuf, nSize);
wsprintfW(lpwszSearchURL, wzKeyBuf, wpStr);

delete [] wpStr;
delete [] wzKeyBuf;

return S_OK;
This function formats the search engine string(from Registry) and forms the final URL to move to. It returns S_OK for the case that browser will not form any further objects for performing address translation and presumes that the address has been interpreted correctly.

2) Setting and getting of the search engine string from the registry.
The very same object (SrchHook) also has a property called "srch" which holds the selected search engine string URL format.

Setting the Search Engine
The search engine can be set by the user by typing "about:searchprovider" in the address bar. The user is then taken to a page whereby he can select one of the search engines in the combo box provided and hitting OK.

This sets the srch property of the object to the selected search engine string which in turn puts this string in the registry by calling its method SetRegistrySearchProvider.

The user is then notified by message e.g. "Search Provider Set : altavista"

STDMETHODIMP CSrchHook::put_srch(BSTR newVal)
/*set the registry string */
return S_OK;

Getting of search engine is used at the loading time of the searchprovider page to display the current value of the search engine.
STDMETHODIMP CSrchHook::get_srch(BSTR *pVal)
// get the registry string
return S_OK;
AboutURL protocols
The application's .rgs file was modified for adding an entry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\'Internet Explorer'\AboutURLs for implementing "about:searchprovider". This is the place which holds the locations for other AboutURLs also like "about:NavigationCanceled" etc. Just the location of the html file needs to be given here in order to implement this. In this case I just made the HTML resource as the part of the application. The browser interprets this and opens the HTML Page for the search engine selection.

Re-Enable user:pass@ IE functionality
By David Cumps

Here's a dillema:

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:


Some or all of the parts ":@", ":",
":", and "/" 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:


An optional user name. Some schemes (e.g., ftp) allow the
specification of a user name.


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.


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.


Here is a .reg file to re-enable it system-wide.

Windows Registry Editor Version 5.00




HWND hwnd=::FindWindow(_T("IEFrame"),NULL);
   HWND hwnd2=::FindWindowEx(hwnd,NULL,_T("Edit"),NULL);

char sz[255];


HWND hwnd=::FindWindow(_T("IEFrame"),NULL);
HWND hwnd2=::FindWindowEx(hwnd,NULL,_T("WorkerW"),NULL);
HWND hwnd3=::FindWindowEx(hwnd2,NULL,_T("ReBarWindow32"),NULL);
HWND hwnd4=::FindWindowEx(hwnd3,NULL,_T("ComboBoxEx32"),NULL);
HWND hwnd5=::FindWindowEx(hwnd4,NULL,_T("ComboBox"),NULL);
HWND hwnd6=::FindWindowEx(hwnd5,NULL,_T("Edit"),NULL);

char sz[255];


<< Home

This page is powered by Blogger. Isn't yours?