Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

ModSecurity Advanced Topic of the Week: Mitigating XSS Vulnerabilities Using Targeted CSP Enforcement

7828_0a4c1839-aefc-4130-b8ef-daed7cfa01c1Content Security Policy (CSP) Implementation Challenges

CSP is an extremely powerful tool for mitigating Cross-site Scripting (XSS) vulerabilities. The main challenge that organizations run into is that actual site-wide implementation is a daunting task. As the image on the right indicates, implementing CSP site-wide is a bit like eating an elephant. Where do you start? In this blog post, I will highlight how to use ModSecurity WAF to virtually patch identified XSS vulnerabilities by enforcing targeted CSP policies.

Site-wide CSP Development

The biggest challenge associated with developing proper CSP policies for resources is the need to remove all inline JS code from the HTML page. When presenting this task to the developers, they might not be that receptive...

Security Reactions: You want to deploy CSP Site-wide?!?!?

In order to implement CSP, there many steps that must be completed (List developed by Colin Watson) -

  1. Choose one pilot web application and a single functional area with greater security assurance requirements (e.g. payment, checkout, order submission, authentication)
  2. Create a change request for deployment to production and assess the risks
  3. Attempt to remove all inline JavaScript, all inline styles and as much third-party content as possible from the functional area
  4. Create an initial Content-Security-Policy header in development, test locally and apply to staging/test systems
  5. Undertake existing unit tests for the functional area using the latest, recent and legacy web browsers
  6. Make changes to code and/or the policy to determine what can be achieved
  7. Build a mechanism to collect the violation reports, ensuring all data is treated as untrusted and is correctly encoded when utilised, and add a report-uri directive to the header to verify the mechanism
  8. In production, add the directives as a Content-Security-Policy-Report-Only header to the functional area (i.e. not as a Content-Security-Policy header)
  9. Monitor and assess the violation reports
  10. Adjust the policy as necessary and re-test, and re-deploy
  11. Once approved, change the header from Content-Security-Policy-Report-Only to an enforced Content-Security-Policy header for a test group of users
  12. Monitor and update the policy as necessary, and re-test/re-deploy
  13. Gradually extend to all users
  14. Update coding standards so that future development is compatible with the CSP
  15. Repeat for other functional areas
  16. Apply CSP policies to the remainder of the web application (with differing policies as necessary).

These are excellent steps to follow. The problem is that this all takes a large investment of time/resouces to complete. Let's focus in on the bolded first item.

Using CSP for Virtual Patching

What resource(s) should you choose to first implement CSP? How about those resources that have been confirmed to be vulnerable to XSS through some type of penetration test or assessment? Prioritizing these resources has the dual advantage of making CSP deployment consumable and reducing risk for a known vulnerability.

Example Vulnerability (

NOTE - although lists the vulnerability on the pastebin. as "UNFIXED" it is in fact fixed.


When this page was vulnerable, the issue was that the "goprivate" QUERY_STRING data was populated into a FORM field without proper output encoding/escaping:

Here is the actual HTML with the XSS payload:

The JS code at will then over-write DOM elements -

The end result is that the webpage appears to be defaced:


Mitigating XSS with CSP

We will now discuss how to mitigate this particular vulnerability using ModSecurity WAF to add CSP policies for this page.

Analyzing Current Page Construction

You must review the current construction of the page to see if/when/where/how code is being used within the page. A great tool to aid in this effort is call CSP Bookmarklet by Brandon Sterne. Essentially, you create a bookmark with the supplied code and then when are viewing the webpage of interest, you just click on the bookmarklet. It will then analyze the page elements and issue a JS alert popup box where it will provide a recommended initial CSP policy, as well as, notify you of any current violations.

As you can see from CSP bookmarlet popup, there is a recommended policy as well as an alert for an Inline Script Violation.

Removing Inline JS Code

When you encounter inline JS code violations, this is when you should consult with the proper Developer to assist with the process of externalizing this code. In this case, the CSP alert identified the "initPastebin()" function call -

This "onload" event is not allowed per CSP and mut be externalized. One method to do this would be to add an "id" element to the <body> block to reference the initPastebin() call. Then in the pastebin.js file, you could add code similar to the following that would still initate the proper function call when the DOM page loads:

// Add event listeners once the DOM has fully loaded by listening for the// `DOMContentLoaded` event on the document, and adding your listeners to// specific elements when it triggers.document.addEventListener('DOMContentLoaded', function () {  initPastebin();});

Using ModSecurity to Dynamically Add CSP

This is there the virtual patching comes in :) You can implement ModSecurity rules to dynamically add in proper CSP enforcement for this resource. The current CSP spec 1.1 allows the use of the "meta" HTML block to add CSP data. With this capability, we could use the following ModSecurity rule which will modify the outbound HTML using the @rsub operator to inject our CSP policy data.

