I wouldn't say one is better than another, just different and each will have slightly different security
concerns.
- Robert
http://www.webappsec.org/
http://www.qasec.com/
http://www.cgisecurity.com/
> 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]> 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
> > >
> >
> >
> >
> > ----------------------------------------------------------------------------
> > 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
> >
> >
>
> --0016364d318f611564048afc26e2
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> <font size=3D"2"><font face=3D"verdana,sans-serif">Which option will be bet=
> ter: Storing uploaded file in a file system or storing it in database?<br><=
> br>Thanks<br>Chander Singh<br></font></font><br><div class=3D"gmail_quote">=
> On Fri, Jul 9, 2010 at 1:44 PM, <span dir=3D"ltr"><<a href=3D"mailto:ro=
> [email protected]">[email protected]</a>></span> wrote:<br>
>
> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
> r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Great Question.<b=
> r>
> <br>
> I have been involved in this exact activity, here's how it was handled =
> it.<br>
> <br>
> Step 1: Identify formats the business wants to support uploading and verify=
> them<br>
> First I had to gather a list of all file formats the business intentionally=
> wanted uploaded.<br>
> Next a pentest was performed to verify the extensions were allowed and that=
> via url trickery you<br>
> couldn't upload files with other extensions.<br>
> <br>
> Step 2: Verify allowed file types<br>
> You'll need to perform some file type validation. For example there hav=
> e been PDF/swf exploits that<br>
> involved overflows due to changing the file structure itself.<br>
> <br>
> Step 3: Antivirus<br>
> While antivirus isn't perfect it will detect some issues and is still w=
> orthwhile using. I can't suggest<br>
> particular antivirus products, but I would ping a few of the main vendors a=
> sking about integrating into<br>
> systems such as this. ClamAV is free and worth looking into.<br>
> <br>
> Step 4: Ensuring that the content-type is displayed<br>
> Browsers such as IE use content sniffing in order to detect the file type. =
> This means you may upload a TXT file but<br>
> that the txt file may have HTML and due to content sniffing could be execut=
> ed in your browser as HTML. Ensure that<br>
> you are setting the content-type HTTP header with the appropriate content t=
> ype (or set it to a contenttype that requires<br>
> prompting to download rather than displaying in the browser). The risk of c=
> ourse here is that now when the user opens it<br>
> it might be in the local zone. The reality is antivirus and performing othe=
> r checks will never be 100% and the risk will<br>
> always exist to some extent. Depending on the effectiveness of 'Step 1&=
> #39;, 'Step 2', and 'Step 3' this can be fairly effective<b=
> r>
> in most situations. More info at<br>
> <br>
> Improper Output Handling (WASC-22)<br>
> <a href=3D"http://projects.webappsec.org/Improper-Output-Handling" target=
> =3D"_blank">http://projects.webappsec.org/Improper-Output-Handling</a> (Cha=
> racter Set and Encoding Considerations)<br>
> <br>
> <br>
> Step 5: Filesystem permissions<br>
> Ensure that the filesystem permissions are read only and contain no executa=
> ble bits. This can prevent possible server<br>
> side execution. More info at<br>
> <br>
> Improper Filesystem Permissions (WASC-17)<br>
> <a href=3D"http://projects.webappsec.org/Improper-Filesystem-Permissions" t=
> arget=3D"_blank">http://projects.webappsec.org/Improper-Filesystem-Permissi=
> ons</a><br>
> <br>
> <br>
> Step 6: Restrict file size<br>
> Work with the business to figure out how large files should be and disallow=
> uploading anything above this.<br>
> <br>
> Step 7: filenames<br>
> Depending on the use case it may be a good idea to randomly name files rath=
> er than keep the original user supplied<br>
> file.<br>
> <br>
> Step 8: Ensure that 'pending' files are not accessible via the web<=
> br>
> While a file is being reviewed (as the steps below indicate) ensure that it=
> isn't in a web reachable folder. It may<br>
> be possible that an attacker can upload an evil file and guess the link pri=
> or to it being reviewed (step 7).<br>
> This can be accomplished by having a folder outside the webroot (or behind =
> webserver level auth).<br>
> <br>
> Step 9: restrict the folder files are uploaded to<br>
> Ensure that people cannot traverse out of the intended file folder via dire=
> ctory traversal type tricks. More info at.<br>
> <br>
> Path Traversal (WASC-33)<br>
> <a href=3D"http://projects.webappsec.org/Path-Traversal" target=3D"_blank">=
> http://projects.webappsec.org/Path-Traversal</a><br>
> <br>
> <br>
> Of course each step should be verified, ideally by a pentest/security asses=
> sment.<br>
> <br>
> Regards,<br>
> - Robert Auger<br>
> WASC Co Founder and Moderator of The Web Security Mailing List<br>
> <a href=3D"http://www.webappsec.org/" target=3D"_blank">http://www.webappse=
> c.org/</a><br>
> <a href=3D"http://www.qasec.com/" target=3D"_blank">http://www.qasec.com/</=
> a><br>
> <a href=3D"http://www.cgisecurity.com/" target=3D"_blank">http://www.cgisec=
> urity.com/</a><br>
> <div><div></div><div class=3D"h5"><br>
> <br>
> ><br>
> > All,<br>
> ><br>
> > I am reviewing Java EE web application which allows uploads of various=
> <br>
> > file types, stores them in a directory, and then offers the same files=
> <br>
> > to other users for download. The files could be images (jpg, gif,<br>
> > png), documents (doc, docx, xls, pdf), or text files(txt, csv).<br>
> ><br>
> > My question is regarding virus scanning of these uploaded files. With<=
> br>
> > vulnerabilities being reported in formats like PDF, I would like to<br=
> >
> > protect the users and infrastructure as much as possible.<br>
> ><br>
> > Are there any best practices for this?<br>
> ><br>
> > What products (commercial or free) should I evaluate for this process?=
> <br>
> ><br>
> > Thanks in advance for any insight!<br>
> ><br>
> > ----------------------------------------------------------------------=
> ------<br>
> > Join us on IRC: <a href=3D"http://irc.freenode.net" target=3D"_blank">=
> irc.freenode.net</a> #webappsec<br>
> ><br>
> > Have a question? Search The Web Security Mailing List Archives:<br>
> > <a href=3D"http://www.webappsec.org/lists/websecurity/archive/" target=
> =3D"_blank">http://www.webappsec.org/lists/websecurity/archive/</a><br>
> ><br>
> > Subscribe via RSS:<br>
> > <a href=3D"http://www.webappsec.org/rss/websecurity.rss" target=3D"_bl=
> ank">http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br>
> ><br>
> > To unsubscribe email <a href=3D"mailto:websecurity-unsubscribe@webapps=
> ec.org">[email protected]</a> and reply to<br>
> > the confirmation email<br>
> ><br>
> > Join WASC on LinkedIn<br>
> > <a href=3D"http://www.linkedin.com/e/gis/83336/4B20E4374DBA" target=3D=
> "_blank">http://www.linkedin.com/e/gis/83336/4B20E4374DBA</a><br>
> ><br>
> > WASC on Twitter<br>
> > <a href=3D"http://twitter.com/wascupdates" target=3D"_blank">http://tw=
> itter.com/wascupdates</a><br>
> ><br>
> <br>
> <br>
> ---------------------------------------------------------------------------=
> -<br>
> Join us on IRC: <a href=3D"http://irc.freenode.net" target=3D"_blank">irc.f=
> reenode.net</a> #webappsec<br>
> <br>
> Have a question? Search The Web Security Mailing List Archives:<br>
> <a href=3D"http://www.webappsec.org/lists/websecurity/archive/" target=3D"_=
> blank">http://www.webappsec.org/lists/websecurity/archive/</a><br>
> <br>
> Subscribe via RSS:<br>
> <a href=3D"http://www.webappsec.org/rss/websecurity.rss" target=3D"_blank">=
> http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br>
> <br>
> To unsubscribe email <a href=3D"mailto:[email protected]=
> g">[email protected]</a> and reply to<br>
> the confirmation email<br>
> <br>
> Join WASC on LinkedIn<br>
> <a href=3D"http://www.linkedin.com/e/gis/83336/4B20E4374DBA" target=3D"_bla=
> nk">http://www.linkedin.com/e/gis/83336/4B20E4374DBA</a><br>
> <br>
> WASC on Twitter<br>
> <a href=3D"http://twitter.com/wascupdates" target=3D"_blank">http://twitter=
> .com/wascupdates</a><br>
> <br>
> </div></div></blockquote></div><br>
>
> --0016364d318f611564048afc26e2--
>
----------------------------------------------------------------------------
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.