 Hi everybody. Can you hear me okay? All right. So, thanks a lot for attending this talk. A little quick introduction about myself. My name is Lavakumar. I'm the founder of Ion Wars Security. I'm the lead author of S-Boxer, which is a DOM security scanner, and I'm a web security expert who has primarily done a lot of work on the client-side part of web security, which is your DOM security or JavaScript security. So, that's a little bit of introduction about myself. So, this talk, we're going to cover four main areas. We are going to look at data exfiltration attacks. We'll see how they can be detected using a technology called a CSP, content security policy. We'll see how this can be implemented. So, I'll cover a few guidelines on implementing CSP in your company so that you can actually detect these kind of attacks and we look at the limitations of using CSP for this particular purpose, and we'll also see how you can mitigate some of those limitations. So, these are the broad topics that we're going to cover. Okay. Let's start with understanding data exfiltration. Anybody here already familiar with this form of attack? You can raise your hands. Magecart, has anybody heard about Magecart attacks? Anybody? Okay. How many of you have heard about idea systems or firewalls? Okay. That is good. Now, let's start with one attack which happened recently. It's called the Magecart attack. So, there are these three companies. It affected a bunch of companies. I'm just going to focus on three here. Ticketmaster, British Airways, and Newegg. All three of them are big companies. If you look at the impact of the attack, it's pretty massive in the sense they lost millions of credit card information, customers credit card information was stolen. But more than the impact, what is even more interesting is the duration for which the attacks actually took place. They went on for half a month and created of British Airways a month for Newegg, and for Ticketmaster it actually went on for more than eight months. And, you know, this is something I joke about which is if someone found out they were pregnant when the attack actually started, then before they found out about the attack, they would have actually delivered a baby. That's how long the attack was actually going on and nobody was able to discover that. So that's a serious concern, right? And these are not, we're not talking about mom and pop shops here. These are very big companies which have very good security policies and standards and all of that in place. Even then, these things went undetected. So, let's see why this happens. Because when you look at monitoring for data leaks or exfiltration, you usually do it for data leaks from the server side. But the blind spot is you do not even consider that customer data can be leaked from the client side. So let's, you know, this is an overly simplified version of your infrastructure. So this is your web server. You've got your firewall and the internet and the user. So your server side is usually monitored by some kind of a system. You know, it can be an IDS, IPS. It can be your firewall. You'll have some other kind of log monitoring systems in place. You'll be looking at your server logs, you know, the usual grind. So if, for example, suddenly your web server or your web applications start sending customer data or any kind of data, you know, let's say to suddenly to some Chinese to dot RU domain, then something in your environment will actually pick it up and it'll give you an alert. It'll tell you that, hey, something wrong is going on here. But imagine if the data is being leaked from the user's browser, right? You currently, you do not have anything in place which will actually pick this up. Now, when I say user's browser, this is user's browser when he's actually visiting your website. So let's say you're hasgeek.com. Someone is visiting hasgeek.com. So the JavaScript they're running on their browser is being served by hasgeek.com. And let's say you're registering for root conference. So you're putting in your credit card information and so on inside hasgeek.com, right? And the JavaScript which is running on the page takes the credit card information and it sends it to the attacker's domain. So it is still the responsibility of hasgeek to make sure that this does not get leaked or at the very least discover that, hey, my site is leaking data outside, even though this is happening from the user's browser, right? And currently we do not have any systems which will pick this up. So let's see how someone can actually inject their JavaScript into a big company. So typically what an attacker does is they'll use a bunch of techniques to find problems in a website and they will inject their own JavaScript onto that application. Let's say, again, hasgeek, I'm using it just because I have to pick some brand. So let's say someone finds some means of injecting their own JavaScript into hasgeek.com. So when you visit hasgeek.com then you have the JavaScript written by hasgeek developers along with the attacker's JavaScript. So this runs on your browser as well and this is what steals the data and sends it outside. Okay, so now how can an attacker actually inject JavaScript into your website? So there are four major ways in which it can be done. One is a vulnerability called as cross-site scripting. It's a web application level vulnerability and if your site is vulnerable to it then an attacker can actually inject JavaScript of their choosing into your website and when your users visit the site this will run on their browser. The other approach is if you're using external CDNs and if an attacker is able to compromise the CDN by a variety of means then they can actually start modifying the JavaScript which is being served by the CDNs, right? And since your users are loading JavaScript from the CDN, they'll be affected as well. The other approach is this one is found in a lot of places is ad networks. So if you're using an ad network, advertising network in your site, you're embedding JavaScript from these external sources and ad networks are usually more flexible about what you can do with them or who can actually serve data through them. So if an attacker actually finds out a way to abuse an ad network and send his own, send JavaScript of his choosing and if this particular JavaScript is going to be shown into your site through this ad network then again, attackers JavaScript is now running on your website. And then finally, if someone's able to compromise your web server itself, now this is the most serious scenario. If they're able to compromise your web server then they can essentially change whatever content you're serving from the server side. So this is an example of British Airways where I don't know if you can see it clearly. So there is this library called Modernizer which is a well-known library. What the attackers actually did is they were able to take control of this particular JS file and they added a few bunch of lines at the end of this Modernizer JS. So they actually modified this existing library and when this was running on the user's machine, it was stealing their data. Okay, now once an attacker is able to inject his JavaScript into a website, right? So these are the four ways in which he can do that. Once he's able to do that, the next step is for them to collect the user data and actually send it to their servers. So they'll have to extract the data out and these are the ways in which someone can actually do that. One is they'll have to make some kind of a network connection to be able to send the data from the user's browser to their server. One is they can actually try to load a resource from an external site or they can force the user to navigate to an external site or they can send data via communication APIs. So we'll just look at these cases. In case of British Airways, what they did was this is the bit of JavaScript which was injected towards the end of modernizes. So this was attacker control JavaScript which was injected into that. They had actually written a nice jQuery method which will make a post request to a domain called baways.com. So this was a domain which was registered by the attackers. So one thing they were doing was they were registering domain names which look kind of similar to the site they're attacking. So if they're attacking British Airways then they registered a domain called baways.com and they were just making a direct Ajax post request to that site with the user's credit card information. So here they get the credit card data from the payment form, a HTML form and then they actually put it in this jQuery and they send it. Okay, so if an attacker is trying to load resource from an external site then they can actually do something like this which is they can, in the URL of the resource that they're trying to load they can actually put the data that they want to steal. So when this request is made to the attacker's site the attacker will get this information. And like you saw earlier in the case of British Airways they can actually make a DOM communication API an Ajax call and they can actually send this information to the attacker's site. Okay, so this is how somebody can actually steal data. This is how they can inject their code into your site. This is how they can steal the data. Now let's look at how you can actually detect something like this. Because right now this might be happening on websites that you manage and you might not even know about it, right? So how would you detect something like this? So this can be done in two ways. One is you can detect something like this at the JavaScript level. There are a bunch of companies which actually give this as a service. So what you do is you inject a piece of JavaScript at the start of every page that you're serving. Okay, so this JavaScript will, what it'll do is it'll essentially create an abstraction over your entire DOM APIs and through that it can actually monitor what your site is doing and it can detect abuse of certain DOM communication APIs. So this is how it looks. So normally your application code, whatever your code your developers have written, if they want to do network communication or if they want to do DOM manipulation, then they would directly call the native APIs for doing that. But once you inject this piece of JavaScript into your site, then this creates abstraction. So any network communication API your developers code is trying to do, it actually comes to this abstraction layer. The abstraction layer can now know that, okay, you're trying to communicate to abc.com and then it can choose to either alert you or it can choose to even block that, right? And then it'll call the native API after making this particular decision. Now it looks good in theory, but there are a bunch of problems with this particular approach. The first one, it's complicated because you're actually changing the nature of your JavaScript's execution environment because you're hooking on to the native APIs. So you change your JavaScript's environment and if you don't do that properly, then you will actually break your website. So it's kind of tricky to get this right. That's why there are commercial services for this. And another downside for this is it's very developer dependent because you'll have to make sure that you're injecting it at the start of every single page. So this will require you to work with your developers to actually have this implemented and it can have performance impact because every DOM communication API or every DOM manipulation that you're trying to do, there's going to be this abstraction layer which is actually going to come inside and it's going to monitor what you're trying to do, right? So that will actually add a performance impact to your regular JavaScript execution and it could break functionality of the site if you have not done the hooking properly and in case your JavaScript is written in a certain way, it can actually break the functionality. So you will get detection for the problem but you might have to face a lot of challenges which means that for you to actually sell it to your management, hey, this is a problem we have and this is a solution and when you try to sell the solution and if you run into these kind of problems like performance impact and functionality breakage, it might not get pushed into production, right? So your effort might just end there. The other approach is using content security policy. Now with content security policy, the benefits are it can be done by the network or infrastructure team so it's not really developer oriented, at least it doesn't entirely depend on the developers. It's a much more simpler approach because you don't have to write any JavaScript, you don't have to change any functionality of the site and it will not break your site. So CSP has different modes, you can put it in blocking mode or you can put it in monitoring mode. If you put it in monitoring mode, it does not have any impact on the site's functionality at all, right? And the last thing is it has almost no performance impact. So in all ways, this is a much more easier approach to take to find this kind of a problem. Now how many of you know what a content security policy is or you have at least heard of it? Okay, that's good. For the ones who do not know because we're going to use this technique to detect this problem, a quick introduction to content security policy, you can think of CSP as a firewall for the browser, right? Essentially it's a header, it's a HTTP response header. You configure this, it's a header and you set a value for this header and what this header does is you're essentially telling your browser how to execute that particular page or in some ways you tell the browser, hey, you know what? When you're executing this page, these are things you can do and these are things you cannot do. So once your browser looks at this policy and whatever JavaScript you have served and whatever HTML you have served and when it's actually trying to render and execute this code, it will use this policy as a reference point, right? And it'll make sure that whatever execution it's doing, it's in compliance with the policy that has been set in the header. And if there is a different mismatch, then depending on in which mode you have set CSP, if there's a mismatch and you have set it in blocking mode, it'll essentially stop that particular functionality from working or if you're monitoring more or reporting mode, then it'll tell you, it'll give you an alert saying, hey, you have a policy and the way in which your JavaScript is executing is not in compliance with the policy. You know, it'll give you this information. Okay, so this is an example of what a CSP header would look. So you have the header names. You have two different header names for either you wanna put it in blocking mode or you wanna put it in the reporting mode and this is what is called as a directive. I'll just cover it briefly. So you have a directive and then you have a value for the directive. So each of these are different behaviors you're defining, right? So you give a behavior type and then you give the nature of the behavior that you are accepting and then you have a report you are in. I'll just cover these in detail in the coming slides but at a high level, this is what it looks like. You have a bunch of directives which are separated by semicolons. So you can have different kinds of behavior defined, okay? And this is the HTTP response header. So in the response, the header is going to be set which means you can set it at any level. You can even set it from your web server level or if you're on cloud fare, you can set it at the cloud fare level as well. Okay, so CSP directives which is essentially, you know, these each block which is separated by a semicolon. So each CSP directive talks about a certain aspect of the browser's behavior, right? So when it comes to detecting data exfiltration attacks, the kind of browser behavior that we are interested in are resources loaded by the browser and communication done by the browsers. These are the only two types of behavior that we are interested in. So when we are looking at CSP directives, we'll have to see what CSP directives are associated with these two behaviors. And these are the different CSP directives we have. Again, I'll cover these in detail in just a little while. So these CSP directives are the ones associated with the resources loaded by the browser and the communication done by the browser. And then you have the CSP directives value. So this defines for a certain behavior, what, you know, like, or for a certain category of behavior, what it is that you think is, you know, acceptable. So for example, there is this directive called connect SRC. So connect SRC essentially tells, defines to the browser who your browser can talk to, you know, which domains you can make an Ajax call to or a WebSocket communication to. And the value which follows after that will give the list of domains to which, you know, you say the communication can actually take place. So if you say none, if you say connect SRC none, then you're essentially telling the browser that you want to disallow all DOM communication. So JavaScript running on the page cannot make any Ajax calls at all because your policy says it should not, you know, you should not connect to anybody. If you say self, then it'll only allow DOM communication or Ajax calls, WebSocket communication and so on, to be made to the same domain from which the page is being loaded. So for example, if you're, you know, visiting Hasgeek and if Hasgeek has this policy, then the browser can only make connections to Hasgeek.com. It cannot make an Ajax call to another domain. And then finally, you can actually explicitly specify a domain name as well, you know, and you can say, okay, I only want to allow communications to these domains. And this is how you would essentially, you know, specify that in the policy. So, you know, these are the values you set to a CSP directive. Okay, I hope till now, you know, things are very straightforward, things are very clear. So now actually, let's actually look at, you know, each of these directives that I mentioned, very quickly I'll see how we look at how these directives apply. For example, if you say script SRC and you give a specific website, you say script SRC and this website, then if you have a script tag and the script tag refers to that particular site, then the browser will load the JavaScript. If you have any other website being mentioned for script SRC, then the browser will refuse to load JavaScript from there, right? Similarly for style SRC, this relates to your CSS. So you can define from where you load CSS content. Image SRC is for your images. This defines from where you can load images. Connect SRC will apply for all your DOM communication APIs, you know, fetch, XML HTTP request, WebSocket and so on. Font SRC, you know, pretty straightforward from where you'll load font files. Object SRC, which is for your flash and other similar embedded content. Media SRC for audio and video tags, HTML file audio and video tags. Frame SRC from where you can load an iframe. Worker SRC, you know, when you start a web worker, you can actually, you can specify a URL. So the JavaScript from that URL will be what is used in that particular web worker. So you can define from which URLs you can actually start a web worker. And form action will define to which sites you can actually submit an HTTP form, right? Once you fill it. Manifest SRC from where you can load manifest files. Right, so these are all the policies that we are concerned about or at least the directives that we are concerned about when it comes to detecting data filtration attacks. And, you know, these are the places in the HTML where they actually come into play. Okay, so now that we know what CSP is, what are the directives we can use to control the browser's behavior. Now we'll have to, the next step is what policy do I set? Okay, I know that I can use content security policy to restrict my browser's behavior. Let's say for example, script SRC. You can define from which sites you can allow script to be loaded. But first you will have to know from which sites you want to allow sites to be loaded normally, right? So that information is not available to you usually. So this is kind of difficult to get, which is you have to first create a whitelist policy. So imagine you're setting up a firewall. One is, you know, you will write a few blacklists. And the other thing is you will have to allow some legitimate traffic as well. So you'll have to know which ports should be opened on the firewall. So you'll have to do a similar thing for CSP as well. But you'll have to first know to which domains you will have to whitelist. Now, getting this information is difficult normally because you'll have to sit with your developers or you'll have to analyze your site in detail. But there's a little trick to it, which is you can actually let CSP itself tell you what sites your browser is actually loading data from. So what you can do is, this is where the CSP's report URI feature comes in, which is if you set CSP and report only mode, and if there is a policy violation, then there is a report which is sent to your, you know, whatever URL you give here, saying, hey, this is where you should send your reports to. Then your browser will actually send you an alert to this particular URL. And from the alert you can actually get information about, you know, the domains from where your site is normally loading data or, you know, from with whom it's usually communicating. So this is how a report looks, a generic report. So here, there is a style src directive, which is specified. It says style src, cdn.example.com, which means that I'll only load, I'm sorry, there is a style src, which is specified here, which says that you'll only load CSS content from cds.cdn.example.com. So this is the whitelist you are specifying. You're telling the browser only load CSS from this domain. But what's happening is the browser is actually trying to load CSS from example.com. So there's a mismatch between your policy and from where the site is actually loading data. So you get a report like this and from the report you actually know the actual CSS content your browser is loading. And what you can do is you start with a very simple policy and then, you know, you let your users browse the site as they're browsing the site. You'll get these reports and from the report you can actually create a database of all the different normal behavior that your application is supposed to do. And with that, you can create a whitelist. So this is how it typically looks, which is you set a CSP policy and you send it to the users. The users as they browse the site you'll get these violation reports and these violation reports will be sent to your CSP endpoint. Now you as a user, you can actually analyze these reports, these violations. You can see what changes are like, you know, what policy violations are usually happening for your users. And then you can determine if this violation is actually legitimate in the sense if you see that a CSS is being loaded from example.com and that's being alerted to you, you can confirm if example.com is a legitimate site from where you want to load CSS. And then what you can do is you can now go and update your CSP policy. So if you, this is like a feedback loop as you keep updating your CSP policy the number of alerts you will get will just keep reducing over time. And then if you do it for some time then you will get a CSP policy which is pretty accurate. It'll define your legitimate behavior pretty accurately. So any violations post that will usually be a problematic violation, right? Which means it is something which probably an attacker's JavaScript is trying to do. And that's how you detect, you know, data filtration attacks with CSP. Okay, so for you to actually start with this, for you to set an initial policy, this is something you can start with which is for all of these eight or nine different CSP directives that I just mentioned, you can start with self which is you're saying that, hey, you know what? You can load CSS content or you can load JavaScript or you can do an Ajax call but you can do it to the same domain. And most websites, they load a lot of content from the same domain. So by doing this, you will at least reduce the number of alerts you will get initially. So this is a very good initial policy to start with. So you start with this and then you look at the CSP reports and based on that you keep, you know, fine tuning your CSP policy. Right, so till now I spoke about, you know, what CSP is, what are the different directives in CSP which you can actually use to, you know, create a system by which you can detect data filtration attacks. Now let's quickly look at the limitation of this particular approach. Which is CSP was not originally designed for detecting these kind of problems. It was designed for detecting or at least detecting and preventing mostly across the scripting vulnerabilities. Right, so that was the original purpose for which CSP was designed. So naturally, if you're using CSP for this particular problem, there are going to be ways to bypass it because it was not primarily designed for this. So some of the ways are an attacker could use DNS prefetching to leak data. They can set the location or HLF property. They can try to navigate the user using an HLF tag. I'll talk about these things in a little detail. They can use window.openAPI to open a new window or they can use the WebRTC APIs. And all of these, no matter how good your CSP policy is, an attacker might use these techniques to actually send data to their domain and your CSP policy will not pick them up because the policy does not apply on these particular behaviors. So this is how an attacker can actually steal data using DNS prefetch which is he'll, the stolen data that he actually wants to send to his domain. So if the attacker's domain is attacker.site and if he's going to take the credit card information, then let's say he base 64 encodes the credit card data and then he'll put it as a subdomain for his website. So now there would be a DNS lookup which will be made for this particular subdomain and the DNS lookup actually contains the credit card information, right? So if the attacker is looking at all the DNS queries which is coming to his server, then with that he can actually steal the data. So you don't necessarily have to make a TCP connection and send the information which is the DNS query itself, the attacker will be able to get the data. So this is particularly tricky to find, a DNS prefetching. And then you have setting location on href which is the attacker could take the stolen data, he could again put it as a subdomain or he could put it as a part of the URL and he'll set it to the location on href which will essentially redirect the user to this new URL, right? So which means the request is made to the attacker's website and the attacker will now have the stolen data. Now this is not covered by CSP. So another thing you can do is you can create an href tag and you can hope that the user clicks on this tag. When the user clicks on this tag, he gets navigated to this new page and when he gets navigated to the new page, he makes a request to the attacker's site and the stolen data is actually sent to the attacker's site. And the same thing you can do with window.open. I say window.open and I specify URL and the URL has the stolen data. Now there is a request made to the attacker's website, the stolen, the data is sent to him. Okay, so you have all these problems. Would you still want to use CSP to prevent this particular issue? I would say yes. It's a very subjective question. So because even with all its limitation, CSP still makes the attack harder for an attacker to perform. Like for example, if you looked at Magecart, the attackers were just sending a plain post message and they were sending the data to the attacker's website very easily. But by doing this, you're at least making it a little bit harder for the attacker to steal the information and if you're looking at very generic attacks, maybe they work on other websites, but because you're having CSP in your case, it'll get detected, right? So the attacker might have to make it a little bit customized for your domain. And another thing is CSP version three, which is a newer version of CSP that is coming. It's actually having mitigations in place for some of the limitations I discussed about. Like for example, there is a new directive called prefetch src, which talks about DNS prefetch. And there's another directive called navigate two, which controls to which site your user can actually navigate to. So these two, once they come into full force and once they get implemented in most major browsers, so this will actually have a good amount of coverage for the limitations that we just spoke about. So this is how the prefetch src works. It's very similar to the other directives. So once you specify a particular domain name, then the DNS prefetch is only done for those domain names, right? For all of the domain names, the DNS prefetch does not work at all. So stealing data through DNS queries is now lost. And then when you put the navigate to directive, it essentially controls the sites to which you can navigate. So if I put a href tag and if the URL I give there is not part of the CSP and the user clicks on it, he will not get navigated to this new URL, right? So his navigation is essentially restricted. The same with setting location or href, the same with trying to open the website using window.open. Okay, so these things do fix some of the mitigations, but that's coming in CSP version three. But in the meantime, you can use existing CSP and you can do a little bit of hack with it to extract some more mileage out of it. So what you can do is you can use CSP to identify the list of all JavaScript code which is running on your site, okay? And on periodic basis, you can take this list. So this is something like this. If you set your script src to none, right? So which means any JavaScript which is loaded by your website, you will get a violation report for that. So which means essentially any JavaScript which runs on the browser, you will get information about it in your reporting. And from there, you can just make the list of all JavaScript code that your website is normally loading. So you can make a list like this by setting script src to none. And once you have the list, you can try and compare it with the historic list. For example, you set script src to none on 20th April, right? So you get a bunch of reports. From that report, you collate the list of all JavaScript code that your site is loading. And then you set your CSP policy back to whatever it was earlier. And then on 27th April, again, you set script src to none. So now you can get the list of all JavaScript code which is being loaded by your website right now. And then you can actually do a biff of these two. So you will know what new JavaScript code has been added to your site in those seven days. And then you can only look at these new JavaScript code and you can see if this is coming from a trusted source or if it's coming from an untrusted source or you can open the JavaScript and see if it looks malicious. It kind of narrows down to the area where you actually have to do any analysis. And if you see there is no difference between 20th and 27th, it means nothing has changed on your site. So there's nothing for you to worry about. So by doing this, you're using CSP in a different way to actually find out what new JavaScript code is being added to your site. And you can use that to analyze and find if there's anything malicious going on. So finally, there are some tools available online which will help you define and create CSP headers. So you have CSP is awesome. So you don't have to know the detective names and you don't have to know the exact values and how to specify them. You can go to the site, it gives you a nice UI. You can go and click a bunch of check boxes and it'll generate a CSP policy for you. And you have this open source project called CSP server. So this is essentially a reporting server which is capable of, so if you want to send your CSP report somewhere, you can set it up on your system and you can point to this URL. So this will take the CSP report violations, it'll store it in a database and it'll make it available to you via Elasticsearch. So you can actually query for information through Kibana and so on. Okay, so with that, I'll come to the end of the talk. So the key takeaways are, you have data leakage attacks on the client side. This is something which is serious. It is very real because it's happening right now. I spoke about three companies which got affected. There's a whole bunch of other companies which got affected and your companies might be affected right now as you're sitting here, right? And you might not know about it. And these attacks are impactful as well as we saw because it can lead to several millions of information, users information being stolen. And this is currently a blind spot in your security monitoring. You might have all the, you might take all the check boxes as far as your compliance is concerned, but still this is a blind spot. Something for you to look at and you can try and mitigate this using CSP. My slides would be available. So you will get all the information about the headers and so on. So that'll give you a head start of how you can use CSP and you can actually come up with a policy and you have a fighting chance against attack like this. Okay, so with that, I conclude my talk. Now I can answer questions. So my question is, with this approach, the mage card attack is only prevented if not only I was able to figure out that BA ways the JS pointing to that is added to my website. Plus I will need to do the code review, right? Because the actual place where it got added was the modernizer, which I'm assuming as per your case study was already part of the website, right? So an existing JS was changed, right? Now that's fine, but the reality is a lot of modern deployment strategies for front end, right, is to pack the JavaScript files. Together, right? Right, right. Especially with your web pack or whatever. Either they called main.app or vendor.js something, right? So what do you recommend is a good approach to be able to do that review? Because otherwise it's a problem. Yeah, so the code review part, that's the thing I spoke about at the end, right? So you see what has changed in your website and then you try to review that part. So if there is a new JS file that's being loaded, then CSP, you know, using that particular hack, you can find out there's a new CSP loaded and you can go and review that. But in case of British Airways, it was the exact same JS code, right? So you will not get a CSP violation for script as RC directive. So there's not a new JS code being loaded, but where you will get an alert is when this JS code, from wherever it's loaded, however it's loaded, right? It might be an existing JS file which has been modified, but its behavior has now changed, right? Because now it's trying to send an Ajax call to a website that normally, this JavaScript was not sending to. That's when the connector SC directive kicks in. And then you get an alert saying, hey, now your website is sending data to baways.com and you can look at baways.com and it's like, hey, I don't own this domain. Now what's going on there, right? So you're not just looking at the code that you're loading. CSP is also looking at the behavior of the code as in like when you're trying to send the data outside, right, it kicks in there. Yes, yes, yeah, yes, yeah. So that's, I mean, like you have commercial offerings for this which automate this whole process, right? Whatever I said about manually. So you have offerings for doing that automatically as well. So in that case, you just turn it on and they just keep getting alerts whenever these things happen, right? Yeah. So I had one question. So isn't this limited to the browser support? Yes, it is. Like for example, that's a good, that's a very good point, which is different browsers have varying levels of support for CSP. So Google Chrome, for example, has very good support, but Edge might not have, although the newer Edge might have because it's going to be built on the, you know, a Chromium engine. But beside that, for this something like this, it is okay if you don't have full CSP support because you're trying to detect attacks which is affecting all of your users. So these are not targeted attacks, right? So somebody has injected JavaScript which is running in the user's browser and it's sending data away. So if even 50% of your users are using Google Chrome, so at least you get an alert that something is going on and you look into it, once you fix it, it fixes it for all of your users, right? So unless the attacker's code is written in such a way that he checks what browser they're running on, so it gets a little bit more specialized. So it's like I said, it's not a silver bullet, but it makes it a little bit harder, right? For the attackers to do their things. One other question. Yeah, you will have limits, but it's very easy to bypass it because the attacker can like split the data into smaller chunks and he can put multiple prefetch attacks. So that is really not a problem from a lot of times that the amount of data you want to steal does not necessarily have to be large. Like say for example, credit card information and so on, they're pretty small, but they're still very sensitive, right? Yeah. For party library available for that, like if the previous question, for example, if I have a very old browser, then I can't prevent it without. You're talking now from the user's perspective? Yeah. I mean, if your browser is up to date, then I don't have to worry about this. Like for example, CSP3 is implemented in that browser, then most of the problems are gone. So is there a third party library or something available that I can inject in? Like a polyfill, you're saying, for older browsers? Instead of CSP, which can work as an alternate? I don't think so. I mean unless if a browser, so again, I will recommend you don't even look at that option, right? Because we're talking now from a website owner's perspective. We're not talking from the end user's perspective, right? We're talking from the website owner's perspective. As a website owner, your goal is to find out if your site is infected, right? So even if 10% of your users are using a browser which supports CSP, let's say CSP version three is released, right? And even 10% of your users are using a browser which supports CSP version three, you're serving the same JS code to all of them, right? And if the JS code is going to use DNS prefetch and leak data, you will get alerts from these 10% of users. And from that, you will know that your site is affected. So now you will go and fix it, right? We can discuss it offline. Okay, so there are two headers, right? One is for blocking and another is for reporting. Yes. So is it possible to do both block as well as report? And another thing is does it sample requests to the report URI or does it send every request? So what I'm hinting at is can it be used in production or like where you're facing a lot of traffic? Yeah, this can be used in production. And if you put both the headers, right? Report header as well as the blocking header, if the header values are the same, right? Then obviously it'll block it and it'll also give you a violation report. In fact, you don't have to put two headers. You can put the report URI in the blocking header as well. What you can also do is you can have a more lenient blocking header and you can put a more strict reporting header. And what CSP will do is it will, in some ways, you know, like honor both of them, right? So whatever is defined in the blocking header, it'll block them. And if it sees violations for the reporting header, which is more strict, it'll give you the violation reports as well. So you can, as long as you're not blocking and when you're blocking, you're sure about what you're blocking. If you're just going with reporting and you're being more strict with reporting, you can put it on production and that should not be a problem at all, right? Okay, thanks a lot, everyone.