Wednesday, May 28, 2008

thumb.db Caused IIS Problems

A while ago I was approached by one of Zajon's clients who had an interesting issue. There was a directory on a web site they managed and when they tried to view it's contents the Windows IIS6 web server returned a 404 (page not found) error message. The directory contained images only and was set to allow directory browsing. They had tried several solutions to fix the problem, but it persisted despite the "fixes".

After looking at the directory I noticed the system file "Thumb.db". We deleted that file and the problem went away.

IMHO - Even though the thumb.db file is suppose to cache image previews it appears as if it was storing a reference to a web page which existed in the directory before it was uploaded to the web site. (The client's computers are a mix of Mac and Windows PCs, they used a Mac FTP client to upload the site). IIS was using the thumb.db file to see what files where in the directory. It saw a reference to default.asp and tried to display it on the browser, but since there was no default.asp file to display IIS showed the 404 error message.

In any case if you run into this error - IIS mysteriously giving a "page not found" error check to see if there are any thumb.db on your site.

Tuesday, May 6, 2008

Our site is safe - isn't it?

This is a follow-up to the April 17th, 2008 post which dealt with a client's legacy web site being hacked with a SQL injection attack.

I was relating the story to another web developer (we'll call him Fred) and he mentioned that he also worked with legacy sites that use SQL, but they use stored procedures. Since the old ASP sites used stored procedures not all the code checks user input data.

Right away my antenna was raise. "Do you use parameters with your procedures?" I asked "Or do you just create a string with the procedure and the parameters in single quotes?" Ex: "sp_getUserInfo 'ablevy' " All the sudden I saw a look of doubt on Fred's face.

To make a long story short - I heard from him the other day and he had checked his client's site. Sure enough there where some web pages that used stored procedures that way and his site could suffer from a SQL injection attack. Luckily the site was never attacked and the code has been updated.