LogSentinel SIEM and XDR for
Website Integrity Monitoring
Prevent data breaches through your website frontend
Website Formjacking (or Magecart) attacks are becoming mainstream and result in revenue and reputation loss and regulatory fines. In those attacks, malicious actors manage to inject scripts that scrape credit card and credential data from your website.
LogSentinel SIEM and XDR has a dedicated integrity monitoring module that alerts you for any script change without the need to modify your website. Get your site protected from formjacking at reduced operational cost and minimize effort on audit and forensics.
Support For Every Website
LogSentinel SIEM and XDR work regardless of the technologies chosen to build the website, as it only monitors the frontend.
Threat
Detection
Discover anomalous script changes with malicious payloads in near real-time and react immediately to prevent damage
Straightforward Integration
No need to change your website, just add the URL and configure test credentials for protected pages.
Data Insights and visualizations
Gain insights by analyzing correlated data from your website script changes and other sources with flexible custom queries and charts
Website Integrity Monitoring Use Cases
Credit Card Theft
Stop criminals from stealing customer credit card information
Credential Theft
Stop malicious actors from obtaining customer and employee credentials
Regulatory Compliance
Improve your compliance with security and privacy regulations (e.g. GDPR, HIPAA)
Sensitive Data Leaks
Don’t let attackers use injected scripts to leak sensitive corporate data
Magecart Protection
Magecart is a specific form of formjacking that is affecting thousands of websites
Website Formjacking FAQs
What threats do LogSentinel SIEM and XDR protect against?
Malicious actors can modify scripts that run on your website in order to steal your users’ data (credentials, credit card details, etc.). British Airways and Ticketmaster are the most notorious such attacks. 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 a thus modifies a script from an otherwise uncompromised server
LogSentinel SIEM and XDR solve those by monitoring your scripts for unexpected changes and alert you when they happen.
Which pages should I monitor?
Should I scan pages or scripts?
LogSentinel SIEM and XDR support both. For public pages, it’s good to scan the whole page, whereas for pages that are not reachable directly via a GET request (e.g. the payment page), you can monitor scripts individually.
Why is this better than a Subresource?
- 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 load with dynamically loaded scripts
- If your main server is compromised, the attackers can easily update the script hash
LogSentinel SIEM and XDR is simple to set up, doesn’t break your website but rather alerts you in case of changes, it works with dynamically loaded scripts and even if an attacker has a control on the system, they can’t stop the monitoring. While they can serve a different version of the script to our IPs that’s a more complicated step than changing the script hash. It may seem strange that an attacker with access to the main server would inject javascript rather than breach the database, but credit cards aren’t usually stored in the plain text there and it’s easier to collect them through a well-tested malicious frontend script than to modify custom code.
Isn't Content-Security-Policy (CSP) enough to protect me from malicious scripts?
No, CSP only defines the trusted domains, but this is exactly how breaches happen – a trusted domain gets compromised and starts serving modified malicious scripts. You should still use CSP for additional protection, of course. 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).
Will monitoring slow down my website?
No, the scans are gentle and don’t involve heavy server-side operations on your end.
