A3 (Injection) — Cross-Site Scripting
OWASP introduced the top 10 web application security risks in 2003 which is regularly being updated to make the developers and the organization aware of the web application security. Among the 10 security risks, the first risk is about the injection flaws including the attacks like LDAP injection and SQL injection, For the second and third risks, the issues of broken authentication and sensitive data exposure are listed. Moreover, the attacks like XML External Entities (XXE) attack, Broken Access Control, Security Misconfigurations like misconfigured HTTP Headers, etc., Cross-Site Scripting (XSS) attack, deserialization attack, components with a known vulnerability, and insufficient logging and monitoring are also included in the top 10 web security risks.
Introduction
Among the OWASP 2017 top 10 web security risks, Cross-site scripting is the A7 risk in the list. XSS, cross-site scripting is the Web attack in which the malicious code or payloads are executed in the victim’s browser to take over the session cookies or even take the control of the browser. If the malicious code/script is executed in the victim’s browser, the attacker can take access to the entire browser, the user session, cookies, and other sensitive browser resources.
The cross-site scripting, XSS occurs when the input taken from the clients is not properly sanitized, escaped, and validated. The attacker can maliciously execute the scripts in the victim’s browser to take the control of the whole browser or the user accounts from the vulnerable web apps. The impact of cross-site scripting gets more serious as the attacker can steal the cookie, impersonate the victim and carry out the operations on behalf of the victim. Not limited to the session hijacking, the attacker can leverage the XSS to capture the screenshot, log the keystrokes, remotely control and access the victim’s browser, etc.
The payload to alert the simple cross-site scripting attacks are listed below:
- Blank Alert: <script>alert()</script>, <svg/onload=alert()>, <img src=x onerror=alert()>
- Origin Alert: <svg/onload=alert(document.domain)>
- Cookie Alert: <svg/onload=alert(document.cookie)>
The three types of Cross-site scripting are explained briefly in the sections below:
Reflected Cross-Site Scripting
When the cross-site scripting is attacked from the current HTTP request, can be defined as the reflected cross-site scripting attack. In the reflected XSS, the payloads and attack vectors hidden in the client’s request are processed by the server. If either the request or the response is not sanitized properly, the payload is then reflected in the web application thus executing the malicious script. If the server processing the request does not store the input dynamically to display the response, and only the malicious code from the request is executed, the attack can be said to be reflected XSS.
The Reflected XSS can be generally found in the search box, taking the request from the user, and reflecting the payload thus executing the malicious script on the web page. The simple reflected XSS implementation is shown in the code snippet below.
Here, the payload can be entered in the browser in the name parameter. The Reflected XSS can be verified with the simple XSS payload. When the code is entered in the name parameter, the code then gets processed in the server, as the code does not have any sanitization going on, the same code gets executed on the client-side giving the empty alert box. The parameter where the attack is executed can be demonstrated as:
?name=<svg/onload=alert()>
The Reflected XSS can be identified easily by examining the parameter entered in the browser’s address bar. The impact of the reflected XSS is limited and is less than the stored XSS.
Stored Cross-Site Scripting
When the cross-site scripting is attacked from the database, not properly sanitizing the user input and the response obtained from the database, can be defined as the stored cross-site scripting attack. In the stored XSS, the malicious scripts are not loaded from the client’s request, but from the server’s database by the malicious attacker. The malicious code can be the cookie stealer, hooking script of BeEF, or even the website defacement. If the counter major is not properly created properly before inserting the user input to the database and fetching the data from the database, the malicious user can distribute the malicious code to all the active users of the web page.
The stored XSS can occur in the blog post, the chat and comment section, etc. where the data is to be stored in the database and show the fetched data from the database. The stored XSS is hard to detect as the malicious codes are rendered from the database. Since the coursework is entirely based on exploiting the stored XSS, extending the impact of hacking the browser to the computer.
DOM-based Cross-Site Scripting
This type of XSS attack occurs when the input from the user has directly reflected the Document Object Model, DOM without performing any kind of input sanitization. DOM-based XSS arises in the web app when the attacker controls the source of javascript execution in the DOM and passes it to the source which supports the dynamic code injection. These execution sources can be eval() or innerHTML which enables the attacker to execute malicious javascript codes.
The commonly used source for DOM XSS is from window.location objects. The other sources for DOM XSS to occur are listed as:
document.URL
document.documentURI
document.URLUnencoded
document.baseURI
document.referrer
window.name
history.pushState
history.replaceState
DOM XSS can be simply mitigated by not allowing any data from an untrusted source to alter the value transmitted sink like document.write or eval dynamically.
Impact of XSS
The impact of Cross-site scripting is not only limited to showing the domain name in alert, stealing web cookies, or defacing the webpage. The impacts of Cross-site scripting in a web app are listed below:
- User/Admin Account Hijacking
- Phishing leads to a credential steal
- Malware distribution
- Redirection to other malicious websites
- Arbitrary Request on the behalf of the user
- Crypto mining in the browser
Mitigation Strategy
From the attack from simple stored cross-site scripting to the malware attack on the computer system, the attack is extended to the way possible. The attack can be mitigated following the below-listed strategies:
Properly Sanitizing and Escaping the user input
The input taken from the users shall be sanitized properly using the inbuilt functions like htmlspecialchars, and htmlentities in the PHP scripting language. Similarly, for the Javascript web apps, the issue can be mitigated by properly validating the input, escape the input data, etc. Also, a framework like sanitize-HTML, DOMPurify can be used to properly sanitize the input in the JavaScript web applications.
Using the no-script extension in the browser
The cross-site scripting attack can be mitigated by using the no-script plugin the browser to block the external malicious scripts. Only allowing scripts to be loaded from the trusted origin, the extension further prevents the exploitation if the Javascript is running from an external source.
Using a trusted anti-virus program with Internet Security
The anti-virus program can be used to mitigate the issue further as the anti-virus program regularly monitors and protects against the malicious script, links, attachments, and other malicious threats online. Antivirus software like Avast, Kaspersky, etc. can be used to be protected from both cross-site scripting and malware attacks.
Implementing the CSP header
The content security policy, also known as CSP is the additional layer within the browser that is used to detect and mitigate the attacks like cross-site scripting (XSS), in modern browsers. The attacks can be used for data theft, malware distribution, or site defacement. CSP can be applied through the meta tag as it is used as the HTTP response header. The CSP headers can be used to protect not only against the XSS but also the clickjacking, UI addressing attack, and even packet sniffing attacks. The CSP is supported by all the major browsers like Google Chrome, Mozilla Firefox, Safari, etc. except the Internet Explorer.
Using Web Application Firewall (WAF)
The Web Application Firewall can be used to protect and mitigate XSS attacks. The WAF works in such a way that the malicious and strange requests are blocked by the firewall before reaching the server. The WAFs like Securi WAF, Cloudflare WAF, Fortinet Fortiweb, StackPath WAF, etc. can be used to protect against Cross-site scripting, DDoS, and other injection flaws like SQLi, etc.
Links:
https://owasp.org/www-community/attacks/xss/
https://portswigger.net/web-security/cross-site-scripting
https://www.acunetix.com/websitesecurity/cross-site-scripting/
https://www.imperva.com/learn/application-security/cross-site-scripting-xss-attacks/
https://github.com/cure53/DOMPurify
https://sucuri.net/guides/what-is-cross-site-scripting/
