Select Monthly Archives
- August 2018
- July 2018
- May 2018
- March 2018
- February 2018
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- March 2014
- January 2014
- December 2013
- September 2012
Filed In: Security Testing, Application Security
Written By: Jeremy Mount August 01, 2018
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.
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.
- “Ticketmaster UK trades blame with chat app provider over payment data breach”
- “Best Buy, Delta, Sears Hit by Third-Party Chat Widget Breach”
- “Cryptocurrency-mining malware put UK and US government machines to work”
- “No boundaries for Facebook data: third-party trackers abuse Facebook Login”
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 (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:
“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:
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.
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.
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.