Cross-site scripting, XSS or arbitrary JavaScript injection is a type of computer security vulnerability typically found in web applications that enables attackers to inject client-side script into Web pages viewed by other users.
For information about cross-site scripting on the client-side, and how to prevent it, see DOM-based XSS .
Examples of Cross-site scripting:
See Exploit examples on Wikipedia for more examples.
Example:
function getTableCell( $out, $value ) {
$request = $out->getRequest();
$class = $request->getVal( 'class' );
return "<td class='$class'>" . htmlspecialchars( $value ) . '</td>';
}
The attacker sends the victim to a URL such as:
http://example.com/wiki/SomePage?class='%20><script>hack();</script></td><td%20class='
POST requests are also vulnerable, using offsite JavaScript.
Victims do not even have to directly visit the page to be affected. Malicious 3rd party websites can embed hidden iframes to crafted URLs to attack a user while visiting a website of theirs. As well they may be tricked into visiting a malicious or crafted URL using short URL services or disguising the URL as another.
To avoid Cross-site scripting do the following:
You can skip validation, but you can never skip escaping. Escape everything.
It does not matter if the escaping is redundant with the validation, the performance cost is a small price to pay in exchange for a demonstrably secure web app. It does not matter if the input comes from a trusted source, escaping is necessary even then, because escaping gives you correctness as well as security.
Escape as close to the output as possible, so that the reviewer can easily verify that it was done. It helps you to verify your own code as well.
Output encoding (escaping) is context sensitive. So be aware of the intended output context and encode appropriately (e.g. HTML entity, URL, JavaScript, etc.)
The OWASP Abridged XSS Prevention Cheat Sheet is a useful and up to date quick reference guide for mitigating XSS issues.
All this is true of any text-based interchange format. We concentrate on HTML because web apps tend to generate a lot of it, and because the security issues are particularly severe. Every text format should have a well-studied escaping function.
Here are some convenience functions which do HTML escaping for your site.
MediaWiki also has some elegant built-in interfaces which implicitly escape your output. For SQL using the 'key' => 'value' syntax of conditions implicitly escapes values. And the Html:: and Xml:: interface methods escape attributes, and depending on the method used may escape a text value as well.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4