A backup is a duplicate copy of the application’s file. Old files might have been for running the program. These files might have been used for the previous update and are now obsolete. There are many servers that contain old backup or forgotten files that may contain sensitive information about the server. The attacker can access these sensitive data. Backup files are files which have nothing to do with the working of the application. These files are created as a consequence of editing application files. These files exist because the developers might perform in-place editing or other administrative actions on production web servers. Due to this technique, the developer might inadvertently leave backup copies, either generated automatically by the editor while editing files. This vulnerability can also occur if the administrator is zipping a set of files to create a backup in the web root.
Impact
Using this vulnerability, an attacker can:-
- gain access to the source code
- find the weak points in the web application and can execute a custom attack to destroy the application.
- access application’s inner workings, backdoors, administrative interface and credentials to connect to the administrative interface or the database server.
Old file
Old files that contain some vulnerabilities but in the up-to-date versions it have been fixed consider about.old.jsp may provide cross-site scripting (XSS) vulnerability that will be fixed in the new file about.jsp but an attacker can find the old file then exploited through that.
Backup file
Backup files can be used to restore the file system in the server. This file may disclose the source code for pages design to the server if an attacker can requesting about.bak file may return the source code for about.jsp, It can be reviewed for vulnerabilities.
Unreferenced files
Files that contain or leak sensitive information that can help an attacker to focused attack toward the application such as absolute file paths, files configuration including references to other hidden content, include files containing database credentials, etc.
Mitigation / Precaution
Beagle recommends the following:-
- try not to edit the files in the web server or application server.
- Ensure the removal of backup files by the developers.
- Use an appropriate configuration management policies were no obsolete and unreferenced files should be stored in the web server.
- try not to edit files in-place on the web server or application server file systems. Editing on the web server will generate backup files by the editors. If you really need to edit files on a production system, ensure that you don’t create a backup. These files need not be generated by the developer, these files might be generated by the editor. Try to avoid this kind of editing methodology. You should sort to this method in the worse case and do it at your own risk.
- Check carefully for any other activity performed on filesystems that might expose the web server like spot administration activities. For example, if you need to take a snapshot of a couple of directories (which is not recommended), you might zip the files first. Don’t forget to delete the zip file.
- Use an appropriate configuration management policies should help to manage obsolete and unreferenced files.
- Try to design in such a way that the application doesn’t store data under the web directory. Files like data files, log files, configuration files, etc should be stored in directories that are not accessible by the web server. This technique is used to counter the possibility of information disclosure.
- The file system snapshots should not be accessible via the web. Try to configure the web server to deny access to sensitive directories.
