Cross-site scripting (XSS) is a web application vulnerability that permits an attacker to inject code, (typically HTML or JavaScript), into the contents of an outside website. When a victim views an infected page on the website, the injected code executes in the victim’s browser. Consequently, the attacker has bypassed the browser’s same-origin policy and can steal private information from a victim associated with the website.
Types:
- Reflected XSS
- Stored XSS
- DOM-based XSS
1.Reflected XSS
- Non-persistent attack – occur when a malicious script is reflected off of a web application to the victim’s browser
- The script is activated through a link, which sends a request to a website with a vulnerability that enables the execution of malicious script
Causes:
- The vulnerability is typically a result of incoming requests not being sufficiently sanitized, which allows for the manipulation of a web application’s functions and the activation of malicious scripts
Impact:
- If an attacker can control a script that is executed in the victim’s browser, then they can typically fully compromise that user. Amongst other things, the attacker can:
- Perform any action within the application that the user can perform.
- View any information that the user can view.
- Modify any information that the user can modify.
- Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.
Examples:
To distribute the malicious link, a perpetrator typically embeds it into an email or third-party website (e.g., in a comment section or social media). The link is embedded inside an anchor text that provokes the user to click on it, which initiates the XSS request to an exploited website, reflecting the attack to the user.
2. Stored XSS – Persistent or Type-I XSS.
- The application stores dangerous data in a database or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content.
- Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information.
Impact:
- An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
Exemple:
Let’s imagine that our app has a “Contact Administrator” function that will open a pop-up where you can type a message, question etc.
Within their message, an XSS payload can be embedded and then the message is submitted. Now, the payload is ready to be executed.
When the Administrator will open the ‘Questions’ part of the app to see all the user’s questions, he will be subjected to the XSS attack:
As the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser then if the malicious user can reproduce a API that can be used only by the Administrator (e.g. edit user role) he will inject that request using ‘Contact Administrator’ option and when the admin opens the application, the request will be executed without problems because all the rights are met.
3. DOM Based XSS 0 or type-0 XSS
Occurs when an application’s client-side scripts write data provided by the user to the Document Object Model (DOM) without proper sanitization. This flaw can allow an attacker to run malicious scripts in the context of the victim’s browser, potentially leading to unauthorized actions on the user’s behalf, data theft, or other harmful outcomes
Impact:
- Data Source: The application reads input from the user, which could be from URLs, document properties (like document.location or document.referrer), or directly from the DOM.
- Data Sink: The application writes this input back to the DOM without adequately checking it for malicious content.
- Execution: If the input includes executable JavaScript code, it might get executed by the browser as it processes the HTML, leading to XSS.
Exemple:
Expectation:
Reality:
Solutions for XSS(cross-site scripting):
- All the above-mentioned sources can be prevented by properly sanitizing the user’s inputs.
- All the user inputs should be encoded => even if malicious content is passed, the app will encode it and it will not be executed.
- For Angular apps, there is a package that can be used: dompurify – dompurify – npm (npmjs.com)
- All the user’s inputs should be sanitized using this function => XSS attacks will be prevented
You may also like: Main Vulnerabilities in Web Applications .
Created by Andrada Vădean, Software Engineer
