Internet Explorer Change in Cookie Storage – WININET workaround

Only just got around to writing this up so many of you may already be aware of this change in IE’s behaviour.

The IE Cumulative Security Update for October 2011 introduced some major changes to the way IE stores cookies. 

See: http://support.microsoft.com/kb/2559049 

And a good article that summarises the changes is here: http://blogs.msdn.com/b/ieinternals/archive/2011/08/12/internet-explorer-9.0.2-update-changes-file-protocol-and-cookie-naming.aspx 

This update affected all versions of IE from 6 to 10.

It used to be that Internet Explorer cookies were stored in the users cookies folder (c:usersusernamecookies or c:documents and settingsusernamecookies) in the form: username@domainname e.g. admin@bbc.co[1].txt 

After applying the update cookies are now stored in a random letter and number format e.g. F6F3N6DQ.txt 

There is no way of telling which cookie is which without opening each text file and inspecting the contents – and even then it’s not obvious. 

Also, there now appears to be a new entry type in the temporary internet files cache folder e.g. ‘cookie: admin@bbc.co.uk/’

This is linked in some way to the relevant file in the cookies folder. For instance if you delete ‘cookie: admin@bbc.co.uk‘ from temporary internet files folder it deletes F6F3N6DQ.txt in the cookies folder. It seems that the specific user and domain information for the cookie is now being stored in the temporary cache rather than the filename.

Therefore, the entire way IE stores cookies has been changed.

The reason given is for security purposes i.e. it is more difficult to find and manipulate a users cookies. This seems absurd as the cookie can still be located via the temporary internet files. However, how you would do that programatically is a problem. As always, a change in security will break things and this change will break any application that relied on matching cookies in a file manager context. In the same way that it is more difficult for malicious software to access the cookies so it is more difficult for trusted programmes to access cookies.

It transpired that the recommended way of handling cookies in an IE application/add on is via the internal cache using the WININET Class. See IE Architecture: http://en.wikipedia.org/wiki/Internet_Explorer

This is pretty complex programming (see below) – so Microsoft have made something which was easy 100 times more difficult. Nothing new there – obfuscate, obfuscate, obfuscate should be Microsoft’s motto, that’s how it makes it’s money after all!

The WinInet class declaration that we use for an IE addon is available here: WININET_CLASS.TXT

You then have to use the 

Wininet_Class.FindFirstUrlCacheEntry

Wininet_Class.FindNextUrlCacheEntry

To loop through the cache entries – you can then use the GET and DELETE functions to actually achieve anything. Throughout all this you have to use memory handles to cycle through the cache buffer.

A sample implementation can be provided on request.

Advertisements

Author: James

IT Manager - Network, Web coding, MS SQL and Online Mapping expert

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s