What prompted me to revisit the topic now, was the recent hack at British Airways website that
resulted in criminals walking away with full credit card information and other personal data of some 380 000 customers who had booked flights between the 21st of August and the 5th of
This time, however, there is a twist. While the crypto currency miners were planted on plain web sites in the open internet, the breach at BA affected a secure payment page behind customer login.
A quick scan of a few airline and hospitality websites reveals, however, that most payment sites include a host of linked external libraries. On a secure credit card payment page, presumably falling under the PCI-DSS compliancy regime.
Now, if this is not worrying, then I do not know what is. As we discussed in February, and as was again displayed with the BA breach, detecting a compromised external library is very difficult even in the best of circumstances. Moreover, having dynamically linked libraries on a credit card payment page begs the question if all these libraries and their delivery mechanisms really are vetted to be PCI-DSS compliant.
And of course, they are not. But they should be.
As discussed in the previous post, implementing the necessary controls is a bit of work, but I’m sure the alternative is not that much more pleasant. By limiting the functionality on the payment pages to a minimum, and by rigorously enforcing the integrity of the code in use, you can avoid being the next in line for exploitation by cyber criminals.
Do you want to know more? Get in touch with me and my colleagues!