When we think of “securing our website” from attackers, we often think of securing against hooded figures somewhere in Eastern Europe working out of a smoky office above an illegal gambling den. Not only is that probably geographically insensitive, it’s also not necessarily the best way threat to get your attention for the risk column in your next CISO briefing.
Well, you might ask, “what should I be focusing on?” The answer: There’s a growing number of issues related to third- and fourth-party scripts running on your company website, so this is a good place to start.
Waterfall chart example — click to enlarge.
Consider a classic webpage waterfall chart: This is a chart that shows you what elements of your web page are loading, and how long each of those elements is taking to load. This can help you with answering some page-optimization questions like, which of these elements can be reordered or possibly combined; or which of these particular artifacts are mandatory and which ones can be removed.
This is the area of interest that most security teams are not looking into. And I’m not talking about page-load times — I’m talking about all of those “elements” that are loading each time a user visits your website.
What could we expect to see there besides visible webpage elements? Well, we might see some JavaScript placed there for advertising tech purposes, marketing automation or possibly user personalization reasons. Let’s not forget the trusty analytics packages that pretty much everyone in the world has loading on their pages. Not only are these resources there to help your webpages perform better, give you information you need about your visitors and provide other sorts of optimization for your site, they’re also a majorly underappreciated source of malicious potential for an attacker.
Let’s look at what happens when these resources and their perceived trust are abused by attackers. In 2013, a group known as the Syrian Electronic Army (SEA) compromised a marketing and recommendation partner for three of the major news outlets in the United States. Because the scripts that were sent to these three news outlets were “trusted” as part of their marketing agreement, they were promptly loaded into every page load for every user that came to visit the sites that day. And when any user clicked on a recommended news article, they were automatically taken to the website for the SEA.
The above “hack” seems like a cool way to get people to come to your website, but what else could be pulled off using similar techniques — perhaps something more malicious? And is this still a possibility today?
Yes, and yes! Last year, a similarly exploited vulnerability wreaked havoc on several online retailers by a collective of at least six attacker groups who have come to be known as Magecart. Uncovered by researchers at RiskIQ and Flashpoint, these groups were able to take more than just the joy out of the holiday season by using formjacking and X-Frame options to perform clickjacking through malicious injected JavaScript code into third-party web elements.
The attackers, using what are still not totally known methods, were able to inject malicious JavaScript into the online retailers’ shopping cart applications, allowing them to perform card-skimming operations, which in some cases led to the full data breach of associated customer records. British Airways in the UK, for instance, lost over 300,000 customer records as part of its Magecart breach.
There have been some solid recommendations made on how to combat this problem, such as using security response headers. These can be used to communicate security policy settings for any web browser that is interacting with your website.
Unfortunately, most organizations aren’t making significant use of these headers, as they either believe that web application firewall security protections can thwart these types of attacks (which they cannot, because the client side is what’s running the malicious JavaScript). Maybe it’s too cumbersome to consider, since the list of headers isn’t static, and continually changes over time – so organizations are unwilling to manage that process. Another possibility is simple ignorance with regard to the depth of the issue.
There are also a few sites that can scan your organizations website for free and give you a simple scorecard to get you started on your journey to correcting the script problem. A few of them are:
Since this problem is not the full responsibility of a website owner themselves, but instead stems from the relationship to potentially exploited partner JavaScript code, this should be considered a supply-chain attack. But how does one ensure that all third- and fourth-party code is secure before you allow it to run against your clients?
An emerging possibility is your own injection of client-side JavaScript into a users’ browser – to be used for good.
This type of capability is categorized as Runtime Web Application Self-Protection (RWASP), and if implemented correctly, it can bridge the gap between the endless variability of partner-side code scanning. It gives the browser itself the ability to make runtime decisions about what it’s actually seeing load during that full-page waterfall we looked at before, via a good JavaScript that can detect unwanted or malicious script functionality.
Additionally, the implementation of this new validation and monitoring check can be done in an ongoing manner.
We’re approaching the biggest time of the year for e-commerce activity – and for malicious card-skimming attacks as a result. By implementing some of these ideas, you can help make sure that this holiday season, your company may only be in the headlines for the right reasons.