WordPress 3.7 Public Release Notes and Updates To Keep Track Of

WordPress Security Issues A Concern For Future WordPress Use

The newest version of WordPress has been release tot he public this week on Thursday Oct. 24. With this update WordPress is looking to the future of WordPress Security by offering some pretty cool features that will help users in maintaining their blogs. 

You can check out WordPress Codex for 3.7 here: http://codex.wordpress.org/Version_3.7

Anyone running a WordPress blog likely noticed the standard update notification on their blog dashboard. As with any new WordPress updates it is helpful to fully understand what the changes are and how they may affect your blog.

*IMPORTANT* 

Before you upgrade your blog make sure to backup your files. WordPress has stated that this update will affect pretty much every single WordPress Core File. This is not the time to forget all those core modifications you may have done. 

Make sure you follow these best practices when making your WordPress Updates:

http://codex.wordpress.org/Upgrading_WordPress

Let’s take a look at some of the updates and how they relate to our favorite topics, WordPress Security.

Two major highlights of this version are included here:

  • Background Updates
    • Automatic updates for maintenance and security updates.
    • Daily updates for developers using nightly builds.
  • Stronger Password Meter
    • New password meter to encourage users to choose stronger passwords.

WordPress posted this about the recent upgrade for 3.7: http://codex.wordpress.org/Upgrading_WordPress

For WordPress 3.7+, you don’t have to lift a finger to apply minor and security updates.

 

Most sites are now able to automatically apply these updates in the background. If your site is capable of one-click updates without entering FTP credentials, then your site should be able to update from 3.7 to 3.7.1, 3.7.2, etc. (You’ll still need to click “Update Now” for major feature releases.)

We like these features for a couple of reasons. So let’s see what they will mean long-term by looking at any pros or cons of these changes.

WordPress Security Updates:

  • Pros:
    • The ability for WordPress to update minor fixes, many of which are security issues, without interaction from the admin.
    • WordPress also states that there will be “Optional filters for background updates, to allow for fine-grained control”
    • This means that you will not miss any security updates because you forgot to login for a month.
    • Faster development. By getting daily updates to developers and people testing beta releases more stuff can be fixed quicker, this could result in more efficient updates.
    • Stronger passwords are always nicer from the owner / admin side which has the potential to thwart some password attacks.
  • Cons
    • Unless WordPress 3.7 “strictly Enforces” the recommendation for a user to use a stronger password will not truly fix anything. We use strong passwords here, in many cases exceptionally strong. We suggest users with password issues always store them securely using a program like KeePass or RoboForm Password Manager.
    • Automatic updates can still present problems. Consider Microsoft’s updating process when you think of automatic updating. Just because updates are done for you does not mean that this update will be fully operational or correct for your needs.What if it affects a change you made, impacts your HTaccess files?
    • Consider what could happens if someone at WordPress accidentally causes an error? Does this mean an error that is pushed out into the WordPress system will then get pushed out to ten of thousands of blogs?
    • What will WordPress consider optional? We like control over our sites. You should too. This means we want it to completely optional.
    • Is there going to be a log of what changes are “published” to the blog as a result of the auto-updates? Sure WordPress keeps track of a changelog, but I want to be able to incorporate this into a tracking plugin that monitors and logs all system usage.

Additional things to consider for the newest WordPress version are these user interactions:

Users

  • Ensure that the user_activation_key is hashed in the database
  • Trim leading and trailing spaces from passwords when saving
  • Streamline the behavior of the default password nag after login

Personally we would like to see even more of the user information encrypted in the database. Why not encrypt any and all sensitive information about a user?

Perhaps WordPress will consider encrypting the username in the future? Too many users use “admin” on their websites as both the login and the author name. While WordPress does give you the option to change your “seen as” naming internally, we feel this would be a easy enough fix to force users to have a login name and a “distinctively separate”: author name or pseudonym.

This could go a long way to preventing “brute force” attacks if it was mandatory for anyone with “administrator” access to also supply a separate author name and force this information when an admin posts to the site.

We actively prevent our admins from posting from an admin account. Specifically to avoid any issues with having the Admin usernames publicly known. Brute force attacks are much easier when the attacker already knows the username.

Additionally we would love to have as a core update the ability to change the username, the User ID, and a naming restriction option.

Updates for Developers

Additionally, WordPress 3.7 has added a considerable number of updates with regards to the developer side of WordPress.

At the time of release there were 16 new Class Structures, 22 new functions, and over 20 new filters just to get you started. WordPress has not listed exactly what all of these do as of the time of this post. We will go back from time to time to see which ones get their own write-ups.

