The Source Defense security platform is deployed on multiple websites, preventing Formjacking attacks in real-time and gathering data that is used by our teams to identify risky trends. Recently, we came across a dangerous shortcut used by some third-party vendors that created an unnecessary security risk that has continued to grow daily. In fact, we found that it was already used to compromise at least 17,000 websites!
In this article, I will explain the details of the shortcut, why it created such a security risk, and how it can be prevented with a few easy steps and at a minimal cost.
But first, let’s start at the beginning.
What is Formjacking?
This (not so new) attack vector created a new challenge for security teams as it was not covered by any of the existing countermeasures used today, simply because this attack happens on each user’s browser with no attempt to breach the websites’ web server.
This means that one successful hack can compromise hundreds or even thousands of websites.
As Formjacking gained popularity, security companies started taking it more seriously, and today there is more than one way to tackle this problem, the three most commonly used approaches are –
Know your partners (and enemies)
No matter which approach you decided to go with or how you chose to implement it, the one thing they rely on is the need to identify script vendors and operations on the page.
As is probably evident by the names and descriptions of the mitigation options, they are all (to an extent) policy-based. From setting a policy that whitelists origins of resources on the page to controlling actions in the most granular level possible, knowing who did what is critical; In fact, it is the only way to avoid breaking the page by preventing a legitimate action.
In a web session, the best (and probably only) way to identify a service is by the domain it loads from, which is why almost any vendor will have one or more recognizable domains they use to load resources.
Take Google, for example; any Google service will load in one of two methods –
- A domain holding the service name (Like Google Analytics, or Google Tag Manager)
- A general Google domain used for resources called Google API’s (like Google Maps)
Technically this is easy enough to do; Google has bought these domains and mapped them to the CDN services they use, a process that takes minutes, you don’t need to be Google to do it, and not surprising it is used by most vendors today.
Now, consider CSP. If you use any of these Google services, you will need to whitelist these domains to load scripts, load CSS, create iframes, and more. If you fail to whitelist one of these domains, you risk anything from breaking the specific service, to breaking the page (depending on the service); This is true in any policy-based platform.
Back to the beginning
Now that we know more about FormJacking and how we fight it today, let’s go back to our original storyline. While reviewing the logs and new scripts identified on a major commerce website, we found a service that uses a general hosting service to pull their resource to the page.
In this case, the service was S3 by Amazon; this means this service forgoes the process of creating an identifiable subdomain mapped to a hosting service. It also means that if the website wants to allow this service to operate, they will need to create a policy that includes anything loading from Amazon’s S3.
Our immediate response was to recommend the website will block this service while contacting the service provider to remedy this oversight. Still, we were also curious how common this might be and decided to do some research into how common this shortcut is. Analyzing data taken from just over 1K commerce, finance HMO websites, and spanning over 500 third-party service providers. We were happy to find that the majority of service providers will stay true to the industry standard and create a recognizable name for their resources. Only 22 service providers did not follow this best practice and loaded their resources directly from CDN or hosting providers such as Cloudflare, Amazon S3, and others.
A surprising discovery was that contrary to an internal theory, these service providers were not startups just starting out, but for the most part, vendors that have been in business for years and for some reason have not adopted this practice.
What should you do?
If you are a third-party vendor, make sure all of your resources are loaded from your own domains and not global CDN and hosting buckets.
If you are a website owner, never whitelist a general CDN or hosting service in your policies, the risk is too high, demand from both your vendors and your internal development teams to work only with registered domains.
To get a free risk assessment of your website, fill a request here
The post STOP! IDENTIFY YOURSELF! A call to all third-party vendors appeared first on Source Defence.
*** This is a Security Bloggers Network syndicated blog from Blog – Source Defence authored by Avital Grushcovski. Read the original post at: https://sourcedefense.com/resources/blog/call-to-all-third-party-vendors/