Although there have been a number of breaches in the last few weeks, the story around the breach at Ticketmaster is more interesting than most. It combines sophisticated web design, re-usable 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 increasingly applications are now built on services that you rent but have control over. Draw a line around the resources you own, keep hackers out, and call it a day.
Application architecture is increasingly heterogenous. 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.
Let’s face it: pre-Tickemaster 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 they discovered the breach because they were able to associate 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 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 that 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. tCell can automate both script integrity and CSP, so if you need to protect an application from the components, give us a call!