WordPress Themes: XSS Vulnerabilities and Secure Coding Practices

As many might imagine, my life revolves around Information Security. If you’re like me, you’re undoubtedly seeing all these new posts talking to insecurities in WordPress themes, specifically a plethora of Cross-Site Scripting (XSS) vulnerabilities. Surprise, surprise, right? Yeah, no, not so much.

So what’s the big deal? Honestly, not much. It’s the same thing that has plagued other development groups for years. What’s perhaps most frustrating is that these are simple mistakes, especially when it comes to WordPress.

I recently attended a SANS course in Las Vegas, SANS Network Security 2012. In it the instructor said if there is anything you can do, as a developer, it’s to perform Explicit Error Checking. If you accept 5 characters, then verify both the size and character set. Fundamentally the principle and advise is simple and sound, and the kicker is it’d help address not just Cross-Site Scripting attacks but OS Command injection, Buffer overflows, and SQL injection attacks.

But saying that is one thing, implementing is another. Being that the time to write about each would be too exhaustive, let’s look at WordPress specifically. Before we do, let’s understand this thing called Cross Site Scripting.

Cross-Site Scripting

Before we can implement corrections to a problem, we have to understand the problem. So what is this thing known as XSS? We can turn our head to The Open Web Application Security Project for an official definition. This is how they describe it:

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

Meh, that definition is OK. For the layman, all it is saying is that it represents a weakness in which someone with malicious intent is able to pass something via your website to the server; this can in turn be used to impact other visitors to your website. When they say browser side script, they’re often referring to JavaScript which most folks have enabled, but it’s not restricted to that.

An example of this would be if you found a website that asked you for username and password, or even your address and you typed in something like this:

<script>Alert(‘XSS Susceptible!!’);</script>

This in it of itself is benign, but if successful it would use JavaScript to render a pop-up on your screen that would read:

Now things aren’t so nice any more. Now I am using the document.location object in JavaScript to reference a file on another server to execute something. Something that probably isn’t as nice as my first attempt.

So what can you do about it in WordPress? Well, let’s talk about that.

To keep this post to a reasonable size I’m going to focus solely on the recommendations to address XSS issues, but please note that there are many other attack vectors that should be looked into and it’s highly recommended you watch the videos also.

Escape late – do it as close to the potential vulnerability point as possible. If you escape before that you’re likely to lose track of what is safe and what is not. – Mark Jaquith

In Harris’s post he goes into much more detail for each rule. Specifically the input validation which is just as important as the output, but here we’ll reference out-of-the-box functions that come with WordPress.

What’s important to note about these escape functions is that they reference whitelist libraries. Whitelist libraries are fundamentally better than a blacklist library which are exceptionally hard to maintain. Hopefully this helps some of you, if nothing else it should help build your awareness around the built-in WordPress functions designed to help you build more secure products.

If you have any questions about this post please leave us a comment or send us an email info@sucuri.net.

Tony is the Co-Founder / CEO at Sucuri. He shares a deep passion for Information Security, Business and Brazilian JiuJitsu. He approaches the business the same as he trains BJJ, one move at a time and gently. You can follow him on twitter: @perezbox.

Excellent advice, One of the real dangerous with XSS however is the ability to create a connection back into the victims machine, by exploiting a vulnerable website, A legitimate user visits the website and wholla, by clicking a reflected link they’re in trouble.

Jut filtering tags is never a good idea as something like <script> will work!

Prevoty

Thank you for covering such an important, overlooked topic, Tony!

The best way to deal with cross-site scripting (XSS) and other content injections targeting WordPress vulnerabilities is to prevent them from happening in the first place. Recognizing this problem, we created a plugin that takes the guesswork out of dealing with these attack vectors.

SmartFilter is a free plugin that acts as a preview layer to sanitize and validate ALL incoming content for you. It doesn’t rely on blacklists or past definitions and has the same technology we use to protect large enterprise sites. It’s also deployed on the cloud so it won’t slow down your site.