Open Mobile Menu

Blog

Filed In: Security Testing, Application Security

Securing Third Party JavaScript

Views: 772

Written By: Jeremy Mount August 20, 2018

Does your application load JavaScript plugins developed or controlled by third parties? If so, how do these plugins and libraries affect the security of your application? Many, if not most web applications use some kind of third party JavaScript. These scripts provide useful functionality and services such as analytics, social media integration, data services, user interface features, chat capabilities and so on, however they also present a substantial risk to the confidentiality and integrity of your application and the data contained within. This is not a new topic in application security, however many companies still fail to consider or fully understand the security implications of adding code from third parties to their applications.

Why Use Third Party JavaScript?

Your customers have come to expect modern, feature rich and visually appealing web applications that work on a wide range of devices. Your business leaders expect real-time analytics and the latest features delivered quickly and within budget. In order to meet customer and business demands within rapid timelines and cost constraints, it makes sense to use off-the-shelf products and managed services. Vendor products can provide functionality that would take countless hours for development teams to recreate on their own. As more third party products and services become available, this trend will only continue to accelerate.

Many of these products and services used in today’s web applications are delivered using third party JavaScript plugins and libraries. The ability to provide powerful features and functionality often with just a few lines of code in your application is an attractive and cost-effective solution. But what companies often fail to consider are the security risks these scripts introduce to applications.

Is Your Site Using Third Party JavaScript?

Sites such as builtwith.com and wappalyzer.com can provide high-level insights into the third party components and software used in your web application, however these don’t clearly differentiate between scripts and other software or show the source from where those scripts are loading. The basic analysis provided by these services also doesn’t show what scripts which may be in use beyond the homepage, such as those loaded only after authenticating to the application.

Today’s web browsers have the built-in capability to provide a detailed view of the scripts used on your site. The Network Performance DevTool within Google Chrome, the Network Monitor Developer Tool within Mozilla Firefox  and the Network DevTool within Microsoft Edge can be used to show the scripts on your page along with the domain from where they are loaded. If you see a script being loaded from your domain, don’t assume that it’s secure. If the script was copied from a third party to your domain, its security may not have been properly assessed before use.

Figure 1 - Google Chrome Network Performance DevTool

Figure 2 - Mozilla Firefox Network Monitor Developer Tool

Figure 3 - Microsoft Edge Network DevTool

What’s the Security Impact?

Without additional protections, scripts added to an application using the HTML “script” tag have nearly full control to view, modify and transmit everything your customers can see and enter into your web application. On every page that contains a script providing traffic analytics, a social media widget, or other functionality, that script now has access to modify anything on the page including adding more scripts, access cookies which may contain sensitive data such as authentication tokens and access to all the data on the page even including keystrokes, mouse movements and clicks. These scripts can also transmit any of this data outside of your web application. The scripts themselves may also contain security vulnerabilities that could pose a risk to your application.

Companies that fail to carefully evaluate the security of their third party scripts often become victims. Following are some recent highlights from the news where high-profile security incidents were caused from the use of these third party features.

How Do I Protect My Web Application?

The safest approach is to not use third party scripts at all, but that’s hardly a viable option. Before using one of these plugins, each use case should be carefully evaluated and the security risks considered when making a decision. Third party scripts with access to sensitive data may also expand your scope under contractual or regulatory security requirements. If you decide to go forward, the following guidance can help improve the security of your implementation.

Only Use Trusted Providers

Diligently assess the vendor’s security practices to gain reasonable assurance that the provider meets or exceeds your company’s security requirements and is contractually obligated to uphold agreed upon security practices. If vendor management isn’t already a part of your security program, AppSec Consulting can help you put the right policies and procedures in place necessary for the initial and ongoing evaluation of your vendors’ security postures and can also perform vendor assessments on your behalf.

Host the Script Yourself

Many scripts can be loaded directly from your hosting environment instead of the third party provider’s domain. This may pose a small inconvenience since you’ll be responsible for managing updates, however you’ll have more control over changes to the script and the security of the environment. Unfortunately, not all providers support this option and in doing so, the burden is now on you to monitor the scripts for updates and promptly deploy new versions.

Subresource Integrity

Subresource Integrity (SRI) provides a mechanism to cryptographically verify that the content of the third party resource loaded into your application matches the content that you expect. This can be used to protect against unexpected or unauthorized changes to the scripts that have been added to your application. SRI works by adding an “integrity” attribute to the HTML “<script>” tag. This attribute contains the name of the hashing algorithm used to verify the script followed by a dash and then the base64-encoded hash value of the script contents. If the file is altered, then the hash value will no longer match and the script won’t be loaded. You can generate the hash yourself or your third party provider may be able to provide them for you. Following is an example of using SRI with the “sha384” hashing algorithm to verify a third party script’s integrity:

