CSP: Advanced Tactics

[applause] Thank you. >> Uh, hi everyone. How's your day going so far? Good. >> This is a kind of a tough spot for a talk because I'm like right before lunch, so I have to talk over all your grumbling tummies as we get into there. So, um, you might be thinking, uh, CSP, content security policy. Some of you are probably familiar with this before and you're wondering, hey, why is this guy doing this talk on this thing? It's been around for a while. Um, and uh, and I I got to doing some some research earlier this year because I was curious how much of the um, like com how are companies actually leveraging it today, you know,

with modern applications with um, with the proliferation of just applications in general on the web. has has it actually gained um proper level of of being adopted? Um and uh that led me down the path of hey you know I found out some interesting things. I was just doing some research for myself and then I decided okay I'm going to make this talk on it. So um this is the result of of that exercise. My mic's going in and out here. Hang on. Making a little adjustment because it sounds like I am my I keep coming in and out. Okay. So, who am I? Um, I'm the CIO at Secure Ideas, which is a we're a

pentesting company. Um, we have about 30 people, which in a company that size, if you're the CIO, that means you basically do all the jobs. [laughter] So, right. Um, so I I do a little bit of everything, including penetration testing. Um, I'm also an Ions faculty member. Has anyone heard of IANS here? Maybe a couple people. Yeah. So, Ians is an expert support system. Um they match up experts in certain fields with companies who are looking for those experts to uh help them with um decisions. So, my area of expertise for Ians is in application security. So, it's kind of in line with with this talk. I'm also an OAS project committee member. Um so, if you've heard

of OAS, hopefully if you're into application security all at all, you have. Um, so I I help shepherd the projects through the uh the various different processes and and and whatnot there and determine, you know, if somebody brings us a new project, where does it actually belong? Is it something that's new or does it belong to another project? Um, those types of decisions. Um, I've been doing some form of pen testing since 2009, so it's been a while now. Um, and I've been programming for even longer than that. So I was a software developer. I my first computer was a Commodore Vic 20. Anybody know what that is? >> Okay, we got a bunch you do. Okay, that

was my first one. I saved up my I was I was just a kid. I saved up my money for mowing lawns and I bought a Vic 20. Um and then I I did the first thing that a kid's going to do with a Vic 20 at that age, which is build a Dungeons and Dragons character sheet generator program on it because, you know, I'm a bit of a nerd that way. Um, which is a challenge by the way because you know the Comra Vic 20 that's only 20K of of of actual memory in there and once you load the operating system you're down to less than 4K for actually writing a program, right? So you're you're pretty

limited. So one could say I actually started hacking things since um much sooner. Anyway, um on from there I have some other interests. I don't think those are are particularly pertinent to this conversation. So, I'm I'm just going to jump into uh content security policy stuff. So, what this is in a nutshell, if you haven't heard of this before, um that's okay. Uh I know the talk is advanced tactics, but I'm going to go over the basics, too. So, content security policy is something that's already built into your browser. Every browser has one. Every modern browser has one. Okay? Um has the ability to support the content security policy. What it does is it lets you turn

features off in the browser. Things that it would normally do, it can turn them off or restrict their use. Okay. Um, one of the the main ones that we think about with content security policy is the ability to run JavaScript. So, with the CSP, content security policy, you can uh you can help define um when what JavaScript is allowed to run within, you know, a particular page, right? That's one of the mains when we think main um use cases we think about when we say CSP. But there's actually a bunch of other things that it can do that a lot of people don't really know about. Um now it is a tool in the toolbox.

Um so it is uh you know you have other controls in place. You can do your output encoding, your input validation. There's there's lots of other things that you can do. You can have WFT in front of it. There's lots of other things you can do to like prevent cross-sight scripting attacks, let's say. So, this is but this is yet another tool. And the convenient thing about this tool is it's available across all browsers already. It's it's already there. It's not something you need to install. It's not something that costs extra money. It's there. Um, unfortunately, a lot of people don't really make good use of it. So um on the screen right now I have a

