F5 Labs published the first annual Application Protection Report in July 2018. For 2019, we are releasing our conclusions in shorter pieces that focus on specific trends and conclusions instead of a single 100-page report released late in the summer. Over the last few weeks we have published our first episode, which is focused on PHP reconnaissance campaigns, and our second, which is focused on public data breach reports and industry breach trends.
For the third episode we are diving into the details of one of the big patterns in the breach trends we identified in the previous episode. Not to give away the ending, but that old vulnerability type, injection, has taken on new significance as a result of accelerating trends in how web sites are constructed. We unpack the trends, link it to new data, and offer tactics for mitigating this new-old risk. But first, to place it all in context, we need to revisit some big-picture questions.
Again, We Ask: What Is an App?
One of the definitive questions we asked in 2018 was: what, really, is an app? We offered a new way of thinking about an application so you could monitor and protect them better. This year, the data revealed trends that cast this question into even sharper focus.
To the user, an application may appear to be a single thing: a program running on a server somewhere with a user interface. In reality, most applications on the Internet are swarms of microservices and sub-applications all converging at the last minute into a coherent user experience. These embedded services can include things like user analytics, chat features, debugging tools, social media sharing capabilities, advertising, and enhanced animation. Increasingly, these microservices are being linked to and run from external third-party sites. In other words, the active web code is running on a server that has nothing to do with the “primary” application.
In reality, most applications on the Internet are swarms of microservices and sub-applications all converging at the last minute into a coherent user experience.
While the pace of this trend is accelerating, microservices and sub-applications are not actually a new thing. At the 2014 RSA Conference keynote, noted security researcher Dan Geer said, "While writing this, the top level page from cnn.com had 400 out-references to 85 unique domains, each of which is likely to be similarly constructed and all of which move data one way or another."1 By 2016, researchers at University of Illinois, Urbana Champagne found that 64% of website resources were loaded from an external domain.2 In 2019, a simple scan of the F5 main web page reveals 70 external domain references.3
This tendency to assemble distributed content and functions at the browser is, in itself, not a bad thing. It saves server bandwidth and processing while freeing developers from having to reinvent wheels. It also, however, broadens the attack surface for that old and venerable vulnerability classification, injection. For that reason, we will revisit what makes injection such a durable flaw, and why its latest incarnation makes third-party content such a significant problem.
Traditionally, when tech people hear about web injection, they think of SQL injection, which is a common form, but is far from the whole picture. Injection is a broad category of attacks that can manifest differently depending on the context. These attacks occur when an attacker secretly adds, or injects, their own instructions into an existing authorized application execution process. Injection can sit almost anywhere in an attack chain, from the initial contact with the target to the final exploit.4 It is often used as a way to circumvent authentication,5 but there are also many injection exploits that depend on the attacker already being authenticated.6 The insertion point for the payload can be at the server level,7 the web application itself,8 or, as we are seeing more and more, in third-party application modules or content (more on this below).9 In some cases, the injected code resides in a Content Delivery Network (CDN).10 It also is feasible to do a man-in-the-middle injection into a CDN.11