A large part of what 3B Data Security do as part of their bread and butter is reviewing malicious code found inside eCommerce websites as part of PFI investigations. It is a regular occurrence that we find fake payment pages that replace exiting legitimate payment pages from the checkout process. These are usually constructed using a combination of PHP and CSS and HTML code. Recently 3B Data Security have come across a fake payment page that uses HTML code to generate itself to replace the existing payment page and display itself instead.
However; this malicious form visually will look very similar if not identical to the original checkout page, leaving only regular visitors and staff members to recognise the change to the site.
If at any point you notice a change in a payment form it may be in your best interests to investigate - so contact the company who is running the page. In doing so may prevent cards from being captured!
The image attached is an example of what a fake payment page can look like if there is no CSS style sheet information for it to use to make it look legitimate. The example was taken from a real case from a confirmed breached site.
What can a developer do to prevent this from happening?
Implement a CSP:
CSP (Content security policy) is a policy that checks to see if the content being loaded into the customers browser is trusted and can be loaded. This will prevent potentially malicious scripts being loaded from a third-party site.
SRI (Subsource Integrity) checking is the method of checking to see if the files found within the website's code base is legitimate. This is achieved through hashing all known good files on the site using an SRI hash generator. If these files were to be changed by the attacker in anyway, this would change the hash value of the file and this would indicate that the file has been modified in some way. The developer can then check to see if the file has been maliciously modified.
Lock down the administration login panel
A majority of cases that we see at 3B Data Security are where the login panels for the eCommerce platform has been compromised, this is often achieved through brute force attempts on publicly accessible panel. To prevent this from happening you can implement the following:
- Allow lists for set IP addresses to access the panel.
- Have a strong password policy in place for the panel using industry standard password lengths and strengths.
- Change the address to access the login panel. Instead of leaving it as default (/admin, /login etc...) change is to something different which is not similar to what the company does or sells.