Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

There is an application I am working on which requires processing the incoming mails to cs@company.com.
The company.com mail accounts are being run via Google Apps for Business.
So I fetch the incoming mails via IMAP and I also store the attachments on the server filesystem.
Attachments are downloadable by the users of the application.
Server is Centos 6.3 and the web interface of the application is based on Apache/PHP/MySql.

My questions are :
1. What kind of security risks I am exposed to by storing the attachments on my server filesystem?
2. Is it safer to store the attachments to an external storage (for e.g. Amazon S3)?
3. Is it safer to store the attachments in the DB?

share|improve this question
    
Very good question. I am pretty curious to know that too... –  Lex Feb 8 '13 at 9:06
    
Can you expand on the access controls uses with your scheme? –  zedman9991 Feb 8 '13 at 12:55
add comment

2 Answers

Technically, a filesystem stores files as opaque sequences of bytes. There is no harm that the said bytes can do to your server as long as you do not try to "interpret" these bytes. Unfortunately, some operating systems are quite eager to interpret file contents, triggering heavy processing without explicit user consent; and that processing could have security holes exploited by maliciously crafted file contents. See this answer for details. Usual countermeasures apply: if you use a maintained OS (like CentOS) and apply published security fixes on a daily basis, then you should be fine. I would still recommend avoiding exploring the directory with a graphical file explorer, so as to avoid automatic interpretation of picture files.

Legally, any act of storing data coming from external sources can put you in trouble, depending on what the file contains and the legal framework in which you operate. When you have a mail server, it is rather unavoidable that you may receive just about anything by email, and most law systems will recognize that, as a technical service provider, you are not responsible for the email contents. It may still be worth talking to a lawyer, though, in particular if you envision creative storage systems. There can be privacy issues, too; you'd better protect access to the storage system for attachments as well as you would protect mailboxes themselves.

Note that safe email handling is not easy; it is considered bad form to lose emails when a badly timed power shortage occurs. Email sending systems are supposed never to physically destroy email data until the receiving system has duly announced that it has committed the email to a physical medium (which, in a Unix filesystem context, entails at least an fsync() call). If you split emails into their main body and separate attachments, then such handling becomes more complex; this is probably easier to do with a database than with a filesystem. Thus, I would recommend the database, not for security, but for reliability.

share|improve this answer
add comment

The security risks of storing these attachments on a fileserver and allowing them to be downloaded through a web application include:

  • Unauthorized downloading/copying of the files
  • Malicious modification of the files, later to be downloaded by the intended recipient
  • Use of the system to host warez, malware, or other troublesome files
  • Execution of the files by Apache as scripts
  • Use of the file storage mechanism as part of an exploit strategy against the server

At the very least, I would recommend:

  • Placing the files on a dedicated filesystem with highly restrictive mount flags
  • Giving them filenames that have nothing to do with their original filenames
  • Being extremely careful with your Apache config
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.