Advertisement
Security

Cross-Site Scripting in WordPress: What Is XSS?

by

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.

The Internet 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 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:

In fact, the Codex article offers detailed functions on:

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.

Related Posts
  • Code
    ASP.NET
    Preventing Code InjectionCsrf dotnet retina preview
    Often, websites seem to exist primarily to put something into a database in order to pull it out later. While other database methods, such as NoSQL, have gained popularity in recent years, data for many websites still resides in the traditional SQL database. This data often consists of valuable personal information such as credit card numbers and other personal information of interest to identity thieves and criminals. Hackers therefore always look to get this data. One of the most common targets of these attacks is the SQL databases that lie behind many web applications through a process of SQL Injection.Read More…
  • Code
    Creative Coding
    Using WordPress for Web Application Development: Features: Saving DataApplication foundation 400
    When it comes to the web, almost any application that runs within your browser is backed by a data store of some type. Usually, these data stores are in the form of a type of database. Until recently, most applications were built on top of some type of SQL database, but with the rise of document-based databases such as CouchDB, other applications have begun to use other backends as well.Read More…
  • Code
    Other
    Client-Side Security Best PracticesSecurity best practices retina preview
    Thanks to HTML5, more and more of an applications' logic is transferred from server-side to client-side. This requires front-end developers to focus more on security. In this article I will show you how to make your apps more secure. I will focus on techniques that you may not have heard about, instead of just telling you that you have to escape HTML data entered in by users.Read More…
  • Code
    ASP.NET
    Understanding Cross-Site Request Forgery in .NETCsrf dotnet retina preview
    You can only produce secure web applications by taking security into account, from the start. This requires thinking of the potential ways someone could attack your site as you create each page, form, and action. It also requires understanding the most common types of security problems and how to address them.Read More…
  • Code
    Security
    Cross-Site Scripting in WordPress: Practical Tips for Securing Your SiteCross site scripting in wordpress what is xss
    In this series, we're taking a look at how to secure our WordPress projects from XSS - or cross-site scripting. In the first article in the series, we defined what cross-site scripting actually is, understanding how it works, and why it's dangerous. We also spent some time discussing how this impacts our day-to-day WordPress development efforts and what we can do about it. Although there are some functions that WordPress has available to help validate and sanitize data, there is more work that we can do in order to secure our projects. In this final article, we're going to take a look at some practical tips that we can follow and some tests that we can administer to secure our work against XSS attacks.Read More…
  • Code
    Other
    HTTP Succinctly: HTTP State and SecurityHttp cover
    In this last chapter we will look at the security aspects of HTTP, including how to identify users, how HTTP authentication works, and why some scenarios require HTTPS (secure HTTP). Along the way, we are also going to learn a bit about how to manage state with HTTP.Read More…