Hate Spam? Turn Off Jetpack Email Sharing

jetpack publicize spam

The past few days have been spent diagnosing various email delivery issues from the AWS web cluster that is running our WordPress plugin store as well as our SaaS locator platform. During this process email routing was pushed from the servers through the AWS Simple Email System. SNS notifications were enabled to monitor the progress and provide some insight as to what was happening on the send mail side of things.

Not far into the mission something odd was showing up. Email delivery notifications were being transmitted from our documentation server — a basic WordPress install with almost no plugins running and a simplified theme. Yet in the “delivered” stack of SNS notifications there were random email addresses being spammed every 30-60 seconds.

The Culprit? Jetpack

Turns out the documentation site has Jetpack installed. It also has the default settings for the publicize sharing enabled. This includes email sharing.

After a good bit of research it was found that the mailing subsytem was being exploited through the front end interface for sharing a post via email. The Postfix mail logs provide immediate evidence of this.

Read More

AWS LEMP Stacks and EFS Issues

Lesson learned — if you are using EFS on production systems you want to be using provisioned throughput mode.

But, before we get into that, let’s go over the details of this implementation…

Service Configuration

We utilize AWS EC2 instances to run multiple WordPress sites hosted in different directories. The configuration is fairly standard: 2+ servers configured as part of an load-balanced cluster. The servers run from the same image meaning they use the same underlying software stack.

Part of that image includes a mounted EFS (Elastic File Storage) directory , used to share WordPress resources between all nodes in the cluster. The original architecture was designed to host not only the typically-shared wp-content/uploads folder of WordPress via this EFS mount but also the code. The thought was that sharing the code in this way would allow a system admin to easily update WordPress core, plugins, or themes from the typical wp-admin web login. Any code updates would immediately be reflected across all nodes.

EFS Web App Code Hosting – A Bad Idea

Turns out this is a bad idea for a few reasons. First of all, EFS volumes are mounted using the NFS4 (network file storage) protocol — this defines how the operating system handles file read/write operations for a network mounted drive. While NFS4 is fairly robust, the throughput of ANY network drive, even on a high speed AWS data center backbone, is much slower than a local drive such as an EBS volume.

That means that even on a good day every PHP file, JavaScript file, or anything else needed to serve up that WordPress web page are going to be a bit slower than normal.

However, the bigger problem comes to light if you happen to choose the default, and pushed as “the mode to use” by Amazon, EFS throughput mode known as “Burst mode”.

Read More

WordPress Continues To Break Things In The Name Of Security

In what has become a nearly annual tradition, WordPress has released yet another update that broke thousands of plugins across the Internet.    As usual, they claim this is in the best interest of security.  Thus the breaking change was done with ZERO notification to developers.   It was also forced onto most sites as a “security patch release” which will update any site that does not forcibly stop automatic updates.

Communication From WordPress Core Is Horrid

While I don’t have an issue with breaking changes for true security issues, what IS a problem is pushing out a change with almost ZERO testing to millions of websites with ZERO communication.    They gave absolutely no warning to thousands of sites that this “update version” was coming and that it would knowingly break things.   They did not communicate to site owners so they could block updates.    They did not communicate to plugin or theme developers so they could come up with new releases.

Read More

Running A Linux Server? Check etcd

If you are running your own Linux server — an AWS EC2 instance, perhaps, you may want to check that your etc daemon I’d not accessible.

Read this ARS Technica article for more info:

Thousands of servers found leaking 750MB worth of passwords and keys

Adding WordPress REST API Security To Basic CRUD Operations

Work has been underway adding REST API functionality to the Store Locator Plus plugin.   Most people are familiar with the basic concept of using REST to fetch data from a remote server.   We use this every day when surfing the web using the basic premise of an HTTP GET protocol.   In short this is the simplest form of a REST “read” operation.   Go here, get this thing and show it to me.

REST APIs get more exciting when  you talk about adding basic create/update/delete operations proving the full CRUD functionality via the REST protocol.    The issue with using REST for these operations , especially via the WordPress REST API , is that you are now exposing your data via  service that anyone with even a touch of technical prowess can now create, update, or delete data elements from your site.     In the case of our locator plugin, we don’t want any random person to send a simple HTTP request to our server and delete a location.

The WordPress REST API provides a simple mechanism for adding security to these types of requests.   It uses the built-in WordPress user authentication and roles-and-capabilities to ensure a user has permission to alter the specific object, in our case location data, before handling the REST request.   To employ this security you will need two things;  A plugin that manages authentication requests  and the addition of a permission_callback parameter to your register_rest_route() call within your plugin/theme class that is managing your REST API.

The first part, adding a plugin, is easily handled by fetching one of the git repositories listed at the WordPress REST API documentation site.   You can choose either Basic Authentication (very weak security) or oAuth (much better option).   Using Basic Authentication is great for development and is what I use when testing RESTful services via phpStorm 2016 with its built-in RESTful service applet.

The second part, adding a permission_callback parameter, is done in the coding of your plugin or them that is managing your REST requests.   This can be handled using a simple anonymous function that returns the results of the WordPress current_user_can() function.     In Store Locator Plus we check to make sure the the user, authenticated with one of the above plugins as part of the source of the REST request, has the capability  of ‘manage_slp_user’ assigned.   By default this is assigned to all admin users when Store Locator Plus is installed.   The register_rest_route call looks like this:

    /**
     * Add a single location.
     *
     * Requires authentication.
     *
     * @route   wp-json/store-locator-plus/<v2+>/locations
     * @method  WP_REST_Server::EDITABLE (POST, PUT, PATCH)
     *
     * @params  string  sl_store        required , name of store
     * @params  string  <field_slug>    optional, other store data. Field slugs can match base or extended data fields.
     *
     * @returns WP_Error | WP_REST_Reponse
     */
    register_rest_route( SLP_REST_SLUG . '/' . $version, '/locations/', array(
        'methods'               => WP_REST_Server::EDITABLE,
        'callback'              => array( $this, 'add_location' ) ,
        'permission_callback'   => function () { return current_user_can( 'manage_slp_user' ); } ,
        'args'                  => array(
            'sl_store'  => array( 'required'    => true ),
        )
    ) );

This setup will check that the REST request has passed authentication and that the user identified with the request has the manage_slp_user capability before executing the add_location method in our REST API class.

Adding security on your POST/PUT/PATCH REST requests is as simple as that.

There are a lot of other tricks built into the WordPress REST API. Keep track of this blog to watch for more articles on WordPress development as I share what I’ve learned each week.

%d bloggers like this: