Example 1: RCE in datatables.net
Datatables.net provides a free library for displaying table data as HTML, available to everyone. The home page of datatables.net suggests using a .js library file that resides at cdn.datatables.net on your site.
This means that a lot of websites on the Internet use the resource cdn.datatables.net as a source of their scripts, and in the case of compromising this resource it will be possible to get an access to all these sites.
While browsing through the company’s services, it was discovered the application https://editor.datatables.net/generator/, which allows generating and testing custom tables on the backend side. Each time a new table was generated, a new PHP file was created on the server. Using a hole in filtering of the input parameters for creating the PHP file, I was able to reproduce an RCE attack: a malicious request injected arbitrary PHP code into the generated file.
When clicking on the link of the generated file and adding the parameter 1=cat /etc/passwd, the contents of the /etc/passwd file were obtained.
It was checked that this vulnerability could be used to access files on cdn.datatables.net, which potentially allowed exploiting the vulnerability on more than a hundred thousand sites.
Example 2: Path traversal in Tealium iQ
The Tealium iQ Tag Management System service is used by many companies to organize tags on their websites.
This vulnerability has been caused by an inadequate processing of the profile name data, received from the user’s input value. Here are the basic parameters utilized by Tealium iQ necessary to post profile data on tags.tiqcdn.com:
https://tags.tiqcdn.com/utag/<Account Name>/<Profile Name>/prod/utag.js
The problem is that the server allows the characters
. to be used in the profile name. Such characters can be exploited to manipulate the directory into which a profile is loaded. For instance, in case the profile name has a value
I have created a convenient exploit that could easily alter the contents of any .js file at tags.tiqcdn.com.
This vulnerability has been detected and reported as part of the Uber Bug Bounty and another private Bug Bounty program.
At the time the vulnerability was discovered, the websites of Uber, Microsoft, Cisco, Intel and thousands of other sites were at risk.
Example 3: DOM Based XSS in TradingView Charting Library
The TradingView Charting Library is very popular across cryptocurrency exchange platforms. Most crypto exchanges use this library as a function in their services to display online trading charts. On September 24, 2018, data on high-risk DOM Based XSS library vulnerabilities was introduced. All exchanges using this library were vulnerable.
Any web app, using the TradingView Charting Library in its services, stores a publicly accessible HTML file called
tv-chart.html on the server. This file is used to initialize trading charts through location.hash parameters. As a result of the charts initialization, the iframe link to the page of the following type is loaded onto the page.
The vulnerability was located in the third-party trading charts loading function. The function used a link obtained from the user input of the
indicatorsFile parameter, and transferred it to
When users clicked that link, the following code was executed: xss.rocks/xss.js.
After the vulnerability had been publicly disclosed, TradingView released a new library version to fix it. The function, responsible for loading third-party charts, was changed. The new version of this function looked as follows.
This fix was incorrect and the vulnerability can still be reproduced using the
customIndicatorsUrlparameter while adding the
As of this moment, a new library version has been released. It completely fixes the vulnerability.
All exchange platforms, included in the CoinMarketCap list, were tested for vulnerable library version. As a result, 90 vulnerable exchange services were identified, including those with top trading volumes. All vulnerable exchanges were notified of the vulnerability.
- 46 exchanges ignored that alert
- 44 exchanges responded to the alert and requested technical data
- 19 exchanges fixed the vulnerability
- 7 exchanges suggested the reward
When testing a web application for security, you should always consider the third-party products used, because in many cases they are no less important than first-party.