Please note: this post is incomplete & pending review.
A7 – Cross-Site Scripting (XSS)
XSS Attacks happen when an attacker puts a script on a website, that is then viewed by innocent users. This script runs on the users browser and can do malicious things like collect data, log key strokes, and much more
A simple example of this is if your site allows comments, and a attacker commented, but added
Nice post! <script>badcode();</script> within their comment. This bad code would be part of the webpage, and could run on any viewer of the web page containing that comment.
They key to prevent this type of attack is to filter out HTML, remove any chance of any malicious HTML being used in any user-supplied area of a website. A simple method for this is using a function like
strip_tags() which removes HTML from a string, or
htmlspecialchars() which converts it.
How Does This Apply In WordPress
WordPress has a ton of functions that escape HTML and sanatize user supplied content. The primary method for preventing XSS is the KSES (“KSES Strips Evil Scripts”) library – through the
echo wp_kses("Nice post! <script>badcode();</script>"); // prints only: Nice Post!
As a plugin or theme developer, we must always ensure the HTML content is sanitized the rule of thumb: escape everything. This is commonly overlooked but we must escape all values, even from core database calls like
get_options() incase the database was ever compromised.
Unsafe API functions
The following functions can cause XSS if not secured as they use the
The above must be wrapped in
esc_url() before output.
As a developer, you need be aware of this attack and audit (it’s open source after all) third party themes and plugins that may of missed this vulnerability.