External Third-party Resources and Your (Web) Application

In first quarter of 2018 we were involved in numerous security assessments of web applications with specific threat models either due to their place in the infrastructure (intranet-only) or general sensitivity (data). All of these applications have been delivered by different software vendors but what’s interesting is that there was one security issue that was prevalent across all of them: Inclusion of resources from external third-parties (majority of which were different versions of jQuery and media files).

This alone is a minor security issue for non-sensitive Internet facing systems and its risk is usually accepted by the business, e.g. common case is a CDN usage where performance pros outweigh security cons. However, for applications that are designed to be intranet-only or are very sensitive —think Level 3 of OWASP ASVS— the severity is higher, up to the point where I could rate it high in case of certain systems.

Tell me more

For example think about an internal web application for project management that (1) is accessible by all employees remotely through VPN, and (2) makes use of an external JavaScript code. In this particular scenario attacker cannot attack the system itself because it’s not visible to the outside world, however since this system is embedding resources from external third-party then this party can be targeted in order to attack its users (via malicious client-side JavaScript) and later the system itself. In this case I would rate the severity at least as medium.

Another example is a web application that handles sensitive data such as any banking website. Would you really want to execute JavaScript from an external resource while you’re doing sensitive operations that involve money? Of course not.

On a meta-level it does not really matter what type of resource we are talking about, from architectural perspective following examples are the same thing:

  • Media files, CSS, and JavaScript code in case of a web application (security posture of your provider has an impact on you, moreover security of the communication channel used to transfer the resource is now relevant. See CWE-1016CWE-829, CWE-830);
  • Dynamic libraries in case of desktop and mobile applications (all vulnerabilities of these libraries are now your problem, you also need to make sure you’re loading what you think you’re loading. See CWE-417, CWE-426, CWE-427, and When third-party components become a source of all evil).

The risk associated with these examples is different but the pattern is same.

I will verify the resource

Yes, in case of web applications you could use Subresource Integrity (SRI) to verify if external resource is in fact what it should be. However, it does not solve the root of your problem which is internal or sensitive system that incorporates untrusted external third-parties, it only lowers the risk for your users to a certain degree.

Additionally, as-is there are two major issues with SRI:

  • It only applies to JavaScript (<script> tag) and CSS (<link> tag) hence if we embed an external media file (e.g. image with <img> tag) then the integrity of it will not be validated so it can still be used for attacking the users (e.g. via 1-day memory corruption in image parsing code);
  • Adoption across desktop and mobile ecosystems is not full yet.

Figure 1. Support for desktop browsers via MDN

Figure 2. Support for mobile browsers via MDN

Figure 3. Support for all browsers via CanIUse.com

Therefore, in my opinion SRI is not a complete solution to the problem until it (1) is able to handle all elements (note in section 3.4 of SRI specification suggests that it is likely to happen), and (2) is supported by all major desktop and mobile browsers (should happen in reasonable timeframe).

I trust my providers

By its nature trust is a transitive relation: If Party A trusts Party B (explicitly), and Party B trusts Party C (explicitly), then Party A also trusts Party C (implicitly) even though Party A might not be aware about existence of Party C.

Figure 4. Transitivity of trust

Note that this chain of trust could be longer, e.g. if JavaScript from Party C would interact with further external third-parties.

Having said that, the problem is clear: When you make use of resources from untrusted external third-parties — and all of them are untrusted to some degree — you never know how long the chain of trust really is and have no control over it (other than complete removal).

Conclusion

Whenever an application makes use of external third-party resource it incorporates all risks associated with the resource itself and its provider, that’s why applications should limit their usage of external third-party resources to the absolute minimum that is justified by the business case. Security is always a trade-off, think about your threat model before going the easy route.

Additional Reading