Those of direct interest to us for security concerns, which could truly be all of them, but the top ones we will keep an eye on are:

Class Structures:

  •  WP_Automatic_Updater
  •  WP_Http_Streams
  • WP_Http::handle_redirects()

Again, since we understand that automatic updates can still cause problems, we would also want to know what the updater itself can do.

  • WIll it be able to write to the system? I would think so.
  • Will it be able to overwrite user updated files? I would think so.
  • Will it overwrite config files? I think it might.
  • Will it make Database changes? Probably.

Depending upon how “customized” your site is, these auto-updates may be more problematic then one might think. It will be nice to see if we will have the ability to “disable” the auto-update options or not. We like to review the updates being made to our system.

Another issue I would love to know is if we can “log” the updates. We track all user activity on our sites. This includes users and admins alike. when something goes wrong, we can look at the logs and know exactly who did what and when. We do not want to lose that option simply because “the system automatically updated stuff”.

We need to rollback versions sometimes when that happens. We don’t want to give up complete control to WordPress Auto Updates.

Anytime you can manipulate the HTTP calls and redirects to a site there is a potential for problems. Check out the post we wrote on Click-Jacking, to get an idea of why this could be a concern to us.

Anyone with enough programming knowledge knows that pages can be redirected away from a site and pointed to just about anywhere. This may present a problem for visitors and site owners.

The last thing anyone wants is to point you to a fake site, or worse a hacked site. Owners stand to lose reputation, customers, and income. So we will keep an eye on these classes for future reference.

Functions:

  • got_url_rewrite()
  • verify_file_md5()
  • find_core_auto_update()
  • get_core_checksums()

Much like the Classes above, we will keep our eyes looking at these functions. These functions cover basic issues that we feel could be exploited or in some manner cause trouble.

Same redirect like issue as seen above would be a concern.

Anytime you verify MD5 strings to me presents an issue. Why is that? Because it will matter if someone can use that function in a template or plugin to cause harm.

Despite the community benevolence, not all plugins are safe to use. Plugins have been created that will dig through and extract information from your blog. After all, once you install a plugin it is in your system. You give it permission to do what it wants.

Sample Problem: That means these four functions, depending on how they are written and structured could be used to redirect your access to a hacked site, verify a false md5 code, while telling WordPress that it could be a core update and making it pass a checksum count. Effectively installing false updates or hacked core files.

Now no one wants to see that happen. But you have to remember, when it comes to WordPress security, there will always be people out there who do not have your best interest at heart. People write viruses, hacks and break into websites. There have been many cases were programmers have made code that was “intended for good” but used for bad.

Filters:

  • got_url_rewrite
  • post_password_expires

We actually look forward to this. Being able to implement filters based on both url rewrite and passwords could be quite useful in theory.

Where you might implement url rewrites could be just about anywhere. Plugins that handle affiliate links, for instance to rewrite the urls into seo friendly versions. From a security standpoint it would be nice to be able to track anything that is causing a rewrite. Perhaps a security checking program would implement a test to make sure which plugins are rewriting urls and whether or not they should be.

Password expiration is something we believe in, however not too many WordPress websites enforce this kind of issue. We have seen admins using the same password for many number of years.

But what about password protected posts? How many people have put passwords on posts only to have that password hacked? Many users might even forget that they used the same password as the admin access. Ooops. Don’t think it doesn’t happen.

We feel that anytime and any place you can put a password on the site should at least have the options to control those passwords, whether it be expiration, updating or encrypting them. 

The Future Of WordPress

WordPress is likely going to be around for many years to come. So much so that they even expect to release a 3.8 version sometime in December.

This release was led by Andrew Nacin, backed up by Dion Hulse and Jon Cave. This is our first release using the new plugin-first development process, with a much shorter timeframe than in the past. (3.6 was released in August.) The 3.8 release, due in December, will continue this plugin-led development cycle that gives much more autonomy to plugin leads and allows us to decouple feature development from a release.

In fact, there were over 200 developers credited for helping with this release version. WordPress is making it easier for developers to actually develop.

For developers there are lots of options around how to control the new updates feature, including allowing it to handle major upgrades as well as minor ones, more sophisticated date query support, and multisite improvements.

WordPress has always been a great platform for users and admins alike. But please remember that as any systems grows, the potential for problems and security related concerns also grow along with it.

With over 200 developers working on a single release you run the risk of code errors. It happens. When it happens those involved will do their best to fix the issue, which will now hopefully be a much faster, more streamlined process.

Ultimately WordPress Security for your blog comes down to you, your abilities and your knowledge.