One of the most exciting aspects of modern web development is the potential that comes with building applications specifically for web browsers (or to run "in the cloud.")

Originally, Java was meant to be the "write-once, run-anywhere" solution, but it appears that the web has become the perfect medium for that. Who would've thought, right?

But along with the various browsers that we have available, the technologies that we can leverage, and, quite simply, the neat things we can do, there's still a dark underbelly to web application development - cross-site scripting.

And considering that WordPress is a web application on which many of us build for fun, profit, or to make a living, it's a topic that we shouldn't avoid especially if we want to have the most robust products possible.

In this two part series, we're going to take a look at what cross-site scripting really is, its dangers, how it impacts WordPress development, and then practical steps that we can take for testing our themes and plugins.

What Is Cross-Site Scripting?

Cross-site-scripting, typically abbreviated as XSS, is defined on Wikipedia as this:

XSS enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy.

I think that definition works well if you're familiar with vulnerabilities, same origin policy, and what exactly constitutes an injection of a client-side script, but, for many, that's simply not enough.

A conceptual view of how data travels from client to server.

So let's take a look at cross-site scripting from the ground up before we go any further.

Understanding Client-Side Scripts

Client-side scripts are basically any code that runs on the client-side of a web site or web application. Arguably, the most popular client-side scripts are JavaScript functions. In contrast, PHP would be considered a server-side script.

Another way of looking at it is this: Client-side scripts are sent from the server to the visitor's computer when the web page loads. The script then executes. Sometimes it does something simple like animate a menu.

Other times, it can do something more advanced like make an asynchronous call to the server, retrieve some data based on the users location, and tailor the information they see.

Though this may be using location information provided by the browser, it's still safe as the browser maintains the data and information is being retrieved based on publicly available information.

So What Is Script Injection?

Perhaps a better name for "Script Injection" is "code injection."

Here, an attacker literally looks for some type of input element on your site - this could be a search field, a contact field, a name field, or any other type of element that submits data to a server. This is normally done through the use of a script - sometimes it's malicious JavaScript, but attackers can be successful in inserting PHP or MySQL commands, as well.

Finally, it's referred to as injection because if the attacker is successful, then they are literally injecting their code into your application.

And What's This "Same-Origin Policy?"

The concept of a same-origin policy is simple: It's a policy that browsers enforce that basically permit client-side scripts - such as JavaScript - to make requests to other pages and server-side scripts on the same server (or, the same origin), but not to other domains or sites.

For example, you can setup a JavaScript function to make a call from tutsplus.com to wordpress.com, retrieve data, then display it on tutsplus.com. That would violate the same-origin policy.

Now, to clarify, this is not to say that it cannot be done. Through the combination of creative client-side functions and server-side calls, things can be achieved, but browsers do the best they can to prevent client-side scripts from actually doing this.

Why Is It Dangerous?

At this point, the implications should be pretty clear. Cross-site scripting vulnerabilities can give malicious visitors control over our sites and web applications in ways that we may ultimately not be able to control.

For example, they can range from relatively minor, to much more critical:

• Attackers may be able to gain access to the database and insert data that is then visible to future visitors
• Attackers may be able to gain access to session information, hijack it, and impersonate a user
• Attackers may be able to retrieve sensitive financial information
• Attackers may be able to do all of the above and/or then bring down an entire site
• ...and many more

All of this depends on what features the site offers and just how secure the site really is.

Whatever the case may be, web application security is something that's here to stay. Granted, I believe that we should all specialize in our respective fields, and that security specialists are people with whom we should consult prior to launching a web application that may be containing sensitive information, but that doesn't mean we can't familiarize ourselves with a few basic strategies for our own testing.

How This Impacts WordPress Development

Before we actually look at the practicality of implementing XSS-safe techniques in our development efforts, it's important for us to note why - as WordPress developers - we should even care about this.

Consider this: WordPress is a fullstack web application. It consists of a database, an application layer, and a presentation layer, all of which are extensible by other developers.

The WordPress Stack

This means that WordPress itself is subjected to many of the same security threats that any other web application is, but those who build for WordPress are, as well.

Even if WordPress was highly resilient to any XSS attacks, that doesn't mean that third-party tools such as plugins or themes reap those benefits automatically.

After all, they are built by third-party developers who may not be following best practices when writing defensive code.

All WordPress features aside and at the most basic level, if your work accepts any input from the user in any way, then you're potentially opening the door for an XSS exploit.

I'd even go so far as to say that if you're looking to leverage some of WordPress' core APIs for accepting input and storing data, then you're not completely safe.

After all, WordPress could have exploits that have yet to be discovered.

What We Can Do About It

So this raises the question: If we truly care about the work that we're doing and want to build something significantly more secure, then there are a number of things that we can do.

First, we need to make sure that we're using the proper API functions for handling input fields, attributes, validation, and sanitization. Some of these functions provide features specifically for:

• Data Validation
• Output Sanitization

In fact, the Codex article offers detailed functions on:

• URLs
• Database input and output
• Validating files
• Input Fields
• ...and much more.

I highly recommend reading the article in its entirety.

Secondly, we can run our theme or plugin through a battery of XSS tests that are used to uncover any exploits that we've failed to catch. But we'll cover this in the next article.

Conclusion

To summarize, cross-site scripting refers to the ability for malicious users to insert their own malicious code into our web site, web application, theme, or plugin in an attempt to gain control of some aspect - or all aspects - of the website.

The potential for exploits varies from application to application, but considering that our area of speciality is with WordPress, we'll be focusing on strategies for exploit proofing our work in the next article.