XSS attacks (Cross Site Scripting, XSS) occur when an attacker enters a piece of code as input. The malicious code is interpreted as DOM markup (gives the browser access to the content of the HTML page) and runs in the victim’s browser. By running their code in the victim’s browser, a cybercriminal can gain access to sensitive data, as well as bypass the Same-origin policy.

Types of XSS attacks

Stored (persistent) XSS (Stored XSS)

The malicious script is injected into the vulnerable application, where it is stored or stored on the vulnerable application page. When the victim loads the infected page in the application, the malicious script executes the user’s session context. Here is an example of persistent XSS in the Elementor Page Builder tool.

The hacker introduced the malware JavaScript code for the site. Clicking on the image launches the payload XSS

Reflected XSS (reflected xss)

An attacker tricks a victim into clicking a malicious link in a vulnerable application. In this scenario, reflected scripts are injected into the user’s browser session and executed as a direct reflection in the HTTP responses returned by the server.

The attacker injected XSS to worker URL, and the injection is returned to the victim’s browser, where the payload is executed.

XSS on basis DOM (DOM-based XSS)

DOM-based XSS also includes a malicious link and can be injected into the victim’s browser via the same attack vector as reflected XSS, but DOM-based XSS does not require interaction with the server. Malicious code is stored and executed in the browser.

The cybercriminal embeds a malicious script in the URL, when connected to this page, the victim’s browser parses the HTML page, reaches the script and runs it, extracting the malicious JavaScript. Thus, server-side code protection will not protect against DOM-based XSS attacks. The independence of the attack from the server also complicates its detection.

What can an attacker do XSS-attack?

By injecting code into the victim’s browser, a cybercriminal can:

• Steal sensitive user information – login credentials, credit card information and other personal data;
• Intercept the user’s session (if your application allows JavaScript to read HTTP session information);
• Send and receive data from a malicious web server;
• Access the user’s webcam, microphone, and location through the HTML 5 API or other known browser vulnerabilities;
• Use advanced phishing methods that will be difficult to identify not only for an ordinary user, but even for a specialist.

Protection against XSS attacks

Secure the framework

Fewer XSS errors appear in applications built using modern web frameworks that have improved security features and help mitigate XSS attacks using templating, auto-escaping, etc. You need to understand how the framework prevents XSS attacks and where there may be vulnerable areas in it.

Achieve perfect injection resistance

For a successful XSS attack, a cybercriminal needs to inject and execute malicious content on a website. Therefore, every variable in a web application must be protected. The guarantee that all variables are tested and then escaped or cleared is called perfect injection resistance. Any variable that does not go through this process is a potential vulnerability. Frameworks allow you to achieve perfect stability, in which all variables are checked, escaped or cleared.

However, even popular frameworks like React and Angular have security gaps. Output encoding and HTML sanitization help to address these shortcomings.

Use output encoding (Output Encoding)

Use your platform’s default output encoding if you want to display data as the user enters it. Automatic encoding and escaping features are built into most platforms.

If you are not using a framework, or need to close security gaps in a framework, then you should use an output encoding library. Every variable used in the user interface must be passed through an output encoding function. A list of output encoding libraries is included in the application.

There are many different methods for encoding output because browsers parse HTML, JS, URLs, and CSS differently. Using the wrong method can lead to vulnerabilities or degrade the functionality of your application.

Clean up HTML

Sometimes users need to generate HTML. You can give clients the ability to change the style or structure of content in a WYSIWYG editor. Encoding the output here will prevent an XSS attack, but it will break the app’s functionality and the styles won’t render. In these cases, HTML scraping should be used.