Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 Scan files stored in database for virus

Author  Topic 

rdaunce
Starting Member

7 Posts

Posted - 2004-11-29 : 16:18:45
We recently updated our web application to store user uploaded files in our database rather than on the file system of the web server. When the files were stored on the file system of the webserver the Symantec Antivirus Client would scan the file with the File System Scanner.

Now that the files are no longer stored on the file system, the files are not scanned. A user would be able to upload an infected file to our database and other users would be able to download it. I verified that this was the case by uploading the EICAR test virus file (http://www.eicar.org/anti_virus_test_file.htm) and downloading it without a problem.

So now that the files are stored in the database how can we ensure that they are scanned for viruses (on their way in and periodically)? My only thought is to have the application write the file to the file system and then upload the file from the file system to the database. We would also have to dump the files to disk to do a periodic scan. While this would work, it seems like too much of a hack put on a production website.

Do you even bother checking the files? If so, how do you go about doing it? Any ideas/suggestions are appreciated. Thanks.


--Bob

DustinMichaels
Constraint Violating Yak Guru

464 Posts

Posted - 2004-11-29 : 16:29:06
Why did you stop storing files on the web server? Most people on this forum think that you shouldn't store images in the database, but instead store links to access the files on the web server.

Dustin Michaels
Go to Top of Page

rdaunce
Starting Member

7 Posts

Posted - 2004-11-29 : 19:59:50
The user uploaded files were added to the database when we implemented several front end webservers to distribute load. We had some difficulties replicating these files from one webserver to another. All webservers have access to the same database server so it made sense to store this data in the database server.

We do not store all files in the database. Images and all files that are part of the application are stored on the file system of each webserver. These files do not change unless a new version of the web applicaiton is deployed. The files that are stored in the database are user uploaded files. These files change continuously. Now that these files are stored in the database they are available to all webservers rather than just the webserver that the file was uploaded on.

This has worked great since the transition aside from the lack of a way to do a virus scan on uploaded files.

--Bob
Go to Top of Page

Merkin
Funky Drop Bear Fearing SQL Dude!

4970 Posts

Posted - 2004-11-29 : 21:34:01
There isn't an way of doing it that I can think of, short of actually hooking into the AV software via an API and streaming bytes into it.

One thing you could maybe do is write the file to the filesystem as well, and when the AV system flags the file as suspect, look at the logs and flag the DB files as suspect.


Actually, now I think about it.... the API way might be an option, because mail scanning software that works at the server level can read the MIME encoded binaries inside the email. Maybe do some research with your AV vendor.



Damian
Go to Top of Page

DustinMichaels
Constraint Violating Yak Guru

464 Posts

Posted - 2004-11-30 : 09:49:30
Perhaps the anti-virus software your using has a dll that you can use in your application to check to see if the file being uploaded is free of viruses. If it is then you can upload it to the database, else you can show an error to the user saying that the file has a virus.

Dustin Michaels
Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2004-12-01 : 08:51:46
quote:
The user uploaded files were added to the database when we implemented several front end webservers to distribute load. We had some difficulties replicating these files from one webserver to another. All webservers have access to the same database server so it made sense to store this data in the database server.
Why not centralize the files on a separate server that is accessible to all of the web servers? This not only lets you avoid replicating files but also lets you isolate any virus infected files on that server only. Theoretically the virus scanning software would only have to run on the central file server.

You also get the added benefit of allowing multiple databases reference the same files, without having to copy them into each database.
Go to Top of Page

Bustaz Kool
Master Smack Fu Yak Hacker

1834 Posts

Posted - 2004-12-05 : 10:04:37
quote:
Originally posted by DustinMichaels

Why did you stop storing files on the web server? Most people on this forum think that you shouldn't store images in the database, but instead store links to access the files on the web server.

Dustin Michaels



I couldn't disagree more with this approach. By storing the data (in this case files) outside of the database, you've opened yourself up to a slew of potential problems.

1) If the file gets deleted, you have a dangling reference
2) When you delete the reference within the database, you need to manange the external data deletion as well.
3) Security - What happens when someone replaces one image file with another (e.g., Their picture on my drivers license)

HTH

=========================================
Let X = {All sets s such that s is not an element of s}

(X element of X) ==> (X not element of X)
(X not element of X) ==> (X element of X)

(Bertrand Russell Paradox)
Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2004-12-05 : 10:37:13
1) If the file gets deleted, you have a dangling reference It's as easy or easier to secure a file against deletion than it is on a database table.
2) When you delete the reference within the database, you need to manange the external data deletion as well. Why? You can keep the file independent of the database, and it can be used by any other application.
3) Security - What happens when someone replaces one image file with another (e.g., Their picture on my drivers license) See #1. Files can be secured with far greater granularity than individual rows in a database.
Go to Top of Page

Bustaz Kool
Master Smack Fu Yak Hacker

1834 Posts

Posted - 2004-12-05 : 16:55:58
There is a larger architectural question here; namely, who is responsible (owns) the image? I argue that thye database is being asked to store, manage and retrieve the data. Given that assumption, it only make sense to let the database do what it's been asked to do. Keeping a subset of data outside its control only detracts from its ability to perform its function. It also adds a second point of failure, unnecessarily.

As for security, either your database data is secure or it's not. If someone can step on the data (image or otherwise), you're in for some heartache. But that's not a function of where the data resides; it's a function of the system security.

Use of image file by other applications - I can see where there could be some uses for this. It does violate my basic assumption that the database has data and supplies it (to any application) on demand. But your point is taken.

These are just opinions, but at least they are mine. ;->

HTH

=================================================================
It was a woman that drove me to drink... And I never had the decency to thank her.
Go to Top of Page
   

- Advertisement -