Re: [Web Security] File Upload Virus Scanning

Additionally, serve user uploaded files from a throw-away domain or
from a IP address. That way, even if your anti-virus misses chamaleon
documents ('gifar'), the browser will not execute the js in the
context of your domain.

--Sri

On 10/07/2010, [email protected] <[email protected]> wrote:
> It is different in each organisation, specially for those who has Data
> Classification in place.
> Some of them requires encryption at rest and if this is your case, then it
> could be easier to encrypt it with
> DB tools than adding more code in the application to encrypt the file
> itself.
> Take a look at your security policies.
> Sent via BlackBerry from Danux Network
>
> -----Original Message-----
> From: Jim Manico <[email protected]>
> Date: Fri, 09 Jul 2010 12:59:13
> To: #Chander - GMail<[email protected]>
> Cc: <[email protected]>; 0x4150<[email protected]>;
> <[email protected]>; <[email protected]>;
> <[email protected]>
> Subject: Re: [WEB SECURITY] [Web Security] File Upload Virus Scanning
> If your total file upload data is going to take up even a modest amount
> of space, you want to push that data to the file system in secure
> fashion (private folders, OS permissions, quota, etc). To much BLOB data
> hurts even horizontal database scalability.
>
> - Jim
>
>> Which option will be better: Storing uploaded file in a file system or
>> storing it in database?
>>
>> Thanks
>> Chander Singh
>>
>> On Fri, Jul 9, 2010 at 1:44 PM, <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     Great Question.
>>
>>     I have been involved in this exact activity, here's how it was
>>     handled it.
>>
>>     Step 1: Identify formats the business wants to support uploading
>>     and verify them
>>     First I had to gather a list of all file formats the business
>>     intentionally wanted uploaded.
>>     Next a pentest was performed to verify the extensions were allowed
>>     and that via url trickery you
>>     couldn't upload files with other extensions.
>>
>>     Step 2: Verify allowed file types
>>     You'll need to perform some file type validation. For example
>>     there have been PDF/swf exploits that
>>     involved overflows due to changing the file structure itself.
>>
>>     Step 3: Antivirus
>>     While antivirus isn't perfect it will detect some issues and is
>>     still worthwhile using. I can't suggest
>>     particular antivirus products, but I would ping a few of the main
>>     vendors asking about integrating into
>>     systems such as this. ClamAV is free and worth looking into.
>>
>>     Step 4: Ensuring that the content-type is displayed
>>     Browsers such as IE use content sniffing in order to detect the
>>     file type. This means you may upload a TXT file but
>>     that the txt file may have HTML and due to content sniffing could
>>     be executed in your browser as HTML. Ensure that
>>     you are setting the content-type HTTP header with the appropriate
>>     content type (or set it to a contenttype that requires
>>     prompting to download rather than displaying in the browser). The
>>     risk of course here is that now when the user opens it
>>     it might be in the local zone. The reality is antivirus and
>>     performing other checks will never be 100% and the risk will
>>     always exist to some extent. Depending on the effectiveness of
>>     'Step 1', 'Step 2', and 'Step 3' this can be fairly effective
>>     in most situations. More info at
>>
>>     Improper Output Handling (WASC-22)
>>     http://projects.webappsec.org/Improper-Output-Handling (Character
>>     Set and Encoding Considerations)
>>
>>
>>     Step 5: Filesystem permissions
>>     Ensure that the filesystem permissions are read only and contain
>>     no executable bits. This can prevent possible server
>>     side execution. More info at
>>
>>     Improper Filesystem Permissions (WASC-17)
>>     http://projects.webappsec.org/Improper-Filesystem-Permissions
>>
>>
>>     Step 6: Restrict file size
>>     Work with the business to figure out how large files should be and
>>     disallow uploading anything above this.
>>
>>     Step 7: filenames
>>     Depending on the use case it may be a good idea to randomly name
>>     files rather than keep the original user supplied
>>     file.
>>
>>     Step 8: Ensure that 'pending' files are not accessible via the web
>>     While a file is being reviewed (as the steps below indicate)
>>     ensure that it isn't in a web reachable folder. It may
>>     be possible that an attacker can upload an evil file and guess the
>>     link prior to it being reviewed (step 7).
>>     This can be accomplished by having a folder outside the webroot
>>     (or behind webserver level auth).
>>
>>     Step 9: restrict the folder files are uploaded to
>>     Ensure that people cannot traverse out of the intended file folder
>>     via directory traversal type tricks. More info at.
>>
>>     Path Traversal (WASC-33)
>>     http://projects.webappsec.org/Path-Traversal
>>
>>
>>     Of course each step should be verified, ideally by a
>>     pentest/security assessment.
>>
>>     Regards,
>>     - Robert Auger
>>     WASC Co Founder and Moderator of The Web Security Mailing List
>>     http://www.webappsec.org/
>>     http://www.qasec.com/
>>     http://www.cgisecurity.com/
>>
>>
>>     >
>>     > All,
>>     >
>>     > I am reviewing Java EE web application which allows uploads of
>>     various
>>     > file types, stores them in a directory, and then offers the same
>>     files
>>     > to other users for download. The files could be images (jpg, gif,
>>     > png), documents (doc, docx, xls, pdf), or text files(txt, csv).
>>     >
>>     > My question is regarding virus scanning of these uploaded files.
>>     With
>>     > vulnerabilities being reported in formats like PDF, I would like to
>>     > protect the users and infrastructure as much as possible.
>>     >
>>     > Are there any best practices for this?
>>     >
>>     > What products (commercial or free) should I evaluate for this
>>     process?
>>     >
>>     > Thanks in advance for any insight!
>>     >
>>     >
>>
>> ----------------------------------------------------------------------------
>>     > Join us on IRC: irc.freenode.net <http://irc.freenode.net>
>>     #webappsec
>>     >
>>     > Have a question? Search The Web Security Mailing List Archives:
>>     > http://www.webappsec.org/lists/websecurity/archive/
>>     >
>>     > Subscribe via RSS:
>>     > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>     >
>>     > To unsubscribe email [email protected]
>>     <mailto:[email protected]> and reply to
>>     > the confirmation email
>>     >
>>     > Join WASC on LinkedIn
>>     > http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>     >
>>     > WASC on Twitter
>>     > http://twitter.com/wascupdates
>>     >
>>
>>
>>
>> ----------------------------------------------------------------------------
>>     Join us on IRC: irc.freenode.net <http://irc.freenode.net> #webappsec
>>
>>     Have a question? Search The Web Security Mailing List Archives:
>>     http://www.webappsec.org/lists/websecurity/archive/
>>
>>     Subscribe via RSS:
>>     http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>>     To unsubscribe email [email protected]
>>     <mailto:[email protected]> and reply to
>>     the confirmation email
>>
>>     Join WASC on LinkedIn
>>     http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>>     WASC on Twitter
>>     http://twitter.com/wascupdates
>>
>>
>
>
>


-- 
--Sri

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

To unsubscribe email [email protected] and reply to 
the confirmation email

Join WASC on LinkedIn 
http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates