Defending Against JavaScript Keylogger Attacks on Payment Card Information

Course Overview
(Music playing) Hello, my name is John Elliot, and I'm a data protection specialist with a particular interest in protecting payment card data. I was Visa Europe's representative on the payment card industry security standards council, which means I had the contributing to many of the PCI standards, including PCI DSS. And I'm Troy Hunt. I'm an author of many different Pluralsight courses about how to protect yourself online. And, of course, protecting yourself online applies to all sorts of different web applications, but particularly those that lead through to payment processing. When Troy visited London recently, we had a chat about the modern ways that criminals steal cardholder data by using JavaScript executing in the customer's browser to read and steal card data from form fields. We discussed how the attack works and how people could protect their organization's web applications. We actually have some fantastic native implementations within browsers that can be used for protecting web applications, collecting any sorts of data, not just payment related information. So, for example, we have content security policies, CSPs, and sub-resource integrity, or SRI. Following the NIST cyber security framework, we also brainstormed ways you could detect the attack, how to respond, and what you would need to do to recover normal operations. This course is based on real-world experience, and we'll be looking at some important industry precedence that highlight just how serious this issue is and how important it is to get the defenses right. Everything we talk about applies to protecting all web forms, not just ones that collect payment data, so I do hope you'll join us as we discuss ways of defending against JavaScript keylogger attacks on payment card information.

The Evolution of the Crime
Hi, this is Troy Hunt and I'm here with John Elliott to talk about defending against JavaScript keyloggers on payment card information. So, John, why don't tell us a little bit about who you are and why you are the right guy to be talking about payment card information. Cool, yeah, well I'm a Pluralsight author, I've written a couple of courses of PCI DSS, I used to work for Visa, and I've spent quite a lot of time helping write the PCI DSS standards. So, PCI is your fault? It's not entirely my fault. I hope some of the good bits in there are things I contributed to, but, I mean, PCI DSS is the fault of bad guys stealing cardholder data. Okay, but I guess in terms of the course, you have obviously spent a lot of time thinking about how information systems need to protect payment card information because clearly that is a pretty critical part of taking these sort of payments these days. It absolutely is, and I think payment cards are almost the canary for how the information security industry works because bad guys have been stealing payment card data for a long time, they know that they can monetize it, and people go after stuff they can monetize. So, we've seen over, well, it's probably about 12 years since PCI DSS came out, that criminals have constantly attacked payment cards, and as PCI DSS has made things more secure in different areas, the criminals have changed the way they attack payment cards, which is what brings us to JavaScript attacks in browsers.

PROTECT: Preventing Webserver Compromise
So these are awesome and they are fantastic tools in order to protect against one of the risks you raised with keyloggers, which is external scripts being maliciously modified. Yep, you'd advise any merchant running a website to do SRI for any third-party content they're pulling into a site. So, SRI is really the no-brainer. SRI is the easiest possible one to do it on. I don't care whether you're a merchant running a website or whether you're a blogger running a website. So, it's super, super simple regardless of the nature of your site, and in fact, you can go to srihash. org, you can take the URL of the JavaScript file you're embedding, you can put it in here, say hash, and you get the tag generated for you. Brilliant. Which is super cool. So that was very, very easy. CSP is also super awesome as well. A little bit more work because you've got to white-list all the sources that you're actually going to accept things from, but enormously powerful, and again, it's like a free thing built into the browser. It is. So, if in my CSP on my merchant's website, I made sure I didn't white-list criminal. com, where the criminal JavaScript is coming from, I'm going to be okay. You are so long as you're not white-listing another hostname, which then allows people to upload their own arbitrary content onto. So, for example, if you are allowing any gist to be loaded and someone put it into a gist, but we can filter down our CSP to say a path of gists, so in fact, if you go to my blog today, you'll see that I allow gists from the path that is Troy Hunt. So unless I put my own malicious script in the Troy Hunt, which I'm not going to do, it's my blog, yeah, it would be protected.