What is Cross Site Scripting?
Cross-site scripting (XSS) is a type of client-side injection attack in which a malicious script is injected into a legitimate website and executed there. An attack begins when the user visits the website containing the malicious code. This blog post is intended to present an XSS definition and to show that an XSS vulnerability poses a high risk to the IT organization, as described by the OWASP Top Ten and the Common Vulnerability Scoring System (CVSS).
Intention of the Penetration Tester
XSS vulnerabilities are more and more often found in single page web applications (SPA) as part of a penetration test, because a lot of business logic in the form of Java Script (JS) is moved to the front end. XSS vulnerabilities are probably the most widespread vulnerabilities for high-risk web applications today, as our pentesters are allowed to discover again and again. Even in API calls these attack vectors are found more often. It is important to us that all IT stakeholders understand that this kind of vulnerability is rightly rated with a high criticality and should not be neglected. Accordingly, this vulnerability is also described in the OWASP Testing Guide with a test case.
Types of Cross Site Scripting
Reflective Cross Site Scripting
Reflective XSS attacks, also known as non-persistent attacks, occur when a malicious script is injected from a web application into the victim's browser. The script is activated via a link that sends a request to a website with an XSS vulnerability that allows malicious scripts to execute. Any Java Script code can be executed in this payload
Persistent or Stored Cross Site Scripting
Persistent XSS, also known as stored XSS, is the more dangerous vulnerability. It occurs when a malicious script is injected directly into a vulnerable web application. Thus, the malicious code is executed whenever the victim uses the web page and works without user interaction.
Local Cross Site Scripting (DOM-based)
DOM-based XSS means that a cross-site scripting vulnerability is injected in the DOM (Document Object Model) and does not appear in any part of the HTML. For reflective and stored cross-site scripting attacks, you can see the vulnerability's payload on the response page, but for DOM-based cross-site scripting, the HTML source code and the response of the attack are exactly the same, i.e. the payload cannot be found in the server response. It can only be observed at runtime or by examining the DOM of the page. In contrast to the common XSS variants mentioned above, the web application on the server is not involved at all.
Case Studies with an XSS Attack Vector
With these vulnerabilities, the following practical attack scenarios can be mapped to demonstrate the actual risk of cross-site scripting vulnerabilities. These vectors are not at a reasonable business risk and must be quickly eliminated after detection by an XSS pentest.
- Ad-Jacking - Here, the attacker's advertisement is placed without the declaration of consent in order to earn money.
- Clickjacking - You can create a hidden overlay on a page to execute the victim's clicks for malicious actions, such as an order, on even more domains.
- Credential Harvesting - A popup can be used to collect credentials for certain services.
- Forced Downloads - It is easier to force a download of malicious malware from a supposedly trusted website.
- Crypto Mining - The victim's CPU can be used to abuse processing power.
- Keylogger - Keyboard recordings of the respective browser instance can be read.
- Get geo-location - After user authorization, the victim's geo-location can be accessed. Works only when GPS is enabled.
- Denial of Service (DoS) - The victim's browser may unknowingly participate in the DDoS attack on another target.
- Force browser crash - The infected browser can be made to crash.
- Forwarding - A redirection can be made to any website.
- Tabnabbing - Only a fancy version of the redirection! If, for example, no keyboard or mouse events have been received for more than a minute, this could mean that the user is not at the computer and the current web page could be replaced by a fake one.
- Capturing Screenshots - Thanks to HTML5, screenshots of a website can now be taken and then made available to the attacker.
XSS Penetration Testing Showcase with BeEF
BeEF is the abbreviation for The Browser Exploitation Framework. It is a penetration testing tool that focuses on the execution of malicious code in the web browser, but is not responsible for XSS detection.
Given the growing concern about web-based attacks on clients, including mobile clients, BeEF enables the professional pentester to assess the actual security posture of a target environment based on client-side attack vectors. Unlike other frameworks, BeEF looks beyond the hardened network perimeter and client system and examines exploitability in the context of the web browser. BeEF connects one or more web browsers and uses them as a bridgehead to launch targeted command modules and further attacks on the system from the browser context. This tool is used for a pentest as well as for Red Teaming and is used there for Network Lateral Movement.
In the following the tool will be presented during an attack simulation:
Taking control of web browsers with BeEF [Tutorial]
Conclusion for XSS Attacks
Vulnerabilities of this type have no acceptable risk, are not compatible with normal business risk and should be fixed urgently after the pentest result. Consistent IT security for web services can be achieved with regular pentests, since XSS attacks are among the critical attack possibilities of every cyber criminal. Sensitive data, such as browser sessions, can be captured or complex social engineering attacks can find their starting point here to carry out further attacks into the deeper IT infrastructure. Every input parameter must be thoroughly checked to achieve a high and justifiable web application security!