Cleaning up Your Website

 In Security

In my first two posts, I shared how to harden access to the admin tool for your content management system. However, there are a lot of other “backdoors” to the administration of your site that people commonly leave on. Make sure you have not allowed public access to this list of things:

  1. PhpMyAdmin – I see security updates on this one all the time. It is a great tool, but I would not want it publically available.
  2. “Secret ports” or URLs for server management tools like Plesk or Hsphere.
  3. Tomcat admin
  4. QA testing tools that reset accounts, grant gold or membership, or perform any bulk actions. These are common in a dev environment to allow for testing, but sometimes these get uploaded along with the rest of the source.

Consider some of the solutions I offered in securing your admin site, such as moving it to a private server or establishing firewall rules to protect those.

Cleaning up your server though goes beyond just removing admin tools. Many times files are uploaded to the server to test out new frameworks, or files are accidentally copied from the dev system. Here are some extra goodies to watch out for:

  1. Library files for your PHP code. Don’t make these web accessible. If there are any security bugs, then people can call your library files directly. Instead of putting them at /var/www/html/includes put them at /var/www/includes and add that directory to your PHP include path in php.ini
  2. Frameworks and tools you installed to try out and no longer use. These items you were trying out are one of the worst issues since you do not use them, you likely don’t update them, and they quickly become the weakest link.
  3. Old versions of your site or game. If you have an unrefined build process, you probably just copy the directory to /backup then copy the whole thing up again. Like in point #2, those will have all your old vulnerabilities.
    Even worse than #3 is if you do backups or build as .zip or .tar the entire dir, and then leave it on your website. It would not be so bad in /var/www/backups. However, if you stick it on /var/www/html where everyone can download it, all you need is for someone to accidentally leave directory browsing turned on and now your entire source (likely with passwords) is gone. The same is true with log files and reports for those who log in the same directory (or ./logs) as the PHP file doing the logging. If your stuck like this and need backward compatibility try a .htaccess rule or firewall rule that blocks all files of type *.log or *.gz
  4. User file uploads. Sometimes this is unavoidable, like when a user uploads an avatar for their forum graphic. However, if the user is just submitting a bug report or fan art, do not store it on the public web. It is possible to embed PHP code into a .jpg and then trick the server into storing it as a .php file. Strong validation would prevent this, but don’t take added risk.
  5. phpinfo.php – We don’t need to tell the whole world your specific config for PHP.
  6. /server-status and /server-info – this is set in httpd.conf (there is something similar for Nginx, but I can’t find it right now). It tells how many connections are currently established (hackers can use to track the status of a DOS) and sometimes what URLs are being loaded. In those URLs is also sometimes backend web service calls with secret tokens in the URL or passwords.
  7. Exception calls that produce stack dumps (especially with Java) on critical errors. These reveal how the code works and sometimes dump variables passed into functions.
  8. Debugging output – this could include FirePHP output, flash trace statements, and/or stuff put into a hidden div. Some frameworks will dump a full call stack and global variables on a server error – what a treasure trove to give to hackers! Make sure you turn debug mode off in production.
Recent Posts
Contact Us

Hello! Send us your question, and we'll get back to you as soon as possible.

Start typing and press Enter to search