<script src="https://example.com/widget.js"   
     integrity="sha384-9jOgD7lo8elm3zY0jgcrxtrERUwCdy1ezm/27HUp5u32gEJ3VVTUfTpZ/iX/V5uG">
</script>

 “widget.js” contains the contents:

alert('This is a trusted plugin.');

When the contents of “widget.js” are changed to the following:

alert('This is not a trusted plugin.');

the resulting hash value becomes “1bvkcT9sl18A4XpfzDjFzmpxFqwe7teqBy+Z69fMopQFUuARTm6s1h1UJD9V6fkg” and since the hash no longer matches the value in the “integrity” attribute, the script won’t load.

SRI can help prevent against loading unauthorized changes, however imposes the overhead of implementing a process to keep the SRI hash updated for authorized changes. Further, not all vendors have development processes that are SRI-friendly. For example, your vendors may follow a continuous delivery software engineering approach which may result in frequent, unexpected changes. If these scripts are loaded directly from your third party, functionality may break without close coordination to keep the SRI hash values current.

Content Security Policy

Content Security Policy (CSP) is a relatively new standard intended to help mitigate and detect various content injection attacks. As the name suggests, it provides directives for limiting how and from where content, including scripts, can be loaded into a web application. Because this standard is evolving with version 3 currently being adopted, support for some features may vary across web browsers. CSP directives are set in either the web application HTTP “Content-Security-Policy” response header or in an HTML “<meta>” tag. Setting the CSP directives in the response header at the server configuration level is recommended to ensure consistent coverage over the entire application.

Configuring a proper CSP rule set requires knowledge of all scripts on your site as well as the functionality of those scripts. For example, a third party analytics script that requests an image to perform tracking may require a different CSP rule (“img-src”) than a script that uses an XMLHttpRequest (XHR) to send the tracking data (“connect-src”). There are also different variations for some CSP directive configurations and you will need to choose the best options for your application that balances security and maintainability.

Using the previous SRI example, we want to configure our Content Security Policy to provide reasonable protection to our site and allow the following third party script:

<script src="https://example.com/widget.js"   
     integrity="sha384-9jOgD7lo8elm3zY0jgcrxtrERUwCdy1ezm/27HUp5u32gEJ3VVTUfTpZ/iX/V5uG">
</script>

To do this, we define the following CSP directives:

Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://example.com

default-src: This defines the default policy for all CSP directives. In this example, the default is set to “self” which means that CSP-controlled content including scripts, images, fonts and so on may only be loaded from the same origin as your application. Make sure to always set the “default-src” since this serves as the fallback for other directives

script-src: This defines the sources from where scripts may be loaded. In this example, we only allow scripts to be loaded from “self” (our application origin) and “https://example.com”. Note that the “default-src” directives are not inherited which is why “self” is defined again.

Be aware that the above CSP directive may have unintended consequences in your application. If using inline scripts or the JavaScript “eval()” function to generate code, those will also be blocked unless explicitly allowed. We can also use CSP to enforce SRI as used in our previous SRI example:

Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://example.com; require-sri-for script 

require-sri-for: With the “script” value, this directive now requires all scripts included on the page to have the “integrity” attribute. Note that as of this writing, not all major browsers provide support for this directive, however you can still include the configuration and the rule will be enforced as browsers catch up to the latest standards.

Finally, you can receive reports when a CSP violation occurs. This can help raise awareness of potential misconfigurations or malicious activities. Building on our example:

Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://example.com; require-sri-for script; report-uri /csp-violation/ 

report-uri: CSP violations are reported to the defined URI end-point as JSON-encoded data using a POST request. A handler at the endpoint can log, alert or perform other actions based on the violation details provided. Note that “report-uri” is currently being phased out to be replaced with the new “report-to” directive. Please consult reference documentation on how to configure the new directive.

These examples only scratch the surface of the capabilities provided by CSP. For more information, please refer to additional documentation to configure CSP to meet your needs.

Conclusion

If you require third party scripts in your application, you should leverage the security features available in modern web browsers to help protect your company and customers. The above examples can provide additional layers of defense, however you are still responsible for understanding the behavior of the scripts you include in your application and are responsible for the security of the application itself. These recommendations reflect only a small part of a well-developed application security program and shouldn’t be used as a substitute for secure web application development and comprehensive testing.

Jeremy Mount

Jeremy Mount is a Senior Application Security Consultant at AppSec Consulting with more than 18 years of experience developing Internet-facing applications and leading application security initiatives in environments ranging from high growth startups to Global Fortune 100 enterprises. He has extensive expertise in application penetration testing, including the use of manual techniques and automated tools to perform detailed assessments across a wide variety of platforms and technologies. Jeremy has led initiatives to help companies build security into products and train developers in secure development techniques.

Jeremy holds the Certified Information Systems Security Professional (CISSP) certification and participates in local and national security events to stay current with the latest security developments. In his free time, he enjoys participating in capture the flag (CTF) security events and learning new programming languages.

read more articles by Jeremy Mount