couple of just little examples of a content of content security policies and what they do. So the default source just means allow anything but only from the same origin. So when we're when we're talking about same origin what we mean by that is like if I load a page from www.agample.com then anything else that's loaded from www.agample.com example.com is the same origin as long as it's the same port protocol and and the domain is the same. It's considered the same origin. Anything outside of that is a different origin. Right? So whenever we have the word self in here, we're talking about same it's it allows loading from the same origin only and it restricts anything that's not self. Right? Does

that make sense? Okay. So, what happens in your browser if you have a violation against a content security policy? And I have some examples of this later because I'm actually going to show you a live demo. Um, but you what you're going to have is is you're going to have an error message that'll look something like this. like it's all I know it looks all scrambled together on the screen but um this is basically saying executing inline script violates the following content security policy directive because on this page I had a CSP defined and then I tried to run a script and it failed u because it didn't meet that policy. So what it's going to look like is uh it's going to

it's going to tell you hey this failed because of the CSP and here's what you need to do to fix it. and actually gave me a hash on there of the script that failed. So, I could put a hash instruction in my CSP, right? Um, it also talks about using a non. And I'm going to go over these in a little bit more detail. Um, and uh, and then it also says, you know, you could also use unsafe inline, which by the way, the word unsafe is a hint that you probably should avoid using that one if you can, right? So um jumping [clears throat] ahead to the stats. So what I did is I I built a

program. This is AI has been great for this sort of thing. I want to do some research on the internet. Call AI for some help on building scripts to do things quickly. Right? So I built uh some scripts to um basically scrape the content security policies off of the top 1 million websites. According to the Tranco list, there's actually only about 760 some odd thousand that resolved with a um that where I actually got a website to resolve on it. So, it's not a full sample, but that's still pretty big. It's, you know, it's still 3/4 of a million sites I have up there that I pulled this data from. And um and I'll show you some more later on, but what

what I wanted to do was look at a couple of things. First of all, how many of them are actually using a content security policy? Now, in some cases, you don't really care. If it's just a brochure website or something like that, it doesn't really need one, probably. I mean, if you have forms on there, you probably should have something. But but if if all it is is literally just brochure wear, then then you might not even really care about having one. So, it's understandable that a large percentage of these don't have any CSP. But that still leaves a big chunk that that um that have a CSP um that I want to kind of dig in a

little bit more on. So um what I did is is I took my my focus area wasn't that 81.31%. That's still a good stat that shows you, hey, you know, most people still don't use them, right? This this technology has been around for at least a decade and it's still not being consistently used. And then the question is, okay, well, what about that nearly 20% that are using them, how well are they actually using them? Because what I noticed in in pentesting is very often we would um when we when we first heard about the CSP, we would just call out or we'd see from scans people calling out that, hey, you don't have a CSP, you need to have a CSP.

Okay, so this was a control that that uh security experts were saying everybody needed to implement on their websites, but they didn't really tell you how. So it became a checkbox. And so now the question is, well, how many CSPs exist that are completely ineffective, right? And that's that's really what I dug in on. So to to measure that, so again focusing on that sort of nearly 20%, we'll say 18% there. Um I I built uh a rating system across six different categories of directives inside of CSP. And I'll talk about some of those directives a little bit later to kind of give you an idea what those are. And then I broke those down into a a scale

that would measure these. And of course using AI scripts, it generated scripts again I was able to very quickly come up with a okay well can you categorize all of this for me. Um, and so I it basically I built out a scoring system that would tell you, you know, how good how effective is the CSP that's actually there, right? So if it's all ones across the board, then it's basically just a checkbox content security policy that doesn't really actually do anything because it's doesn't have a a script source defined um or like it's it's missing most of the aspects of this. it probably has u unsafe inline um and it's you know it's basically using features

inside of the CSP that are just loosening it up completely so it's not really that effective um and then I I built some thresholds uh so we would what I said is okay going going back to here where we have these six different items that are being scored oops if I have um all of the areas were three or higher I would say okay this is comp comprehensively protected okay and note that oops sorry I just went too far hang on um this is a scale from one to five so by saying three I'm actually being generous I had to do that because when I said five the numbers were always zero like nobody's doing that right there nobody is

