1. VULNERABILITY INTRODUCED

When development teams use component-heavy development patterns, they sometimes do not even understand which components they use in their applications much less keeping them up to date.
Developers often do not know:

• The versions of all components they use (both client-side and server-side);
• If the software they use (OS, web/application server, database management systems, run-time environments, and libraries) is vulnerable, unsupported, or out of date;
• If the underlying platform, frameworks, and dependencies are fixed or upgraded in a timely fashion;
• If the compatibility of updated, upgraded, or patched libraries is tested.

Some of the largest breaches (like the Equifax hack) have relied on exploiting known vulnerabilities in components.

09/2014: ShellShock allowed remote code execution, resulting in password files theft, downloading malware to the vulnerable server with WGET, DoS attacks, and more.

04/2014: Heartbleed allowed attackers to read a window of arbitrary memory from web-servers that used OpenSSL, often leaking private encryption keys, contents of web requests/responses and more.

09/2017: Failure to patch Struts2 OGNL Injection vulnerability in the Jakarta Multipart Parser component allegedly resulted in the Equifax hack, largest known hacking incident in history (so far) with personal information of 143 million Americans leaking. They took their time patching, and look what happened!

It’s obvious that vulnerabilities in frontend components are not as critical as the ones on the backend. There was no buzz about any critical vulnerabilities in frontend components that led to the leakage of personal data or money theft. Those vulnerabilities usually affect a single user and do not cause massive and/or severe damage.
Security professionals and developers usually update backend components and keep track of backend vulnerabilities, but they tend to forget about frontend components or simply ignore the need to update them. Nevertheless, this sometimes can lead to bad consequences. The nastiest consequence of using a vulnerable frontend library is usually an XSS.
If an attacker can trigger the XSS, then they can do whatever they like inside the browser:

• Steal confidential data like session cookies
• Read every key the user presses on the keyboard
• Use the users’ browser as a cryptocurrency miner
• Perform any action on behalf of the user in the application

2. EXAMPLE OF THE VULNERABILITY

The majority of websites that use JavaScript on the frontend import JQuery library to run scripts and most of those websites use an outdated version of JQuery library. For example, there is a vulnerability in the JQuery library prior to version 3.0.0. that allows an attacker to run an arbitrary script in the user’s browser under specific conditions (CVE-2015-9251). Severity and probability scores of this vulnerability are low, but anyway it leads to an XSS.
Let’s consider the case when the application uses outdated JQuery library to make a cross-origin request to a malicious website without specifying anexpected data type of the response. Under these conditions, the malicious site may trigger an XSS.

3. EXERCISE BACKGROUND

Alice is a freelance software developer. For one of her customers, she developed the news portal Coolnews.me that among other components uses a weather widget that requests data from the server each time the browser loads the corresponding page. As this widget was planned to be used on multiple domains, the weather server allows cross-domain (CORS) requests.
Alice had a tight schedule, so she decided to re-use parts of her old code in the new project. And in that code, there was a link to the outdated version of the JQuery library. Also when she embedded the widget, she didn’t specify the expected data type of the response.

This is a part of the weather widget code. getWeatherData function takes the user-supplied location and sends GET request to the weather server to receive weather data for that specific location.

In case of success, weather data for the specific location is displayed in the widget. In case of failure, an error message is displayed.

4. VULNERABLE LIBRARY

Each time the user opens Coolnews.me, the browser uses JQuery library to interpret the code of the widget and make a GET request to the weather server. JQuery library also parses the JSON received in response from the weather server.

In this response, we see that the weather server accepted a cross-origin request from the Coolnews.me website and sent the JSON with the weather data in response.

5. VULNERABILITY EXPLOITED

Bob is a hacker. While he was browsing the Web, he came across the weather website that provided the popular weather widget. From his development background, Bob knows how reluctantly frontend developers update software components.
For example, he is sure that among all the users of this widget there will be websites that are using outdated JQuery library. So he decides to hack the weather website and put his cryptocurrency mining script instead of the weather data. Now, instead of a JSON, a script is received in response from the weather server.

After Bob hacked the weather website, he put a cryptocurrency mining script instead of the JSON with the weather data.

6. SUCCESSFUL ATTACK

Now each time some user opens the Coolnews.me website, vulnerable version of JQuery receives the malicious script from the weather server and executes it so that cryptocurrency miner starts running in user’s browser.

7. VULNERABILITY EXPLAINED

Let’s recap why that was possible:
1. The website makes a $.get or $.post request to a domain of a different origin.
2. The server of that domain allows cross-origin (CORS) requests.
3. The server of that domain sends a response with Content-type: text/javascript header and JavaScript code in the body.
4. The vulnerable version of JQuery on the website executes the script from the response if the expected response data type was not specified in $.get or $.post.
Usage of $.get(‘https://codebashing.com’) or $.post({url: “https://codebashing.com”,data: “test”}); without dataType parameter is not safe for cross-domain requests.

8. REMEDIATION

Alice wants to know what she could do to prevent the issue occurring in the future.
As a general rule, Alice should always check that she is using the latest versions of third-party libraries and other software components. And she shouldn’t forget to restrict data types that are allowed in incoming or outgoing requests:
Incoming request:
$.get({
url:’https://www.codebashing.com’,
dataType:’application/json’
})
Outgoing request:
$.post({
url: “https://www.codebashing.com”,
data: “test”,
dataType:’application/json’
});

In this fixed code sample, Alice uses the latest version of JQuery library (jquery-3.3.1.min.js).