Secure backup storage [#191206]

Most excellent module! I could not imagine it better, and I have a rather wild imagination.

A "security Nazi" concern: backup files are stored within Drupal "filesystem", which, depending on the setup, could be secure or not. In fact many modules demand it to be directly accessible.

If it is directly accessible, then the backups (with lots and lots of potentially sensitive data) rely on "security by obscurity". Granted, there is a lot of obscurity there (which is why I assigned "minor" priority), but someone determined would not have too much trouble breaking it.

A potential solution would be to store the backups elsewhere, outside of the document root (just like the secure Drupal filesystem does).

Another solution would be to FTP them out (or scp?) - there is a new ftp API module http://drupal.org/project/drupal_ftp that has been developed to support very similar applications.

Let me know if you want an alpha-tested for these features ;-)

Comments

Comment #1

ronan CreditAttribution: ronan commented 12 November 2007 at 00:56

Good points. I've tried to be conscious of the security concerns raised by this module. I should at least be more explicit in the README and project description of what the vulnerabilities are.

For the first version of this module, I chose (after some deliberation) to use the files directory for storage by default simply for convenience and because it is the only folder that is always writable by the web server. It's not the most secure solution, and I always planned on allowing storage of files to locations outside of the web-root.

To mitigate the danger of publicly accessible backup files, Backup and Migrate currently writes a .htaccess file to it's destination directory which instructs apache to disallow direct access to the files (which is why. I understand of course that this is not a perfect solution, and fails completely in non-apache servers, a better solution is needed.

I meant to do a more thorough write-up on the security issues and I should probably put the warnings on the backup screen itself (not just buried in the README). At very least a caveat emptor is in order. I should also have the module actually check if the save location is vulnerable (by attempting to access the file)

As for backing up to and restoring from ftp/scp/webdav locations, that is most certainly on my future feature list. Support for remote backups and restores could make this a much better module (apart from the security issues involved). Thanks for the heads up on the api module you mentioned.

Comment #2

MarcoR CreditAttribution: MarcoR commented 20 November 2007 at 01:27

Just tried - it works fine. Thank you! Another enhancing solution would be to add a random code.

@andrabr: Naming your concern "security N***" is neither funny nor in any way appropriate to a matter of privacy, which at last gives people the opportunity to live and express freely. Please avoid such terms if you don't know what you are speaking of. Thank you.

Comment #3

andrabr CreditAttribution: andrabr commented 20 November 2007 at 02:27

Ouch!

Comment #4

ronan CreditAttribution: ronan commented 24 November 2007 at 00:37

Status:

Active

» Fixed

I should also have the module actually check if the save location is vulnerable (by attempting to access the file)

I've added a check which should make sure that backup files are not publicly accessible before saving to the server. This should ensure that people are not leaving their data vulnerable without knowing it.

Saving to locations outside the webroot as well as offsite (ftp, scp, webdav, etc) will both be version 2 features.