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


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

Why You Should Use Radamsa

During my time at Secunia I’ve seen a lot of fuzzing results published either publicly or privately (via SVCRP). What struck me at the time was that most of them were made via random bit flip. While this approach is certainly the easiest and fastest to implement and execute, there are other ways to mutate data. One of them is to use Radamsa.

They say that a picture is worth a thousand words, hence we will make a comparison between random bit flip and radamsa with images and our eyes as parsers (more scientific, thus correct, approach would be to collect and compare code coverage data).

Below you can see the results of a random bit flip approach on this seed file (1-to-256 changes of 1/2/4 byte(s) size):

Bit flip

The images are broken in a chaotic fashion. Additionally they all seem to be quite similar.

Now, using radamsa we can get somewhat different set of mutations:


This time images are less broken and mutations seem to be less chaotic. Also we can observe more structural variations (e.g. re-ordered chunks).

We can clearly spot the differences between these two approaches and so can parsers, hence next time when designing your fuzzing operation you should think about incorporating radamsa as one of your mutation engines.

For grids crafting I’ve used ImageMagick’s montage tool (hence we basically tested how ImageMagick’s parser sees things).