WordPress

Protecting Your Site From Content Injection

What is Content Injection?

Content Injection, otherwise known as Content Spoofing, is the act of manipulating what a user sees on a site by adding parameters to their URL. This act is a known form of attack on a website. While Content Injection and XSS (Cross Site Scripting) Attacks are similar, they differ in a few key ways. Firstly, XSS attacks specifically target users by using <script> parameters, mainly using JavaScript. Content Injection by comparison mainly relies on adding parameters to the end of a static URL (/login.php for example).

Here’s a basic example:

For static files like error pages (in this case a 400 error), attackers can manipulate the text on the page to say what they want. You’ll see in the URL bar that the attacker added extra text to the URL which made the error page print the text since it was part of the URL. Notice, they couldn’t make “www.hackersite.com” actually a clickable link in the basic output which is a good sign. But, easily misled visitors may still try to navigate to “www.hackersite.com” based on the text on this page. The general intent of content injection is usually phishing. Or in other words, getting users to enter their sensitive information by misleading them.

So what’s the fix?

In the interest of protecting your site from content injection on static files like the above, you’d want to use the “AllowEncodedSlashes” directive in Apache like so:

AllowEncodedSlashes NoDecode

With this directive you’re telling Apache to not necessarily show a 404 when “encoded slashes” like %2F and %5C in the URL are added, but instead to show the actual page that *should* have come up. Here’s an example from one of my own sites, with and without encoded slashes set to NoDecode:

And with the NoDecode directive set:

So, using the NoDecode option I’m able to let my users see the correct page, even if someone tried to manipulate the URL to print other text.

Another alternative would be to rewrite static files to your WordPress theme’s 404 page. This way users see your custom page instead of the default white-text static error pages (since they can be manipulated as we saw). This isn’t always the best option for all sites though. It all depends on how you want to handle requests with extra content added to the end.

These types of content injection are usually pretty low-risk. This is because all the attacker can do is manipulate text on specific files. If your site is being affected by XSS though, to where they are able to inject URL links and formatting on a page, that is a more serious concern. Use this guide to help prevent XSS on your site.

That’s all, folks! Have more input on content injection? More tips or tricks? Want to hear more? Let me know in the comments or contact me.

The Anatomy of a DDoS

What does DDoS stand for?

First, let’s define the term “DDoS.” DDoS stands for “Distributed Denial of Service.” The concept behind a targeted DDoS attack is: overwhelm a server or site’s resources in order to bring it down. There can be many reasons behind a DDoS: personal vendettas, political disputes, disagreements, getting past security or firewall barriers, or even just for “fun.”

The effects of a DDoS attack can be truly devastating. Beyond server downtime, companies can suffer brand damage, bandwidth/usage overages, and more.

How do DDoS attacks happen?

So how would one go about overwhelming a server’s resources? Most commonly this happens by attackers building a “botnet.” Botnets are typically a series of malware-infected machines connecting to the internet. Attackers will try to add devices like routers, computers, web servers and more to their botnet. A common method for this is to use “brute force” methods to hack into your site or device. Once a device is infected with malware, the attacker can direct the “army” of infected devices to send thousands of simultaneous requests to a site. As a result, one attacker can bring an entire site crumbling down.

The tricky part about the DDoS method is that the requests are coming from a wide range of IP addresses and user-agents. In this way, the attack is “distributed.” With this method the attack is coming from a vast network of devices. There is also a term “DoS” which just stands for “Denial of Service.” Plain “DoS” attacks originate from the same IP address. With this method, security systems are easily able to detect and block the attack. The system simply has to block the IP address to thwart the attack.

DDoS Mitigation

Once a DDoS is started, it’s pretty hard to mitigate the attack. Usually by the time an attack starts, the attacker knows the origin IP address where your site’s content resides. So by the time you get behind a service like CloudFlare or another Reverse Proxy service, it’s too late. While these services “hide” the origin IP address so attackers can’t see it. However, if they’ve found it already, the damage is done. In this case, you’ll need to get behind a DDoS protection service and then move your origin server and update DNS records.