actually making perfect CSPs out there at least from the data I had I didn't find even one that was that was would have rated all fives on my scale so I'm like okay well maybe my scale is a a little bit too tough. So, let's just say three is is what we're aiming for. And so, I said, "Okay, well, let's aim for three." Con so comprehensively protected is all three uh areas areas are three, all areas are three or higher. Substantially is u four four to five out of the six areas at a level three or higher. Partially, so substantially protected, that still seems kind of like we're being very uh loose with this, right? Just kind of letting a lot of

things slide. Um and then partially protected is two to three areas and then minimally is everything's below a three. Um but at least one score is a two or exactly one uh one component is is greater than or equal to three. Um and then ineffective means everything's at a one. Um and so this was the output from that. So, and what I what I found was that um on a percentage basis, we have about 30% of all the CSPs that are that are implemented on the internet appear to be completely ineffective. Like they're basically just a checkbox. It doesn't do anything. It's just there so that to make somebody happy that they they implemented it. And then nearly half

fall into that minimal category, right? So they're not really doing anything. And and if you look at this really comprehensive like so we're actually doing all of the things at a just a level three or better on my scale is only 6% that are actually implementing to that level, right? That have actually done all of the the the work on it. Even if you combine those two, the substantial and comprehensive, you're still looking at, it's still well well below 10%. Right? So it's a pretty small amount that are actually doing it. And so that kind of led me to, okay, well maybe we need to talk about this again because we tried like 10 years ago

talking about content security policies. It got pushed out there. Some people used them. Um, and I I really think it's a I don't think it's a necessarily a required control, but it's one of those defense and depth things, right? it's an extra layer. Um, and it doesn't cost you that much to put it there. So maybe we need to understand it a little bit better so we can make use of it. Okay. So if you don't take anything else away from my talk, you should take this part. This is where all of the oh yeah, here's all of the extra things that it does knowledge is that people don't really understand. So, if I take the

script part out of the equation, okay, because that that one that's the one that anyone who's dealt with a content security policy before probably understands like the script source aspect of it. So, when you take that out, what's left? Here's the extra things that it can do. So, you have a frame ancestors directive that can be used to actually prevent clickjing attacks. Okay, it can make your it what it does is it is it instructs the browser to say, "Hey, don't load this page into any other frames except for the frames that I've whitelisted here that I've approved." Right? So that makes it really hard for an attacker to take part of your website like maybe your login or something and

stuff it inside of a frame that they control. Um, so that's frame ancestors form actions is great because if you think about this, um, if if I'm able to inject HTML onto a page, but maybe you have a CSP in place so that I can't run scripts on that page, that doesn't mean I can't still deface the page in some way. And what if what if or or either deface it or change other parts of it? One of the main things I like to do, this actually happened on a pen test. I found and I swear there there was a content security policy. It was preventing me from running scripts. It was in the login

form that I was able to put an injection point and it was a field. It was a hidden field above the username and password. So, you kind of imagine there's three fields in there. I can't remember what the field was for, but but it was something that was actually passed into by a URL parameter. And what I did was I'm like, "Okay, that's great. I'm going to use my injection point because I can't run scripts in here. I used my injection point to close out that form, start a new form that had its own action so that it submitted the form to me instead of submitting it to where it was originally intended to go." Right? All without

using any scripts on there. And it worked. Now, had had they actually set the form actions on there, the CSP would have prevented me from being able to submit that form somewhere else, right? So, that would have been actually an effective control for that particular form, right? And it's very easy to do. I mean, most of the time when you're writing an application, you're not expecting to be submitting forms somewhere else, or if you do, you know where you're sending them. Like, you're going to have a list of places that that are okay to send it to. So, but this is almost never you almost never see this in a in a content security policy where

form actions is actually defined anywhere. It's very rarely used. Um, frame ancestors actually is used a lot. Uh, and I'm not sure exactly why. I'm guessing that somebody gave advice um probably as a replacement for X form actions or something or X-frame actions. Um, so I have actually seen quite a few cases of that but form actions I don't um the base URI. So setting that one on there is important too because that the base is basically the root of everything else that happens on that web page. So if you're able to change that then you can you can effectively change where that page thinks it is like what it thinks it's um it's its same origin

