Last week two very popular plugins, WooCommerce and WordPress SEO, identified, fixed, and disclosed security issues. The details of these vulnerabilities are now publicly available, which allows other developers to learn from their mistakes.
In a previous article for Torque, I discussed the importance of responsibly disclosing security issues. To get a better understanding of this in relation to the recent vulnerabilities I reached out to James Golovich, a WordPress developer who recently discovered security issues in WP All Import, Easy Digital Downloads, and IgnitionDeck as well as several other plugins and themes, which he details on his highly informative blog.
James’ site not only educates developers on how to avoid making the same mistakes, but also provides an excellent example of responsible disclosure and good cooperation where developers act swiftly to protect their users.
Lately, there have been lots of security vulnerability disclosures in several WordPress plugins. And, while publicly announcing these vulnerabilities may damage WordPress’ reputation, the speed at which these issues are being resolved shows the strength of our community. No software is perfect or will ever be perfect. We are lucky to have a supportive, connected community that can fix these types of issues so quickly.
I spoke with James to get a clearer understanding of what these issues are, and what plugin developers should be on the look out for in their own code. Since hackers are on the lookout for these vulnerabilities, too, now is the time to double-check your code. The more security issues that are identified and fixed by their respective developers or by responsible researchers like James and security companies like WordFence—who discovered the WooCommerce vulnerability—the less dangerous these issues become.
My conversation with security expert James Golovich
I know James through his active contributions to the Pods Framework. Though he didn’t discover our recently disclosed security issue, he was the first person we consulted to review our fix and help us with the disclosure process.
Our issue dealt with an unsanitized GET variable being used to create a MySQL query, similar to the vulnerability found in the WordPress SEO by Yoast plugin, which is actually what prompted our review. In the process we also found and reported several similar issues in other plugins.
To help educate the community on what exactly these issues are, and to help developers avoid them, I asked James a few questions to help explain these issues:
Can you explain what the issue is with the orderby query that seems to be so common?
Somehow it slipped past everyone (myself included) that it’s very common for people to take untrusted user input, send it into esc_sql(), and assume it to be safe. This function is intended to be used for user input that is enclosed in quotes in SQL commands. It is almost always better to use the $wpdb->prepare() function call.
Can you explain what an SQL Injection attack is and what the potential danger is for site owners from the SQL injection vulnerability disclosed last week in WooCommerce and WordPress SEO?
SQL Injection attacks are always rated in the top 10 types of vulnerabilities. It always starts with untrusted user input that gets inserted into SQL commands. Depending on the usage the attack can allow someone to login to a user account without a proper password, retrieve additional information from the database, or even completely trashing the database.
These most recent vulnerabilities are dangerous, but not extremely critical, in my opinion. In general most of them require the admin to click a link that includes the SQL injection. The most severe cases don’t require admin intervention and are easily scriptable.
What is the best way for developers to find similar issues as these themselves before they are found by others?
Always think like an attacker would. Just because your file upload form is safe behind an admin interface doesn’t mean that the actual upload functionality you hook into during the ‘admin_init’ action is safe as well. I recommend using a debugger and stepping through the code to see what is actually called and when. [ and also to look at] which WordPress actions/filters [are used].
What are other common lapses plugin and theme developers make that lead to security vulnerabilities?
It always comes down to trusting user input. The most common issues I see are:
- Believing the is_admin() function is true when a user has administrator privileges, when really it returns if the loaded page is under the admin section.
- Not properly checking authorization on AJAX calls. There are two types of AJAX calls on WordPress one is accessible to anyone and the other requires a valid account on the system (not just an admin account).
- Always use a nonce and/or current_user_can() to properly verify authorization.
- Allowing user input into eval() or other similar function calls
- Using predictable data for naming files/directories for data uploads. ie: Calling md5( time() ); is not a safe way to properly name a temporary directory.
In your experience when issues are reported to plugin developers and WordPress.org security, are they handled properly and responsibly?
In general most developers are very receptive to information about security vulnerabilities. They usually request additional time after the issue is resolved before disclosing to give time to notify their customers and for people to upgrade.
I have not had any direct contact with the WordPress.org security so I can’t comment on that. I suspect they are being overwhelmed with issues now that people realize they can force push security updates.
Stay vigilant, friends
Because of the openness in these disclosures, we can expect to see more disclosures of similar issues in the coming weeks. If anything, it should motivate other authors to fix and make an honest disclosure of the issues affecting their plugins while everyone else is doing it. Together we can create a more secure WordPress ecosystem.
For more information on data validation and security, and keeping WordPress code secure in general, I recommend studying following links: