Renaming files can be a big mistake

Any project we are working on should always have some type of development environment where we can test code before we take it live (aka “in production”). In reality, this is not always the case due to resource or time related constraints. When working on live sites we don’t want to make mistakes but unfortunately there is a huge mistake we can make while trying to avoid mistakes. This mistake is making backups of files and leaving those backups on the live server, accessible to the world.

But how would anyone know where to look for them? you might ask. Well, they can guess. Us humans are surprisingly similar and assuming a pattern of behavior can obviously yield results. Otherwise the “bad guys” wouldn’t keep trying. I recently reviewed my access logs. Judging by the assumptions made by the hackers, these are the names that people have used in the past when making live backups of their WordPress config file (wp-config.php).

Examples of wp-config backup file scans:

wp-config.php~
wp-config.php.bak
wp-config.php.save
wp-config%20fix.txt
wp-config-backup1.txt
wp-config
wp-config.phpOLD
wp-config.txt
wp-config.phpa
wp-config.old
wp-config.php.txt
wp-config.
wp-config-backup.txt
wp-config-backup
config.bak

Remember that only files ending in .php will be executed before they are served so the examples above deliver all your WordPress database information in plain text format to anyone who were to access those files. If you think you may have done this on a WordPress site in the past, you better undo it asap. If it was a long time ago, there is a big risk the site is now hacked. Ideally, you should not be leaving any backup files on the live site at all. It takes up space can cause confusion for other developers about which files are actually in use. If you have a good reason to leave backups of files on the live server, make sure you put them below the root (public_html/www) so that they are not accessible to the world.

Return 404 response code for certain query strings in WordPress

When WordPress site owners have been victims of hacking they often suffer consequences by getting blocked by Google or getting warnings from Google about malicious URLs on their site. After cleaning the site, these problems can linger when the URLs are only query strings and not actual URLs because query strings will not trigger a 404 in WordPress. One way of fixing this is to gather all the nasty query strings and then set them up to trigger a 404. Here is a basic script that does just that.

To add query strings to the list that triggers a 404, add them in the “force404” array. In the example below the following URLs force a 404.

mywebsite.com/?some-spammy-query
mywebsite.com/?another-spammy-query

Please note that this script requires a 404 template so make sure your theme has one.



add_filter('template_redirect', 'my_404_override' );
function my_404_override() {
	$qs = $_SERVER['QUERY_STRING'];
	$force404 = Array(
		"some-spammy-query",
		"another-spammy-query"
	);
	if (in_array($qs, $force404)) {
		status_header( 404 );
		nocache_headers();
		include( get_query_template( '404' ) );
		die();
	}
}