is right. Um so that's that's kind of an important one. Uh object source um that's for controlling like plugins and in embeddings and stuff like that. A lot of websites don't even use that but the feature is on by default and CSP can turn it off. So we all know in security that if you have features in any system you can reduce your attack surface by taking turning off the features that you don't even need. It becomes something that's not attackable. So why not just do that right? So we can we can completely eliminate objects sources from working. Um image source uh that one's a good one as well. There are attack vectors that leverage um that

leverage image tags. Um I don't have um style source on there, but that would be another one that would kind of go in with image source. Uh and then um and then you have um cont uh connect source, which that one's a really big deal because this is how a lot of actual payloads are going to work, right? Um, so if they can get script running onto a page, what they're going to want to do usually is leverage that to collect information to send it somewhere else. This is how a key logger is made on using cross-ite scripting. Right? So if you can control the connect source, which again, this is another thing where normally when we're building an

application, we know what we want to allow it to connect to, right? We're not going to let it connect to random things in most cases. There might be some exceptions, but most of the time we, you know, it's going to connect to itself or it's going to connect to certain APIs or other systems that you already own. Um, so it's easy to come up with what that list is of things you should be able to do, but most people don't set this one. So, it's another one. Um, so that that's it, right? That these are the essential directives. These are the things that that in my opinion opinion we should be doing. Um, okay. So now we get into some of the

advanced tactics because one of the biggest problems that we run into if anyone's in uh on the on the side of of uh telling your developers, hey, you need to implement a CSP. Um the push back that you're going to get very often is, well, when I do that, it breaks stuff, right? You've all heard that one. It's breaking things. So how do we get around that problem? And how do we make this secure? And so I I have a a couple of things to consider here. Um, and this is this is the big three um advanced ways of using CSP that are out there. There's it there are a lot of lots of other nuances that you can build in but

but these are the main ones. So you have nonses, you have hashes, and then you have this concept concept called strict dynamic which typically goes with nonses. Um, and I'm going to show just a a simplified example for each of these in a second. Um, and then normally how you'll want to use these is for external scripts, those things or things that you're loading from outside of your application, you'll use nonses for that. For things that are already built into your application because it's easy for you to generate a hash of those at build time or deploy time, those are things that work really well for hashes. And once you've defined those in there and then combined with

strict dynamic, you'll see it becomes very very difficult for an attacker to actually get a payload to actually get into that system because they won't know the knots. So they can't guess that and they have no way to to uh put the hash in and it's really really hard to find like a with a SHA 256 for example, it's going to be really hard for them to build a script that's going to work that's going to be the same uh hash as a script that's already on there, right? there is a possibility of finding a collision but it's really really rare. So um looking at what these actually look like. So the the header remember so

the CSP header is typically going to be a response header right it's going to be coming back from the server. That's not something an attacker is ever going to really have any access to. If they do you have bigger problems. Um but in the so what'll happen is inside your content security policy header you're going to say um you're gonna you're going to have script source and then nons and some random number and that would get generated fresh with um us often you can do it with every request right and then down inside the script you have your knots actually defined where where your script tags are and because these two match the content the browser will say

hey you have a content security policy that says only run scripts with this nons. Oh, I found a script block. I'm gonna check the nons and says, "Yep, they match. Okay, I can run this one. This is safe to run." If it's missing the nons or the nons doesn't match, it won't actually run it. Okay. Um and you'll get that type of error that we saw earlier. And then we have um hashes are very similar uh only you don't have to define those in the script, right? So what you would do is maybe at at let's say build time or deploy time, you would take the script blocks that you've already vetted and trust and those you would you would

basically bundle those up and create a a hash and then that would be pushed in as your header there, right? Um and because like this isn't a full hash on here. I obviously shortened it for the slide, but the the SHA 256 hash you see on the top highlighted part, that's the hash of whatever's between those script tags there. Um okay and then you have strict dynamic. So strict dynamic is kind of an interesting one because it actually improves some aspects of security and it also loosens up another aspect of security. But together it's necessary for modern applications because what happens with a lot of modern applications is they do a lot of this sort of bundling where um well it's

