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
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:
- 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:
<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
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).
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.