🔒 Evolving protections against browser supply chain attacks

Hello. Hello everyone. Welcome to Cloudflare TV. We are here today to talk about some very exciting innovation as we kick off Security Week 2023. And what we're here to talk about today is positive blocking in our Page Shield product. Very, very interesting and thank you for tuning in. So my name is Dan Gould. I'm on the product marketing team and I look after the marketing for our application security portfolio. And I'm actually joined by two terrific guests today. You've probably seen them on Cloudflare TV before, but Michael, why don't you say hi? Hello everyone. Thank you, Dan. Excited to be on Cloudflare TV again. I'm currently working in the product team responsible among many things about Page Shield, which is the product that implemented positive blocking and we're going to talk about today. Great. And Apoorva. Hey, everyone. I'm Apoorva Ravikrishnan, Senior Product Marketing Manager at Cloudflare. One of the products I help with is Page Shield, and I'm very, very excited to be here to talk about the positive blocking features and how beneficial it is to our customers. Indeed, indeed they are beneficial. Now we're going to dive in. But before we do that, a reminder to those watching. You can actually ask questions. You can email us during this segment today. If you send questions to [email protected], we'll take a look at those and we'll answer what we can. So with that out of the way, let's dive in. And maybe, you know, it makes sense to to set the scene and discuss why a product like Page Shield is necessary, why we built it. And maybe Apoorva, you know, you can get us kicked off here, like you know, what was the why behind getting Page Shield to market? Yeah so developing web applications is involved in so many different ways with JavaScript dependencies being a cornerstone on how it's being developed today. So it cannot be an overstatement to say that most of the web applications and websites we see today rely on third-party scripts to add new functionalities to make it more interactive. Basically, third -party scripts do a bunch of good things. We'd be here the whole day if we start talking about the benefits of them. However, uncontrolled third party scripts lead to client-side attacks, also called Magecart attacks or browser-based supply chain attacks. These attacks happen on the website visitor's browsers and just to double click on the nature of these attacks, it can get website visitors' sensitive data such as credit card details or their phone numbers, or it could deliver malware, or they could carry out crypto mining and traditional or core application security products like our WAF or DDoS focuses on protecting the origin servers and the underlying web application, but they do not give visibility and they do not address the attacks occurring on the end user's browser, where the application gets executed. So some of these attacks were actually headline news for some, for the longest time. Ticketmaster was hit in February 2018. They targeted the chatbot Ticketmaster used on their site, the code which was present throughout the site. So login details and payment information of at least, you know, for at least four months. And 9 million users were impacted because of this and 66,000 credit card details were exposed and they were in fact fined 1.7 million pounds. Another one, again, we'll be here the whole day if we go about some of the biggest attacks. But British Airways, it's something which we've all heard about before. Attackers compromised self-hosted JavaScript library and for 14 days the infected script sort of exfiltrated payment details from British Airways' checkout page. The attackers, in fact, preserved the original script functionality to avoid detection and then they went on to do this for 14 days. And the fallout of that included 429,000 credit card details which were exposed, and they were slammed with $230 million fine. And this is where Page Shield comes in. It's built to provide that visibility and protection against client-side attacks. So an organization can deploy as many third -party scripts as they want without worrying about whether their their scripts or third-party scripts have been compromised, which then is used as a vehicle for client-side attacks. Yeah, indeed. And I think, you know, we'll talk a little bit more about sort of the whys behind, you know, why we use third -party libraries and dependencies. So why do you think, why is Cloudflare in a good spot to provide these protections, to provide this visibility? And I don't know, Apoorva or Michael, either one. I think that's that's an interesting angle here. Michael, do you want to... Oh, Michael, you're on mute. Good point. I can give a go to that question. So first and foremost, we've been around for a while. And as many of you know, we offer self service plans on our platform. And the standard onboarding process to the Cloudflare platform is for you to either move over your domain to the Cloudflare DNS management suite or simply point your traffic to Cloudflare. And that has made us, over time, a proxy, a reverse proxy sitting in front of millions of applications out there, right? And that position in the proxy is really, really good for us to start serving not only, as Apoorva mentioned earlier, protection to the origin servers. So actually making sure hackers do not infiltrate back-end applications, but also flip it the other way around and provide protections to the client environment. And as long as customers or, you know, if you own a blog site or a local local e-commerce little, little, little application, as long as you're proxying traffic through Cloudflare, turning on Page Shield is just a click. And that puts us in an excellent position to, of course, make it very easy to gain that visibility in what's happening in the client environment. The other reason then, on top of the simplicity of the solution, is the visibility we're getting, right? So if you look at the blog post, the announcement we just, you know, announced earlier today, with lots of our customers turning on Page Shield, we're getting access to a lot of data on what's happening in the client environment, which by consequence makes our product better. So we listed, for example, what are the top companies or organizations from which customers are loading JavaScript from, as well as which are the top companies and organizations for which, you know, websites are sending data to. And that visibility, when we spot anomalies across, you know, common trends and patterns. For example, if I'm a little old-school here, if you're using something like jQuery on your application and all of a sudden we see a jQuery starting to send data to a new destination. That is something that we would easily spot across the Cloudflare network and then, you know, can provide that additional visibility, especially when it comes to malicious detection to our customers directly from the dashboard. That is very, very powerful stuff. Yeah. And so we're obviously, and I think, Michael, in a few minutes, you actually show us this, this, this in action. But, you know, before we do, I think it probably makes sense to discuss this challenge of JavaScript and compromised JavaScript a bit more, and I know, Apoorva, you mentioned that. When we say compromised JavaScript, what do we really mean? Yeah. Like Michael said, JavaScript dependencies have become a cornerstone of web applications and we just saw about how important it is for every organization. But these scripts could be used from many different sources. It could be picked from a trusted code repository or it could be a code snippet a very talented well-meaning developer has put together. And sometimes the hard truth is that these third party JavaScripts, whoever developed it, wherever it's from, might not have prioritized security or it could not be, it might not have been in the forefront of their mind when they're developing a solution to something. So there are different ways or ways that these scripts could be compromised, and that's what attackers do. Indeed. Indeed. And, you know, probably also I wanted to hit on the point that, you know, why do we turn to third-party libraries? Like what is the reason for that? It feels like, given and despite all this risk, we still use them because it seems like, at least from, you know, feel free to chime in here, there's a lot of value in terms of how quickly you can add additional functionality, capabilities to a site that you don't have to build yourself. And a lot of the things that might be, and I think Apoorva you were talking about a script that was compromised, I think on the BA side, it's probably a somewhat mundane yet critical capability for the website that they didn't have to build themselves, they could borrow, sort of plug in, if you will, and away they went and they can continue working. Um, it seems like, you know, there's there's so much value in using third party scripts. That's not going away. So I think what we do need to change, though, as we think about this compromised, you know, JavaScript, is making sure we have the right protections in place. At least that's how I see it. I don't know. Michael, what do you think? Yeah, no, I agree. And there's actually two, two aspects here, right? Number one is what you mentioned. There's JavaScript libraries and not only JavaScript, also CSS templates and similar that just provide you out of the box, you know, calendar widget out of the box, you know, little chat application or contact form. And it is very, very tempting, I've done it myself, to go on a popular JavaScript repository, cdnjs being one of them actually behind the Cloudflare Proxy, search for what you need, copy, paste in your website application and bam, you're saving yourself what would have been many hours if not weeks of application, right? Of application development. That's one aspect. There's the other aspect which is everyone in the tech industry nowadays is building a software as a service platform, right? And any software as a service platform that's integrated into applications is normally done via JavaScript library in many cases. Think about Zendesk, you know, chat application, Stripe Checkout page, and we need to rely on these services. It's impossible for everyone to build everything, right? And what is the reality is at the end of the day, any large or somewhat even middle -sized application will be loading sources and code from external, you know, entities even ten, 15 times on a single checkout flow. Yeah, that's that's that's pretty incredible. And you know, we mentioned this before. I think, Apoorva, you were getting at this. There are a lot of these third-party libraries, dependencies, etcetera, and they're created by well-meaning developers. However, sometimes security just is either is not at the forefront of their mind, there's just not enough time or they just don't, you know, get back around to it to harden things and make it, you know, more, more secure. And I don't, you know, don't see that changing necessarily either. So I think to be able to to move quickly, Michael, as you're talking about, I feel like, you know, that's what brings us here today to to think about Page Shield. Um, and you know, when we think about a successful compromise, I think it's also important to know it's not just the credit card details say, that might be scammed, but also more broadly, the brand trust when you know, if a particular, you know, I don't want to rub salt in the wound of any of the companies who've been breached. But you know, if your site gets popped in this way and the, you know, European Union gets involved and there are headlines and there are fines, it's, you know, a lot more than just the actual data breach. I mean, I think there's broader trust that is shaken and that can also be just, you know, a really good reason to think more about, you know, getting these protections in place. Um, so that said, Michael, I guess we'll transition to you a little bit, thinking about how we can help in these scenarios with with our Page Shield product and the capabilities. And so, you know, I certainly think of it as sort of three key areas that Page Shield can help with. But maybe you want to walk us through that. Sure. Yeah. So before we jump into today's announcement, we referred to Page Shield quite a few times. What is Page Shield at a high level? Page Shield is Cloudflare's client-side security solution, right? So we're trying to do something integrated into the dashboard that protects the browser environment. Before today, Page Shield provided a couple of major features. We actually differentiated ourselves from the market a little bit and we actually only focused on detection of malicious behavior. So up until, you know, last week more or less, if you were to turn on Page Shield and again, it's a single click in the dashboard, you would get two things, mostly. Visibility of what's happening in the browser environment, and when I say visibility, you get an inventory of JavaScript files being served by your application that are then being loaded by the browser environment, right? So just by turning it on, I've actually had conversations with customers surprised and you know, they didn't know their team had added a specific script from a specific company. And you know, Page Shield gave them that visibility. And the second part is not only the JavaScript libraries, this was actually after we brought the product to general availability, we added a second monitor. We call these visibility features monitors, Connection Monitor. So in addition to telling you what libraries are being loaded by the browser, we're telling you where the browsers are sending data to. To some extent, this is even more important. There's no harm in potentially loading a JavaScript library from a malicious third party, although this is how a lot of, of course bad scripts get served. Normally, a malicious script will also be sending data out of the browser environment and that's where the data exfiltration happens. That's where your end user data is leaking and Page Shield is now able to report on all of those destinations that might that might be of interest. So if you have, for example, a checkout payment system on your on your page at the end of your checkout flow, Page Shield will tell you where is data being sent to and the actual underlying endpoint. By default, we don't report the entire endpoint. That's very often the sensitive details in the URL, but that can be something that you can configure from the Page Shield dashboard. So this is the visibility part. The other major part that comes with Page Shield, especially for those customers who are purchasing the Enterprise add on is where, and where the big differentiator is, in my opinion, is the detection of malicious behavior. Something that not many other tools on the market do today. As soon as you turn on Page Shield, every time we find out about a new JavaScript resource or a new connection being performed by your users, we will do a couple of things. First and foremost, we scan the URL and the domain against our own internal threat feed intelligence database. And as you all know, Cloudflare has been operating in app security for quite some time. We have our own threat intel, threat intelligence teams internally. We are using a lot of external providers to feed us with a lot of information on known bad domains. Some of this data is also exposed in our radar platform right out of Cloudflare.com. If we find a match, so if all of a sudden a script appears on your site and is known to be hosting, you know, under a domain that's known to be hosting malware, you will receive a notification directly to your inbox or webhook or whatever mechanism you've set up. And we do this both on the domain as well as the full URL. This is actually two separate feeds. We actually are ingesting and using feeds specific to Magecart-type attacks. The second capability, which is mostly around the JavaScript, is we actually try to fetch the JavaScript and then we actually run it through our own custom ML classifier, which has been trained against a very large set of known bad scripts. And we give you a score, an output on how bad a given script could be based on obfuscation and data exfiltration. And again, all you need to do is turn, click the button on, and you get all of this out of the box without having to implement any new tools on your site. That's really powerful stuff. And, you know, just getting to the the the the fact that Cloudflare delivers a lot of visibility. All paying customers get the script monitor. And so this, as the old sort of security adage goes Michael, and you've heard this a million times, if you can't see it, you can't protect it. So visibility, Michael, to your point, like you've worked with organizations and they're surprised to see the full list and what was actually loading into the site. This visibility feature is actually available for all Cloudflare paying customers. So we do encourage you, if you do have access to this, please turn it on. And then and then you'll actually just begin with this powerful visibility. And just to clarify, that's from the Pro plan or above. You have access to Page Shield today. So and there's little risk to just turning it on. Indeed. Indeed. So really powerful stuff. And so, you know, I guess maybe we can transition a bit, transition a bit to today's news and what we're talking about here in terms of positive blocking. You know, today we've been doing a lot of visibility, a lot of detections and alerting on malicious activities, be it, you know, connections or, you know, scripts being served from, you know, known malicious places on the Internet. How are things changing today, Michael? What's new? Yeah, right. So we started with the detection and visibility capabilities. And today we're adding prevention capabilities. We haven't reinvented the wheel here. We're using a very well browser-native supported technology called Content Security Policies. CSP headers allow application owners to essentially tell the browser from the back end what JavaScript files or what connections are allowed and therefore should be executed or connected to from a specific list of, you know, vetted list of approved destinations. Browsers that receive these Content Security Policies will then enforce them or potentially just log or report on violations. And that means that if an attacker is able to compromise a JavaScript file and that JavaScript file is outside of the allowed list, browsers will not actually execute that malicious code. So if I were to describe in a nutshell, what positive blocking allows you to do is reduce the attack surface that an attacker has available when trying to compromise a website. The other the other quick thing I'll mention here is CSPs are notoriously difficult to manage, especially in very large applications. So we didn't just provide the ability, we're not just providing the ability to build the CSP from the browser, but we're also wanting to make it easy to first of all, build the policy in the first place and then secondly, keep it updated so it's as restricted as possible because difficult CSPs or large CSPs for large applications tend to be very, very broad and then they lose the the sort of effectiveness of preventing an attack in the first place. And we do not want that to happen. Yeah. Let's dive in on CSPs for a second there. So it's content security policies, right? CSPs. And it's my understanding, Michael, those effectively tell the browser sort of where, very explicit instructions via a response header of what they can load or where they can load resources from. Right. And to your point, that helps reduce the attack surface. Now, CSPs are certainly very well meaning but it sounds like from what I'm hearing, they can be tricky to manage across an entire organization where you've got marketing trying to do their best to make the site amazing and high performing. However, we're also trying to reduce security risk of these, say, new dependencies and libraries that the site might be using. So it sounds like we need, with CSPs, you'll need to make sure they're always up to date based on the most recent sort of resources that are running in the website and if not, either the client side site won't load properly, it won't work right because the CSPs aren't up to date or, to your point, we make the CSPs deliberately so broad, they're entirely watered down and they don't provide really much security any longer. Did I get that right? Yeah, no, that's right. And actually, even just creating a CSP in the first place I've heard is a is a challenge because normally it's the security internal team that wants to implement CSPs within an organization. And sometimes that team is separate from the actual application development team and even the ability to review what is actually being loaded as a starting point to build the CSP is difficult and we've actually focused on making that part of the journey extremely easy. Really, really cool. So does it make sense? You know, a demo is worth a thousand words as my grandmother always said, Michael. Yes, let's do that, very quickly, conscious of time. So I'm going to quickly share my screen. Uh, Dan, can you confirm you're seeing my screen? Perfect. So just to focus actually on that last part, making CSPs easy in the first place. This is my personal blog. Not much traffic going on there, but for the purpose of the demo it's more than enough. I'm logged into Cloudflare. I can head over to security and directly to the Page Shield tab. And here you can see we've got our monitors, right. Active connections detected on my site. You can see I am, confirm I am loading some JavaScript on cdnjs.cloudflare.com. And then under that, I've got the full list of scripts. This information lets us propose or give you a very simple way to build a policy in the first place. So I now have access to this policy's UI. I have no policies deployed right now. I can go ahead and create a positive blocking policy, give it a name, and then the nice thing here is that for very large applications, creating a policy that matches the entire application is very hard. It would be very large. So you can focus on the parts of the application that matters. For example, I could do something like only deploy the policy when the URL contains the keyword "checkout", which means Cloudflare will only enforce on that specific part of the site, which is where you are at higher risk, right? Because that's where users might input credit card details. And now the nice thing is under this you actually can build the directive. In this case, we're building a directive for allowed scripts only. And rather than going to figure out what you're what you're loading from your site, etcetera, that information is directly embedded into the UI as we have Script Monitor turned on, right? So I know for example, that in my website, yes, I am loading a bunch of scripts from cdnjs. I actually am hosting some scripts directly under my domain. You can see here I've got a custom one that I that I wrote and therefore building my policy becomes as simple as essentially confirming that yes, I recognize these domains, these are things I do want to load, and potentially let's assume this full list here wasn't something I wanted to allow. I only wanted to allow one of these. I can make exceptions as I go along. And my preview is provided right below, right? So for users who are familiar with Content Security Policies, you actually get to see the preview in the first place. And if you wanted to add exceptions, of course you can do that quite easily by simply adding custom sources directly from the UI. Once you've reviewed your policy, we don't expect users to deploy them in an enforcement mode from the get go. So of course you can deploy it in log mode and then once that is done, you actually get violation reporting directly in the UI to validate it's working as expected before you potentially switch it to enforcement mode. But every time you go to edit the policy, we will provide you a list of updated scripts according to what we're seeing on your website at that given moment in time. And with that, I think that's the end of the very quick demo. You know, so also that that's incredibly powerful because a), it's really, really easy to use and it reduces risk incredibly. Now, one question comes to mind. I think about, you know, CSPs won't necessarily tell you if something is malicious, correct? Like even the CSPs and we're sort of, you bring a lot of automation to creating the CSPs to take burdens off of teams. But I guess is that where the detection capabilities you talked about before? Right. So our detection capabilities are always going to be running in the background, including over your allowed scripts and connections. So let's say we trust Google, we trust Facebook, we allow them in our CSP policy. So browsers are only allowed to load and execute script from those sources. What if, hopefully it never happens, Facebook gets compromised. Our detection capabilities for malicious activity will always be running also on your allowed list, so you will get notified if we spot anything bad and you can sleep well at night knowing that you're covered. So visibility the the the ongoing detections which are always running and then the the positive blocking which will effectively automate the CSP policies to make sure it both provides the security you need and also doesn't get in the way of business. Powerful stuff. So, speaking of business Apoorva, um, there actually are some emerging controls that businesses do need to be concerned about with respect to the, you know, the risks of third-party dependencies. And it's reflected in some in the most recent PCI updates. Um, can you tell us a little bit about, you know, this this new PCI update, I think when it came into to when it will come into enforcement and what we need to know? Absolutely. For those of you who might not know, payment card industry data security standard, PCI DSS, like Dan said, is the short form. So it's an information security standard which is administered by the PCI Security Standards Council. And it's use is mandated by all the credit credit card brands. The PCI DSS applies to all companies which accept, processes and transmit payment cards. And last year, the PCI published a newly updated version, version 4.0 of PCI DSS, and currently we are in the transition period where an organization can be assessed either with a previous version or the newly updated 4.0. But from March 31, 2025 onwards, the new data requirements become mandatory. And with respect to client-side security, there were two requirements that have been set forth in version four. The first one for client side is under section 6.4.3, which says organizations should put a method in place to confirm each script is authorized, a method to assure its integrity, and it should also keep an inventory of all scripts. This is easier said than done because some of these can be very, very hard to meet, like Michael has been showing us and Dan has been telling you. So it's very hard to meet. And the second section for client side is under Section 11.6.1, where it states that if there are any unauthorized modifications to a script, then relevant folks should be alerted on a periodic basis. This is again, easier said than done because you need to think about setting up a mechanism for all this. So sometimes, for example, just to highlight how tricky it is, even if there is a minor patch release from a vendor, it essentially means that the code has changed and it can be very hard to keep track of these changes, which is what one of the requirements states. So this is something that organizations need to start thinking about today. That sounds great. So it sounds like, though, for this new set of PCI controls, we're, you know, you mentioned some of the things they need to be concerned about. I'm guessing, Apoorva, it's safe to say that Page Shield will really, really help with compliance in these areas. Absolutely. So we can leverage some of the existing features of Page Shield to meet these requirements. Positive blocking feature which Michael was talking, which is the feature we launched today, helps us ensure only authorized scripts are executed on the end user's browser. And switching gears, Page Shield implements different mechanisms to determine if a script or a connection made by a script is malicious, with things like URL checks and domain checks with script detection by using threat intelligence and machine learning. All of these will ensure that the integrity of the script is preserved. And the Script Monitor... visibility is the first thing. You've mentioned that, Dan. So the Script Monitor gives an inventory of all scripts and all these things, all the features that I just spoke about, will help address the section, the first session of client-side security requirements that PCS put forward. And the second one, 11.6.1, where it states that unauthorized scripts or modifications to a script, these are all in the roadmap. Ultimately, we want to make it super easy for customers to meet PCI 4.0. That's amazing. And, you know, it should go without saying, but I guess it bears repeating nonetheless. You know, Page Shield is naturally fully integrated into the rest of our application security portfolio. You will, when you log in, you'll find it in the same console as the WAF you're comfortable with, your DDoS protections, bot management, API security, and naturally Page Shield is integrated there for tremendous ease of use and ease of management. So with that said, sounds like we've got some really powerful innovation coming with respect to to reducing the risk of third party JavaScript. Michael, thank you for joining us. Apoorva, this has been a lot of fun. We encourage everybody please check out the blog during Security Week. There's a lot more innovation to come and if you are an enterprise customers, please go ahead and turn on Page Shield script visibility today. With that, many thanks for joining us. Talk soon, everyone.