bundling and then it's also dynamically pulling in more libraries. Um, and so it might initially load some JavaScript and then that JavaScript has to load additional JavaScript files and then that they might load more as well. And so how do you get all that to work without having to go through a a really crazy exercise of trying to find out the hashes for all those things or try to figure out some way of getting nonses on. And so um, strict dynamic allows you to still use a knots on like think of that like the outer script tag, but then everything inside of that will safely load. Now the kicker is if you're using strict dynamic you have to universally

use um basically nonsis throughout everything like you can't have unsafe in um unsafe inline won't even work if it's there it will stop functioning um so you you have everything has to be in in a knots at that point I think uh I think actually you can still put hashes in there too so if you do have anything in there it' have to be in a hash or nons um but this is how how it allows that to So, um, so it does lock things down more while at the same time it it allows you to bring in other libraries, right? So, now there's there's a couple of different options for how to implement this. And this is kind of the

instructions you can go back to your um to your dev teams on. One is if it's if it's more of a modern thing where they're doing a lot of like CI/CD and it's maybe in a react based application then you'll want to use a tool like helmet um which that's just a it's a plugin but allows you to actually write the security headers that come back in the response. So it can do some of that calculation of hashes for you for example. It can also insert the knots um into the page for you. And so there's there's a basically was a library set up to be able to do this for them. So that's possible. Um, but the other thing

that we have to consider uh as well is what about legacy applications? What if they're running something like a JavaScript app or some or or sorry not Java like a like a Java application um where it doesn't necessarily have um that level of access um or it's a legacy application that you really don't want to mess with the application itself. Like you don't want to mess with the code. Um, if you're running it through a reverse proxy, this should be uh familiar for for a lot of you who if you do that um you know more of that system um deployment stuff with legacy apps uh engine X or or um or Apache or something

like that um you can actually do string replacement in your request response traffic through that reverse proxy which is kind of convenient right so what we can do is we can set up knots placeholders inside the application. Um, and then like for all of the script tags that are there and then have the reverse proxy actually um, swap those out. I would use something other than the word nons though because you don't want something that the attacker can guess what the uh, the replacement word is. So maybe something you generate with each time you do a new build and have it more of a um, a randomly generated hash or something. But um I can show a little bit about

what that looks like too. Okay. So to kind of demonstrate this, I I had AI, see I leverage AI a lot these days. I had AI help me build an app. Um and this is this application is just for showing some demonstrations of content security policies. So, in this one here, we have no content security policy at all. So, everything is going to work. Um, and it does a few different things. I should probably see if I can zoom in a little bit. Hang.

Okay. Um, so it it does there's a bunch of different things on here. All right. The timer, by the way, that's that's just to to demonstrate to myself that JavaScript's actually still running on the page because as I was troubleshooting this, I want to make sure that I wasn't breaking all the JavaScript on the page at the same time. But if if I were to put um uh like there's this little comment form in here, and I can put a a cross-ite scripting payload. This one's a an image source. So, I'm giving it um an invalid source and then saying on error on error alert, right? So, because it's invalid, it'll error out. Um, and then if I post

that, it's going to, you know, I get the the cross-ite scripting pop-up box, right? So, we know the alert worked. So, we're able to actually inject something on the page. Um, and then similar to that, I have um this one's for for um cross origin form submission. Remember, I was talking about the form actions, that sort of thing. Um or um or the uh the connect source type. I can't remember which one this actually is, but let's say we just have some uh let's change it to some sensitive data that's getting submitted somewhere. And let's say an attackers has managed to put a a key logger in here or something like that. Um, so I have this this other

domain set up. And it's probably hard to see on here. Let me zoom in again. Um, but we can see where where it actually captured some sensitive data on here. And you may not be able to see it from where you're you're standing, but these are actually two different origins. So, this was vulnerable. By the way, example.com is only running on my laptop. You can't go out to that domain. Um, however, this entire demo is um it's on GitHub, so you can pull it down later if you're interested. Um and uh and so it's this actually just demonstrates basically like a key logger or form capture type of of malware that might have been in um installed onto the page

