Cross-site scripting protection disabled
ID |
java.xss_protection_disabled |
Severity |
high |
Resource |
Misconfiguration |
Language |
Java |
Tags |
CWE:79, NIST.SP.800-53, OWASP:2021:A3, OWASP:2021:A5, PCI-DSS:6.5.7 |
Description
Cross-Site Scripting (XSS) vulnerabilities occur when untrusted input is improperly sanitized, allowing attackers to inject malicious scripts into web pages.
Web / template frameworks can provide some protection against XSS, but this protection can be disabled. The detector reports where the framework configuration disables XSS protection.
Rationale
Disabling XSS protection exacerbates this risk by removing browser or application-level defenses designed to mitigate such attacks. XSS vulnerabilities can occur if output encoding is disabled in web frameworks or template engines that provide this feature against XSS attacks.
Consider the following scenario where an XSS protection header might be disabled, leaving the application vulnerable:
import javax.servlet.http.HttpServletResponse;
public class XSSProtectionExample {
public void disableXSSProtectionHeader(HttpServletResponse response) {
// Disabling XSS Protection Header
response.setHeader("X-XSS-Protection", "0");
}
public void displayUserInput(String userInput, HttpServletResponse response) throws IOException {
response.getWriter().write("<html><body>");
// Potential XSS vulnerability by directly using user input
response.getWriter().write("<div>" + userInput + "</div>");
response.getWriter().write("</body></html>");
}
}
In this example, the method disableXSSProtectionHeader
sets the X-XSS-Protection
header to “0”, effectively disabling a fundamental browser-level defense mechanism against reflective XSS attacks. Furthermore, direct embedding of userInput
without proper encoding leads to a high XSS risk.
Remediation
To fix the vulnerable code shown before, make sure that the XSS protection header is set:
public class SecureXSSExample {
public void enableXSSProtectionHeader(HttpServletResponse response) {
response.setHeader("X-XSS-Protection", "1; mode=block");
}
}
In addition, consider encoding input potentially taken from untrusted input before inserting in HTML code, according to the context in the HTML content:
import org.owasp.encoder.Encode;
public class SecureOutputExample {
public void displayUserInput(String userInput, HttpServletResponse response) throws IOException {
response.getWriter().write("<html><body>");
// Safely encode user input
response.getWriter().write("<div>" + Encode.forHtml(userInput) + "</div>");
response.getWriter().write("</body></html>");
}
}
To mitigate the risk of XSS vulnerabilities in web applications, ensure the following strategies are implemented:
-
Enable XSS protection in framework / templating engines: Always configure escaping by default of HTML content appropriately. Only in certain cases should the default escaping be deactivated, ensuring that user input is validated or neutralized against XSS attacks.
-
Output encoding: Encode all user-supplied data that is included in HTML content to prevent the execution of malicious scripts. Use encoding libraries for HTML encoding appropriate for your environment.
-
Content Security Policy (CSP): Implement a robust Content Security Policy to help prevent XSS attacks by controlling resources the browser is allowed to load and execute.
-
Input validation: Validate inputs thoroughly, allowing only expected and acceptable data to reach different layers of your application.
-
Security testing: Regularly perform security testing, including SAST, DAST (Dynamic Application Security Testing), and penetration testing, to identify and address potential XSS vulnerabilities and other risks.
The old X-XSS-Protection header is deprecated on most modern browsers, as its functionality is flawed or incomplete for most but the most trivial XSS attacks. The header itself introduced new security issues, including cross-site information attacks.
|
By incorporating these preventive measures, web applications can significantly reduce the likelihood and impact of XSS attacks, safeguarding both the application and its users effectively.
References
-
CWE-79 : Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
-
OWASP Top 10 2021 - A03 : Injection.