SecContentInjection OnSecStreamOutBodyInspection OnSecRule REQUEST_FILENAME "@streq /" "chain,phase:request,t:none,nolog,pass"  SecRule &ARGS "@eg 1" "chain"    SecRule STREAM_OUTPUT_BODY "@rsub s/<head>/<head>|00|<meta http-equiv=\"Content-Security-Policy\" content=\"default-src 'self'; script-src http:\/\/\/; style-src http:\/\/\/; report-uri http:\/\/\"<\/>/"

The resulting HTML would look like this -


It is also possible to have ModSecurity set Apache environmental variables and conditionally set HTTP Response headers for the CSP policy as well. This may be necessary if you are using older browsers.

This CSP policy would then instruct Chrome browser to block the XSS payload as we are disallowing inline JS. In the Developer console in Chrome, this event would be generated -


CSP Violation Reporting

One of the features I like best about using CSP enforcement is that you are able to gain insight into violations by using the report-uri directive. Here is a screenshot of the violation report sent from the browser:

In this case, we can alert ModSecurity when a violation occurs by adding the following rule:

## Check the REQUEST_BODY for CSP Violation Report data and generate an Alert#SecRule REQUEST_BODY "({\"csp-report\":{\"document-uri\":\"(.*?)\".*?violated-directive\":\"(.*?)\".*?blocked-uri\":\"(.*?)\")" "chain,phase:2,id:'960001',capture,t:none,log,pass,msg:'Content Security Policy (CSP) Violation for Vulnerable Resource',logdata:'blocked-uri:%{tx.4} violated-directive:%{tx.3}',tag:'OWASP_AppSensor/RP3',tag:''"  SecRule TX:2 "@streq file://localhost/Users/rbarnett%201/Desktop/XSS%20Defacement%20By%20Atm0n3r.html"

This rule inspects the CSP JSON body content of the request and parses out important data. It then checks to the document-uri element to see if it was our vulnerable resource. If it was, it generates this alert message:

[Mon Jul 15 16:23:57 2013] [error] [client] ModSecurity: Warning. String match "file://localhost/Users/rbarnett%201/Desktop/XSS%20Defacement%20By%20Atm0n3r.html" at TX:2. [file "/etc/httpd/modsecurity.d/crs/base_rules/modsecurity_crs_42_csp_enforcement.conf"] [line "33"] [id "960001"] [msg "Content Security Policy (CSP) Violation for Vulnerable Resource"] [data "blocked-uri: violated-directive:script-src"] [tag "OWASP_AppSensor/RP3"] [tag ""] [hostname ""] [uri "/csp_violation_report"] [unique_id "enUZ5cCo8AoAACw8BQ8AAAAP"]


Hopefully this blog post has provided a pragmatic approach for implementing CSP within your site. By focusing and prioritizing resources that have been identified as vulnerable to XSS, it allows your organization to take a smaller tactical approach vs. the enormous task of site-wide CSP development.


I wanted to thank two people with whom I discussed this CSP use-case and content:

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More