1

British Airways has suffered a big data breach allegedly because of a skimmer attack, whereby malicious javascript code was injected into their site. See https://www.bbc.co.uk/news/technology-45481976

My question is, how to you protect against these kinds of skimmer attacks when modern websites rely so much on third-party javascript libraries?

1 Answer 1

2

how to you protect against these kinds of skimmer attacks when modern websites rely so much on third party javascript libraries?

Simple answer, you cannot. If you use a third-party library by referencing it by URL and not copying the actual library files to your site, then you trust the third-party library maintainer to do his job (keeping you safe).

Miscreants know this and try very hard to infiltrate code into these third-party libraries.

More techy info on the subject: https://www.theregister.co.uk/2018/09/12/feedify_magecart_javascript_library_hacked/

Option 1: Do not use third-party libraries.

Option 2: Copy the actual JavaScript files to your site*, purge all unused code, maintain them yourself (you are creating a fork - added later after comments)* a̶n̶d̶ ̶u̶s̶e̶ ̶t̶h̶e̶m̶ ̶f̶r̶o̶m̶ ̶t̶h̶e̶r̶e̶. You will have to make sure you are allowed to do this (e.g. copyright, license), obligations might apply.

EDIT (after one comment):

Does not matter what you use, if you load resources from third parties, any resources, even encrypted, you trust the third party to keep you safe. Even option 2 (Copying the files) is not safe, unless you vet each line of every file you have copied and even then ... Option 1 is, imho, the only way to be sure.

Option 2 is safer than linking to remote resources because the punk would have to change the code on your server (provided, of course, the code was "clean" when you copied it), and if you have a punk on your server then you have other problems ...

Any 3rdparty can potentially be defeated and will attract more attackers if it is widely used. This has happened in the past already, with punks injecting cryptominers in JavaScript libraries, defeating Subresource Integrity, the code was sneaked into the libraries, the 3rdparty server "thought" the code was genuine ... not sure what happened with B.A., how the changes made their way into the website ...

8
  • 2
    Thanks for the answer. It is not however practical in all cases to copy the files locally. How about SRI (Subresource Integrity) hashing if the vendor supports it?
    – M Raymaker
    Sep 11, 2018 at 11:37
  • Echoing this, you're reliant on the organisation handling your data to ensure they have sufficient controls. Your best form of protection is likely to come from any subsequent actions taken with your bank to detect fraud on your account.
    – Doomgoose
    Sep 11, 2018 at 12:55
  • 1
    "defeating Subresource Integrity" [citation needed]. As you say copying files is only safe if you audit them, it's the same with SRI. Sep 11, 2018 at 13:03
  • I read somewhere, no time to look which, when etc (will look it up later today) ... the punk managed to commit to the git repo of a JavaScript library, changes were not properly vetted and the code was distributed... all you need (social engineering ?) are credentials of a dev who has access to the repo ...
    – thecarpy
    Sep 11, 2018 at 13:07
  • 1
    @thecarpy And that new version wouldn't match the SRI tag. If you update to a new version with a new hash, you have to audit it again. Same as copying a new version to your own server. It's not entirely clear that this is really the issue anyway, from what I've been reading it looks like they were able to add a malicious script tag on the site. Sep 11, 2018 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.