through through uh scripting. So um so that's one. Um and like I said, this is with no CSP at at all. So let's look at something that has a basic content security policy on here. Um and I'm going to do exactly the same thing as before. Hang on. Let's see. So, still my name and then the same crossite scripting uh vector there. And then I'm going to post that and we'll see that we didn't get a popup. But what we did get was the error in here. And this is one of the first slides I showed. And you remember when I said, "Hey, there's a an error message on there saying, hey, um uh this uh inline

event handler violates the following content security directive, policy directive, and then it it talks about how to fix it, right? So that's what that message is up there. So that's the type of behavior you're going to get. Now, I didn't install any plugins or anything like this. This is the way all browsers behave. So this is this is built in. All I had to do was is I I had this um at the very top. this content security policy came back in the response. Okay. And then the browser obeyed it. It's like, okay, I understand my instructions. This is what I'm going to do. Okay. Um, and so it did that. And uh because this is this one's actually it's

a fairly basic one, but it's very strict as well because it this is saying default source self, script source self, style source self, form action self, so it won't submit forms to other things. Um, image source, it'll be any image source is okay. And object source, none, which is good because if we don't have any objects on the page, this is the whole turn the feature off type of thing, right? Um, which is what we're doing there. And then if I have my sensitive data again, this time it should just fail. See, it tried to go to that page, but it just the browser just wouldn't let it. It opened a tab, but it was empty. Um, and then if I go back

here, it will actually say sending form data to malicious.ample.com violates the following content security policy directive. So, it actually prevented that form from being submitted. Right? That's the one that nobody does this. Nobody actually sets up this directive that's right there and so easy to use. Um, [clears throat] so, so that's another example I had on there. Um, and then I have a couple uh like a here's a hashbased one. So this one I took all of the scripts on the page and I I put them into um into uh basically hash them up. And so I have this uh shaw 256 and then the hash of of all my inline scripts on the page are there. So anything that's

running outside is going to fail, right? So, this first button here says test inline test inline script. Um, okay. So, that that one should fail because that one's actually outside of the um the hashed block on there. I I you kind of have to look at the details on here. Hang on. Um, this is getting too much in the weeds. I'm just gonna I'm just going to pass that for now. Um, but if you're interested in kind of digging into the the details on this more later than you can, like I said, all of this is available. Um, and then the I have the hash script was in its own block. And so that one will actually

run. Okay, so we see we got a popup on that one. And it didn't put an error in the in logs. And then an any external script, of course, because we don't have any nonses set up or anything like that. That one's also going to have a violation. You can see the new one just popped up here. Okay. Um, and then I I do have, you know, a bit of an example of what I did with Engine X. So, I have the um a knots uh filter on here that does a replacement for um and it's basically generating it off of the um um I think it's the request ID or something like that. So there's a

there's a a pseudo random number that's inside of engine X on every request that's available for things like this. And so you could just use that to generate the knots. So so every page refresh I'm going to get a different knots. Um and then we have like any inline script is not going to be part of that knots. Remember the knots is mostly for external scripts. So the inline script of course it's going to fail because it's not in there. um the uh not space script should work which it did. Yeah. And so it's basically that same sort of pattern. Thanks. Um and then helmet will be will be similar to that as well. So I'm going to at this point I'm going

to start wrapping up and oops I did that wrong hand.

Okay, I'm going to start wrapping up because I want to leave it open for questions for you guys and I know that um that lunch is coming up too. So, some of you are probably hungry. So, [laughter] the key takeaways here, first of all, this is a feature that's in your browsers already, right? Um, and there's there's a lot of capability built into the browser that is just turned on by default, right? But we don't need it all. So, we can turn parts of it off or we can limit its use through the content security policy. Like, this is the the agreed upon way to do this. So, we should be using it effectively to turn off features that we