Some common DDoS protection services include:

CloudFlare Business/Enterprise

Sucuri CloudProxy

Imperva Incapsula

Akamai Prolexic

The services above are great to use in preparation of an attack. If you’re already being attacked by a DDoS you would need to implement a service above and then change IP addresses. Or, you can use HiveShield from HiveWind, which can be deployed inside your current infrastructure. You can activate HiveShield even when your site is already being attacked. It will automatically begin deflecting the bad actors without needing to change Origin IPs. This is what sets HiveShield apart from its competitors.

If you want to try HiveShield DDoS protection on your own server, use the coupon code TCHGRLKB. This coupon code is good for 8 cores/$50 a month OR 16 cores/$100 a month, each with a free 30 day trial – a 50% savings!

Whichever service you use, be sure you use one to protect your site now! This way you’re protected against DDoS attacks. And, you won’t have to scramble to move your origin server if you’re attacked. So, which of these services is best? Read up, compare, and find which one is right for your business needs!

Have more questions about security? Is there a topic I didn’t cover? Feel free to let me know in the comments, or contact me.

Streamline Your Workflow with WP-CLI for WordPress

What is WP-CLI?

WP-CLI is the command-line interface for WordPress. What makes WP-CLI useful is the ability to perform administrative actions without actually having to load the WordPress backend. You can use WP-CLI to manage your sites in a more efficient way! You can perform actions in bulk, manage plugins and themes, search and replace your database, and more.

Before getting started, you’ll need to install WP-CLI. This guide assumes you have SSH access to the site where your site is hosted (a requirement to use WP-CLI). From there, use the Quick Start guide to jumpstart your WP-CLI experience.

What can WP-CLI do?

You’d find a shorter list when looking at what WP-CLI can’t do! I’ll cover some of the basics in sections below.

Plugin and Theme Management

WP-CLI allows you to install, activate, deactivate, and update plugins and themes. Keep in mind, when WP-CLI runs it does still load your plugins and themes. If the code in one of your plugins or your theme is triggering a fatal error, this prevents the WP-CLI command from running. You may use WP-CLI to run a command that fails because of a fatal error. In this case read the error output to see whether it’s a plugin or theme causing the issue. If it’s a plugin, add the flag “–skip-plugins” to the end of your command. Or if it’s a theme, add “–skip-themes” to the end.

Here’s a couple examples of things you can run:

$ wp plugin deactivate akismet Plugin 'akismet' deactivated. Success: Deactivated 1 of 1 plugins.

$ wp plugin activate akismet Plugin 'akismet' activated. Success: Activated 1 of 1 plugins.

$ wp plugin update ewww-image-optimizer-cloud Enabling Maintenance mode... Downloading update from https://downloads.wordpress.org/plugin/ewww-image-optimizer-cloud.3.6.1.zip... Unpacking the update... Installing the latest version... Removing the old version of the plugin... Plugin updated successfully. Disabling Maintenance mode... Success: Updated 1 of 1 plugins. +----------------------------+-------------+-------------+---------+ | name | old_version | new_version | status | +----------------------------+-------------+-------------+---------+ | ewww-image-optimizer-cloud | 3.6.0 | 3.6.1 | Updated | +----------------------------+-------------+-------------+---------+

Database management

WP-CLI can also help manage your database. Some functions it can handle include: setting and deleting transients, search and replace, import and export databases, run queries, optimize tables, and manage your wp_options table. WP-CLI will use the database credentials found in your wp-config.php file to communicate with the database. With that in mind, be sure you confirm you have the right credentials in the wp-config.php file before running database commands!

Here are some examples of database functions you can run:

$ wp transient delete --all Success: 5 transients deleted from the database. Warning: Transients are stored in an external object cache, and this command only deletes those stored in the database. You must flush the cache to delete all transients.

$ wp db query "SELECT ID FROM wp_posts WHERE post_name LIKE '%database%';" +----+ | ID | +----+ | 57 | +----+

$ wp db export mysite.sql Success: Exported to 'mysite.sql'.

WordPress core

