Quite possibly, one of the most devastating things to a webmaster is when his work of art and dedication is intruded by unwelcome hackers. Online hacking has been a phenomenon as old as the internet itself, there have always been that group of people who love to reverse engineer whatever it is that other programmers have built.
Who can blame them, working as a security analyst can prove to be a very rewarding job, with large checks at the end of the month, as well as the ability to work with latest technology. WordPress has been the most sought after CMS for many years, and we can all agree that it will continue to dominate the market for at least a decade ahead of us.
It’s data as reported by OpenSourceCMS, and only reflects about roughly ~1% of the total market share for all of the content management systems included in the snapshot. However, it does reflect the sheer volume of market share that WordPress has accumulated over the years, and leads us to our next paragraph.
WordPress is the target for many hackers, both black hat and white hat. And, in my opinion – it makes perfect sense. It’s a system that millions upon millions of webmasters use every day. I’d like to direct your attention towards this report by Checkemarx security company, which did a security audit of the top 50 most popular WordPress plugins, and came to a shocking conclusion.
In June 2013, Checkmarx’s research labs ran multiple security scans against the source code of the most popular WordPress plugins. The result? More than 20% of the 50 most popular WordPress plugins are vulnerable to common Web attacks, such as SQL Injection. In total, 8 million vulnerable WordPress plugins were downloaded. This report presents the research findings as well as recommendations and mitigation measures for plugin developers, Web admins and platform providers when developing and installing third-party extensions. [S]
Because WordPress is an open-source community, it is often impossible to keep track of the state of security for each and every plugin, no matter how hard the WordPress team is working to prevent such high percentages of plugins to be vulnerable. But, if you’re a developer and you actually do develop plugins (or plan to do so in the near future), it might be a good idea to take a look at some of these WordPress functions that will help to prevent vulnerabilities, and other security risks.
How do we protect our WordPress plugins?
You can rest assured that the WordPress Codex page does provide insightful and useful information regarding security precautions, but I wish of this post to be somewhat of a reference to you – so if you’re learning or actively developing WordPress plugins; this might be a good resource to bookmark for future viewing.
Turn on Your Debugging
As developers, we’re often thinking about multiple things at once, scouting trough endless files of code and trying to locate bugs that didn’t seem to be there before. All this can make us forgetful, and cause us to forget about some standard methods of protecting and analyzing our code. Always turn debugging ON.
this is what we need to copy/paste in our wp-config.php file that we use on our development environment. This will enable for us to have a live dev environment in which we will see all the necessary error messages that might otherwise gives us headache, and generally waste our time. It’s a very simple thing that is mostly overlooked due to the simplicity.
Avoid security flaws by sanitizing majority of your functions, especially those that are related to database queries, or user input and output – most often the places were hackers will look first, for vulnerabilities and possible exploits.
WordPress provides an extensive list of functions in regards to sanitization, and all are easily to be referenced in the official Functions documentation – all I can say is that they’re all self-explanatory if you’ve seen the basic set of WordPress functions.
Remember to Escape
Untrusted data comes from many sources (users, third party sites, your own database!, …) and all of it needs to be validated both on input and output. It’s best to do the output validation as late as possible, ideally as it’s being outputted, as opposed to further up in your script. This way you can always be sure that your data is properly validated/escaped and you don’t need to remember if the variable has been previously validated.
Validate Your Database Queries
Always pay close attention to how you query your database and whether your queries are sanitized and properly arranged for minimum security risk.
A nonce is a “number used once” to protect URLs and forms from being misused. An invalid nonce causes WordPress to send a “403 Forbidden” response to the browser, with the error message: “Are you sure you want to do this?” You can create a nonce and add it to the query string in a URL, you can add it in a hidden field in a form, or you can use it some other way.
all of these lovely functions will help to authorize and protect your URL’s from being maliciously attacked.
CURL != for WordPress
It is strictly advised against the usage of CURL within your WordPress plugins, and it is a best practice to use built-in WordPress functions that help to prevent security risks that come alongside CURL requests.
Native WordPress Functions
WordPress is serious about security, as it understands its own userbase and the size of it. For that reason, there are many native functions that we can use to protect our plugins, and to make our plugins much faster and more efficient. As seen in this post, it only takes a bit of research to learn about many exciting ways of keeping our plugins AND users safe. In the end, it is all about protecting our property, and making sure our users are safe and secure.
How do you protect your own WordPress plugins?