SoFunction
Updated on 2025-04-13

Common forms and prevention methods of SpringBoot XSS attacks

introduce

Cross-Site Scripting (XSS) is a common security vulnerability. By injecting malicious scripts into web pages, attackers can execute these scripts when browsing the web page, thereby stealing sensitive information, hijacking sessions or performing other malicious operations. In Java Web applications, XSS attacks are also a security issue that needs attention.

XSS attacks refer to an attacker inserting malicious scripts into the input data of a web page. When other users browse the page, these scripts will be executed on the user's browser. Since the script is executed in the context of the victim user, it can access all session information and permissions of that user, which may lead to security risks such as information leakage, session hijacking, malicious operations.

Here are some common forms of XSS attacks and prevention methods:

Common forms of XSS attacks

Storage XSS (Stored XSS)

An attacker stores malicious scripts on the target server, such as a database, file system, or application cache. When other users access a page containing malicious scripts, the script is executed.

Features:

  • The attacker constructs a URL containing a malicious script, which is executed immediately when the victim accesses the link.
  • Usually, this kind of attack is injected through HTTP request parameters (such as query strings, form submissions, etc.), and the malicious code is reflected back to the browser for execution.
  • It will not be stored on the server for a long time, and users need to be induced to click on specific links before they can be triggered.

For example, an attacker submits the following comment in a blog comment system:

<script>
  ='/upload?cookie='+;
</script>

When other users view this comment, their cookies are sent to the attacker's server.

Reflected XSS (Reflected XSS)

The attacker injects malicious scripts into the target website through URL parameters or other input fields. After the victim clicks on a link containing the malicious script, the script will be executed immediately.

Features:

  • Attackers inject malicious scripts into the content stored by the server, usually databases, message boards, comment systems, etc.
  • When other users access this stored data, the malicious script is executed in the victim's browser.
  • Malicious scripts are stored in a server or database, and all users who access the victim page will be attacked.
  • The attack is not required to click on a specific link to trigger the attack, just visit the relevant page.

The attacker constructs a malicious URL:

/yyyy?q=<script>alert('XSS')</script>

If the server directly embeds the search terms into the response without filtering, the user will see a warning box after clicking this link.

DOM-based XSS (DOM-based XSS)

The attacker uses client scripts (such as JavaScript) to directly manipulate the DOM in the victim's browser, thereby injecting malicious scripts. This attack does not depend on server-side storage or reflection.

Features:

  • Unlike traditional reflective and storage XSS attack types, it is not passed through the server, but instead injects malicious scripts directly by modifying the page's DOM tree.
  • When an attacker uses JavaScript to operate the DOM, he inserts malicious code into the page and executes it on the client.
  • The attack occurs entirely on the client (browser) and does not involve the server.
  • Malicious code is usually inserted and executed by manipulating the browser's DOM elements.

Suppose there is the following JavaScript code in the webpage:

var name = (1);
("welcome, " + name);

When a user accesses this URL, the malicious script is executed.

Other attack methods:

Use the attribute value of HTML tags to perform XSS attacks, such as<img src="javascript:alert('xss')"/>(Note that not all web browsers support the JavaScript pseudo-protocol, so this type of XSS attack has certain limitations).

Bypass filtering by spaces, enter and Tab keys, such as<img src="javas cript:alert(/xss/);"/>。

Use events to execute cross-site scripts, such as<img src="#" onerror="alert(1)"/>。

Use CSS to cross-site, such as embed JavaScript code in CSS.

Disturbing filtering rules, such as bypassing security detection through case mixing, special character encoding, etc.

XSS defense methods

Input verification and filtering

Strictly verify and filter all user input to ensure that the input does not contain any malicious scripts and prevent malicious code injection.

Use regular expressions or specific libraries to verify that user input meets the expected format, type, and length.

Set reasonable range restrictions on numerical data to avoid safety problems caused by passing in abnormal values.

You can use the whitelist method to allow only specific characters or formats to pass, ensuring that only inputs that meet the expected format are allowed.

Filter or encode special characters (such as <, >, ', ", etc.).

Output encoding

Encode the output content HTML entity to prevent special characters from being interpreted as HTML or JavaScript code.

When inserting data into JavaScript code, JavaScript encoding of untrusted data should be performed, and only the data should be placed in the value part surrounded by quotes.

Remove or escape potential malicious code, such as HTML tags, JavaScript code, or SQL statements.

Use Java's HttpServletResponse object's encodeURL, encodeRedirectURL method, and StringEscapeUtils libraries to encode the output.

Use a safe framework

Modern JavaScript frameworks (such as React, etc.) will encode user input by default to prevent XSS attacks. Avoid direct operation of the DOM, and try to use the framework's binding mechanism instead of manually splicing HTML.

Choose to use security audited frameworks and libraries, such as Spring MVC, JSF, etc., which usually have built-in mechanisms to prevent XSS attacks. Make sure the version of the framework and library is up to date to fix known security vulnerabilities.

Use secure template engines: secure template engines such as FreeMarker, Thymeleaf, etc. They will automatically encode user input to prevent XSS attacks.

Use a secure rich text editor: Select a secure audited rich text editor to make sure it handles user input appropriately.

Set up a secure HTTP response header

useContent-Security-Policy(CSP) header to limit which resources can be loaded and executed.

useX-Content-Type-Options: nosniffHeader to prevent the browser from interpreting the response's content type as other types.

useX-XSS-ProtectionHeader to enable the browser's XSS filter (although modern browsers have enabled this protection by default).

Security configuration and update:

Ensure secure configuration of servers and applications, timely update patches and fix known vulnerabilities.

Configure the database securely to prevent attack methods such as SQL injection.

Audit and monitoring:

Regularly conduct security audits and testing of applications, including code reviews, penetration testing, etc.

Use automated security scanning tools to detect potential XSS vulnerabilities.

Monitor application logs and abnormal behaviors, and promptly detect and respond to security incidents.

The above is the detailed content of the common forms and prevention methods of SpringBoot XSS attacks. For more information about SpringBoot XSS attacks, please follow my other related articles!