Technosailor.com

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

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:

might have some code that supplies apropriate content,

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:

Now, his page is actually running this command:

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.

Pick up your copy of the WordPress Bible, a wildly popular resource for beginners and experts alike.

Written by Aaron Brazell on September 28, 2006

Popularity: 1% [?]