Re: [Web Security] File Upload Virus Scanning

Danux <[email protected]>
Newsgroups gmane.comp.security.websecurity,gmane.comp.security.basics,gmane.comp.security.web-applications
Message-ID <[email protected]>
Good checklist Robert,

I think all the steps are really good ones and necessary, but talking
specifically to the Step 2, it is the most critical and more difficult
to accomplish. "Performe some file type validation" still to open and
I think is what the requester is asking for.

In my opinion, this file type validation should rely more on the
security controls in the environment instead of trying to validate it
at the Application layer.
An up to date AV is a good option, just make sure to copy the uploaded
file over the file system, in case your AV is a signature based one,
otherwise if the file is kept at memory, it could be difficult to
catch it.

If an attacker is able to upload a malicious file, still it will be
hard to get it executed successfully, specially because the attacker
does not know (hopefully) the AV brand so that he cannot concentrate
in bypassing the signature detection mechanism of that product.

Apart from Content-type header in the response, also make sure to use
HTTP instead of HTTPS when sending the file to the end user, this way,
there is a change that another security control like IDS/IPS can catch
the file while flowing back to the end user through the network.

Mis $2.5 centavos

On Fri, Jul 9, 2010 at 3:44 PM,  <[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 #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
>>
>
>
> ------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> ------------------------------------------------------------------------
>
>



-- 
DanUx

----------------------------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.