Posted by iStryker on December 17, 2012 at 2:16am
2 followers
Jump to:
| Project: | Backup and Migrate |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
This module is open for security risk by web script crawlers and people not updating their modules. If you query/ping http://www.example.com/system/files/backup_migrate/scheduled/test.txt and get an 403 (access denied), then you know backup_migrate is install on the server. I think this is bad practice.
Comments
#1
While I agree in principal, in practice I'm not really seeing the problem. Backup and migrate is used by almost a quarter of the Drupal sites out there, so if you think you have an exploit for it it's probably easier to just try it on all Drupal sites you know of rather than try and isolate the ones you know to be running B&M. Also the same argument could be made for ANY module that writes any file to a predictable place in the files directory (ctools, styles, boost, etc. etc.) or even any module that adds css or js to the site.
If you want to further harden your own setup you can modify the .htaccess rules to return a 404 instead of a 403 for that file or move your B&M folder out of your webroot altogether. If you want to truly harden your site you shouldn't run B&M on the public facing site anyway (you can run it on a separate, protected site with access to the same DB if you still want to use it).
That said, if you have a practical solution for this then please let me know.
#2