This blog was previously published on blog.tcell.io.

Although there have been a number of breaches in the past few weeks, the story around the breach at Ticketmaster is more interesting than most. It combines sophisticated web design, reusable components, the security model of the web browser, and even a dash of payment regulations.

The breach itself is interesting because many breaches take place on the server side of an application. As a result, the focus of many security products is to enable IT departments and the security teams within them to defend resources you control. Historically, these have been servers in your own data centers, though applications are now increasingly built on services that you rent but have no control over. Draw a line around the resources you own, keep hackers out, and call it a day.

Application architecture is increasingly heterogeneous. Making an application is, if you'll pardon the terrible pun, like being a chef. You start with a list of ingredients, and when the result isn't quite right, you can add a dash of something to come up with the perfect dish. Rather than having to build the entire application yourself, it's much more like assembly.

In the case of Ticketmaster, it decided to add a chat function. Fortunately for application architects, there is a competitive industry in supplying chat functions to websites. Ticketmaster chose to use a company called Inbenta, which works by having the web application host a JavaScript for chat functionality. Unfortunately for Ticketmaster, once you let a script run, it has access to everything that's in the web browser. You've just given your chat supplier access to everything that's on the page, including the credit card transactions. Whatever security model was in place on the application servers is now irrelevant, because the best way to compromise the application is not attacking the heavily fortified application itself, but to attack the web component that has access to ... everything.

Let's face it—pre-Ticketmaster breach, how many IT security teams would have been able to link the addition of a third-party component to the overall security of the application? My guess is not many. UK bank Monzo described how it discovered the breach because it was able to associated credit card fraud with cards that had been used at Ticketmaster and compromised. By one account, the compromise may have been aided by a one-line modification to the chat script.

The existing PCI standards are, I'm sure, catching up to these changes in application design. One of the advantages of PCI is that it is highly prescriptive and tells a security team exactly what needs to be done. The disadvantage of a prescriptive approach is that it needs maintenance to address new threats.

What can an application security team do to defend an application against embedded components. After all, security applies to the application as assembled, and now your security depends on being able to protect the application against attack vectors that may affect components you have no control over.

Scripts are powerful because they have access to the entire page. The two ways to use scripts more safely are to ensure the scripts are not altered and that they are given clear communication channels to only the resources they need. To maintain script integrity, you can use the sub-resource integrity tag, but that requires maintaining hashes for each script. To keep scripts from communicating data back to attackers, a content security policy (CSP) can restrict where an application can communicate to, and the web browser will prevent connections to anything not on an allowed list.