aren't using in applications. It helps reduce your attack surface on an application. And like I said before, sometimes you don't care. If it's a brochure website, maybe you don't really care. But if you're dealing with sensitive information at all on your application, you should definitely be having a content security policy on there and be making use of the features of that policy or the directives in that policy to turn stuff off in your browser um that you don't need. Um also based on the data, which I ran that that was just earlier this year, so this is pretty recent. Most sites still don't even have a CSP and many of the sites that do have

one aren't it's not it's not very effective. It's like it's barely barely actually being used properly. Um and lastly, even if your developers are saying, hey, you know, if I put a CSP on here, it's going to break everything. Um there are ways around that or at least compromises you can make. That nons replacement tactic in EngineX, that's not perfect. You're not going to have a perfect content security policy off that, but it's way better than just having a checkbox one. Like it's it's going to prevent a lot of possible things from happening. Um that and you if you do that and then also do I didn't put it on here, but going back to that

essential directives page of okay well putting scripting aside, what about all these other things that we can do? Um if you do those two things then then you can do you can put a lot of production even into a legacy application without impacting the application. Right? So that's pretty much it. Um so appreciate you guys coming out here um and listening to my talk. Hopefully this made an impact on some of you who are working with applications. Thank you. [applause]

Anybody have questions? What are some of the considerations in the construction that you have to differentiate between a static and dynamic application? >> Some of the differences in the implementation processes in the CSP >> um between a static and dynamic application >> like you had said that the uh the hashes were used for uh for like local localiz

and if you have a static page that >> that kind of hot reloads like in a react framework how would you like implement a system in such a way that like it would actually load more than just the first nons on page load. >> So you could have you could have a single knots for the whole page. Yeah. >> Um and uh my guess is for for that situation your your best bet is to basically have a nons generated on the initial page load and you would use that same not nons for the entire session. So you would just propagate that through any of your trusted sources. Uh you can do which is something you could do dynamically at

that point. um because you're going to know your application should know should quote unquote know I mean they don't think for themselves right but so it has to be programmed in there but it but it should know which u which libraries are expected to be loaded at least the top level ones and that but that's where that strict dynamic comes in right so and when you're using strict dynamic uh you you're you do run the risk of supply chain it does not prevent some like if you're using a trusted library that's using something else that you haven't vetted, it's not going to prevent that from working like from uh from causing a problem. Um but that's not the type of

problem that it's meant to solve. So um then from a so that's I don't know did that fully answer your question? >> Uh not fully but you gave me a good jump. >> Okay, >> cool. You got a question? >> Yeah. policy across >> across different browsers. >> Um, at this point, no. >> Yeah. Yeah, they're doing pretty well with it. Um, at at least the the uh the version that I have up here, which I think is version three. Um, although I think almost everything I put up here is is uh supported in version two of the CSP. So, it had does go through revisions and sometimes some browsers are a little bit behind on them, but um

like if you're looking at like any Chromium based browser um Safari um I mean that pretty much accounts for for most of what's out there Firefox um like that they all support at least CSP version two and are working on three if they're not already there. So, yeah, it's a good question though. We're working with policies likely break. >> Um, okay. So, yeah. So, the question is, uh, when you're working on a CSP with developers, what are some things that are likely to break and how do you mitigate that? Um, there are actually there's actually another CSP header that's a report only header that I didn't mention before. So that's a a tactic you can use while you're

troubleshooting your way through um building a content security policy or if you're just having a new release and you want to test it. So what the report only does and then there's also I can't remember exactly how it's worded but there's a there's a way to actually define your reporting endpoint as well. So you can have um the report only will still put those errors in the console that we were seeing, but it won't actually actively prevent things from happening on the page. So it won't it won't like so if you're if you're trying to troubleshoot like a live application or something that's like already in production, we're trying to implement a CSP, you can put it out in report only

mode first and then monitor the logs off of that to see did it break anything. Um and then as long as it didn't then you know then you can move it over to the actual policy and so you can actually have you can both run both simultaneously as well um and have a reporting endpoint for like the report only you actually specify a CSP there. So you can have one CSP that's report only and a different one that's in effect. So you have two versions running simultaneously and the report only can you can use that to um like I said to to find the problems. >> So Any other questions? Everybody's ready for lunch. [laughter]

>> All right. Thank you.