Last updated at Tue, 14 May 2019 19:34:02 GMT
When attackers compromise a website with XSS, it is important to understand what actually happened leading up to the exploit, as well as information on how the exploit was performed, and have clear information on how to remediate.
The importance of this was recently illustrated to me in working with one of our customers on an alert triggered by an XSS exploit on the customer’s web application. This blog is an account of that incidence.
The XSS Alert
tCell is built in the age of DevOps, and the starting point for almost any type of incident is the alert. In this case, the alert came through a Slack channel alerting the security team that tCell had spotted a suspicious inline script on one of their pages.
A bit of background first, tCell not only monitors the backend servers, but also the browser. This is important because, XSS, by definition, is a browser-side attack. So the best way to identify XSS of all types (stored, reflected, DOM) is on the browser-side.
tCell instruments the HTML pages rendered by the browser, and collects a stream of information about the structure of each page every time the page is loaded. One key piece of data is what unique inline JavaScript blocks exist on each page of the application each time the page is loaded. From this, we know what scripts appear on what pages on what browsers, etc. and when. This telemetry is collected by the tCell cloud service, and goes through a stream processing pipeline built using Apache Spark which performs real-time classification of all this information to identify suspicious inline scripts. When a suspicious script is identified, it results in an alert that tCell then sends to a pre-configured Slack Channel setup by the security team.
The ScriptID
Each unique JavaScript in the system is assigned an ID. Drilling down on the details of this particular script, including:
- What does the script look like “alert(document.cookie)” is suspicious indeed!
- What IP(s) requested the page
- From the IP information, we can also get geolocation information
- What page(s) did it show up on
- What location(s) of the page had the XSS
From this, we have extremely high-fidelity details of the XSS attack. We know what the script looks like, we know what pages are affected, and we can pinpoint the exact location of the page where the exploit occurred.
At this point, the security engineer is quite happy that there’s actionable information for the developer to quickly remediate the problem.
Server Side
Actually, there’s more information that can guide the developer. Remember, tCell not only does browser-side detection, but server-side as well.
How did that XSS get to the application in the first place?
When tCell is installed on an application server, it inspects all HTTP requests and responses within the application, and not on the wire, it can perform deep inspections of complex structures like JSON. In this case, the application is being sent an HTTP POST request with a JSON body, and within the JSON the attacker has a field value:
“><svg/onload=alert(document.cookie)>
Now, we not only know what executed on the page, but what payload was sent that bypassed the application’s defenses.
But Wait! There’s More!
Remember that the IP address we gathered as part of the browser-side analytics is what is happening to the client. So, a curious thing. The IP is coming from Pakistan, and there isn’t a lot of traffic typically coming from Pakistan. Furthermore, the attacking payload was also from the same IP. The clear conclusion (along with the fact that this is an “alert()” call and not a XHR request to an attacker-controlled site) is that this is an attacker probing and subsequently discovering a vulnerability in the site.
Now that we’ve discovered that the attacker is up to no good, we can also look at what else the attacker has tried on the site, and learn from the attack to further improve defenses.
The Takeaway
Developers hate nothing more than problems that are ill-described. With tCell’s multi-layered approach to runtime application security, incident response teams, not only can accurately be informed when an application has been compromised, but they can give clear, detailed information that enables the developer to fix things quickly.
Furthermore, since there are powerful data exploration tools at the security analyst’s fingertips, attackers can be monitored and tracked to learn more about what they are up to, and what responses defenders deploy pro-actively to anticipate the attacker’s actions.