In a previous blog post, I outlined how you could use ModSecurity to inject defensive JS into the HTML response page sent to the client web browser. The goal of this technique was to override many common JS elements that are often used by security researchers/attackers when conducting reconnaissance testing for XSS flaws. While this was an interesting PoC for using ModSecurity in combination with defensive JS, it had one fatal design flaw: the detection logic was exposed to the attacker. By sending our defensive JS code to the client, we are tipping our hand to the attacker as to our intention and methods. This allows attackers to then play around with various evasion methods.
Ideally, we need to keep this type of detection logic server-side, away from the prying eyes of attackers. But how then do we detect Browser/DOM events server-side? This blog post will
PhantomJS describes itself as:
PhantomJS is a headless WebKit with JavaScript API. It has fast and native support for various web standards: DOM handling, CSS selector, JSON, Canvas, and SVG.
PhantomJS is created by Ariya Hidayat.
It is useful for:
The key browser functionality at play with PhantomJS is that it uses the WebKit browser engine that is found within Safari and Google Chrome. For our purposes, the fact that it is "headless" is key as we want to use it for server-side inspection of HTML data to help identify XSS attacks.
Due to the fact that PhantomJS can utilize WebKit's full browser environment, we can detect successful reflected XSS attacks much more accurately than a server-side app/WAF regular expression filter. The main advantages are:
By using PhantomJS, we can do our analysis at execution time within the Browser DOM after deobfuscation.
In order to use PhantomJS to detect successful XSS attacks, we need to be able to pass it real data from live HTTP transactions.
Have I mentioned how completely awesome the Lua API is in ModSecurity? Well, it is. It allows you to hook in any external program you want which creates an endless number of integrations. With Lua, we can use ModSecurity to extract the required HTTP data and pass it off to PhantomJS for inspection. Here is an example rule that launches our js-overrides.lua script:
SecRule RESPONSE_HEADERS:Content-Type "@contains html" "chain,id:'85',phase:5,log,pass"
SecRule &ARGS "@gt 0" "chain"
SecRuleScript /usr/local/apache/conf/crs/lua/js-overrides.lua
This script will run at the end of the current transaction (phase:5 in ModSecurity) after the response has already been sent to the client. This is done to limit latency impacts on clients so the response is not held while PhantomJS tests are being run. If you want to do active response blocking, you could move this rule to phase:4. The rule will check the response content-type to verify it contains html data and then checks to see if there was any parameter data being sent to the web application (as we would see in a reflected XSS attack). If these conditions are met, it will then fire off the js-overrides.lua script:
The Lua script exports the RESPONSE_BODY content obtained by ModSecurity and dumps it into a temporary OS file. It then executes the highlighted PhantomJS command with two arguments:
Let's now take a look at the xss.js file contents:
The script creates a new PhantomJS WebPage object and populates it's contents with the data in the highlighted line. This line essentially mimicks our previous PoC example where we manipulated the outbound HTML response going to the real client and prepended our JS overrides code (in the js-overrides.js file) to the top. Here are the contents of the js-overrides.js file:
The script then calls up the wp.evaluate command to have PhantomJS/WebKit evaluate the contents of our web page.
In order to test this setup, we can take examples from the xssed.com archive such as this one that has been fixed:
The highlighted parameter data would then be reflected into the response body content like this:
And this would execute in the web browser and issue the JS Alert pop-up box:
After the PhantomJS script evaluates the web page data, the JS overrides code would identify the JS alert code execution and it would generate the following ModSecurity event:
As you can see, we now are able to accurately identify when actual JS code executes in a client-side context thanks to PhantomJS/WebKit without having to expose our detections to the end user!
In addition to our JS Override proxy code, we can also gain alert data generated by WebKit if client-side code attempts to violate security policies. One such can is when JS attempts to access the document.cookie data. Here is another example taken from xssed.com for an old flaw in the zdnet.com site that is fixed:
When this successfully executes, PhantomJS/WebKit will generate the following ModSecurity alert indicating a DOM Security violation:
Up to this point, we have only been using PhantomJS to evaluate the HTML response body and looking for certain events. There is another key piece of XSS protection that is available within WebKit that we can take advantage of: XSSAuditor.
Leveraging WebKit's XSSAuditor
The WebKit engine contains reflected XSS protection code called XSSAuditor (an excellent whitepaper by the developers is here). The XSSAuditor filter is located in between the HTML Parser and JS engines which helps with its accuracy.
XSSAuditor will analyze inbound client data with the outbound, parsed HTML data to see if there is any executable code found from the client within the response. If there is, then XSSAuditor would generate a console alert similar to the following:
In order to use WebKit's XSSAuditor component, you must initiate an actual HTTP request. We do not want to replay the captured request data on the live web application as that could have negative impacts to the current users application flow. Fortunately, PhatomJS comes equipped with its own embedded web server! We can therefore use it to send/receive data captured by ModSecurity from the live transaction. Let's take a look at the updated ModSecurity rule as it is executing a new Lua script called xssdetect.lua:
SecRule RESPONSE_HEADERS:Content-Type "@contains html" "chain,id:'85',phase:5,log,pass"
SecRule &ARGS "@gt 0" "chain"
SecRuleScript /usr/local/apache/conf/crs/lua/xssdetect.lua
Here is the updated xssdetect.lua script contents:
Notice the new bolded/highlighted sections as we now also need to gather the inbound request URI data (including QUERY_STRING contents). We then execute PhantomJS again but we pass it a new file called xssdetect.js and two more arguments holding the names of the temp OS files holding the request/response data. Here is the contents of the xssdetect.js file:
The xssdetect.js script does the following:
If this same request from the previous ZDnet XSS screenshot was sent through our server-side implementation, we would received the following alert indicating that WebKit's XSSAuditor blocked execution of reflected XSS code:
While I must admit that I am pretty excited about the possibilities for server-side XSS detection with this proof of concept, there are some considerations that must be addressed if you want to field this setup in a production environment.
There are many security researchers who have in part inspired this work and/or who directly helped me with developing this proof of concept: