Website Integrity Monitoring (Formjacking Detection)¶
Not all data breaches occur at the database. Some occur in the browser. By using website integrity monitoring, you can prevent such attacks by monitoring your scripts.
One example of such attacks is Magecart - a group of hackers that steal credit card numbers. Website integrity monitoring helps prevent Magecart-style attacks, as LogSentinel SIEM notifies you on changes to your scripts.
How formjacking attacks work¶
Malicious actors can modify scripts that run on your website in order to steal your users' data (credentials, credit card details, etc.). They can happen in multiple ways:
- A 3rd party script hosting (e.g. CDN) gets compromised
- Your own static resource server gets compromised
- An attacker performs a man-in-the-middle-attack an thus modifies a script from an otherwise uncompromised server
Adding a URL¶
URLs to monitor ara adding from the "Website integrity monitoring" section in the Alerts menu. You can monitor any page, but it's best to monitor the following:
- Homepage - if the page your users land on is compromised, then an attack can do anything to trick them into submitting sensitive data. Since you are most likely reusing templates, monitoring the homepage scripts will mean monitoring the scripts on most pages
- Login page - this is where an attacker can get hold of your users' credentials
- Payment page - the most lucrative data is credit card details, so monitoring the payment page scripts is key. Your payment page may not be directly reachable from a specific URL, so you may have to manually monitor each script on that page
For publically accessible pages pages it's recommended to scan the whole page, whereas for pages that are not reachable directly via a GET request (e.g. the payment page), you should monitor scripts individually - find which scripts are included on that page and add them as separate URLs.
LogSentinel SIEM website integrity monitoring does not affect the website performance.
In order to have a website protected form malicious third party scripts it's recommended to have a good Content-Security-Policy. Website integrity monitoring is not a replacement for CSP, but it's a key additional measure.
CSP only defines the trusted domains, but this is exactly how breaches happen - a trusted domain gets compromised and starts serving modified malicious scripts. CSP can be used to whitelist trusted domains that the website sends data to, thus limiting the ways a malicious script can send the data to the attackers, but that's very tedious to configure right and it still leaves several options (e.g. sending the browser to a malicious page and passing the data as GET parameters).
Another way to protect the integrity of static resource is the so called subresource integrity. It's good to have it, but it's complex to setup on existing websites.
- It complicates build automation as you have to recalculate hashes of bundled and minimized scripts and inject them into page templates
- Minor changes in a script can break your entire website
- It doesn't work with dynamically loaded scripts
- If your main server is compromised, the attackers can easily update the script hash