What is Cross-Site Scripting Prevention?
A Cross-Site Scripting attack involves the execution of malicious code on a victim’s browser. Typically, the challenges to prevent Cross-Site Scripting (XSS) vulnerabilities are complex since attacks can be orchestrated at any point in a vulnerable web application. This article explores the best practices for Cross-Site Scripting prevention, types of attacks in modern web applications and addresses commonly asked questions.
But before that, here is a quick introduction to how an XSS attack is orchestrated.
In an XSS attack, the threat actor crafts a malicious script that is routed to the user, then executed by the application browser. This is usually perpetrated by the attacker using input fields to send crafted HTML/JavaScript code to a website which gets interpreted by modern browsers of the victim. The web application includes the executed script as part of its response as if it is legitimate. As soon as this happens, the attacker has full access to all resources available for the current session, including cookies, local storage, form values, etc. In addition, the malicious user may also have complete control over the victim’s machine.
Benefits of Preventing XSS Vulnerabilities
If not detected and fixed on time, cross-site scripting vulnerabilities can facilitate attacks detrimental to the organization. Through XSS attacks, threat actors can easily compromise how websites present content to users. Additionally, attackers can leverage XSS vulnerabilities to seize accounts, exploit user credentials, identity theft, impersonate users and escalate privileges. Other malicious actions they can undertake include uploading malware, phishing attacks, exposure of sensitive data, and orchestration of full-blown attacks.
How to Prevent XSS Attacks
Since its discovery in the late 1990s, XSS vulnerability has been considered a common attack vector widely exploited by attackers. Since there are several identified gaps in the sanitization of user input, security professionals often focus on fixing cross-site scripting vulnerabilities based on two factors:
Programming language used to develop the application.
While considering the factors, security professionals categorize XSS attacks as:
- Reflected attack
- Stored attack
- DOM-based attack
Reflected XSS Attacks
The simplest type of XSS attack is where the application immediately processes and returns unsanitized user input in a search result, error message, or other HTTP responses. The application logic returns an unsafe input as part of the response without rendering it safely or storing data generated by users. In most reflected XSS attacks, the data provided by users never even leaves the browser.
Stored XSS Attacks
A persistent form of XSS that relies on the application persisting user input on the target server. Unsuspecting users then retrieve this data from the application without any sanitization or validation. Modern applications that use HTML5 allow attackers to store the malicious payload permanently on the browser, typically using HTML databases.
DOM Based XSS
The Document Object model is a platform-independent interface that defines a logical structure for accessing and manipulating documents in HTML and XML. Hackers orchestrate DOM-based XSS attacks by modifying the DOM environment on the browser so that client-side code is executed in an unsafe manner. DOM-based vulnerabilities are advanced and challenging to fix since malicious client-side scripts do not go to the server. This makes it difficult for automatic vulnerability scanners and a Web Application Firewall to detect them since they don’t leave traces on the server logs.
Strategies for preventing XSS attacks also depend on the platform/programming language used. In the sections to follow, we will explore how to prevent XSS attacks on the following application types:
- Prevent XSS in PHP
- Prevent XSS in Javascript
- Prevent XSS in JQuery
Preventing XSS in PHP
If a PHP application accepts HTML or Javascript input, the web client executes remote scripts while rendering content. For instance, if the client-side includes a Javascript file:
// http://example.com/darwin.js
document.write("I'm executing");
And the application directly processes a string that is parsed into it:
<?php
echo '<div>' . $_GET['input'] . '</div>';
If the GET parameter contains and is not sanitized, then the PHP’s script output will run the command of the darwin.js script:
<div><script src="http://example.com/darwin.js"></script></div>
This script will display “I’m executing” on the web page.
PHP includes an inbuilt function called htmlentities that can be used to encode HTML entities. Developers call this function to escape user-supplied HTML input.
For Javascript, developers use unicode-escape input. While PHP does not supply a function to do this, it can be done with a PHP code similar to:
<?php
function jsEscape($str) {
$output = '';
$str = str_split($str);
for($i=0;$i<count($str);$i++) {
$chrNum = ord($str[$i]);
$chr = $str[$i];
if($chrNum === 226) {
if(isset($str[$i+1]) && ord($str[$i+1]) === 128) {
if(isset($str[$i+2]) && ord($str[$i+2]) === 168) {
$output .= '\u2028';
$i += 2;
continue;
}
if(isset($str[$i+2]) && ord($str[$i+2]) === 169) {
$output .= '\u2029';
$i += 2;
continue;
}
}
}
switch($chr) {
case "'":
case '"':
case "\n";
case "\r";
case "&";
case "\\";
case "<":
case ">":
$output .= sprintf("\\u%04x", $chrNum);
break;
default:
$output .= $str[$i];
break;
}
}
return $output;
}
?>
FAQs for preventing XSS Vulnerabilities in PHP
Are there any templates that simplify the prevention of cross-site scripting in PHP?
There are third-party libraries that help teams quickly prevent an XSS application vulnerability in PHP. These include:
All these are highly efficient templates that are straightforward and can be used by even beginner-level PHP developers.
What are other ways to prevent XSS in PHP web applications?
- Use htmlspecialchars to obtain HTML entities from special characters
- Use the strip_tags function to strip PHP and HTML tags from a string
- Limit CSS file sources with Style_src
Preventing XSS in Javascript
Javascript is popular with modern web apps because it uses the Document Object Model to create dynamic HTML pages. Unfortunately, data included in the dynamic content may consist of malicious links sent to the webserver from untrusted sources without sufficient validation.
Since Javascript does not include native functions to encode HTML, developers need to create their HTML encoders. For example, to convert a string to HTML, developers should develop a Javascript function similar to:
function htmlEncode(str){
return String(str).replace(/[^\w. ]/gi, function(c){
return '&#'+c.charCodeAt(0)+';';
});
}
The function is used in a script as follows:
<script>document.body.innerHTML = htmlEncode(untrustedValue)</script>
For inputs inside Javascript strings, developers should include an encoder with Unicode escapes. A sample encoder would look similar to:
function jsEscape(str){
return String(str).replace(/[^\w. ]/gi, function(c){
return '\\u'+('0000'+c.charCodeAt(0).toString(16)).slice(-4);
});
}
This is then parsed inside a script as shown:
<script>document.write('<script>x="'+jsEscape(untrustedValue)+'";<\/script>')</script>
Preventing XSS in JQuery
Most XSS attacks on JQuery applications are performed when user input is parsed to the JQuery selector. Developers should use in-built functionalities of the JQuery editor to enable the sanitization of user inputs before they are executed in the JQuery content area. When writing code, developers should use attribute dripping and value encoding capabilities to validate scripts executed by the application. They should also use the serialization.custom and deserialization.custom editor options, as shown:
<script src="https://cdnjs.cloudflare.com/ajax/libs/dompurify/2.0.12/purify.min.js"></script>
<textarea></textarea>
<script>
function sanitizeHtml(html) {
var temp = $("<div></div>").html(window.DOMPurify.sanitize(html));
return temp.html() || "\ufeff";
}
$("#editor").kendoEditor({
tools: [
"viewHtml"
],
deserialization: {
custom: function(html) {
return sanitizeHtml(html);
}
},
serialization: {
custom: function(html) {
return sanitizeHtml(html);
}
}
});
var editor = $("#editor").getKendoEditor();
editor.value('<object
data="data:text / html;base64,PHNjcmlwdD5hbGVydCgic2VjdGVzdCIpPC9zY3JpcHQ+"></object>');
console.log(editor.value());
</script>
`
Risk levels of XSS vulnerabilities
XSS vulnerabilities are the second most prevalent security flaw in modern applications and fall into the category of injections. They are, therefore, in the third position on the OWASP Top 10. XSS attack vectors have an exploitability factor of 3, meaning that even freely available, automated scanners can be used to detect and exploit them. The vulnerabilities also have a detectability score of 3 since they can be readily discovered, especially in mature technologies. Besides this, XSS vulnerabilities have a technical impact of 2, since reflected XSS attacks are moderate and stored XSS attacks are severe. The business impact of these attacks varies with the sensitivity of data and systems exposed.
Other XSS prevention measures
Some methods to prevent VSS vulnerabilities on a vulnerable application include:
Organization-wide awareness
The most significant threat vector for XSS attacks is the user input interface. Therefore, every user of an organization’s applications needs to understand the impact and severity of XSS attacks and avoid the pitfalls that lead to successful hacks. It is also important to disclose special characters and other methods that attackers can use to orchestrate their acts for company-wide preparedness.
User input validation
It is critical to ensure that user-supplied input is clean and valid. This is achieved by first using a safe transfer protocol such as HTTP or HTTPS. Developers should also set up filters to ensure that expected numeric inputs are integers. Finally, Whitelisting also ensures that the application only accepts valid characters.
Escaping/encoding
All user data should be encoded before being committed onto a page. This involves converting non-whitelisted HTML values into entities. For example, in Javascript, alphanumeric values are escaped using Unicode. In most applications, multiple layers of entity encoding are used to embed user input inside other functions safely.
Sanitize HTML input
Developers should limit users from posting HTML markup whenever possible. When user input includes some HTML markup, developers should consist of functions for filtering and encoding. Another method involves using libraries that accept markdown content which is then converted to HTML on execution.
Content Security Policies (CSPs)
CSPs are considered the last resort of the XSS prevention tactic as they allow software professionals to restrict what an attacker can do once they gain control of the system. A CSP is deployed by including an HTTP response header named Content-Security-Policy and supplying a value containing the policy. The policy helps developers control various factors, such as inline script execution, object sources, and the loading of external scripts.
Frequently Asked Questions
How do attackers use XSS vulnerabilities?
Attackers insert malicious scripts through the web page using a hyperlink or a web form. Once the script is executed, attackers can hijack the session, steal sensitive data, or redirect users to malicious sites.
How frequently do XSS attacks occur?
XSS vulnerabilities are the second most prevalent issue for modern applications and are found in about two-thirds of websites. However, while attackers quickly discover these, security teams can also find them fast, reducing the frequency of attacks.
What is the difference between Cross-site scripting and Cross-site request forgery?
With XSS, the attacker uses an endpoint (browser) to send malicious content to be executed by the application. In CSRF, attackers rely on social engineering and other tactics to trick users into performing unintended actions.
How our scanner can help you prevent and detect XSS attacks vulnerabilities
Crashtest Security Suite helps you detect threats such as XSS vulnerabilities by implementing a security vulnerability scanner that provides accurate reports and remediation advice. The continuous, automated vulnerability scanning process allows developers to save time and focus on work while it benchmarks the web app against OWASP top 10 to enhance security posture. In addition, the suite integrates with most existing development stacks and allows you to scan various web applications, Javascript functions, and APIs in minutes.
Try Crashtest Security today to discover how it integrates into your development stack for efficient, automated vulnerability scanning.
This article has already been published on https://crashtest-security.com/xss-attack-prevention/ and has been authorized by Crashtest Security for a republish.
Top comments (0)