Cross-Site Scripting (XSS) vulnerabilities

SOCFortress
5 min readOct 3, 2024

--

Need Help?

The functionality discussed in this post, and so much more, are available via the SOCFortress platform. Let SOCFortress help you and your team keep your infrastructure secure.

Website: https://www.socfortress.co/

Contact Us: https://www.socfortress.co/contact_form.html

Intro

CISA and FBI have recently released a Secure by Design Alert on Eliminating Cross-Site Scripting Vulnerabilities. Vulnerabilities like cross-site scripting (XSS) continue to appear in software, enabling threat actors to exploit them. However, cross-site scripting vulnerabilities are preventable and should not be present in software products.

References:

Cross-Site Scripting (XSS) vulnerabilities

Cross-Site Scripting (XSS) vulnerabilities are a type of security flaw that occurs in web applications when an attacker injects malicious scripts into webpages viewed by other users. These scripts are typically executed in the victim’s browser and can be used for malicious activities such as stealing sensitive information, defacing websites, or taking over user accounts.

XSS is one of the most common vulnerabilities found in web applications and can be highly dangerous if not properly mitigated.

There are three main types of XSS vulnerabilities:

  • Stored (Persistent) XSS:
    The malicious script is permanently stored on the target server (e.g., in a database) and executed when a victim accesses the affected page. This type of XSS can have widespread impact as it affects all users who view the compromised content.
  • Reflected (Non-Persistent) XSS:
    The malicious script is embedded in a URL and reflected back to the user by the server, usually as part of a search result or error message. The script executes when the user clicks on a specially crafted link.
  • DOM-Based XSS:
    This type of XSS occurs entirely on the client-side, where the vulnerability lies in the document object model (DOM) rather than server-side code. The attacker’s script is injected and executed through modifications of the DOM in the victim’s browser.

Attack flow:

  1. An attacker injects a malicious script into a web page or URL.
  2. A victim visits the web page or clicks the crafted link.
  3. The victim’s browser executes the malicious script, allowing the attacker to perform unauthorised actions.

Common XSS Attacks:

  • Stealing cookies or session tokens to hijack user sessions.
  • Redirecting users to malicious websites.
  • Defacing websites by altering webpage content.
  • Keylogging to capture user inputs.

Prevention:

  • Input validation: Ensure that user inputs are properly sanitised and validated before being processed or rendered.
  • Output encoding: Encode user inputs before displaying them in the browser to prevent scripts from being executed.
  • Content Security Policy (CSP): Implement CSP headers to limit the execution of scripts on a webpage.
  • Use secure libraries and frameworks: Many modern web frameworks have built-in mechanisms to mitigate XSS risks.

Prevention and Protection at the edge: ModSecurity + OWASP CRS

Apache ModSecurity and the OWASP Core Rule Set (CRS) are powerful tools that can help mitigate Cross-Site Scripting (XSS) attacks as part of a broader web application firewall (WAF) strategy.

ModSecurity

ModSecurity is an open-source web application firewall (WAF) that sits between the web server (like Apache or Nginx) and users. It acts as a layer of defence by intercepting and analysing HTTP requests and responses, helping to block malicious traffic before it reaches the application.

For XSS, ModSecurity can:

  • Detect and block malicious input patterns: It analyzes incoming requests to identify suspicious strings that match known XSS attack vectors (such as JavaScript or HTML injection attempts).
  • Real-time request inspection: By examining all HTTP requests, ModSecurity can dynamically inspect and block those containing malicious payloads commonly used in XSS.
  • Flexible rule customization: You can write custom rules to prevent XSS specific to your application’s context or unique attack surface.

However, ModSecurity by itself relies heavily on the quality of the rules it’s using. This is where the OWASP CRS becomes critical.

OWASP Core Rule Set (CRS)

The OWASP CRS is a pre-defined set of rules for ModSecurity, designed specifically to mitigate various common web application vulnerabilities, including XSS. It provides a comprehensive set of default rules that protect against many forms of XSS.

The OWASP CRS includes numerous pre-configured rules that detect XSS attack patterns by checking for script tags, JavaScript code, and other common vectors in user input or URLs.

CRS rules apply strict input validation on incoming requests, ensuring that potentially harmful characters (like `<`, `>`, and `’`) are identified and blocked. CRS can detect XSS attempts in various parts of an HTTP request, such as headers, query parameters, forms, or even URLs, providing broader coverage than typical application-side validation alone.

CRS is maintained by the OWASP community and it is regularly updated to cover new XSS techniques and attack patterns, ensuring that even evolving threats are caught.

ModSecurity acts as the enforcement engine, inspecting HTTP requests and responses, while OWASP CRS provides a powerful, well-maintained set of rules that detect XSS attacks.

This combination allows protection without modifying code (web app), providing an additional security layer beyond in-app sanitization.

While ModSecurity and OWASP CRS are not a replacement for secure coding practices, they add significant value as part of a defence-in-depth strategy against XSS and other web application attacks. (See the secure by design guide referenced above).

WAF and Packet Filters: WAZUH’s Active Response.

Levearing Wazuh’s active response, we can block traffic using Packet Filters in the WAF after ModSec has blocked a web request (403, Forbiden).
For this, we need to inspect WAF activity via Apache Logs and translate WAF blocking event into a kernel packet filter rule.
Additionally, we can also detect web scans via event correlation and apply filter rule as well.

ModSec + Packet filter flow:

Need Help?

The functionality discussed in this post, and so much more, are available via the SOCFortress platform. Let SOCFortress help you and your team keep your infrastructure secure.

Website: https://www.socfortress.co/

Contact Us: https://www.socfortress.co/contact_form.html

--

--

SOCFortress

SOCFortress is a SaaS company that unifies Observability, Security Monitoring, Threat Intelligence and Security Orchestration, Automation, and Response (SOAR).