views:

127

answers:

3

We have an asp.net application that allows users to upload files, the files are saved to temporary disk location and later attached to a record and saved in DB.

My question pertains to security and/or virus issues. Are there any security holes in this approach? Can a virus cause harm if it is never executed (file is saved, then opened using filestream, converted to byte array and saved to DB.

Later, when the file is needed we stream the file back to user.

The files are saved to a folder on the web server like this:

context.Request.Files[0].SaveAs(); (location is a folder under app_data/files)

later when the same user creates a record we grab the file from disk and store it in db like this:

FileStream fileStream = File.OpenRead(currentFilePath);
byte[] ba = new byte[fileStream.Length];
int len = fileStream.Read(ba, 0, ba.Length);
//ba saved to DB here as varbinary(max)

We limit the files that can be uploaded to this list:

List<string> supportedExtensions = new List<string>(10) {".txt", ".xls", ".xlsx", ".doc", ".docx", ".eps", ".jpg", ".jpeg", ".gif", ".png", ".bmp", ".rar", ".zip", ".rtf", ".csv", ".psd", ".pdf" };

The file is streamed back to user's web browser like this:

//emA = entity object loaded from DB
context.Response.AppendHeader("Content-Disposition", "inline; filename=\"" + emA.FileName + "\"");

context.Response.AddHeader("Content-Type", emA.ContentType);
context.Response.BinaryWrite(emA.FileContent);
+3  A: 

There's always a security risk when accepting files from unknown users. Anyone could potentially write a virus in VBA (Visual Basic for Applications) in the office documents.

Your approach is no more or less of a security risk than saving them directly on the file system or directly in the database except for one concern...

If the files are saved to the disk, they can be scanned by traditional virus scanners. As far as I know most virus scanners don't scan files that are stored in a DB as a byte array.

If it were my server, I would be storing them on the file system for performance reasons, not security reasons, and you can bet I would have them scanned by a virus scanner if I were allowing potentially dangerous files, such as office documents, executables, etc.

David Stratton
+1 back at you because you reminded of something I should have implemented! :-)
IrishChieftain
+1  A: 

Have your users create logins before allowing them to upload files. Unchecked access of this kind is unheard of... not saying that this is a solution in and of itself, but like all good security systems it can form an extra layer :-)

IrishChieftain
+1 to you as well. Every layer of security helps.
David Stratton
+1  A: 

I can't see there being anymore security risk than saving the files to disk. The risks here are often not to do with where you store the data since as you've already pointed out the stored file doesn't get executred.

The risk is usually in how the data is transfered. Worms will exploit circumstances which allow what was just data on its way through the system to be treat as if it were code and start being executed. Such exploits do not require that any sense of "file" being transfered be present, in the past a specially formatted URL could suffice.

That said, I've never understood the desire to store large binary data in a SQL database. Why not just save the files on disk and store the file path in the DB. You can then use features such as WriteFile or URL re-writing to get IIS do what its good at.

AnthonyWJones
Exactly. And the debate about storing files in the database has been pretty resoundngly answered as "don't do it" in many posts on this site.
David Stratton