Advanced WordPress Security
By Grant Stokley
Copyright 2020 Grant Stokley
All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses permitted by copyright law.
Published by Grant Stokley
gingsoft.com
Table of Contents
Index
Conventions used in this book
The following typographical conventions are being used in this book
Bold
- Exact names for things that you should be seeing in the browser.
Mono-spaced
- Is for code or command line
- Three dots are used to identify where the output of logs, source code, or configuration files have been truncated to make it easier to locate the subject matter.
Introduction
This book goes beyond the basics and dives into more advanced defenses. Ill show you how to surgically replace WordPress PHP code with a deceptive modification. The attacker can brute force every possible password, and never know which one is correct. You dont need to be a developer; Ill show you step by step. Ill show you how to hide your username from common enumeration techniques, so the attacker wont even know which users password to attack.
Ill show you how to stop ongoing attacks then blacklist the attacker. For a more secure approach, use whitelists, user-agent strings combinations, and a 2FA plugin. Plugins are like trojan horses, they provide functionality for you and the attacker. Ill show you how to use free tools that perform static and dynamic application security testing (aka SAST & DAST) on the plugins, so you can avoid installing risky plugins that compromise your WordPress site.
Have you ever wagered on the Kentucky Derby? If you have, then you might be familiar with the online advanced deposit wagering platform, twinspires.com. That website and mobile application will accept your money, allow you to place your bets, and pays you when you are a winner. On Derby Day, tens of thousands of registrations, deposits, and wagering transactions happen every minute leading up to the big race. There is a lot riding on that application.
I was a member of the Information Security Team (aka InfoSec) at Churchill Downs Inc. focused on application security for twinspires.com. Before moving into that role, I was a software developer for twinspires.com. So, I have a deep understanding of what it takes to secure web applications on multiple levels from the code itself, the servers it runs on, the networks that are traversed, all the way out to the Web Application Firewall. Im giving you my application security experience in this book.
Chapter 1 | Configuring Access Control
Overview
Apache access control can be configured using either the directory level .htaccess files or apache2.conf, the main Apache configuration. You can allow or deny based on partial or full IP addresses, subnets, domain names, and even environment variables such as user-agent string.
Allow, Deny, & Order
To give you some context as to what this looks like, Figure 1-1 is an example of a Directory directive in the apache2.conf file.
FIGURE 1-1 Use of Directives
There are three directives that you will use to configure access control. The Allow directive identifies which hosts can access the directory. Conversely, the Deny directive identifies which hosts will be denied access to the directory. The Order directive sets the default state to be either a whitelist or a blacklist configuration.
FIGURE 1-2 Default action is to deny
An example use case for the Order directive might be something like Figure 1-2. During the development, you take a whitelist approach by allowing only the subnets where the system administrator and developer hosts reside and deny all other hosts. When the site is finally ready to be released, you will reverse the order of the directives and allow all hosts, except for known bad actors, like in Figure 1-3.
FIGURE 1-3 Default action is to allow
Access Control Rules
The rules are relatively straight forward when evaluating for access control:
Syntax for the Allow and Deny directives
To create an access control rule, follow these syntax rules:
- Use from before you designate the target of the rule (e.g. Allow from or Deny from ).
- The target can be full domain names (e.g. Allow from awpsec.com ).
- The target can be partial domain names (e.g. Deny from .com ).
- The target can be IPv4 or IPv6 addresses (e.g. Deny from 13.37.13.37 ).
- The target can be partial IPv4 or IPv6 addresses (e.g. Allow from 10.0.0 ).
- The target can be network/subnet mask (e.g. Deny from 13.37.13.0/255.255.255.0 ).
- The target can be a CIDR notation (e.g. Allow from 10.0.0.0/24 ).
- The target can be all (e.g. Allow from all ).
- The target can be an environment variable (e.g. Allow from env=siprnet_user ).
In Figure 1-4, you can check your configuration files for syntax errors without starting the server by using sudo apache2ctl configtest or just sudo apache2ctl -t command line option.
Figure 1-4 apache2ctl
Troubleshooting Example
You are in the development stage of building the website. No one (Deny from all) but you (Allow from 111.2.3.45) should have access to it. You have read this far and have implemented the Directory directive that you think will work similar to Figure 1-5.
FIGURE 1-5 Double deny issue
You restart Apache2 so the changes you made take effect, by typing apache2ctl restart .
apache2ctl restart
You hop over to the browser and receive an error like this is Figure 1-6.
FIGURE 1-6 Forbidden error from Apache