Using WP-CLI you can also manage WordPress core files. You can check the current version of WordPress, install WordPress core, update your version, revert back to a specific version, convert to Multisite, manage the wp-config.php file, and even verify that WordPress core matches checksums. When reverting down to a specific WordPress version, you’ll need to make sure to add the “–force” global flag.

Below are some examples of WordPress core-related WP-CLI commands:

$ wp core version 4.8.1

$ wp core update --version=4.8 --force Updating to version 4.8 (en_US)... Downloading update from https://wordpress.org/wordpress-4.8.zip... Unpacking the update... Success: WordPress updated successfully.

$ wp core update Updating to version 4.8.1 (en_US)... Downloading update from https://downloads.wordpress.org/release/wordpress-4.8.1-partial-0.zip... Unpacking the update... Success: WordPress updated successfully.

Manage cron jobs

If you use WP-CLI, you can manage scheduled events on your site easily, without needing an extra plugin. You can check what events are scheduled, manually execute cron jobs, verify the status of WP-Cron, and delete cron jobs.

Here are some examples:

$ wp cron event run wp_version_check Executed the cron event 'wp_version_check' in 2.054s. Success: Executed a total of 1 cron event.

$ wp cron test Success: WP-Cron spawning is working as expected.

Manage media and posts

On top of general WordPress, database, and plugin/theme management, you can use WP-CLI to also manage individual media, posts and post types, and importing/exporting WordPress site data via XML. If you’re missing specific image sizes, you can regenerate the thumbnails associated with any image. Be forewarned, if you have a lot of images this may take a long while!

Below you can find some examples of media and post management:

$ wp media regenerate --only-missing --yes Found 116 images to regenerate. 1/116 No thumbnail regeneration needed for "deactivate_activate" (ID 160). 2/116 No thumbnail regeneration needed for "wp_plugin_list" (ID 159). 3/116 No thumbnail regeneration needed for "pexels-photo-190574" (ID 157). [...] 115/116 No thumbnail regeneration needed for "cropped-17361942_10155125372797938_2032688595763223584_n.jpg" (ID 6). 116/116 Regenerated thumbnails for "17361942_10155125372797938_2032688595763223584_n" (ID 5). Success: Regenerated 116 of 116 images.

$ wp post create --post_type=page --post_title="This is an example" --post_status="draft" Success: Created post 161.

$ wp post delete 161 Success: Trashed post 161.

Manage users

Managing users can also be accomplished with WP-CLI. When you use WP-CLI, you can add new users, add capabilities and roles to users, add new user roles, change passwords, and import a list of users from CSV.

Here’s some example user management commands:

$ wp user create test [email protected] --role=subscriber Success: Created user 3. Password: **********

$ wp user delete test --reassign parameter not passed. All associated posts will be deleted. Proceed? [y/n] y Success: Removed user 3 from http://techgirlkb.guru.

Manage Multisite networks

If you manage multiple subsites in a Multisite network, you might run into trouble differentiating the above commands to tell them which subsite to run on. For this, WP-CLI has the “–url=” command. You can use WP-CLI to run any of the commands above on each individual site by adding this global flag. Additionally, you can manage super-admins, manage Multisite-specific meta fields in the database, convert a single site to a Multisite, and more.

Here’s an example of a standard command, run on one subsite of a multisite:

And there’s more!

We’ve talked about a ton of stuff that WP-CLI can manage, but it can do even more. You can combine WP-CLI commands using basic bash skills and save the output of commands. You can add aliases for commonly-used commands so they’re easier to type.

There are also several plugins that have custom-coded their own WP-CLI commands. You can find a full list in the WP-CLI handbook. And, since WP-CLI is open source, you can create your own pull request if you think you’ve identified a bug or want to add a new feature.

To sum it up, WP-CLI is an incredibly powerful tool for WordPress admins to control their sites using command line. Using the tools it provides, you can manage bulk tasks that otherwise would take hours! For a complete list of the various commands you can use with WP-CLI, check out Commands.

What do you use WP-CLI for? Have any other uses that I missed? Feel free to leave a comment or contact me.