Bug Bounty Hunting For Client-Side Injections Part II - Reflected & Stored Cross-Site Scripting XSS

All right, we are finally going to talk about bug bounty hunting for client side injections again. Now, the first video was almost four hours. I think this one's probably going to be even longer, so I'm not going to waste a bunch of time talking in the beginning here, but uh let's go ahead and bring the slides in and we can get started. Now, this is part two of my bug bounty hunting for client side injections video. So, if you haven't seen part one, I I'll put the link in the description. You can go down there and check it out. However, you don't necessarily need to have seen part two and or part one in order to watch part two here. The first one focused on actually getting that client side injection to execute. That's what's typically called popping an alert. And uh you definitely hear me say that a few times in in this video as well. Now, we're going to focus on showing impact. So, this is going to be we're going to be looking at more authenticated routes. Um, once you have the ability to get some type of client side injection, to get JavaScript to execute, how do you escalate that or demonstrate to the company that you're submitting the report to that there is impact here? How can you explain to them, articulate to them how you as the attacker would weaponize this in order to damage their company, to target their users, exfiltrate sensitive data, something like that. So, and that is a huge huge part of client side injections. I find a lot of people that can get that uh client side injection to execute but don't understand how the compensating controls affect your ability to actually weaponize it. How the same origin policy is something we're going to talk about a little bit. There's, you know, getting the the alert to to execute or getting JavaScript to execute is really the the first part of of the fight. And then there's an an entire separate step where you want to go through and say, "Okay, here's how I can weaponize Because a lot of times when you go and actually try to weaponize it, you're going to find that cookie flags or the content security policy or the way that the subdomains are set up. There's all these different layers of security that can affect your ability to actually weaponize that injection. And so that usually leads to things where people will submit uh you know maybe just showing document.domain executing and you might get a return and say oh it's you know there's no impact or it's a self cross-sight scripting selfss is is something that you may have heard before. So, I want to focus this video on helping everybody in the community go from getting that alert to execute to understanding how to demonstrate impact. I'll say, "Okay, this is how I would, you know, target a legitimate user, steal their data, make them do some action that they didn't want to do, you know, etc." So, if you're new to the channel, my name is Harrison Richardson. I also go by Arson. I am the founder and CEO of Arson Security. And I do have a couple email addresses down there at the bottom. So if there's ever anything you can or we can do to help, uh, you can reach out to us there. Both those domains go to arsoncurity.com and that's ars0enssecurity.com. So if there's anything that we can do to help, like I said, please let me know. Uh, moving on a little bit more about me. So I am a product security engineer and that spans across the web application, the cloud infrastructure that's hosting it, and also any AI systems that would be integrated within it. Right? So I take a lot of pride in having a depth of knowledge across all three of those fields and understand how they work together and how vulnerabilities within an application could have downstream consequences on the cloud infrastructure security and and vice versa there. I do have a bachelor's degree and a master's degree in cyber security and I also have you know several certifications. I've got some of my top ones listed there. So for ISC squared I've got CISSP and CSSLP. Uh for offensive security, I've got the offensive security web expert certification and then also recently was able to get the the brand new certified AI security practitioner uh which is from practical devs sec ops and I I recommend that. It was it was a good uh practical, you know, you it's not a multiple choice. You actually go and do those tests there. So that was a fun one. As far as bug bounty hunting, I have been doing bug bounty hunting since 2019. That was when I submitted my first report. I've done it, you know, part-time while I've had a job. I have done it full-time as well. Um, gone kind of back and forth, but quite a bit of experience as a bug bounty researcher. Um, I also led the application security team to build and mo maintain a public bug bounty program on hacker 1 and that was the flowcast program. It's still there now. I'm quite proud of the metrics. I'm no longer at flowcast, but the the team that's accepting the reports is is my team still and and they do a phenomenal job. So, uh, hopefully you'll you'll check that out and and help them secure their application. I also designed and built the arson framework version two. Well, version one as well, but uh it's it's a bug bounty hunting framework if you haven't heard of it and there are videos showing it on my my channel here, but um it's bug bounty hunting framework that is designed to eliminate the friction for getting started with bug bounty hunting. It automates my full recon methodology where you can start from a company name and you can end with a long list of live URLs pointing to web servers that you can go in and test. There's a I mean there's tons of functionality in there so you can go check that out there. And finally, I have educational content on YouTube, right? That's what you're watching right now. So, uh I try to when I can when in my free time, uh put out free educational content for the community. Uh focusing on really deep dives, practical testing, like I said, um you know, manual testing, going through understanding the application, uh understanding the compensating controls, and being able to find things like complex logic vulnerabilities or or really the access controls, idors, things like that is typically how I hunt. So, yeah. Um, again, once you're done watching this, hopefully uh if if you like it, you can check out some of the other ones on the channel. Okay, let's talk about what we're here to talk about today. We are going to do a deep deep dive into bug bounty hunting for client side injection. So, what is a client side injection? I when I look at a specific vulnerability or class of vulnerability, I always like to try to boil it down into one sentence. and and a clientside injection in one sentence is an attacker forces their victim to execute JavaScript that the developers did not intend to execute. Right? And this is only going to happen through a payload that manipulates the DOM in the way so that there is there's JavaScript executing or that the you know some payload is going to need to come in through an HTTP request. Now and we'll see these different ways. It may be directly reflected in the response. It may go stored in a database and then come back. It may never leave the browser at all. It may just stay within the browser and be executed within the DOM as the client side JavaScript processes it. There's a lot of different ways that we can do this. But ultimately, your attack vector that you're looking for is going to initiate where you're going to send that payload will be in an HTTP request. Somewhere within that HTTP request, there's a value being taken that. That's the user controlled input that is later being processed by the application and manipulating the DOM. The way the DOM is manipulated results in JavaScript executing and then the idea from the attacker perspective is to have that JavaScript be malicious and target the attacker or the uh the victim in some way. Um so with that in mind, you have to be able to deliver your payload to a victim. You've probably heard the term selfcrossite scripting, self XSS. That means there's no way to deliver it to anyone. Now, with a stored cross- sight scripting, if you're putting it in the database, it's coming back out, right? Then you just have to get them to navigate to where the page loads that payload from the database. However, if you're doing it for a reflected cross-sight scripting, then it's got to be somewhere where they're going to typically click a link, a fishing email. We're going to go into a much deeper dive with all of this, right? You have to be able when you're submitting your report, you have to be able to articulate to the company how you are going to deliver this payload to the victim, get the JavaScript to execute, and then you also have to articulate how that JavaScript is actually going to have a negative impact on uh on your target on your victim. Right? So again, that's typically called popping an alert when you just see that. Um, I see a lot of people that just get that to work as I mentioned before and then they'll submit the the report and they don't understand why they're it's being declined or or for whatever reason. You got to go there's three different steps, right? Get the alert to pop. Figure out how you're going to to deliver it to your victim and then figure out how you're going to weaponize it as well. What is going to be the impact? What are you going to do to that victim? Those are all the things that we're going to talk about today. And we're going to focus in on four different types of client side injections. Right? We're going to look at reflected, stored, and DOM based cross-ite scripting. And then we're going to look at client side prototype pollution. But I want to be clear about this. With client side prototype pollution, there's two different ways to weaponize that. It's a little bit different than the others. You can weaponize it by escalating the prototype pollution to a cross-ite scripting type thing where you get the the JavaScript to execute. That's what we're going to focus on today. However, and this is probably a whole different video, you can also use client side prototype pollution yourself to potentially bypass security controls. You know, you can if you can find a way to manipulate um all the different objects and running memory. Again, we we'll dig into this more in just a second, but um to to change is admin to true, then potentially you yourself can leverage that uh uh polluted prototype to be able to get access to parts of the application that you wouldn't normally be able to access. It's very different from what we're looking at today. So I really want you to kind of dial in because this is you know in my opinion about 75 80% of of the attacks when people talk about client side injections is you are getting JavaScript to execute in a victim's browser. You have to deliver it to them and then in some way you have to be able to weaponize that JavaScript once it executes. So again we want to kind of dial in to that specific use case. Starting with reflected cross-ite scripting. This is the one that people probably are most familiar with. So, if you look on the left hand side there, you've got an uh HTTP request and response that on the top the request, we have our what's called a canary. And you're going to use canaries a lot with with cross-ite scripting. So, that's I use my, you know, little fancy uh uh handle arson rs0. You you want it to be a string that you're almost certain is not going to be within the application at all. Right? So, a lot of times people will use their their hacker handle because it's much less likely to actually be built into the DOM depending on how complex it is or or what the name is. But yeah, ultimately you need to have a Canary that will you you can easily search the response to see whether or not your user controlled input is actually being reflected in the DOM there. Uh because that's how you're actually going to get it to execute. So, but ultimately again reflected cross-ite scripting. So the HTTP request goes in and the direct server response includes that payload and that's what's going to be loaded in the DOM. So in that case your goal you can see there on the picture is to get say you know a script tag injected in there so that when that response comes back it will load up that script tag and it will execute the JavaScript that that you want to to execute and then you've got to figure out how to deliver it to uh to the target. Right? So, a lot of times that means that your payload, your attack vector needs to come from the URL in some way, whether it's a a path, whether it is uh a get parameter, um you know, whatever it is, you're going to need to get a victim to load the page with that payload built into it. So, it's almost definitely going to have to be in the URL if you're looking for reflected cross-ite scripting. And again, the four steps down there bottom. So, the payload is sent in an HTTP request. that payload is reflected in the HTTP response directly and the payload has not been modified in a way that would prevent it from executing. So, it's actually going to have to be loaded up into the DOM and and you know, we'll talk about output encoding and things, you know, other compensating controls in a while, but it's a lot of things going to happen to that payload in between when that HTTP request comes in and the server's response comes back. So, it's very important to understand the different ways that it's been modified so you can actually get it to execute. And then again, like I said, finally, you've got to actually deliver that directly to the the victim. Now, with stored cross- sight scripting here, you're getting your payload to be stored in the database and then it's going to be loaded up in multiple different places. The the most common way or I guess like the the default like you know, easiest way to describe this is you have a a you know, public profile page for your user. Let's say you're on a forum. And so, you're it has your first name and your last name and all these different things. And you can go in and change your first name and your last name. This is like the the most basic stored cross-like scripting that people will do. They'll go into that profile page and well, my name instead of being Harrison Richardson is now script alert one and script tag. And the goal is that gets stored in the database and everywhere that my first name or last name or whichever attack vector it is gets loaded up into the DOM. Hopefully, they're not going to sanitize it. The DOM's not going to consider it. Again, there's going to be tons of compensating controls that affect this. But if everything goes right for the attacker and wrong for the developers, wrong for the victim, then as that's loaded up, it's going to automatically execute. That is much much easier to deliver to a victim or have a a much larger impact because if you could get it on a public page that people navigate to, you know, anyway, uh is something they do naturally through their browsing, then it's going to be very very easy to get those victims to uh to to go to that and and have that execute there. Now we also have DOMOBM based cross-sight scripting. Now DOMbased cross-ite scripting no HTTP request is ever going to be sent. Everything happens within the browser. That's why it's DOMbased cross-ite scripting. So and the the most common version of this is going to be a typically a hash fragment. Uh if you're not familiar, it's the the pound sign or the number sign or the hashtag sign. I guess you yall are all probably younger than me. You probably don't know what a pound is on a phone anymore. um a a hash fragment, it is loaded up in the JavaScript, but if you if you were to capture that request in Burp, you're going to see that that value in the hash fragment is never going to be sent in the HTTP request. It is only processed within the browser. So, but if the developers are taking that hash fragment and whatever the value is, they're passing it to a method like um you know, write in our HTML or something that allows you to write to the DOM. Then you can potentially add the payload as a hash fragment. You deliver that to the victim again as a link or get them to automatically navigate to that from another malicious website. And then it's going to execute. And this is, you know, even a little bit better from the attacker perspective because the uh maintainers of the application, the developers, they never have any idea that anything happened because it only stays within the victim's browser. And and that goes, you're going to have a source and a sync. So that source, you know, again, a hash fragment is a great example, but it can be any value that can be accessed by JavaScript. So, and I always look for custom JavaScript when I'm looking for DOMbased cross-ite scripting. And we'll once we get into the hunting phase of this presentation, we'll talk about that a lot. You'll get to see that in action. But um yeah, you you want to find something where the the JavaScript is accessing one of these values that you have the ability to deliver to them or force the the victim to set that value. And then that's what's called a source. And then it's going to be passed later to a sync. And a sync is some type of a JavaScript method that allows you to either execute JavaScript. So maybe it's an eval allows you to write to the DOM, something that's going to allow you to to craft a payload that will cause it to instead of doing what it was meant to do, it's going to execute that JavaScript that that you want to happen that the victim doesn't want to happen. Right? So again, just DOMBM based cross-ite scripting. Remember, it all stays within the victim's browser. there is no HTTP request that's being sent out there. And then finally, client side prototype pollution. Now I there's a lot of things I could talk about this probably a whole video that I could dig into it here. Again, we are looking at sources and syncs. So we are going to have some type of a JavaScript is going to access this within the DOM. Um a lot of times this there's no HTTP request involved with it. A lot of times this is just going to be uh happening within the DOM on the client side as well. However, the methodology is very different. Um, what we're trying to do with client side prototype pollution and I actually do have a whole video on this that you can go watch. Um, uh, let's start with object-oriented programming. Object-oriented programming. So, if you're not familiar with this in and object, essentially the goal is to write your code in a way so that you're building these classes, you're building these objects that represent realworld uh, things, you know, whatever it may be. So you're going to have and and web applications have tons of different objects within them. So you're going to have like a user object, you're going to have, you know, if if it's a forum, right? Document objects, everything within the application is most likely going to be represented with some type of an object. And in JavaScript, which by the way, prototype pollution can only happen within JavaScript. It's very important to understand. Um, everything in JavaScript is an object. That's just the nature of JavaScript. Within object-oriented programming, there is a uh there's a concept called inheritance. So if you let's say you have an object that's a car and and that object has the characteristics of you know four wheels and uh you know steering wheel that lets you control it and you know has an accelerate method and has a decelerate method and right like it's you have the basic formation of a car but then you also have this new class that's a Jeep and and the Jeep class it inherits all of these characteristics of the car class but then It's got additional characteristics laid on top of it. And so that would be, you know, it it has four-wheel drive and it, you know, it has all this, right? You can take the the the roof off and the doors off, like all these things that are specific to a Jeep, but it still has all the characteristics of a car. So that inheritance, what it's actually inheriting or what's happening behind the scenes, it's pulling in uh what's called a prototype object. And especially within JavaScript, every object that is instantiated automatically pulls in this object.prototype uh characteristics that are that are have all the things that make a JavaScript object an object. Now this can be identified with just the word prototype object.prototype. You can see there in slide deck um underscore protocore is very very common. It can be constructor.prototype constructor.c_proto. There's a lot of different combinations of way that these can be set, but your goal with client side prototype pollution is to essentially insert a key value pair into that object prototype so that every new object that is instantiated automatically inherits this new prototype. And there's some scoping within running memory and everything else. this gets very very uh it gets pretty complicated when you start looking to the individual use cases and stuff like that. But um but yeah, ultimately you want to and and by the way, this only happens if there's what's called a deep merge or recursive merge. And what that means is you've got two separate objects. And one of those objects, the key in the key value pairs of those objects, the the attacker is able to control a key. Not the value, the key. That's very important because the attacker is going to change the key of one of those objects or control it to be underscore proto or they'll do constructor and it'll come out to a new object and that'll be prototype proto whatever it is that when when these two objects are merged when they're combined together using a deep merge or a recursive merge which means the nested objects within that initial object are also included within the merge. Then it's going to go through and and what can happen is it will assume this is just the way JavaScript works that the underscore protocore key and then whatever key value pair is nested under that needs to be added to the prototype of the object and that is how you can poison that prototype. So we still have a source and a sync but instead of writing to the DOM or anything you have something you have a user controlled input from a source that gets passed to a deep merge a recursive merge. Um there's a lot of famous ones that come from client side on mpm packages like low dash and things like that. But it will insert that so that every new object that's instantiated gets that new key value pair. That's where you can see if you have the is admin equals true. If you're doing it for yourself, again, we're not focusing on that for this uh this use case, but it it does do a good job of highlighting it. If I can have every object that's instantiated has is admin equals true, then when my user object is instantiated, even if it already has is admin equals false, the prototype will overwrite that. And so when it's instantiated, I will now have my user object will now have a key value pair that's inherited from the prototype that says is admin equals true. And so that may affect the way that the application works when different things are sent and and you know what I have access to especially if there's client side routing like a react route or anything like that can have a very big very big impact there. So, so and again for this video what we are focusing on is we need to first of all poison that prototype and then we are going to escalate that to actually get that JavaScript to execute and and that's a whole other step but a lot of times what you need to do to do that is whatever key value pair you can add into the the uh objects now you need to find some key value pair that is being used to write to the DOM and then you're going to poison that value. And again, the value of the prototype will overwrite what it should be and then potentially you can get it to execute. So, I I could do a whole other video on this. Um, it is one of my favorite vulnerabilities to test for. It's we're going to go into exactly how to test for it and the types of things that I look for. It's a lot of fun, but it can be quite complex and you do have to have a good amount of JavaScript knowledge in order to do that. So, okay. So, we've talked about uh, you know, the four that we're going to focus on. Again, like I said, part one of this video or of this uh series focused on getting the alert to execute. What we're going to focus on now is weaponizing those. Um, so when the the payload executes, you can see there in the picture behind a lot of times people would just say XSS or document.domain or anything. So you have the ability to get that uh JavaScript to write to the DOM and execute. But when you're weaponizing it, you are taking that proof of concept and you are turning it into a real world attack. And again, that's a two two-step process. How am I going to deliver it to the victim? What am I going to do to actually weaponize it? So, it's really really important to understand this. If you if you look at this in the picture here, the first one just comes and does XSS, but on this one here, we can actually access and if you look at DVWA, we can access the session token and we can also potentially control the security of the website there. So showing that we can access that the next step that I would do is you know uh you know potentially try to steal that session token or can we leverage it if there's a is there a lack of uh cross-sight request forgery protection so that we can force the victim to make to perform an action that that they didn't want to do like transfer money from their account to my account if it's a banking app or change their password so now we can do it disable multiffactor authentication or two-factor authentication. Any one of these are ways that you can show impact. Um, and again, I've said this a lot, but we're we're going to dig much much deeper into all this. So, um, but really important to understand if all you're doing when you're submitting a client side injection bounty is just showing that you can get an alert to pop, you're probably going to have a lot of frustrating interactions with the uh with the companies, right? Because it's a lot of times it may be a selfcrossite scripting or there may be other compensating controls that would prevent you from weaponizing it. So, yeah, I'm just going to keep saying this over and over again. Get the alert to pop. Get the JavaScript to execute. Step two, figure out how you're going to deliver to a victim. Step three, figure out what it's going to do to the victim. Very, very, very important to understand the difference between executing and weaponizing and understanding how to articulate the weaponization that you're going to be using. Uh, okay. So, compensating controls. We talked about a lot of the compensating controls, uh, that we're going to talk about now in part one. I wanted to just kind of go through them again. um maybe provide a little bit more color and how they're going to affect weaponizing as opposed to just getting them to execute. But it's so important to understand compensating controls and how they affect. I mean this is this is really I see so many people that get frustrated because they don't take the time to understand the compensate control. it they have such a huge huge impact and every web application now is just layers and layers and layers of these compensating controls and it it's so easy to think that you can do something because you're so cool and usually there's just one little control that stops you for oh it's you know this just does this one thing and oh if we can get around it but a lot of times you can't get around it and so again that's where you see a lot of things where people submit where they say it'sformational or or not applicable there's no impact everything is you've really got to go through and make sure you got to understand how these compensating controls are implemented, how they're affecting you getting the payload to to execute, how they're affecting you delivering the payload to a victim, how they're affecting you actually weaponizing it once it's delivered to a victim. These compensating controls can have a huge impact at all three stages of that process. So if you want to elevate your your bug bounty game, study compensating controls, understand them, study how they're implemented correctly, not correctly. And then what that also allows you to do is once you start to test, you start to see say, "Oh, this is not implemented quite right." You know, this is a little different. This, you know, and once you find those, those are what I call pointers. That's where you can start to dig in. Oh, this CS surf looks like it's implemented, but actually it's as long as the header and the cookie value are the same value, it doesn't matter. And I can control both the header and the cookie value with JavaScript. So now all of a sudden that CSURF doesn't have any impact anymore. So now you know what to test for. Now you can test for session writing attacks, which is yeah later. Um, now you can try to get them. Yeah. So it's the the uh compensating controls affect what you can do affect how you can they affect all three stages of it. So it's so so important to have a deep understanding for these. So first off client side validation it has no impact whatsoever but it's still good to talk about. It's still good to understand. client side validation. You know, you go into the form, you go to type login for your username and you type script alert equals 1/cript and it, you know, there's a little red thing that pops up through JavaScript said, "Oh, you can't do that." But if you just send with a regular username, capture it with with burp proxy, you you want to just send it directly with curl or postman or anything, and then you change it to script alert one equals, you know, whatever. And it and it allows it to go through like you've bypassed that client side validation. the client side validation it is entirely there just for a user experience that's that's the only value user experience um you know yeah it it's it's for UX UI benefits if you see any application relying entirely on client side validation um that's great right because you can just bypass it from the attacker perspective not from their perspective but you can help them understand you can help them uh fix it make it more secure um and client side validations can also give you an idea potentially of some things that the developers don't want you to try, right? You could start to get some some uh potentially get some knowledge about maybe the technology on the back end. Um, and to give you an example, right, if it's a login form and if you put uh, you know, a a single quote or a double quote or a backslash or a you know, dash and any of those, it kicks it back and says you can't use those characters, but you can use a dollar sign. then you probably know that they have a typical relational database like a SQL database, right? It probably doesn't have a MongoDB database because a MongoDB database um now granted it needs to be in the key. So that's another conversation. But um but a NoSQL injection, a lot of those characters, a single quote, double quote and everything don't have a huge impact. Um typically you want to get a money sign in the key somewhere. Uh so yeah, I mean you can kind of get some information potentially, but it's it's just important to know client side validation is there. I always want to take note of it and understand what they're trying to do, but uh it's not going to have any impact on the security of the application at all or your ability to actually get the payload to execute. Really doesn't have any impact on anything. It's just good to know. Web application firewall on the other hand is going to have a big big impact on your ability to execute your payload. So web application firewall it is an appliance that sits in front of the application that again like I said every client side injection is going to originate from a user payload in a user controlled input in an HTTP request. So what a WTF is going to do a web application firewall is it is going to parse it's going to read through every single HTTP request that's coming into the application and if it sees a string that it is listed as potentially malicious then it will just block that outright before it even hits the the load balancer the application anything like that. So you can imagine and and this is typically with client side injections this is a big thing just to get it to execute. I talk about this a lot in part one uh of the videos there. But um yeah, if it sees things like a script tag, it might, you know, kick it back or on error on clear, you know, all types of different things that it can find. And it's a binary. It's yes or no. So, um a lot of times just to get the payload to execute if they have a web application firewall, you've got to do some uh you know, figuring out what types of patterns it's looking for and try to find ways to circumvent it. Um, however, it's also good to know that, and this is kind of an older saying, uh, best way to make a web application insecure is to put a W in front of it. And the reason for that is it can give you a false sense of security because it is binary. And a lot of times, uh, researchers and and, you know, malicious attackers, real malicious attackers, they will find ways to circumvent the common web application firewalls and they will hold on to that as like a trick. And then because what that basically means is they now have a way to test payloads on an application that nobody else can test on or if they're an attacker, right? They can actually use it and it's probably it's the equivalent of a zero day. Um although not that much typically it's more of just like a bypass you can do there. So um yeah, web application firewall it it will sometimes deter me from testing on an application. It depends on what it is. It depends on it depends on a lot of things. Um but it's important to know, right? This is once you get past it, once you find payloads that get past it, like it's more annoying than anything else. Once you find payloads to get past it, um then it's not going to affect your weaponization at all unless it's blocking some of the specific strings that are included within your weaponization. So, but yeah, very good. Got to understand web application firewalls, how they work, because they're going to have a big impact on your client side injection testing serverside validation. So, the HTTP request comes in, it hits the WFT, the WFT parses it, says I everything's good. I'm not too worried about that. So it sends it on to the server. The server is now the serverside code is now processing the parts of that HTTP request that user controlled input. This is where server side validation comes in. Serverside validation is incredibly important when it comes to protecting against client side injections. So what are they doing? Are they checking programmatically to see if there's a script tag? Are they looking for or stripping out uh you know open greater than less than symbols? Right? So, you can't go and and make an HTML tag. Um, there's all these different things, right? And there's there's a lot of standardized libraries that do it. Some people implement their own, which can kind of become a bit of a cat-and- mouse game. But then if you have a standardized version and there's a known vulnerability or a bypass in that standardized version, then they're automatically going to be able to do it, right? So, there's an argument for either side. But ultimately they are programmatically they know that they are processing uh user controlled input that is untrusted input and so they are running it through a function or a middleware that will validate the user controlled input typically to make sure it doesn't have any malicious characters and it's the size and type that they're expecting before they're allowing the server to process it and send it back to the user. server side validation huge huge huge impact on your ability to both execute and weaponize a client side injection. Um and you don't have insight into it. So you have to kind of you know test and probe and and try to to figure out what exactly they're trying to do or what exactly they are doing to sanitize it. Um Joy is a very common mpm package back in npm packages for um you know for JavaScript based nodebased applications too that you can look up. If you want to see an example of that uh content security policy again huge huge impact definitely has an impact on exploiting or uh uh executing but has a much bigger impact on weaponization. Content security policy policy is huge huge huge for weaponization. So a CSP a content security policy there are directives that are set and it content security policy can be established two different ways. It can either be in a header that's returned in a server response. That's the most common. And that's what I typically recommend to my clients. It can also be added as a meta tag to the HTML itself. And uh again, that's not as common today, but it's good to understand that it can be there either way because you've got to go check both. And from there, you can determine what the the directives are. But within the content security policy, it's going to there are several different directives that can be established. So, some content security policies are one line, some are, you know, makes the server response, you know, 10 times as long. You know, I've seen ones that are just absolutely crazy. It just depends on how granular they get with each of these directives and how many different uh, you know, pages they need to allow. But ultimately, the content security policy tells the the browser, so in this case, it's really the victim's browser, you know, but it tells the browser what it can do and what it can't do, right? So what you know where can JavaScript be loaded from? Can JavaScript even execute you know once uh once everything is is loaded. Um where can CSS be loaded from? You know stylesheets things like that. What where can uh JavaScript HTTP requests be sent to? All of these different things. And I put several examples in the the slide here. I you know you can read through those. I don't need to talk through each of them. There's and this is just some examples. There's a bunch of them. Um, these directives are going to have, like I said, a huge impact on your ability to actually weaponize it. You know, you may have a a cross-ite scripting that works and then when you try and grab the uh the the session token and send it off to your server so that you can steal it and steal their session, well, the content security policy may prevent you from even sending a JavaScript request outside of a few different places. Um, if you want to like the more complicated uh client side injections that that have like a really extensive weaponization, a lot of times those need to be loaded in from a separate source because you can't if it's, you know, entire page, if it's like 30 lines of of JavaScript to go and do all this complex stuff and enumerate, steal data and this and that. You're not going to be able to put that in a URL and deliver it to a victim. I mean, you could do a URL shortener or shortener, but that's a huge red flag to to anybody. And typically that's you you may get some push back on that. So ideally what you can do is have a an external script that you are hosting maliciously be pulled in and then all those are going to load and execute. Now in order for that to do or in order for that to work the script source has to be directive has to be configured in a certain way to allow that to happen. A lot of times what happens is a script source is set up so that uh you can only load from certain p places that that they know it needs to load uh from. So that may you know maybe some Google things and you know whatever it may be. So then what you want to do in that case if you do want to load an external script which by the way is always a way to show more impact if you can load an external script as opposed to just having something execute inline because again you can do so many more things. Um, what you may have to do is maybe you can go register, you know, a a domain, a subdomain, something on there if it allows it or maybe you can host something on that domain that that allows it to be brought in, right? So, um, yeah, there a lot I I could sit here and talk about content security policies forever, but it's really important, especially the ones that I have listed up here. definitely go take a look. Doing research into a content security policy and really understanding how all of these directives work and impact your ability to weaponize the the uh attack that you're doing um is so important. It's this is where you know again it's like if you don't understand that then you may be 100% certain that your attack should be working and you can't figure out why it's not and then you go into the console and see all the content security policies blocking it something. So uh cookie flags are very similar. Cookie flag is going to have a big big big big impact on your ability to weaponize your attack. Um, and the number one in my opinion cookie flag that has the biggest impact is the one on the top, the HTTP only flag. HTTP only flag if it is set and typically it's going to be set on a session token that means that JavaScript does not have the ability to access that session token. You can't if you do document.cookies cookies and and run that. And you can test this within the the console. I'll show that later in the actual hunting phase. But if you run document.cookies within the console, you're going to see that even there any any uh cookies with an HTTP only flag are not going to load up because that JavaScript can't access it through that method. It's being blocked with the HTTPON flag. Now, if you send an Ajax call and you have include credentials true, it will still send that. And so that where that's where okay, we can't grab the session token and just send it using JavaScript to our malicious server, but maybe we can just go ahead and send an HTTP request naturally within the uh application and force the victim to do something they didn't intend. And once again, that uh is impacted by uh cross-ite request forgery, which is going to be another one of these uh slides here in just a second. But um you know, you've got secure, which is another one. uh it it forces the cookie to be sent over HTTPS. Um it's really rare to see uh flag or uh session tokens or anything that doesn't have a secure flag on it. But if it doesn't, then one of the ways that you can uh articulate the impact is well, you know, if I can force the victim to send this over an open network in like a coffee shop or anything to where I'm you I've done art table poisoning and I'm intercepting all of the requests, something like that. It's it's a bit more convoluted, but you can definitely get there and show some good impact if they're missing that. I think that'll be pretty few and far between. There's not a lot of legitimate use cases anymore to not have that because it it means you have to you have to send your session token over plain text and it just doesn't very very rare to see that. Uh same site same site is related to cross- sight request forgery and the same origin policy essentially. Um, are you allowed where are you allowed to uh send that that uh cookie to? You know, where does it actually go to? Um, and you've got strict, you've got lax, and you've got none. This is now a a require a required um cookie flag. But yeah, ultimately it's just related to curve. Um, so if you have something that is same site strict, it's going to be you're not going to be able to send that all over the place. Um, it it just depends, but ultimately the same site is going to uh relate to sea surf. um and where you can actually send that cookie. Uh the domain and path is another one like that. So um the every cookie is going to be scoped to specific domains can be scoped to specific paths and that just tells the browser if you're making a request to this domain to this path whatever it is um then include this cookie. So the more uh widely scoped a cookie is, the more opportunities you're going to have to send it different places. If you've got a session token uh or something that's scoped to all the different subdomains, that is much better than if you've got it that's scoped to one specific fully qualified domain name. Uh because you know there's just more opportunities. You're always looking for more opportunity to send it more places. So um if you find cookies that are very widely scoped that are sent to a bunch of different uh subdomains or anything in there and it's a session token, you can look to leverage that to potentially, you know, maybe it goes to an API and it can uh uh you know, manipulate they they change somebody's password. um things like that. Again, anytime you think cross-ite scripting and uh uh curve, which this kind of falls into the same area, uh you're going to think of that session routing attack, which we will dig into more. And then finally, the max age, whether or not it expires. Um well, I mean, it's it's going to expire, but what is the amount of time it takes to expire? If you steal a session token, that session token, you know, expires in, you know, 30 seconds, it's going to be really really difficult to weaponize it. On the other hand, if you go in and find a session token that doesn't expire for 60 days, that's it's really easy to show impact there because you can explain to the the uh companies say, you know, I steal this. And if you can show them, I can steal this. So, you can it doesn't have the HTTP only flag and it doesn't it has the same site none. So you can, you know, and it's scoped, whatever it is, you can grab that and you can send it off to your server and now you've got that session token. And then later, you know, if you got 60 days, you can just sit, you got all the time in the world to go back and use that. Maybe also there's a session fixation vulnerability where it doesn't actually expire when a new session token comes on and you can use those old tokens until they expire. That's something that I see fairly common and it is uh uh that's again another pointer that tells me, "Oh, this is great. If I can find a way to steal this session token, it's going to be very easy to explain to the company, hey, I've got 60 days to just sit back and relax and and uh use this however I want, it's not going to be invalidated. So, max age very very important. But again, cookie flags for client side injections, most important by far is HTTP only. Um, and then a lot of the other ones impact, you know, much more granular weaponization things. Uh, okay. So, talking about a virtual DOM, and I I dug into this a little bit in part one, but I wanted to this is one of the ones we didn't talk about too much in part one. I wanted to to really dig into it here a little bit because it's very very common nowadays. Most web applications that you are testing are going to use something like react or angular view or next or you know one of these uh client side JavaScript frameworks that leverage a virtual DOM and all of them work differently. I don't want to get too deep into this, but fundamentally what that means in a lot of cases and what that's going to look like to you as the tester is you can have a payload that looks like it wasn't affected by any other compensating controls and it looks like it's loading up in the DOM. So you see script alert one and script. It looks like everything's right. However, it doesn't execute and it's I get this question all the time. It's like I'll get a screenshot. It's like, hey, there's everything's good. I've got the script tag in here, but it's just not executing. And you go and look at it. The reason for that is typically that it's using something like React. React uses JSX under the hood. It builds a virtual DOM. It loads the entire DOM, has everything happen within that, and then it passes this over to your actual DOM without the opportunity for JavaScript to execute. And so the DOM was manipulated within the virtual DOM. That script tag did not execute because it was within the virtual DOM. and then it got sent back over to the the main DOM and that's why it doesn't execute. But it appears that it should be correct. Um so there's a separate methodology for testing uh applications that are built with a virtual DOM. Um there every every individual framework has its own way of doing this. Most of them have uh some way to do this in an insecure way. if you do need the user controlled input to execute JavaScript and in React uh probably most famously there's the dangerously set in HTML method. Um so uh typically you can test for this by you know just kind of scan and test for it. It's good to understand it. I don't want to go too deep into the granular the different pieces there. I would say ideally if you're testing for client side injections your target does not have a framework with a virtual DOM. If it does, you got to identify what it is. You got to figure out how things can go wrong and then see how much of that JavaScript you can get access to. With React, I see this all the time where the Webpack is not properly serialized and obuscated before it's shipped to production. So you can go into the browser tools and or the developer tools in the browser and you can inspect it and instead of seeing a bunch of minified JavaScript and everything that was created that chunk file and the map file and this and that that was created through the virtual DOM and sent back out you can actually see those raw react files and if you've got that you can easily download that um the uh what is it uh JS minor in burpuite has you just right click and you can download all those you can download all the file files. You can go through and parse them, do static code analysis on them. Um, and very quickly see, so if I see that I see React, go into the browser tools, developer tools. If it's not serialized, nonoffuscated, we download that and then we search all that for the dangerously set in HTML. That can be a very easy way to find some great client side injections. Um, but it's just a completely different methodology. So ideally what I do is I try to find targets when I'm doing client side injections that don't have a virtual DOM and then I'll move over to the ones that do and I'll go through and I'll do my specific testing for React. Angular actually has a lot um especially with the content security policy. There's actually some funky things that you can do with Angular and the content security policy to actually uh if you can poison the CSP, you can actually get things to execute and uh that's that's a whole other thing. Anyway, very important to understand this, especially I just want to come back to this before we move on. If you see where your payload looks like it's being loaded into the DOM, you don't understand why it's not executing, it looks like everything should be good, most likely it's using a virtual DOM with one of these frameworks. Uh, now output encoding. Output encoding is very, very important to client side injection. This is probably the most common security control that you're used to seeing. Basically the request comes in with the user controlled input. You can see the pictures of the request on the top has the script alert arson and script. It gets past the web application firewall. It goes through it gets past the server side validation is processed by the the application. and it's about to be sent back and before that is sent back to the user if it's a reflected or before it's loaded from the database if it's a uh stored crossite scripting whatever it is there are operations that are taking to change specific characters into a safe version of that character. So if we look at the pictures here on the top, I've got my script tag alert arson incript. And when it loads up in the DOM, now we've got this amperand number, uh, some type of two-digit number, and then a semicolon that has replaced the majority of these special characters. We can see everything from the HTTP, the image, right? and everything in there, any special character that might have actually been loaded into the DOM and cause that script tag to actually execute, it cannot happen because these are being modified as before they're being sent out. So, the output is being modified or encoded. Um, this probably has the biggest impact on your ability to get a CL client side injection to execute. There are tons of different ways to do this. So when you see this, it's really a matter of figuring out how they're doing it, doing a lot of different probes, a lot of different types of payloads, and then trying to to circumvent it. And something like this where they're actually modifying every individual special character, uh, can be quite challenging to to get around. So ideally, you have something where they're kind of dialed into just a few different characters and maybe you can do, you know, URL encoding, double URL encoding. Like it just all depends on how they do it. The more complex their code is, the more opportunities you have to bypass the output encoding. And that is consistent in all bug bounties you do. You hear me talk about this all the time. Complexity, complexity, complexity. If you see something that is overly complex, it is going to be very difficult for them to secure and that is where you want to focus your time. Uh complexity is uh it breeds vulnerabilities. Uh so yeah, we've talked about cross-ite request forger in a while. it. I wouldn't necessarily consider this a um compensating control for client side injections necessarily, but it is definitely again has a huge impact on your ability to weaponize it specifically with those session writing attacks. So, if you want to force your victim to uh perform an action that they did not intend, then how your ability to do that is going to be entirely determined on their sea surf protection because that's really what it is. Um now obviously if they just have no CSURF protection then you can just do a straight CSER you can just build your own page and it sends the the uh HTTP request in the background and it's you know don't check but a lot of times what you have is you have uh CSURF implementations that are uh have ways to to circumvent them if you have a client side injection on top of it. If you're going to to weaponize it this really affects your ability to weaponize it. So definitely when you're doing client side injections, take some time to understand how they're doing cross- sight request forgery protection. Um, again, I like I said, I see this a lot where there's a there's a cookie that's a value that's pulled in and there's a header value that's pulled in. And as long as those two values match, it will allow it to do. And so you can just change that to your canary. Um, you can control all that uh potentially with JavaScript depending on how everything's set up. Um, and then again, right, if it's a CSURF cookie, does that have the HTTP only flag on it? Because if it does not, then you can control it. If it does, you're going to have a really hard time manipulating that as well. So, you can see how I mean, all these different things. It's it's layers upon layers, and it's it's a web of different opportunities for ways to weaponize it. And just all these little things, it's everything has to go wrong for you as the attacker in order to get it. It's actually very very difficult today for everything to go wrong. But when it does, a client side injection is is like a superpower because then you can you can typically combine that with something else and try to get an account takeover. I always say never just submit a client side injection. It's unless you really can't find anything else to do with it. But ideally when you're submitting it, it is, you know, cross-sight scripting plus uh misconfiguration and cesur protection leads to account takeover through uh uh password change something like that. That's the type of reports that I want to send for client side injections, not uh cross-ite scripting on this endpoint. Who car, you know, like you I want my report I want the title of my report, everything in my report is explaining how I'm going to be able to impact my victim, impact their user and ultimately them because the user is going to be very unhappy that that their application allowed that to happen. Okay, so that is all of the compensating controls that I wanted to talk through. Um, again, I just want to highlight weaponizing is it's it's so important to to be able to articulate how you can weaponize this, right? We've talked through a lot of this here, so I don't know if I need to reiterate too much, but right, um, how are you going to have a negative impact on their users? That you have to be able to understand that. You have to be able to very clearly and simply articulate it. identify who your victim is and then tell them how you're going to weaponize it, how you're going to show impact. So, I want to talk about a few different ways um maybe in a little bit more detail that we can do that. Um I've mentioned each one of these in some capacity throughout uh the presentation so far, but uh we're going to do a deep dive into each one of them. So, session hijacking, right? That is you steal the user session token and you're going to leverage that session token or whatever, right? However they are uh performing authentication authorization, however the application is, you're able to steal that token and impersonate them in order to get access unauthenticated access to their environment um and do something malicious. HTTP only flag, cookie flags, and content security policy are going to have a huge huge huge huge huge impact on your ability to do this. Cross-ite request forgery doesn't really have any impact on this because that's not what you're trying to do. You're not trying to execute an action. You're just trying to get these sensitive values outside of the application somehow so that you can grab it and leverage it. Again, the um you know, how long a cookie lasts also has a huge impact there, too. Um session writing, I've said it over and over again, cross- sight uh request forgery plus cross-sight scripting. So, let's say you can't steal that cookie. Now, I want to try and get the victim to perform an action that they didn't want to perform. And that's ideally I can load in an external script that has multiple different things it's going to do. I'll go change their password and go do this and that, you know, and and at the end of it, ideally, you can leverage that to, you know, either you've stolen from something from them or you can get unauthorized access to their environment. Um, and then if that doesn't work, data exfiltration, if we can't grab the session token and excfiltrate the session token, well, you know, do they have an API key that we could grab or I mean, anything, right? Is it do they have sens sensitive documents that are back there? Do they have a a greater level of privilege than we do? Is it role-based access control with different layers where they're like a super user or even an admin? Can we load in an external script that actually makes a ton of git requests to all these different things and actually enumerates these pages that we don't even know exists? Maybe grabs the DOM and sends it back. And we have our own server over there. And if the content security policy is set up that doesn't prevent this, we can just keep pinging it all back, you know, to our server. And we've got a whole database full of like here's the endpoint, here's the DOM, etc. I mean, we could probably steal a lot of different information from it. Um, so yeah, if if you know that's typically the hierarchy of of uh weaponizing uh attacks that I try, right? Let me get session hijacking first. Can I just steal their session token because that's the easiest way to show impact? If not, can I use session writing to force them to do something that they don't want to do? Or otherwise, can I just steal some data from them? So, we can dig into each one of these a little bit more. I've included a lot of information on the slides here and I'm not going to talk through all of it. This is something you know for all these really you can pause them and kind of go through but you know just some examples right steal the session token through document.cookie cookie. If there's a JSON web token or an API key that's maybe stored in local storage or session storage, something like that, you could grab that and send it out. If they're using OOTH, right, can we get control of a OOTH access token or a refresh token and can we exfiltrate that and send it off? Maybe the the session token, maybe they have some type of an exchange, right? So, they there's a refresh token and an access token, but then there's an exchange on the back end that that sets up the session token and we can steal that access token and do our own exchange and get a valid session token, right? even curve tokens, right? Do they have Curve tokens in there to where we can potentially steal it and then from there we can execute a session writing attack? But we have to get that Curve token first and maybe it's hardcoded or specific to the user. Um something like that. Yeah. Um again there I mean there's tons of different ways that you can do this. You can see in the picture too, right, the different types of you know I mean it depending on what the content security policy is, you could use an Ajax call. could uh you know write to the DOM and and have it create a new image tag and that image tag is going to send there's so many different ways that you could do this but fundamentally you're going to access some type of sensitive data that that is related to their session and then we are going to use an HTTP request send it to something that we control so that we can we can access that and use it again session writing I'll just go through a few more examples here yeah changing their email changing their username changing their password although obviously like the username is not going to have as big of an impact if you don't know their password. But yeah, can you change the way that they log in so that you can successfully log in um without their knowledge? Right? This will just happen when the page loads up. Um is there some type of SSH key, API key that that we can, you know, grab and leverage to give them, you know, if there's again if it's stored in certain places that JavaScript can access if it's stored in the DOM, right? if it's if you've seen API keys that uh when when it loads up, you know, you generate an API key and it loads up and it's not hidden. Ideally, you know, it's all or or even better, it is hidden, but in the DOM, it's actually still written in there. You know, I see that a lot, right? And you've they've got the thing where you can hide and unhide it, right? If JavaScript can control it, like you can unhide it using JavaScript, you can grab it using JavaScript just by, you know, select uh by ID or whatever. And then you can send it in a request and you can control you go in authorization header equals that. So all this might happen on the back end again without the user ever even knowing it uh because that information is available in the DOM or available somewhere uh where it can access it and then just leverage it as part of the uh the existing session. Um I mentioned before can you get them to disable two-factor authentication? That can be a big thing. Not only can that be a big thing to target the users but it can also be a compliance concern. you know, if if uh if everybody, you know, if there's some type of compliance requirement with their application where the two-factor authentication is important for certain users and you can show a way to disable it. Yeah. What if you disabled all those right before an audit? I mean, that's or for the customer, right? If it's an accounting software and the customer, you know, they need to have that as part of their audit. That's an even better way to to show impact there. Um, yeah. or or what if they're an admin and I can they have the ability to send these these uh invites with a higher privilege. So I invite myself without them knowing. I go there and I it it's a post request that does and a post request goes to an endpoint. It sends an invite at the admin level to an email and I send my email and it goes and boom, now I'm in there. I'm not on their session anymore, but I've escalated my privileges and I now have the ability to act as an admin. I can go do a lot of other things. So um yeah, you are leveraging their existing session, making HTTP requests to the application. You're not going outside of it, but to the application. You're leveraging existing functionality, but you're making these calls using their session that uh that they obviously did not intend to do. Uh and then yeah, data excfiltration. I mean, anything that could be sensitive that you can access with JavaScript if the content security policy allows or or not, right? Because there's some other ways to get around that. You can exfiltrate that data. So ideally the content security policy allows you to send HTTP requests outside of the application and that's what you're going to do, right? You'll go and load it up in like a get parameter or something and then you'll send it off and you'll be able to get access to it. Now I mentioned before, right? Could be an image beacon, right? You can get the full HTML. You can grab the keystrokes that they're doing. You can get access to what their keyboard has. That's super interesting because that may go outside of the scope of the individual application. Um, whatever it is, right? But you you exfiltrate it out and if you can't get those calls going out, can you leverage the functionality of the application in order to exfiltrate it? You know, so is there uh somewhere where you can post a comment and uh you know, and that's essentially so you do a session writing attack on top of that. You grab the data and then you go post a comment. this person post a comment with their API key or their password or something like that with it or um yeah, can you either get it out there or leverage some type of existing functionality to write it within the application and then you go in there and get it either manually or that's what you got a whole script to do it, right? And that's that's where you start getting into those OSW type of things where you you get the victim to execute the session writing attack and then they write their API key to a comment and then your script next goes in and grabs it from that automatically and goes and makes the calls and then it deletes it afterwards using the existing session to kind of cover it up, right? Things can get very very convoluted here with these attacks. But yeah, I mean fundamentally if you can't steal the active session, if you can't leverage the active session to do anything that's that's, you know, going to take over their account or anything, try to find some really good sensitive data because fundamentally every report that you do for the most part is going to be tied back into how you're affecting customer data. That's what companies care about more than anything else. If you watch some of my other videos, like especially with Starbucks, I've said Starbucks doesn't care if you can get a free cup of coffee. Starbucks has plenty of money. If you go in there say I can get free one free cup of coffee every day. that has no impact to them at all. They make plenty of money. They got no problem giving away a cup of coffee, that's not going to that's not going to really get them riled up. But if you can show them how you can access their customers, you know, bank account information. I don't know why they have bank account, you know, some type of really sensitive information and how you're going to affect their customers and how that's going to end up on the news and affect their reputation and possibly have legal consequences and do something like that and a ton of overhead. Now, all of a sudden, you've gone from a $5 cup of coffee a day to you're talking millions, tens of millions of dollars in impact. So, always, always, always tie it back to sensitive customer data. All right. So, talked about this a lot. Just want to kind of reiterate again. Once you have found a a client side injection, stop before you do anything else and understand decide exactly how you're going to deliver that to a victim. If your cross-ite scripting, if your client side injection is coming from a post request that you are sending, how are you going to get the victim to execute that? Think about it for a minute. It's a post request. You if you can't if if it's included in a in a header, right, your payload's included in a header uh or something like that, how it's going to be so much more difficult to deliver to your victim if it may be impossible. You know, a lot of times when you get a a client side injection or cross-ite scripting through a post request, that does ultimately become a selfcrossite scripting because you have to force somebody to submit that post request in some way. Now, there's, you know, there's some other cases like that, especially with cookies, like if you can poison their cookies, then then potentially do, but there's usually it usually needs to become a chain and have multiple vulnerabilities before you can you can actually weaponize that. So, um, yeah, we we'll do a ton of different demonstrations when I'm actually going through the hunting here, but just I mean, just really, you got to internalize this. I'm going to keep saying this over and over again. Get the client side injection to execute. Figure out how you're going to deliver it to the victim. And it has to be a very clear, you know, it's the payload is in this get parameter in this link and I send it to them in a fishing, you know, type thing or I get them to click it there or I redirect them from my own malicious website, you know, whatever it is. You have to be able to clearly articulate how you're delivering your client side injection to a victim. Full stop. If you're talking about a cross- sight scripting and you can't explain how you're going to deliver it to a victim, you're not going to be able to show impact. That part has to be part of your report. Full stop. Okay? So, want to be really really like keep hammering that home because again, this is a mistake that I see people make a lot and I want to uh hopefully uh help to square that away a little bit within the community there. Um, so yeah, just moving in there. Um, I mentioned right like delivering it to the if it's a reflected or anything, the the query string, the the get parameter, delivering it to the victim, they're going to click on it somewhere, some type of fishing attack or however you're going to get to it. Um, for stored cross-ite scripting, I mentioned this before, store it in the user profile or if it's in a forum, any type of a public page, you can poison that and then you can hopefully just get uh get the the victim to navigate to it naturally or multiple different victims to navigate to it naturally. Um, you know, you can also depending on how the client side injection is executed, you can potentially set up a malicious page that just redirects them over to that. Now it's there's a lot of things that have to happen because sometimes the get parameters depending on how that's done are not going to be carried over. Um it it gets more complicated with that. But there are some cases where that's a good way to deliver your payload if you can't do it other ways. Um yeah and then you know it if you can uh somehow find a way to poison an API response that you know that they're going to load as well, right? Similar to the stored uh cross-ite scripting there. it's, you know, through the the natural uh use of the application, they're going to uh they're going to eventually kind of load that up and do it. And one thing that I didn't mention here on the slide that I should have um because this is one one of my favorite chains if you can get and it's super super hard to get it, but it's a huge impact. Client side injection um specifically like a reflected typically reflected cross-ite scripting um combined with uh web cache poisoning. So if you can get a reflected cross- sight scripting to where it poisons the DOM and it has that that uh JavaScript execute and you can get a webcing to where your malicious response loads up to everybody for a period of time. That is a really cool, very effective way to show impact. Now I have to do a whole other thing on webc poisoning and webc deception, that type stuff because it's a that's a whole whole other thing. Um, and it could be quite complicated, but if you're familiar with if you look into it, definitely keep that in mind. Um, I love I I always love to to find those if you can and and if you get a webc poisoning, right, definitely check to see if you can also get a reflected cross-ite scripting in that input there. All right, we talked a little bit about the same origin policy. I'm not going to go too deep into this, but it's really, really important to understand. So, we'll go at the surface level, and again, you can read the slide, do your own research as well. um the same origin policy. This is a uh natural security control that is built into all browsers. This is just how browsers work. They have to adhere to the same origin policy. And what that means is if I have loaded up, you know, a.com or you know, arson1.com and I try to send an HTTP request to arson.com, it's not going to work. You cannot send HTTP requests from one domain to another. Naturally, the browser will block it. Um, and you're going to get an error within the console there. Um, that is what corors is for. Cross origin resource sharing. That is the reason that corors exists. Excuse me. Oh jeez, I have something in my throat. Um, that's the reason the cross origin resource sharing exists. So when a developer has the need to access information and actually I should say you can send the HTTP request you can't bring the data back. That's that's really the thing like you can't it'll send it out but what it'll do it is it'll do an options pre-flight. It'll do an options call and then if the course headers are not returned then you're going to get uh that you know it's going to fail before it even comes back. So you can't you can't grab the data from another origin and go back and load it within uh a separate origin. It's probably a better way to say that I realize as I'm recording which is probably not great but that's fine. Um so corors allows you to bypass this and you can configure an API or anything say no no no no any uh request from either from any domain or request from this domain. Uh if it comes from there then you can return the data uh and it can be loaded up in the browser. Um and then these can either include credentials or not include credentials. So um once again corores that would be a whole uh a whole different video there but but it's you really got to understand it as far as weaponizing uh cross-ite scripting is just understanding what the same origin policy is and how it can impact once you get that uh JavaScript to execute. You may go and say okay well I'm going to load in and steal data from this separate domain. Well no only if they have uh cores configured for that. Um, and if they don't want you to do that and they have cores configured correctly, it's going to block it because it's not going to be within that domain. So, and I'll move to the next slide here. A lot of times what happens is, um, and especially with data exfiltration, you'll get a client side injection and then you'll you'll chain that with a misconfiguration in cores. And the most common misconfiguration in cores is where the origin header. So, what corors does, let's start with that. What Kors does is it checks the origin header and it compares that with a uh a header that says, you know, essentially has a domain that says, you know, it's allowed to do that. Um, so it'll, you know, request comes in from google.com and if the course header is set to allow either all domains or just google.com, then it will allow it to to return that data. Here's the the crux of the issue and honestly somebody needs to update cores because it would be a pretty easy way to fix this but there is no way within corores to configure it to configure your corors uh implementation to allow any subdomain from a specific domain that is not built into corores. You only have two different options. You can allow any domain well three different options really and that's where the cruxy issue comes from. You can either allow any domain. You can allow a single fully qualified domain name or you can programmatically implement it so that it you know uses reax possibly to check and see if it's a subdomain or and this is what this is the most common cores misconfiguration that you're going to see all the time. they will simply take the value of the origin header in the incoming request and reflect that in the uh access control allow origin header in the response. So the developers and it's you know you know it's kind of the simplest way to solve the problem. They will just take that value and reflect it in there. So if you type in evil.com as the origin header manually and send it you're going to see it's going to allow it to come back and it'll say evil.com. Now here's another thing. I'm just kind of thinking of these as I go through. Um, some uh web applications will only block on the options pre-flight. So, and that actually becomes a red herring because it looks like it's vulnerable when you send the actual post request or put request or whatever it is, it reflects in the response and it looks like it's vulnerable. However, when you actually try to execute the proof of concept, then the options pre-flight goes and you hit a wall basically and then you can't. It won't send the next one because the options pre-flight gets kicked back. So, it looks like you can do it, but when you actually try to build the proof of concept, you realize that they've their security control was is a little bit different um and it blocks it. I've run that a few times. It's it's clever. It's frustrating from the attacker perspective. So, it's clever from the defensive perspective, but um anyway, so it's probably as much as I'll go into here with course misconfigurations and stuff, but um as you're testing for client side injections, keep note of any endpoints that have cores, um any data that you might want to exfiltrate. Definitely, if you find anything that is just reflecting the origin value, if it is using a reax to try to allow any subdomains, right, reaxes, there's a lot of ways that you can break those or circumvent those depending on how they're implemented, how complicated the reax is. So you can definitely try to bypass that. Uh but you will as you're trying to weaponize your cross-ite scripting attacks, your client side injection attacks, you will definitely want to leverage misconfigurations and cores in order to uh to keep building that up. And that is a way that you can bypass the same origin policy and continue to build that impact. Okay, this very very important if you're kind of doing two different things and you know you're uh multitasking or something. If there's one thing that you learned from this outside of client side injections, just one thing for bug bounty hunting, there's one thing that you learn from this video, this should be it because this is the biggest mistake I see people making. Figure out don't don't go find a program, a a application you want to test on and then test it for a whole bunch of different things or test it for client side injections. What you want to do is figure out what class of vulnerability you're you want to test. So in this case it would be client side injections and then go across all the different public programs the private programs you have access to whatever it is and find good targets for that vulnerability. I always say bug bounty hunting is not a penetration test. This is a shining example of that. This is I see this is the most common mistake that I see is people treat it like a penetration test and they go and everybody's doing the same thing. They're running a burp active scan and they're going and they're testing all the same stuff, all the same attack vectors and everything. No, no, no. go and find the programs, the applications, the targets that have the technology stack and have these pointers and everything that make them more likely to be vulnerable to the specific attack class that you're looking for across all the different programs and then hit them over and over again. Do the same test over and over again. And what that first allows you to do is you're not wasting your time on these other targets that may, you know, an entire application may only have one or two legitimate targets for a client side injection. If that's the case, then you don't even want to touch that. If you're testing for client side injections, it's too much context switching to go back and forth with that. The other benefit is as you go through and keep testing the same things over and over again, you're going to start to notice the patterns of compensating controls. Like, well, I just tested Grammarly and Grammarly, you know, had the excuse me, had the options pre-flight blocked, uh, even though it looked like it had a course thing, but then this one doesn't have it. you know, you're going to start to see these differences, these these inconsistencies, and you'll start to notice the patterns of what works and what doesn't work. So, not only is that going to give you a much greater uh chance of finding a legitimate vulnerability, but you're going to learn and grow much quicker because you're going to be learning just naturally the things that most people don't learn because they're going through trying to learn the pen test and the attacks. And the attacks are fairly easy to learn. It's what's difficult is learning the compensating controls, understanding how the whole picture of the application works and going and doing the same thing over and over again across a hundred different programs, you know, over two weeks. You're going to learn that naturally and you're going to start to pick up on those patterns. You're going to start to see like the the implementations that are less secure, that are that are not as effective and you can start to seek those out. And then later when you're doing a testing for something else and you may go say, "Oh, oh, they have this course misconfiguration here and I saw that in that other one. They also have this Curf and this and that and they're missing this cookie flag and ooh, this is a good target for client side injections, too." And it and it's going to become more natural. You'll go into it. So, um, that again, I I cannot highlight enough how important that is. You want to change everything about your bug bounty hunting overnight. That's the one thing that you can do. figure out what class of vulnerabilities you want to test for, then go out and find all the different targets for it. So, with that being said, what are the targets that we're looking for for a client side injection? First, you want to have in order to show a good amount of impact, it needs to have some sort of authentication. You know, you need to be able to tie it back to some sensitive data, you know, getting access to a a user's account or anything. So if you can get a client side injection on, you know, maybe just like a marketing page or something that doesn't have any real information and that ties you can you can use that to attack another domain that that maybe does have that. That's great. But ultimately, first of all, I I really only test for client side injections on, you know, it's an application that has multiple ideally multiple different roles, but a you know, sensitive data that's stored back there where you can target a user. Um because there's just going to be so many more ways to show impact there. If it if the entire target is just a marketing page and there's nothing else, no other subdomains, there's no login or authentication. Even if you get the crossite scripting, how are you going to show impact, right? What's what's the worst that you can do? There's there's not a lot that you you can still show some, maybe they'll care, but it's not going to tell the the same type of story there. Um you know, I mentioned the the cross domain. If the application has a large number of subdomains, if it's spread across a lot of different domains and it's using a lot of cores, implementations and everything that can be another great target because there again the more complexity it has a lot more opportunities for something to go wrong. You know, you would think, excuse me, you would think that they would standardize, you know, and and and some companies do, some some development things do, but it's it's easy to think that like, okay, I tested this one cores implementation and it's secure. I tested this one thing and it's not vulnerable to it. So, they're probably doing the same thing across, right? Because of course they have something that's worked. Why is working here? Why wouldn't they have it work everywhere else? Well, the problem is it if you ever worked on a blue team or if you ever been a developer or anything, it it's just it's not possible. You've got so many different teams, a lot of them are doing their own things. Now, ideally, the blue team, the security team, this is, you know, what what I've done in the past, you want to come in and try and standardize that. But I can tell you from many years of experience and frustration and exhaustion and burnout and a lot of other things, it can be almost impossible to standardize across that because the code bases can be completely different. the way the teams approach their development can be completely different and the faster the company is trying to move so especially if it's preipo um then they're you know or they're in trouble financially or anything um then there's very likely going to be more comp right they're just kind of going and doing their own things and trying to standardize that across everything is very very difficult for the company for the the security team so you can take advantage of that as a bug bounty hunter right so the more opportunities that you have the more cross-domain trust boundaries that exist that potentially have mcon configurations, the greater opportunity that you might find something that you can chain and you can weaponize there. Um, user content generated surface, um, or user generated content service. Good grie I I can't talk today. Um, you know, things like forums, anywhere that you can put comments, social media, anything like that. It's where, uh, uh, applications where there are a lot of opportunities for users to prevent public data that's read by a lot of other people. That's a great opportunity to test toward cross- sight scripting. Again, every single one of those places where data is put into the database and then pulled out of the database is an opportunity for something to go wrong. So the more areas that you have where that's happening within an application, the more opportunities you're going to have to find something that's going to circumvent a security control. And you've really got to think about this like you're looking for a crack. You're just looking for a crack. That's that's there. You're not typically going to see anything that's wide open. But if you just that one thing that this one little piece went wrong or this was implemented in a slightly different way, that's your crack and that's your way that you can get in. And once you can get that to execute, you can start playing around with the compensating controls there. So uh any application that has a lot of userenerated content um is going to be a great opportunity to test stored cross-ite scripting. Single page applications um that's where you get into your DOM based your you know with the virtual DOM testing those vulnerabilities within those. Right? So um again it's a different methodology. a different type of testing, but uh it's we'll definitely look at that. Um the more JavaScript, the more custom JavaScript especially, uh the greater opportunity and then if they are using these these frameworks, um you know, hopefully they're using some of these dangerous methods that they can leverage as well. Um and then yeah, any anytime you see a session token without an HTTP only or without same site strict, um definitely dig in, especially if it doesn't have HTTP only. If there's a session token without HTTP only, there's a reason for it. And if they and the reason is typically that they're doing something funky, right? Maybe they are um the let's say the session token is a JSON web token and it's sent naturally to a lot of the the endpoints, but then the API uh the API endpoints require it to come in an authorization header. How do the developers do that without being able to access it with JavaScript? It's almost impossible. So if you see again this is an idea of like a or an example of a pointer. If you see that, if you ever see a session token, a session cookie that does not have the HTTP only flag on it, especially definitely start testing because if you can get a client side injection, the game is over. You can easily show impact because you can just grab that and do something with it, right? It's if depending on their content security policy, you can just steal it or maybe you can leverage it, go send it somewhere else, but you're going to have a ton of opportunities if they are allowing you to access the session token through JavaScript. Um, so yeah, just talking about a few of the attack vectors here of ways that you can deliver it. Again, we talked about search parameters there. Um, you know, if you can poison a uh an API response there, um, potentially something that's coming back, there's an error message. Um, yeah, we've talked about a lot of this before. Um, you know, you can get clipboard access as well as an interesting thing. So, you can uh, you know, potentially poison their uh, clipboard and and have that, you know, be injected somewhere else. So, but typically what you're going to find the most common place is going to be within the URL. That's the easiest way to to deliver it there. Um, again, these are just some ideas. We've talked through most of them up until this point. Um, okay. So, kind of wrapping up and again, we will look at all of these as we move into the actual hunting phase, but um, automated testing. There's a bunch of different ways that you can do automated testing. There are a ton of existing crawlers and scanners out there, right? Burst Pro, Zap, Nuclei, all those are going to test it. They're all going to do basically the same thing is they're going to send payloads uh through the uh different attack vectors when an HT http request. They're going to look for anything reflected in the response. They're going to look for I it's going to do the same thing, right? It's going to send canaries and parse the response. Um it can be fairly effective, but anybody can do it. anybody like I see uh I see this happen a lot where people go and they buy you know a Burswuite pro license and and they just go start running active scan against a bunch of stuff and you know they'll um hey the most you're going to get is duplicates you know because ultimately if you're doing automated testing and that's all you're doing for client side injections then you just have to be fast that's that's the whole game you have to you know if it's a new program it's a public program you have to be the first one to go and test it the people who are doing this that that actually make money from it. They have this down to a science. They have everything automated. They have the report submission automated as well. You can you can submit reports through the API of Hacker One, by the way, if you didn't know that. So, I mean, I they are and they're not even touching it at that point. They they've got something that's checking Hacker One for new programs every, you know, probably 5 seconds or something. Hopefully, not that fast, but um when they find one, it's going to go through, grab all the information, go ahead, start, crawl, scan. It's going to do all this happens automatically. something's found, they've already got templates uh for the the cross- site scripting, the different type, and it'll submit it. I mean, this a lot of people that do this, they they build their own automation to go and handle all this. So, that's not to say that you you shouldn't use automated testing, but uh just understand, especially with client side injections, it's a very common uh way to test. Um it is very fairly easy to automate at least, you know, some of the main uh attacks. Um so yeah just understand that you know it it should be a part of it but um typically there's going to be a lot of manual effort with client side injections uh especially you know like I said understanding the compensating controls and actually getting it to execute. Typically what happens is you're going to find a lot of your good ones with manual testing. And that manual testing is going to be you'll find something that's reflected in there first of all or it's stored and loaded somewhere. And you're going to have to go in and see how each of the compensating controls affect the the output and how it's loaded into the DOM. And then eventually you can get that alert to fire. And that's step one. And then you'll see okay now I can put it in this get parameter and I can deliver it to the victim. And that's step two. And then all right now I need to figure out how I can weaponize it uh and go through. So, but yeah, I mean essentially you're going you're identifying attack vectors manually, whether it's reflected, stored input, any uh sources within the DOM, etc. Um, and then it'll, you know, once you get it to execute, you'll go and have to do it. Um, the book, I don't know if I have it with me. I should have had it ready. Um, the book that's in the, uh, the JavaScript for hackers book by by Gareth Hayes at at Portswigger. Um, I think I don't know where I have it right now. Typically, I have it beside me, but um, that is you definitely want to have that for your manual testing. He goes into incredible detail about how JavaScript works and how the different characters and payloads can be manipulated and and all these different opportunities for you to to circumvent these security controls and and be able to weaponize it. So, I can't recommend that enough. Um but again the majority unless you're moving super super fast and automating everything with custom automation and submitting the reports and everything most likely your client side injection needs to come with manual testing and uh it can be quite uh tedious you know and so I think that's what you know a lot of people think that they can just go and and kind of spray the the payloads around and eventually find it. Um unfortunately yeah there's just too many people trying the same thing. So, um, yeah, you want to you really want to focus on manual testing and the automated testing is more to, uh, supplement that. Ideally, the automated testing finds a payload that doesn't quite execute and then you can find a version of the payload that does and then you can go and weaponize it from there. That's probably the most common way that I actually find a client side injection. All right, so that is everything. Um, I think we got about an hour and a half to to start here with the presentation, which is not too bad. Um, but yeah, so you know, again, I mean, you can read this through to to summarize it. But yeah, I I just want to keep reiterating. Find and get the payload to execute, deliver it to a victim, find a way and articulate how to weaponize it. Really, that is the summary of everything that we're talking about today. So, that's what I want to show you with with the hunting now. Um, but yeah, that is uh client side injections in a nutshell. Uh, so yeah, thank you if you made it this far. I hope it was helpful. Um, we're going to go ahead and switch over to doing the actual hunting. Um, but I do want to mention as well, like I said in the beginning, I do offer private bug bounty hunting tutoring. I can offer it for individuals, offer it for uh groups, you know, if it's a corporate team or anything like that, whatever you'd like. So, if you are interested in having me or one of the engineers that I work with helping, you know, guide you along in your bug bounty journey, help you find your version of success, definitely let me know. Tutoring arsoncurity.com. Again, that's arszereroinssecurity.com. Uh, I would love to help. But with that being said, uh, I'm going to go ahead and, you know, we get the slides out of here and we are going to go ahead and start actually hunting. So, let's do it. All right. So, the first thing that we're going to do is we're going to go to my GitHub and we're going to download the repo for this video. And this is something that I want to start doing more. I built out a couple things. There's a script that's going to help us find programs that are going to be good targets for client side injections. There's an app that I've built uh not not necessarily an intentionally vulnerable app, but more of a a lab environment where you can go in and set different uh security controls and test out different payloads and and see how they impact and everything. So, we'll play around with that a little bit. Uh and then it's also got the slides for everything that we just saw. So, you want to go back and you want to get the actual image version of the slides, go and review those uh yourself. Obviously, there's a lot of additional information that I did not talk to or through in those slides. Uh, you can go and get that as well. So, but let's go ahead and we'll just go to GitHub here. So, github.com and we'll go straight to my page here. Yes. Yes. I know I go to GitHub a lot. We'll just go up to repositories and right here, client side injections part two. I just got it built out a couple days ago and uh yeah, there's some good stuff in here. I'm pretty pretty excited about starting to do this more and more as I uh keep making these videos. So, let's just come over here. Get clone. Add that in. We will move into that. Make sure we got everything. And I'll just go ahead and get VS Code brought up here. It be a little bit easier to work with. Okay. So, yeah, like I said, you got the slides in a zip file here. You can open those up and uh you can unzip it, take those out. Uh the read me for the uh vulnerable lab here along with a little bit of information on the script is included. So you can go through and read all that, figure out how to do it. And then our find programs directory here does have uh the script that we're going to use to go ahead and uh find good targets. So and if you remember, like I said, if there's one thing that you take away from this video, outside of all the client side injection stuff, just please remember this. the successful bug bounty hunters that I have seen and this is the way that I was able to find success. You do not go and find an individual program and then do basically a pen test on that where you test all these different client side injections server side right all these different attack classes. Uh the successful bug bounty hunters that I see they pick specific attack classes and then they search across all the public programs the private programs that they have access to for good targets based on their technology stack and and everything else. So, we're going to start with this XSS target finder script that I've built. And that's exactly what it's going to do, right? So, and actually, let's go ahead and go down here to the bottom. So, you you can give this uh both your hacker one and your bug crowd API key. I'll probably build some more in there as well, but I just wanted to get something out there and working, right? So, um they're done with environment variables. You can see that that uh what the naming convention is there, and it's also in the read me, and I've actually already got it set up over here. So, uh, within this instance of the command prompt, I've gone ahead and stored my API key for hacker one in the environment variables there. So, uh, what this script is going to do is it's first going to go through and build out a JSON file with all the public data for public programs on here that it can access. So, uh, hacker one will go through and find all the public programs. It'll get the scope for it, some additional information, etc., and it'll store that locally on that or once that's done, it's going to start picking programs at random. So, every time you run this, it'll work a little different. And if you've already got the program data there, it'll check first and make sure you do, you know, do you want to update the data or do you want to use the one that's already there? If it's data from a day or two old, right? There's no reason to go through and update it anyway. But it's going to go through and pick random programs and it's going to identify first of all any scope targets that are just a straight URL as well as any wild cards. Now, depending on the flags that you give it, and I don't want to dig into a bunch of stuff here, but you can uh for the wild cards, you can give it a flag that will tell it to use certificate transparency logs to reach out and try to find additional subdomains that we can test. We're not going to worry about that right now, but by default, if there's a wild card, it will just convert that down into basically a domain, right? So, if it's star.grarlely.app, then it would just test https grammarly.app, right? So kind of a simple thing there, but it it reaches out and it does a you know some basic inspection on that. The main thing it's looking for for this for the client side injections is it's looking for the client side technology stack, right? Does it uh have a lot of custom JavaScript files? Does it have uh is it using React or Angular or Angular or anything where we're going to have to get this really specific thing or or does it not have a client side JavaScript framework? you know, does it have jQuery and all these other things that are going to give us a lot more opportunity to go in and actually find some potential client side injections? So, the script is going to do that. It runs consistently and it builds out a text file as it finds new targets. Um, so what I typically do is I'll let this run for, you know, I mean, it just depends on how long, but a couple hours, uh, give or take. And, uh, as it starts to build that up, then we'll be able to look at it. Um, you know, you go test them one by one. It also gives a really basic numeric score based on it's between zero and 100 based on how likely it thinks that this could have potential uh client side injections and and how you know we can weaponize it too, right? It checks to see uh if there's any login buttons on on the main page or things like that, you know, because if there's authentication, there's going to be a lot more opportunities to weaponize, etc. So, so what we'll do is we'll get this script running. We'll go through and find or have it find the the programs. And while it's doing that, I'm going to pull up our lab and I'll do some some demonstrations of how you can use it to do your own testing and your own training and everything. I'm not going to go through every feature in there because I actually built a lot into it. Uh, but it'll be available and free for you. Go clone the repo down. You can play around with it yourself. And there's a lot of verbose instructions and information and learning materials within that to explain what's going on. You know, what code patterns are actually vulnerable, etc. I really wanted to include as much of that as possible. So, so let's go ahead and do this. um get this up here and then first of all I think everything's already installed but uh what do we have? Let's go into our find programs and then we will do pip install attackr requirements.txt. Okay. So yeah, you can see I've been testing this. I already have everything installed. That's why you see like requirement already satisfied, requirement already satisfied. Yours will look a little bit different especially if you're not installing on Windows, which I'm doing all this on Windows right now. Uh, but you know, it's pretty basic, right? You just install the packages. Hopefully, I mean, if if you have any issues with this, simple Google search, you know, Google Gemini get you squared away. So, I'm not going to worry too much about this here. Um, from that, let's see. We can just do Python 3 and XSS find target there. And then we're going to give it a couple flags. So, let's come back here and take a look at what the flags are that we can use. Um, yep. So, here's a few. Oh, no. No. No. That's for the wrong part. I forgot where I put the code. I forgot where I put the code. That's going to make it easier. Okay, here we go. We got the parser. Oh, it's I thought I put it in a different function. Oh, that's fine. So, here we can see the flags, right? Um, now by default, it's going to check for a hacker one and a bug crowd environmental variable. If neither are there, the tool just exits because it's it can't do anything without either one of those or or if the existing JSON data is not there as well. Um you can tell it to do only hacker one or only bug crowd. Uh so that's what you see right here if you want to tell it. We're going to skip those though. Um we also have two different main uh modes that this tool runs in. So there's the reflected stored and the DOMB base. So the targets for uh reflected cross-sight scripting and stored cross-sight scripting are going to be a completely different technology stacking completely different things compared to DOMB base. So DOMB based cross-sight scripting and then client side prototype pollution as well. So we have two different ways to run this. We're going to start right now with the reflected and stored cross-ite scripting. That's going to be the first half of this hunting section. I'm going to go through and we're only going to focus on reflected and stored cross-ite scripting. Then we're going to come back to this script later and we're going to run it for the DOMbased checks. We're going to get a whole new list of targets and we're going to go in and test those and those are going to be ones with a a large number of custom JavaScript files. They are going to potentially have some of those like Angular, React, everything. Whereas now with the reflected and stored, it's a big bump in the score if it does not use that framework because it's more likely for us to find that specific class of vulnerabilities. Again, decide what type of vulnerability you want to hunt. Find targets that are good targets for that. If you want to do one thing to give you an a huge boost in your percentage chance to actually find valid vulnerabilities and stop wasting time, that's it. Again, if you forget everything about client side injections that I teach in this video, take that one thing away. It will have a profound impact in your ability to find bugs. I promise. Uh, okay. And then you can also tell it subdomains. Again, that's going to inform it that uh either we want to use the certificate transparency logs and it anytime it finds a wild card. I'm not going to bother with that cuz we got plenty of different targets. And then you got verbose as well. I like to run it for for verbose. But that's really it. So our command we'll tell it to do just hacker one um because I only have that API key in there and it I don't want it to even have to go and check. Um I'm going to tell it to do reflected stored and then I'm also going to run verbose because I like to do that there. So let's come over here and we will do tactac hacker one tactac reflected stored. It would be fantastic if I could type. And finally verbose. So let's go ahead and get that running. And here in just a second we should see that it's going to start. Uh interesting. Let me figure out what's going on. We'll get that fixed. Okay. So today I learned and I'm I'm doing this on Windows, right? Remember it's a Windows command prompt. Today I learned that if you use set X instead of set, which set X on Windows uh sets that environment variable systemwide as opposed to set would just set it temporarily, then you need to actually restart your command prompt before you can access it. Uh I did not know that and I just learned that right now. So, that was the reason that the tool didn't work is uh I, you know, or at least it it didn't find the environment variable because I need to restart the command prompt, too. So, let's get back into where we at. How do we end up back here? Don't know, but that's fine. Find programs started to type fine as I was saying fine. Funny how stuff like that happens. Okay. All right. So, we should be good now. So, once again, we're going to do Python 3. We're going to do our Python script. We're going to tell it hacker one. We are going to tell it reflected stored. And finally, we're going to tell it verose. And okay, perfect. So, it is reaching out. It's going to take a little bit of time because it's a fairly large JSON file and there's a bit of data in it. So, we will let that run. And in the meantime, I'm going to come back over here. I'm going to open a terminal and we are going to get our demo app set up. All right. So, uh, just like everything that I do, it's it's fully dockerized, got docker compose manifest in there. So, just like with my framework, all you're going to do, try to set that down lightly so it doesn't make a weird noise. I've noticed looking back at these videos, there's like this weird echoey noise. I need to fix that. But anyway, uh, docker compo. Ah, up tactac. I cannot type. There we go. All right. So, we're just going to build this. Uh, yeah, takes a couple seconds. There you go. And now it is running on localhost 3000. So we'll open this up. Go and keep that there for the sake of it. And here we have our training lab. Uh so you can see right at the top I've got the four different vulnerability classes that we're going to be focusing on for this video. Reflected stored DOM based uh cross-ite scripting and then our prototype pollution as well. Client side prototype pollution which we can then try and elevate to uh a cross-ite scripting type payload as well. Um, I also have quite a bit of information on each of the compensating controls that are covered in this. So, I I focused on the main ones that we're going to run into, right? Client side server side validation, output encoding, web application firewall, content security policy, and secure cookie flags. Each one of these gives you an idea of how effective it is, what are the types of things you're looking for, what is the impact on a cross-sight scripting, etc. So hopefully that little bit of information that reference you can use as you're going back and forth. And then just a couple additional things down here, but really the bulk of the application is in each one of these vulnerability types. So let's go ahead and go into reflected cross-ite scripting. And you can see so you can set the security controls here. And I'll leave it wide open as well. Um content security policy, you can do all different types of content security policies depending on what exactly you want to test. Um, so again, this gives you the more the further down you go in the different ones that you do, it's going to get more and more challenging. You can test yourself and and learn ways to circumvent these here. And uh, we got examples of different payloads. It'll tell you what security controls are active down at the bottom. Super easy, right? So, just to start, I'm going to go ahead and send my Canary. This is exactly how I would manually test. And we would see, okay, we have uh, the Canary going out and then we have the reflected output coming in. Now, let me go ahead and open up Burkswuite as well. And we'll go and look at the proxy. And here we can see that actually happening. So if we search for arson here and arson here, we can see that it's actually being reflected in two different places. We have one that is being added as an attribute. Right there is the value. And then we also have one that's being put in the middle of this div. Now this is your ideal scenario. It's not embedded within an existing uh HTML tag or anything else, right? It is wide open within there. So, anything that we put in uh we can, you know, ideally it'll it'll load up in the DOM within that div there. So, uh let's go ahead and send this over to the repeater. We can also see that we do have a session token there. So, that's something that we could attempt to to grab. We'll send this over. Let's do a search for arson right there just so we can see it. Now, we'll just do a couple probes here. So let's go ahead and send an open quote. Oh, let's tell this as well. Auto scroll there so we can see it. Um, so here we do see some output encoding. Okay, so uh uh well actually what we would test there. Let's just send this. And uh okay, once again, so it doesn't look like we would need to put a double quote right here to be able to break out of this. And then we could go in, we could either close the tag itself, the input tag, and put a new one in, or we could potentially manipulate the attributes so that this HTML tag itself executes. Although, I don't know if an input, there's a couple ways I could do it with an input. It'd be a lot more complicated, though, and you would need the the victim to actually click on it there. But again, here we see we've got the double quote that's rendering. We've got the uh open tag there. So, it's looking pretty good for us here. So, let's go ahead and do this. And I'll get rid of my canary at the beginning and we'll send this. And once again, we have a lot of output encoding coming up here. So that's one of the security controls we talked about. That's a very effective security control. However, we see that this certainly appears to be loaded in there successfully. So let's come back over here. We'll do the same thing again. submit our payload. And there we can see the basic cross-sight scripting exploit there. We now have the ability to to execute that. And you know, we could do document.cookie and send that. And uh it would certainly help if we didn't put it in quotes. I like to keep my mistakes in there so that uh people can see and and see me respond to it there. All right. So, uh, now we can access that session. And then maybe instead of, and let's do this. Let's come up here. I'm going to go to web hook. And this gives us a uh web hook on the external internet. This is a free site that you can use, although you can, I believe, do some some paid stuff with it. And I would certainly recommend it. I've used this my entire career. Um, but we're going to instead this is going to be a fetch. And then we are going to do fetch just sends an API call. if you're not familiar with it's very basic JavaScript thing there. So we're going to put our web hook in here. We're also going to add a get parameter that's a Q and then we will append our document.cookie to that. So I'll submit this payload here and uh looks like nothing happened. However, when we come here, we can see that we have actually exfiltrated the victim session, right? We can see that it's it's put up there. So what I can do and we can see this is all put within the git request. So I can come over here, copy this and send this over as a link to somebody. And when they click that link, once again, the victim is uh is executed. Right? So that shows the thing. We we have identified that we can execute. Now we have figured out how we're going to deliver it to our victim. We're going to deliver it in this URL that is poisoned. And what are we going to do? we're going to steal their session token so that we can come back in and use it to get access to their account. That's the most basic uh cross-ite scripting exploitation there. So, um let's go back over to an alert just so that it's there go. Yes, the same thing. Um and now actually let me copy this first. We're going to go ahead and add some client side validation to it. So you can see we we applied the security controls. We got a different get parameter up there. And now if I come in here and send this. Oh, now we get this client side validation. So so that's great. That tells me as the user from a user experience that I can't send these these characters. However, uh doesn't really do much of anything for us. So let's just get rid of these here because it shows us, right? This is also an example of why when they have verbose error messages, it's not good for them because we know exactly what characters we can't include. And let's come over here to burp and let's put a little intercept on there. Let's send that through and again script right there. Come over here slashcript. It'll do the HTML encoding on its own. We'll run that. We come back and we have our execution. So client side validation does absolutely nothing. Now server side validation, let's go ahead and apply that instead. Now we will do why did we get no response from a server? Is that a problem with the tool? Huh? What in the world happened there? Oh, that's I I genuinely don't know what happened. Um, but that's fine. Something hiccuped. You know, it's Look, I this is not a production app. I I threw something together so you'all have something to play with. If you find any issu or issues with it, uh, let me know in in the issues in there and I can get it patched up real quick. I I have no idea why that didn't work for, but all right. So, now we have serverside validation. Now, it is making its way into the server side code and that serverside code is processing it. But there's a method in the beginning that's checking to see whether or not it has any malicious characters there. Now, we don't know what malicious characters those are. So, we'll come back here and uh we can send this. So, here is our section. Um we saw that the client side validation said that you can't use the greater than or less than symbols because those can be turned into HTML tags. So, my assumption is that that is what we're not allowed to use. So, and these are the HTML encoded versions of that, right? do this here and this here. And now we're still getting an issue there. Ah, because we've got one still in there. Oh, because of the slash script. That's right. Um, no, that one's not getting it either. So, that tells us because you can see over here that there's no open or close tag. So, there's probably something with alert as well. Or maybe the word script. Let's check alert first. No, it still doesn't like that. Let's check the word script. Okay. And that allowed us go through. So you can see how we're starting to get an idea of what server side validation is in there. Um so that we can try to find a payload that we can potentially do it. Now um I'm going to leave this to you. I'm not going to show you the solution. There is a solution here. You can either go through and manually do your testing code by code. You can do that JavaScript for hackers book and everything. That's my recommendation. Another thing that you can do is find a bunch of different types of payloads and uh you could go through and uh test it, right? So, we may just come over here and do an active scan uh or yeah, however you want to do it. You can manually load them up into intruder uh whatever, right? But that's that automated versus that manual testing. So, um that's server side validation. Let's see. We'll go back here uh output encoding. So, we will set this and we can see everything's changed there. So now we're going to do our script alert arson. Submit that. And it loads. And it actually it loads up there. We come over here and inspect it. Uh maybe can't find it. Why is this up so high? So when we go into the HTML, it actually appears like it's rendering, but it's not actually being processed as script. So this this is something that would actually look like React was being used in the front end as well, but it's actually some pretty clever output encoding where if we look at the request itself and the response specifically, we'll see that everywhere it has actually been encoded. And the only difference Yeah, that is well that as well. So the only difference is that uh we you know we got these things the these different encoded characters in here. those are being loaded into the browser and processed by the browser so that to the user they appear that they're coming in as the actual characters but you can see the raw HTTP response. We can see that it's actually encoded and the browser is just handling that for us. So that does happen fairly often. Um if you see that where it's not actually executing, go in here, take a look at the raw response and you will probably see some some encoding. So this is why a lot of times just like you saw with the first test that was successful with no security controls. What I typically do is do a lot of testing in Burke because you can see more in there and then once I see the payload is full fully loaded in there then you can go over to the browser and that's where you'll see the impact of things like content security policy um yeah other things like that. So cookie flags etc. So uh okay so that's output encoding. Let's get rid of that web application firewall. Very similar, right? The difference is web and and this is not a real web application firewall, right? I kind of wrote some code to make it appear as one. It just checks for specific patterns. It's similar to the server side validation, but it does happen before any of the code is processed by any of the application at all. Right? So, if we go do our exact script here once again, we're going to see this. Now, the difference here is we can actually see what the pattern is here. So, again, we have verbose error messages that are coming back. We can use that to our advantage. I'd take this I go drop it in chat GBT and say uh I'm building an application. I'm using this reax for to prevent uh cross-ite scripting and client side injections. Um are there any payloads that can bypass it? Right? That's what I told CHP. Meanwhile, what I'm actually doing is taking whatever it gives me coming back and I'm using it to target this application. Right? All right. Uh let's see. We can clear that out. Uh secure cookie flags. Let's go ahead and do that one. So we'll set the flags now so that specifically let's come in here and inspect and look at the application itself. So the session token now has HTTP only true and same site strict applied. Those were not applied before because remember we were able to grab that uh using document.cookie. So let's come down now and we will use the same payload that we did before to alert document.cookie cookie and now we have an open empty alert because our JavaScript because the HTTP only flag can no longer access that cookie that's stored there. All right. Okay. And now last but not least, let's go ahead and take a look at the content security policy. I'm not going to go through all of these, but let's uh let's just do this one here. So block data exfiltration. So earlier we were able to use that fetch command to send the victim session to our external facing web hook here. So let's see what happens when we have the content security policy that is preventing these fetch requests to going out outside of this origin. Right? So it says allow same origin forms. So that means that if this form is pointing to uh something that's within the same origin remember the same origin policy. So in this case it would just be local host on port 3000 then it will the content security policy will allow that request to come through if it is submitted through a form. However this is going to completely block API calls going with JavaScript. So you can see how these content security policy directives can get very granular and how they can have a very big impact on your ability to actually weaponize these. Once again, this is where this is the difference between a a an experienced bug bounty hunter and somebody that's brand new that's just throwing a bunch of payloads out there. This is the process that you have to go through doing client side injections. It is a very methodical step. There's a lot of things that have to go wrong. So, most applications will have certain controls. Now, this is a very strict control. You're probably not going to see this, but uh but let's just take a look here. So once again, we are going to come over and do our script and we're going to try to send this over here again. So we'll hit submit payload. And we don't have anything there. So there's no error necessarily here. We come over here, but we don't get a new request. Remember, we only had these two requests there before. So let's come in here and hit inspect. And instead of just going in to look at, well, actually, let's look at it first so you can see the script has been loaded. The script has been added to the DOM there. Um, but it's grayed out. So, why is it grayed out? It looks a little different than it did before. It wasn't grayed out before. If we go into the console, we're going to see that there's actually an error with the content security policy. So, that's very, very important when you're testing and when you're determining things like content security policy and cookie flags. This console can be very helpful, right? Because just like I can't do this, I can't come over and do fetch even even if I just try to fetch google.com. Once again, the content security policy is going to reject it. It's getting rejected by the browser. It's not reaching out to Google and Google's saying, "No, I don't want it." Google has no idea what's happening because the browser is checking the content security policy of this application of my application that I built. And my application is saying, "No, no, no. These requests are not allowed to go to any actually in this case, it's saying no uh API calls using JavaScript. are only allowing form submissions to this same domain, which is why I'm able to to submit this. If I didn't allow form submissions either, then I wouldn't even be able to submit this form. It would block me from from doing that, and we'd get an error within the console here, too. So, um, that's everything for reflected cross- sight scripting. I'm not going to go through again a ton of of these different ones here. Um, they're all fairly same. I mean, stored cross-ite scripting, right? You just kind of have comments that you can do. So, you can do start with that. Uh, uh, oh, okay. I'll get this fixed before it comes out. I promise I'll get that fixed. Um, but yeah, you can go through and store uh the different comments there. All of these security controls are the same. What is going on? I really don't know what's going on there. I feel like I'm having some issues with just Firefox or something here. Let's Let me try this again. No. Okay. Then we click this. Now I've got Yeah, there's definitely some errors here. I'll get it sorted. Don't worry about that. Again, um I'm not going to stress too much about it right now because I want to focus on recording the rest of the the video. But store cross-ite scrubbed, it works the same. I'll get that database issue squared away very quickly. Um we also have the the DOM based XSS. So this is a little bit different, right? So here you can actually see the vulnerable code pattern that's being used. So here we're going to be taking a hash fragment and then we're going to be writing it directly to the inner HTML, you know, and then you can see this is what uh can be done instead. Um got some recommendations there. Uh so if we come over and do our arson payload here, now we have the output right there. And we can see up the top we're not at a git parameter anymore. We're in a hash fragment. Now I mentioned this earlier, but what does that mean? We come up here to Burpuite. And as you can see, the last request that was sent was a get request to this endpoint. We don't see anything with a hash fragment, and we're never going to see anything with a hash fragment here because the value of the hash fragment is never sent from the browser. That's what make makes this DOM based. The the DOM itself, the document object model is accessing this value here and then it is automatically rendering it. It's all staying within the victim's browser here. But we can still do the same type of thing. We can come down here and do a script alert arson. And we can go ahead and submit this. Now it doesn't show. We can go take a look and see if it was actually written. And it was. Once again, it's grayed out. Come to the console. Oh, there's no content security policy blocking anything like that. So why in the world would this not be executing? Well, the reason is if we go back up and look at our vulnerable code, we are using the inner HTML method. Something you have to understand with the inner HTML script tags that are implanted in here will not execute. So it if you do a script tag that is written to the DOM with inner HTML just by the nature of way the method works it will not execute. However, if we instead do an image tag source equals x on error equals alert arson and submit that. Now all of a sudden we have execution. So that's just another thing to know. If you see the code is using inner html. Don't use a script tag. I've got some examples down here. Right? You can do body, iframe, SVG, image. All of those will work. Um, go to, you know, Port Swigger has a g great, uh, cheat sheet for that. It's written by Gareth Hayes, once again, who wrote the JavaScript for hackers book. Incredible, incredible, incredible uh, client side uh, security researcher over there at Portswigger. Um, yeah, but again, this works fairly and uh, I think it's fine for that. Again, you can go in and most of those are the same security controls. There's a couple different ones like sanitize DOM and stuff that affect specifically with DOM based. Feel free to to go and play with that however you want. And finally we have our client side prototype pollution. So the client side prototype pollution you first need to pollute the prototype and then you need to find a vulnerable gadget chain. So if we look here in the vulnerable code up here at the top we have a recursive a deep merge. Now it does have a check for proto construction to prototype or constructor prototype. However it does the same thing no matter what. So that's not really going to help us here. And you can see something what you would do is have these dangerous keys and just have a basic conditional here. If it includes that just skip it and then if it runs into the proto or anything it will just overlap it. Um however here it does not do that and later we can come through proto or pollute it and then uh we can try and find some some gadget chains here. So let's focus first of all on polluting the prototype and we will come down here with no security controls and I'm going to do it's still going to add it to a hash fragment just like the other one did. I'll do proto and then we'll give it a we're going to add a key value pair that's just arson equals arson. And ideally if our attack works then every new object that's instantiated after this page is loaded is going to have in its prototype the arson equals arson key value pair. So and we can see right here it does show that it was polluted at that point. Now, what does that actually look like in practice if you don't have something in the DOM that tells you? Well, you're going to come in here to the console, right? Ignore this as well, cuz that's already there. And uh we can instantiate a new object right here. And then we can do arson. Now, if it was not polluted, let's uh cut that for a second. Let's load this back up. And then I instantiate a new object now with Whoops. without the pollution arson is undefined. It doesn't exist there. But once again, once we have this that loaded up here, let's come down. Oh, I moved out the prototype pollution thing. That's good. You can tell I I rehearsed this, right? And by that I mean I did not do that at all. I built this for the most part within an evening and uh was going to go ahead and get it recorded because I want to get to the actual testing. But I do want to put this out there again. I will fix the bugs uh by the time this video comes out. You shouldn't see any of those issues. But come back here. Prototype pollution. Add the hash fragment. Load this back up. Let's just get it here. There we go. And now, and again, usually you can just type it in and it'll pull it out there depending on what the the scope is. But you know, if you don't see that, you can instantiate a new object like I did before. So, um, and let's just do let's get our new object and then let's just do proto. So, let's actually read the prototype the object so we can see it. So, you see all these different things that are already built into it. And what's just kind of shoved in there is arson equals arson. That's it. That's prototype pollution. So we have now polluted the prototype of all objects that are instantiated here within running memory. So now what we need to do is we need to find a vulnerable gadget chain that we can use to pollute whatever method or whatever variable or value is being used to write to the DOM. So if we come down here, I've actually included four different vulnerable gadget chains that are in here and you can read exactly what it's doing and get an idea. There's an example payload of how you would actually execute this for each one. So we'll just focus on the main one at the beginning. Right? We have a empty user object. Then it's going to pull the uh gadget output here. So it's going to take the value from that and it's going to write it directly using inner HTML. Now once again writing with inner HTML, we're not going to be able to use a script tag in order to do it. But we can see here our working exploit. And I'll just copy and paste it for the sake of time. We have that there. And then when we render our profile, we see that our payload executes. Okay. So, uh yeah, I'll get everything squared away. Again, when you're watching this, you shouldn't see any of those errors and issues there. But, uh for the most part, I'm I'm I think this is going to be helpful. you know, I really because client side injections are just there's so many different things, so many different variables uh the way an application is built and configured that can affect whether or not they work. And I just I I've seen this so many times where people just get a bunch of payloads and access and they just go throw it out there and they're like, "Ah, I can never find a client side injection." It's ah, you're you're it's not that easy. It's it's really really hard. hard. Client side injections are really really hard and people seem to think that it's it's like something that you can just go and get this to execute. They're watching they go to labs and they go to um you know these these really basic old vulnerable websites that just take it and write to the DOM. That's not realistic. This is realistic. Every website that you're testing in a bug bounty program no matter what it is going to have multiple multiple different layers of these compensating controls that you're going to have to figure. You need to go through and figure out is it doing clients? Well, clients I do whatever but I like to I like to record it. Is it doing server side validation? Is the output encoded? Is there a web application firewall? What is the content security policy? What are the cookie flags? Go through. You need to identify all of these first and then you can start to try to get an alert to pop. And then, as I've mentioned over and over and over again, get the alert to pop. Figure out how you're going to deliver it to the victim. And then figure out how you're going to weaponize it. Right? All of these are the process from finding reflected input to getting a successful client side injection. There's like 12 different steps before you can actually get there. You might get lucky and find one with active scanner just throwing a bunch of payloads out there, but you're probably one of a thousand different people that got lucky and find that because it's super easy to find. So, you're almost definitely going to get a duplicate. So, why even look for that? But if you go in and do it manually like this, find reflected input, identify the compensating controls, get the alert to pop from there, and then figure out how you're going to deliver and weaponize it, that's how you can get impact. And then you can start chaining these with other vulnerabilities, and you can start to get things like account takeovers, things like that. And that's where, you know, you go from spraying payloads, getting a bunch of duplicates to finding account takeover, $10,000, $15,000 bugs because you're taking the time to understand the application and you're you're finding those ones that other people just don't go through that effort and so they're never going to get to the point where they can even even get close to it. All right. Okay. Have fun with that. Really hope it's helpful. Let's go ahead and move back over here and let's see what we have found. So, you can see this is running through. I was looking at uh 8 by8, which is a program I've actually tested on before, right? You can see some of the different things here. So, this is a 95 for this one. That's good. It's uh not finding any. Yep. No virtual DOM frameworks. We got a couple custom JavaScript files there. So, you can see with the two custom JavaScript files, bumps it up to a 95. Otherwise, it's with none. It's down to a 70. Um, yeah. And you can see some of these. So, nope. That one has React. That's not a good one. But all of this data is being added into an individual file. So what I'm going to do is I'm going to allow this to run for three or four hours here and I will come back next time I have time to record. Um I'm doing you know bit by bit aside from the the presentation was something that I did on Sunday where I actually had the time. But I'm trying to do this in blocks of like you know 30 45 minutes in the evening go through and edit and stuff to to get it built out. Um so yeah I hope it's helpful. Again, enjoy the lab. Um, when we come back, we will look at the results and we will start actually testing on real bug bounty programs for client side injections, which I'm excited about. Cheers. And we are back. Uh, I had the script running for about 24 hours. Uh, now it's been a couple days since then. I just haven't had time to come back and record record again. But it looks like we've got a lot of results. Uh, so let's go ahead and start looking into them. And once again, as I keep saying, we're going to use this to reach out across all of the different public programs or several of them right now that we've tested on Hacker One. And we are going to identify targets that based on their technology stack and the way they respond to certain HTTP requests um appear to be good targets for testing client side injection, right? And again, if there's one thing you take away from this video, that's something that I want you to take away. But let's see what we've got here. Go ahead and list it out. We can see our results file. that txt file there. So we can do cat XSS targets and let's see what we got. So you can see the output here. We've got the different individual URLs on the left hand side. So these are the targets that we want to look at. And then we have a score in the middle from 0 to 100. That score is based on, as I said before, things like custom JavaScript files, whether or not it has a web application firewall, content security policy, uh does it have a virtual DOM? All of these things come into play. And we can see there's some like this one right here that has a score of 95 out of 100. So that one we can assume is a very very good target for client side injections. Whereas this one down here on Coinbase has a score of 15. So probably going to be much more difficult to find one on those. And you tend to see some some trends as well. Right? A lot of these here 50 5050. So these different uh URLs these different applications are probably all using a very similar technology stack. I think if uh we come up here a little bit, you know, again, you typically see it, right? John Deere, we're seeing a lot of 65. So, you'll start to see some patterns as you look through it. Um, and more importantly, you're going to start to see those patterns as you test across the different technology stacks. You're going to start to figure out what compens uh what compensating controls work, what don't work, what's an expected pattern, what's an unexpected pattern, uh, etc. So, um, and I do have the program in here as well, obviously, so you can go and check that out. So if we look at the bottom one here, you know, this is a score of 95. That's very good. So I would want to go ahead and open this up and let's take a look at the program itself. So this is Simrush. I I have not tested on Simrush, I don't think. If I have, I don't remember any reports I submitted, so it's been a while. But just looking at the metrics is pretty good. We've got response efficiency of 100%. They've been going since October of 2017, which good grief is almost 10 years now, as as wild as that is. But um so they've been doing quite well. Now, we have a wide range of bounties here. It's kind of a mid-range target as far as bounties go, but that's not bad at all, especially if they're uh very generous when it comes to these low bounties, right? If especially if they're giving low bounties for things like compensating controls or something that maybe doesn't have an exact way to weaponize it today, but it always depends, right? Whenever you're working with a new program you haven't worked with before, you always want to submit a report to get an idea of what it's like to work with that team because that's what it is, right? you really are coming together and forming a partnership to to work to resolve these vulnerabilities and uh you know from the researcher side you want to work with companies that that want to work with you and and want your advice and and everything. So um that's how I would probably approach this. But this looks good overall. You know you can see the response 4 hours one day one week. This is all very very good. Um so I'm pretty bullish about this one specifically. Now I do I use the uh hacker one API and go in. So, I don't expect any of the results from the uh find programs or find target script in here to uh be out of scope. Uh it also checks to see if they are live URLs if they're actually responding with the 200 response. So, I wouldn't expect to see a bunch of forbiddens or a bunch of things that are not responding. All that should be taken care of. But I I definitely recommend once you run it, just come in real quick before you really start testing on anything and make sure that the domain is included within the scope. Right? We can see the the one that we're looking at here. That's it, right? seab.io. Yep. So 95. Uh it is a high. So not one of the most critical ones. Although good that it's not the one that's ineligible for bounty there and definitely not included in one of these that's out of scope. So So yeah. Um I don't you know I I do that once I start doing any real active testing. Um we want to make sure that everything we're doing is in scope, but we can go ahead and at least put everything in Burp. Um and uh yeah, again the the script does provide some reliability for that. But just please be careful when you're doing it there. So, uh, I don't know how many results we got. We got a lot. Does it go all the way up? That's a good number. Tell you what, let's see. Let's do word count tac L, which going to show us the number of lies. And we'll do it on our same file there. And it looks like we have a,038 targets. So, that's great. That's a lot of different opportunities for us to go in and test. We'll do automated and manual testing. Although the automated testing I'm again I'm not going to use active scan to throw a bunch of like cross-ite scripting payloads across or anything. And so that's not what I want to do. But I am going to use active scan to look for things like reflected user controlled input very quickly while I'm going through and finding manual targets for that as well. And that'll especially help with finding the reflected user controlled input that might not be as common. Right? Uh now sometimes that ends up being a header and that ends up being a cookie or some of those like attack vectors that we don't expect and in that case we're going to have to figure out how to actually deliver that to a victim. So whether that means getting some way to write a cookie through a JSON or a JavaScript injection, something within the DOM, potentially a CLRF injection to where we can, what you're doing is injecting a uh a basically a new line within the byte stream to trick the application into returning a header that you're inserting as part of a git request or a hash fragment or anything like that. And we can see what that looks like in a little bit. But anyway, got a lot of different opportunities. Um, we will start with going ahead and populating burp here. And I'm going to use bash to do that. So, let's Yeah, let's grab this one here. And I've already got a few written out for this. I'll just come and paste it so we can look through. And we can use this uh bash oneliner to go through. And first of all, it's going to use GP to identify any URLs within our new results file, right? The file in here. So that's going to grab all these. It's also going to grab all the hacker one files, which we don't want. So next, it's going to pipe that into GP. And now it's going to do a reverse GP to pull out anything that does not match this hacker one domain here. Right? So that's going to filter out all the ones here and only leave our individual URLs that we want to send a get request to. And after that's going to set up a while loop while is kind of cut off with the thing there, but that's fine. To read each one of those URLs, pass it to curl and then curl is going to use the tac x command here to pass that through the burpuite proxy at localhost880 and then just check to see right it pass or sends the output to dev null and then it will let you know if it was successful or not. So, this is a very easy way that we can use just a simple bash oneliner to go through, pull all of these URLs out, and then use curl to go and send it through. And this will populate Burp uh with everything. And then we can use all of these URLs once they're populated in Burp to go through and run an actual scan on them. So, let's let it go ahead and start doing that. And immediately, we see our proxy catches it. So, let's turn our proxy off. We come to HTTP history and we'll see them start to go through there. So, it is going to take a little while, right, Curl? Um, oh, we're getting some 302s also, but that's fine. I can continue to do that. Oh, Flowcast came up as well. Flowcast is is my old company. I actually built that program. I think I mentioned that earlier. I know I did earlier. Yeah, you've heard me say that. Sorry. I'll shut up. All right, this is going to take a little bit. In the meantime, uh maybe I should Can we do a new tab here? I always forget how this works. Maybe. Maybe we cannot. Okay, let's just do a a whole new one over here then. That'll be fine. I'm going to bring it over here. While that is running, I'm going to go. Okay. Okay. So, I've got us back in here. I'm going to go ahead and just uh just read this. We can start clicking through them. So, while that script is running in the background to go through and populate burp, I'm going to start clicking into these and I'm specifically going to click into the ones that I think have a really good score on here. Right. And then in this uh get bash, let's maybe just come over here because it doesn't really matter. Um you can just hit control and click it and it will open right up. Now, interesting. That's what happens when you load the Interesting. Okay. So, I can see I probably need to add a little bit more logic so that I make sure that it's an actual DOM and not that. But who knows, we may be able to get something injected in there. So, let's check out this windstream.net. All right. So, here's an actual page stays on windstream.net, right? Uh, so we can do search and as I'm going through, I'm just going to manually start to populate Burp. You can see here that I've got Foxy Proxy running. It is. Let's see. There we go. Now it's running through Burp. That's probably better. Oh. Oh, it's a it's a search. I was like, why is all my stuff coming up? Okay. So, then go back here. So, it's like a you know, I didn't even see the thing. Search the web. I wasn't even paying attention. But, um I just want to make sure. So, we got it going through burp now. So, I'll I'll click on this here. And if we come back over to Burp, we should see Yeah. Yeah. There it goes. There. So now we're starting to populate a little bit more with the actual areas where we know that something's being uh reflected. Right. So we've got a get parameter here. We have user controlled input that's being reflected. We obviously have it several different places within the uh web results here. So already we're starting to see a good target for client side injection for cross-ite scripting, right? So how we would if we could find this, we'd go script dash Ah, and now we have found that we have a web application firewall as well. Okay, so you know what? This is good. We want to go ahead and start getting our notes set up here. So, let me click on this. And this is going to open up. I'll bring this over here so it doesn't clog everything up. And I'm just going to do a Let's get you over there. Get you over here. We're going to get you away. Don't need that. Don't need a terminal. All right, that'll work. Uh, so we will do client side injections part two notes right there. And then I'm going to split this up into two different categories because what we want to do is we want to start identifying attack vectors for cross-sight scripting. Um, so this is one attack vector. we have it in a get parameter where we see it's reflected and then we want to start documenting what the compensating controls are that are going to prevent us from actually being able to get that client side injection and we found one right here. So um first of all to get our target we'll go back here. So, and that actually needs to come down here. And this will be reflected and stored XSS, right? Because that's the first category that we're going to do. And there's going to be another category later on XSS and CSP client side prototype solution. And we will get some going there. Uh, okay. So I want to make sure before we start testing because again we have found our attack vector. The attack vector and attack vector for client side injection is there is user controlled input that is reflected in the DOM somehow whether it is immediately reflected in the server response. whether it's stored in a database and pulled out later. That would be your stored cross-ite scripting. Whether it's reflected or let's just focus on those two for now, right? Because the DOMB based cross-ite scripting is a little bit different. But for here, we're just focusing on user controlled input. So that's coming from an HTTP request that's being reflected. Now remember, if we get this to to uh alert, if we get uh a a if we get JavaScript to execute, we need to figure out how we're going to deliver it to a victim. So we have already found a way. This is our user controlled input. That's our canary. That's our payload. So, if we can get somebody to click, if we can get this to execute, then we can put our payload within the URL and we can deliver it to a victim. We can set up a malicious site that would redirect them over there. There's a lot of things that that we could do. Um, and I still, you know, uh, think it's cool that all this stuff is coming up. I guess it's it's probably just using the same type of thing that uh that Google is, but indexing its own stuff, but um, okay. So, we have found a potential attack vector. I want to go back and I want to confirm that this is within scope. Again, just be cautious. My script should handle it, but you never know. And let's also just look at the thing in general. Uh response efficiency 100%. Now, I'm not seeing uh any bounties on here. So, this may be a program that's more of Yeah, it is right here. A vulnerability disclosure program. So, unfortunately for this one, we are not going to get paid any bounties. However, it's still great to test on these if they have good metrics for response and everything because this can get us once we do find vulnerabilities. It can get us uh invites into private party or private programs and that's where you can really make a lot of your money, right? You want to get get into those private programs that have much less uh testers on there and then you can go in and uh hopefully find parts of that application or domains in that application within scope that nobody else has tested yet. You know, that's that's usually the goal we're getting into. So, still a great target to to start on. Let's come over here to the scope and make sure that there's nothing that we're missing here. So, it is the search. We're definitely within scope there. Let's just make sure in the out of scope. No. Okay. So, we're not seeing anything about the search and I wouldn't expect that because this is the main root domain. So, so yeah. So, this looks good. This looks like a good target. We'll go ahead and minimize that there and we can get BU brought back up. That's totally fine. and still running through each of those. And we'll come back here. Okay. So, we have that. Now, again, we want to start probing. Let me just bring this over. It's going to be easier. We we want to start probing for the different compensating controls. Okay. So, we already did that once. We came up here. We'll grab the Q. By the way, Q is a very common parameter for for searching there. And we're going to do script alert one/cript like I did before. We will run that. And we get blocked here. And this is a Cloudflare um WF web application firewall. So let's come up here. W I don't know. I don't have any specific uh format for my notes if you can't tell. I just kind of make them up as I go. So, web application firewall. Yes. Cloudflare. And then under here, we want to show what is triggering it. So, let's see if we can figure out what this hits and what it doesn't. So, let's get rid of the script tags. Come on. And it allows it to go through. So, We'll say that removing script tags equals no block. What about an open and a close right there? That's fine as well. Okay. So, it is not checking for the open or close. It's not checking for alert. I'm guessing it's checking for some actual payloads in here. Let's just try let's try just one script tag. See how that works. Okay, that one's blocking. What if it's there's a plus in the middle? Still blocking it. and uh you know Cloudflare as well there's a lot of known blocks so we can look for w bypasses with that will be the next step but I'm kind of just trying to probe because they can go in and manually configure this based on some certain things I'm hoping that they have use cases where special characters need to get through to where we can potentially you know break that what if this is what if it's got a U in the middle okay so this as well it really looks like it's just looking for a script tag. Um, I'm not going to do this all day, by the way. You just want to probe. We're starting to get an idea. Again, we got so many different targets. We don't want to get bogged down. We're just starting to kind of dip our toe in the waters and all these different things, all these different uh programs, and we'll we'll start to see the patterns. We'll start to see the ones we want to dig into further, etc. So, um, let's just maybe one other thing here. Let's see how it likes an image tag. Let's get rid of all the rest of this and let's just do an actual image tag. Just do something like that. Super simple. Okay. So, it is all right with that. Image source equals that uh on error equals or one. Let's see if it's picking up that pattern. Okay. And it is picking up that pattern. So, come here. I'm just going to grab this. That's probably all the context that I need right now. But we can see it's not checking for like if it was blocking on just including an open uh open tag close tag, right? Greater than, less than, whatever you want to call it. Then that's going to make it much more difficult to to circumvent, but it's also really hard to to do that. This I actually kind of expected to block and it didn't. um you know cuz it's just why would you need to send a full HTML element even if it's not a real element but anyway so it it looks like there's some daylight within that compensating control but obviously this is going to have a big impact on our ability to actually get those payloads through. So let's come back here where we have everything working and let's see if we can probe for some other compensating controls. Let's let's go back to script just to check some client side validation. No, that's fine right there. Uh, all right. How about because we know we can send these. Let's just see if we are getting output encoding. Oops. We'll just focus on this one right here first of all. So, it doesn't appear that we're getting any output encoding. Let's just do this. Let's come up here. I'm going to go arson right there. We'll click that. And I want to check within burp sweep because as we saw before, can I get back in there in time? Grab it. Grab it. Okay. Send this to repeater. Go ahead and send that through. Let's search for our arson Canary, which actually is popping up. Okay, we've got this coming in a lot of different places. So, output encoding. Yes, at least in some places. So, we have the title right here. I want to turn this into a oneliner. We don't need all that extra white space. There we go. Okay, we'll keep clicking through these here. Ah, and here, this is great. So, you can see we've got some different types of output encoding here. We've got it coming through the HTML and this session payload. So, the session ID is written in the DOM. That's when we're talking about weaponizing. Again, I assume this session ID and I'm not logged in, so we need to find out if you know if it even makes sense to log in. And that's something we'll check in a little bit. But the output encoding is definitely very different here, which I would assume is so that we can't break out of this uh JSON because what we would need to do the only character that would work in this case is a double quote. We would have to find a way to inject a double quote. Now the unic code coming in here is is interesting. Um so that is you know obviously before it's being sent back that is the output encoding where it's converting those to those unic code characters. I'm just going to grab this in general. I think you know, let's just drop this off. That'll be fine. Okay. And that's all just one thing there. Uh, good. Okay. So, we're seeing some output encoding, but they're they're different. And I definitely don't think what we're seeing is uh do I have walizer on here? No, I don't think we do. See if React is mentioned in here. Uh that's not what I was thinking. This looks like something that's coming from the from the actual results or something. I don't know. But yeah, I don't think this has it's not looking like a virtual DOM at all. Let's come back over here to Burpswuite and see. Oh my gosh. Okay, let's make this bigger. See, go work. Uh, where we at? Where we at? Made me lose it. Ah. Oh, and then here. Huh? Was that our session ID that we just grabbed? Where's our notes? No, no, no. It's not. Okay. I was going to say that'd be pretty wild. I don't know what this SC parameter is here, but we can see another output encoding where this is being embedded into other URLs that are being that can be used. Yeah. And then we've got the the hex encoding here. So that may be it's actually very difficult to do that or to break out of this if it's coming from a get parameter, but we'll mark that as output encoding as well. Let's just get the whole href here. Copy that. I'll probably have to leave this open. Just keep opening it up here. All right, let's keep going. So, we've got a bunch of different output encoding. And this is great because this gives us an opportunity to try a lot of different ways to circumvent this output encoding. We got three different ones right off the bat. So, maybe something won't work to circumvent this or this, but maybe I can break out of this one here. Right? So, it's there's a lot of complexity here for their security team to deal with. this is very very challenging to come in and you know make sure that the output encoding for all these different use cases all these different types of encoding is going to prevent uh a working cross-sight scripting or working client side injection. So this is certainly the type thing that I want to see. So the the second target that we looked at the first one that we're actually digging into is already one that is getting me very uh excited considering we're looking for client side injections. Let's keep going down see what the other ones are. We'll have a lot of these here. more HTML encoding. Now, this where is this coming from in the actual thing. I don't know if this is actually from that there. That's that's one problem with doing the search where it's pulling it back. I don't know if this is actually being reflected. I kind of don't think it is because if it is, it would mean that it's stripping these off and that's going to be a um let's do this. that would be a uh serverside validation instead. So I want to just do a completely random canary that I know is not going to be there. Copy. This shouldn't give us any search results or anything like that. Let's do this. And now let's see where just this completely random piece is. That's the input. So this is going to be that search form on the top. And we can see it's being added in in the value. So let's actually grab this one as well. This is good to know for our notes. Although I would say this is going to be the most thoroughly tested attack vector that there is. Anytime there's a search engine or any search that goes through and that search result is reflected as the value in the the actual search bar, this is like the number one place that people test. So I never expect to find anything here. I will just add it for the sake of it. Let's see. Did I copy that? I did. And then I just want to put in parenthesis here search bar at top so that I know that. All right, let's go back to trying to figure out whether or not that was a uh something from search results or something that was actually being written there. Now this okay so we're in between an HTML tag here. Uh we are again seeing the output encoding, but this is a really really great attack vector 2 because we're out in the open. So if we can find a way to circumvent this output encoding and actually get a greater than less than to to be written in there, then we could have a lot of opportunity. So I definitely like to see that. Let's come and add that to our notes as well. All of these are telling me showing me and telling me that this is going to be a good target to do some thorough testing. And because they don't actually pay bounties, there's probably not a as much testing as there would be if it was one that actually paid very good bounties. So again, we can do that. Focus on those programs that don't pay bounties. Get a couple valid submissions. That'll get you invites to private programs. That'll get you a much higher chance of being able to actually find uh or get get a higher bounty, especially if you're getting started. I would definitely focus on those. So without the arson in the search results, we got nine different ones for this very unique canary. And I think that's a good start. I'm not seeing any evidence of server side validation right now, but that certainly doesn't mean that it's not there. Um, but it definitely looks like output encoding is one of the main things that they're relying on. And let's also take a look at their content security policy, which I'm not seeing one at all, unless it's written in a a metadata here. Anything CSP? I don't believe they have a content security policy. I need to poke around a little more cuz again content security policy can be in two different places. It can be in a server response or it can be in written into the HTML in a a meta tag there. So, but I'm not seeing that. Let's just I'd say yeah, don't see one now. And there's no headers in response to search. So, we'll just kind of keep that as a note temporarily. And what I can do as well, let's bring this back up. Let's come over in the console and oh well, there's definitely a content security policy because there's we've got a refer policy which I think is set with a content security policy. Again, there's so many different directives. I might be missing that, but I'm fairly confident that's what that is. We can test that out in just a little bit. That's the only one that I'm seeing, though. Let's try just doing fetch google.com. Okay, so we do have a content security policy there. Well, oh, uh, we're getting a Coors error. So, yeah. Yeah. No, sorry. This is not a content security policy. This is a course error because that one uh Google was not giving an actual course response. So that's fine. So I don't think I am seeing that. Let's just try see if we can see a few more of these meta ones here as a final test. But I'm not seeing an actual content security policy pulled in here as or pulled in here at all. Yeah. So, right now I'm going to consider this a really good target and for all the reasons that we've talked about, right? It's it's um output encoding looks like the main thing that we need to circumvent here. Uh as well as the web application firewall. So, we'll put a pin in this. Um there could be a content security policy on certain places that I'm missing. Um I need to do a little bit of, you know, poking around there because sometimes it can hide within the DOM. Sometimes it can pick up uh ones from from other pages that are loaded. So, it it just depends. But it looks like we've got no content security policy. We've got a very complex output encoding. So every single one of these is going to require different logic, especially when we start trying to circumvent it. So we might be able to find a crack there. We can also look for known ways to bypass Cloudflare WS because that happens all the time. This is where a lot of times people will find a way to bypass Cloudflare and they'll just sit on it for a while and they'll be able to like circumvent it when nobody else can and you'll you'll be able to clean up for a little while until it uh eventually obviously Cloudflare is going to recognize this when they're doing their research and then they'll put that block in and probably submit it out but takes a little while there. So this is a pretty good target. This is a pretty good target. Let's uh let's come down. I'll save this. Let's see how our first script is running. And it looks like that's done. So, we should have everything populated in Burp. And we have the other ones here. So, let's let's maybe find one more to do manually and then we'll get some stuff running in Burp. We have the 95 there. Let's find another one that has a good high number here. We got some 50s, some 60s. I see an 85. There you go. 85. Starbucks. Starbucks got an 85 there. So, let's click on this one first. Is this the Starbucks? No, this is not the Starbucks program. Hold on. Starbucks. That can't be right. Or maybe it is. It is interesting. What is this? So, headquartered in Kuwait, the Ala Group. Um, I apologize sincerely. I I know I'm saying that wrong. Is a leading international franchise operator for some of the world's most recognized retail brands. Okay, so this this Starbucks I got worried. I was like, "Oh, no. I something screwed up with my script, but it's not this this Starbucks Target." So, this is a uh basically a conglomerate based out of Kuwait that it looks like they specialize in building up franchises. And so, they must have ownership of this Starbucks.az domain here. So, and that one's showing up as an 85. Let's take a look. Now, is it just a a regular Starbucks page? No, no, no, no. This is a completely different technology stack. Here you go. So, it does have React on the front and Nex.js. So, both of those are going to impact our ability to do that. Um, of course, uh, platform as a service. So, it they must have it actually hosted within uh, Verscell, which Verscell is the company that that creates and maintains Nex.js. JS there. Um, so the React is going to make it a little bit more difficult. Let's see. Do we have good attack vectors here? Not seeing a lot of places for us to put in user controlled input either. This page looks like it's doing more of just showing us information. Do have an email address there. That's not a Might have to do some translation here, too. Showing us some stuff. Okay. So, I don't know how great this one looks. Let's maybe move on from this right now. I may come back to it. Let's see. We got a 95 up here. Let's take a look at the program first. And that was this one here. Just so we can go ahead and open it. ResMed provides obstructive sleep apnea, snoring solutions, obstructive sleep apnea, snoring solutions, hypertension, and repository care. So, this is medical, right? So, immediately when I see anything that has to do with medical, I start thinking of HIPPA. When you uh for anybody who doesn't know, HIPPA, um crap, I'm going to forget what it stands for. uh health insurance privacy uh act something HIAA um gosh I really should know that I you know if the camera went on I'm sure I'd be able to say it I'm going to remember it right when I you know right when I start doing something else but uh so in America if a company stores what's called uh PHI personal health information so somewhere you've heard PII personal uh personally identif identifiable information which is sensitive data for their users. PHI health information is even more sensitive and any organization that stores PHI falls under the regulations that were established with HIPPA. So what that means is and HIPPA is interesting. HIPPA is not like PCI, the payment card, PCIDSS, the payment payment card industry. Um, uh, the the regulation that they have to make sure that your credit card information stays secure and hold the company accountable. For PCIDSS, there's that's a compliance that you have to proactively go through and do things like penetration test and everything. You have to get certified, your environment certified for PCIDSS. HIPPA is different. HIPPA is reactive where there's nothing that you necessarily have to do before something happens. Um there's certainly a lot of guidance that you need to be doing these things, but ultimately what you do before uh an instance where personal health information, PHI, is compromised determines whether or not the company is liable. It depends on or determines whether or not they they perform what's called due diligence and due care. And if the company is found to have uh not gone through the proper due diligence due care, if they're found to be negligent and they were the target of a cyber attack that resulted in the loss of personal health information, the fines for that loss of personal health information are going to be much greater. So if a company is is uh the subject of a cyber attack that includes personal health information or PHI, they are definitely going to be subject to fines from the government. And the amount of those fines, and it varies greatly, is going to be determined based on whether or not they're found to have done what they needed to do to secure it. Right? If they did everything that they possibly could, and it was still compromised, those fines are going to be much much less than if I mean, one of my favorite case studies was uh didn't even involve anything with technology. uh a uh a company had all paper files and they were transporting the paper files from one location to the other on the back of a pickup truck in cardboard boxes and while the individual was driving them from one place to another they didn't realize that the boxes had come open and they were just littering this uh patient records and paper documents all over the place and whim was catching them flying them all over the place. The the really crazy thing about HIPPA is you get fined for every individual PHI record that's lost. So, as they had all of their records in the back of this pickup truck and it sprayed across an interstate and everything for miles and miles, they had to go back and try and collect those because everyone that they couldn't find was going to be a fine from the government. So again, when you're going in to explain the impact, when you're talking about how you're going to weaponize this against their users, now you can start to explain to them, hey, here's how I'm going to target the personal health information and here are the consequences of that and how you could potentially be found uh, you know, where where you didn't have due care and everything. I mean, look, don't try and scare them. Don't you don't want to write those big things or have uh chat GBT turn out like an AI slop that's a bunch of stuff that don't try and scare them, but but it is a reality. And if you highlight that reality and if you focus on getting that PHI and showing how you can get the PHI in your your attack, then you're going to have a much easier time demonstrating to that company how your attack has impact and they're going to be more likely to want to remediate it to resolve it. Right? So medical always good. Didn't mean that to be a tangent, but it kind of turned out to be one. Anyway, let's come over to scope. I forgot what the URL was. Uh resupply.restmed.com. So restmed I think is their main one. Here we go. Now, it is ineligible for bounty. Oh, and this is a VDP anyway. I we already talked about that. That's right. Um, so yeah, again, this is a good one that we can go and take a look as well. It is within the uh the scope here. We have AWS and C#.NET, which by the way, C#.NET does tend to be uh good targets for cross-ite scripting and client side injection. Just the technology stack. There's, you know, with with JavaScript, um, you know, JavaScript based applications, stuff, different types of frameworks, some of them are are they just handle user controlled input in a different way. And in my experience, the C#.NET, there's a lot more manual process to filter those out, whereas some of the technology stacks kind of have it built in. So, this all seems like a great target for me. I really like that. We can come over here, uh, and we see here we have, uh, a login page as well. Now, the question is, are there a lot of other targets within this that we could potentially use to to have user controlled input? Is it just going to be here? But this is definitely one that we can start to to take a look at. So, let's just kind of do arson arson. We'll send that through. Of course, it's going to tell us that that's invalid. And if we come over here, we can see what was actually submitted. Are we going up or down? We're going up. Okay. So, we have a post request. Not seeing any get parameters right now coming through there. So, I think what I'm going to do, I'm just going to copy this URL for now. And we can bring our notes back up. I want to have this one be another target. So, we know it's got authentication. So, we know it's a good target there. Let's kind of save that. And I do not see a content security policy coming back. Do we only have those three metatags right there? No, we have six, but none of these viewport setting the character set. None of these appear to be a content security policy. So, yeah, I do not see a content security policy on this as well. So, if we can find a way to get a client side injection, it's going to be very easy for us to exfiltrate their um their data. And actually, let's um let's get this brought back up. Let's get web hook.site site on here. Again, I'm not seeing a content security policy at all. This one seems like it's a little easier to check compared to the other ones. But let's come up here. Let's go to inspect because that is going to have cores set. So, we're not going to get that same course error. So, let's do another fetch and let's fetch that. Oh, does not have course configured. I may have to set up something to actually do a course there so we won't keep getting that. But the content security policy would have blocked it at least if it prevented us from sending requests outside of that. So, um yeah, not seeing a content security policy. We do have authentication. Uh we can try and test some client side injection here. Let's just see what it does when we try and do this. Not seeing any client side or injection client side validation. Not seeing any of that. Um, let's also see I cannot type anymore. You know, a big part of my job lately has been a lot more process driven and uh ah okay, so we do have a W. Yes. Although I don't really know what kind this is. This looks like maybe something custom. Let me see what actually happened here. Is this the block? Yeah, you've been blocked. I mean, this looks like what you would typically get from a Cloudflare or a CloudFront ID, but it's I mean, it's just a a a gooid basically. So, I don't know if that actually has anything to do with it. Could be a custom one. Uh yeah, looks like they have a custom response. Uh now that could be just a known web application firewall, but they don't want you to know what the technology is. This is interesting. So, let's do this. Let's copy this. come back over here to Firefox and okay so we see immediately F5 results coming up. F5 is a web application firewall. So that tells me that what we are dealing with here is a F5 web application firewall. We'll just do that right there. That'll be fine. So once again, we do have a web application firewall that we're going to have to circumvent when we do that. Uh we have authentication, etc. Not seeing content security policy server side validation. It's kind of hard to see. And let me just come back over here, open up the full thing, and let's see if it lets me do this. Okay, it does. And then what I want to see over here is do we have any output encoding? Yep. So we do have some output encoding. Let's move you over here. You right here. And we'll bring these up. That looks like the only place. So the only place that it's being reflected is in the value of the input right there. Is that okay? That's just the way that it's populating there. So we do have a little bit of output encoding. It's fairly basic one. Let's see. So the only thing that we would really be able to do there, we need to break out of it first. So let's just do a double quote and see if it lets me do this. Okay. And we can see that's being output in code as well. So let's grab that instead. So it has that because we would need the double quote in order to be able to to break out of that right there. So let's do this. Be fine there. And that gives us some basic information, you know, so you can start to see. I mean, I'm going to do this for a while as I'm starting to do it. you know, we're going to start to dig in, find the the targets that are going to be potentially basically worth our time. That's what we're always looking at, right? Bug bounty hunting is always an Easter egg hunt. There's always a percentage of chance that you're going to find something. And what we want to do is use our techniques and our skill and learning a bunch of different types of attacks and understanding the compensating controls. All of that is going to give us a greater chance of finding those Easter eggs, right? But it's there's always a big component of luck in this as well of just kind of stumbling across a part of an application that somebody hasn't done thorough testing on yet. You know, whether it's a new functionality within the application or it's a piece that's difficult to find, doesn't really matter. But yeah, we're always trying to kind of tip the scales in our favor. So, let me go ahead and open up Burp fully here. And we now have several different targets that are populated through here. So, what I'm going to do, and I don't want to do all of them. There's actually quite a bit of them here, but I'm going to grab a block of these. So, let's just say that up to here. I think you can shift and click, can't you? No, apparently not. Oh, I was hitting caps lock. Good grief. All right, we're just going to grab a section of these. And what I want to do is go ahead and get some automated scanning going as well. So, yeah, about 108. I usually try to get about 100, give or take, uh, on every scan. You don't want to do too much, but we'll come in here and hit scan. We will do a crawl and an audit. So, we'll see if it'll come in and be able to crawl any of those. And for the scan itself, we don't need to do any super specific scan details right now. We could just kind of go through it. But we are going to do a custom configuration. I'm actually going to create a new one here. So, um, the crawling is fine. We can use in fact let's go ahead and just select from the library for the crawling we're going to do crawl strategy more complete not most complete but that'll be fine and then we also want to make sure that it doesn't stop the crawl due to application errors and we don't want to stop the audit due to that as well although actually I could just include that within here so let's do a new one for auditing and we're going to call this reflected input for our demo and we'll set up a few things here. So, the speed we can leave it as fast or I mean as normal. That'll be fine. Uh I do want to minimize false negatives. So, that's going to give us the greater chance. Um I'd rather have several false positives that I can rule out as opposed to just completely missing any of them uh as a result there. And I just have the luxury of time. You know, in an enterprise environment, you might go the opposite direction there. Um we're not going to put a maximum time in there. I think all of those are fine as well. Yeah, that'll be good. Now for the individual issues. So we're going to select individual ones and we're going to come down and just very quickly highlight everything within here and we will disable these. So right click, click on enable. And now we have no scan checks that are selected. So now we'll open this up and I'm just going to look for reflected. See what we have. Now, you obviously have all these in here that are already going to test to see if uh there's an actual injection in there. I'm going to start by just looking for input reflected in the response. So, this is just going to be anformational finding. I also want to do suspicious input transformation because that is going to tell me if I can potentially circumvent some of the output encoding. This is going to find instances where we are submitting characters that are already encoded and they are being reflected without that encoding. So, this is something that can potentially help us find something there. I don't know if we want to do anything else. Um, open redirect is great if we need to circumvent a content security policy. We haven't seen a content security policy on anything yet. Um, so we're not going to play with that. Remember, I said if you're doing a client side injection through the cookie, you may need to do cookie manipulation first to do it. So, that's what we would test. So, we're going to we'll come back to these. We're going to keep doing more and more, but right now I really just want to focus on link manipulation. Maybe I think these two are fine. Yeah, because I just want to know where user controlled input is being reflected. As simple as that. And then those are the ones that we can go and we can test further. Now these DOM based especially we'll do a lot more in the scanning when we get to the second section where we're doing the DOMB based cross-ite scripting and the uh client side prototype pollution. But for now, this is a good start. Uh, so now I'm going to set this and we're going to put 9999. So if we have almost 10,000 failures, then we are definitely going to do that. Otherwise, we're not going to pause it. I'll do the same thing there. And make sure we're doing every insertion type. We don't really need to modify those, especially not for this. Uh, that's all fine. just ones we know we want to ignore. That's fine as well. And then for JavaScript analysis, I want to bump this up to 60 just in case it takes a little longer to do that. And I do want to do some static analysis techniques as well as part of that. We don't need to touch that there. So, all right. Finally, I'm going to go ahead and save to the library. And that will give us our reflected input scan there. So, uh we won't do a a login and I'll go ahead and keep the default default resource pool. So, I think that is going to be fine. Let's go ahead and hit scan. Why is it kicking it back? Oh, so it's not doing Okay, shoot. Um, so this happens. At least that's been saved in there. So, uh, if you select too many different individual URLs, then when you come in here and look at the scan details, and I just wasn't paying attention to missed this before, it doesn't actually populate with it. So, if the the list is longer than kind of what it expects or there's obviously barrier there, then it'll kick that back. So, let's just cancel this here and we'll do a smaller group. I think we probably just went like right over the the limit there. Let's just try that much. Oh, we're still not finding it. There must be some of these with a lot of individual URLs cuz what it's actually going to pick up is all of these under here as well. I wasn't expecting there to be a lot, but there must be some here that have quite a lot already enumerated under it. There's probably like a WordPress site or something there. So, let's just grab a much smaller number. Hit scan here. We're still not seeing it. So, it must be one that's up there. Let's try this. Let's see if it'll let me do this. Okay, it's good there. Oh, yeah. There's way more. Yeah. Oh, yeah. Yeah. Okay. So, some of these do have a lot more endpoints and URLs than I was expecting, but that's fine, right? If we got to go through and do it a few times, you can. That's no problem at all. Um, for our scan configuration, again, we're going to come back. Select from library. Never stop. Ah, we already did that one. That's built into our other one. Uh, never stop the crawl due to application errors. Call strategy most complete. You can see where they were used before. And then we should have our reflected input demo right there as well because we saved it to the library. Again, application log or login. We're going to skip that right now. We're going to use the default resource pool. That should be fine. And we are now going to scan all of those there. So now when we hit scan, that's going to go. All right. Always love to include things that uh are not correct in there because that shows you what to do when it happens. And uh look, happens to me all the time. Especially I think as you can tell, I'm a little rusty. you know, I've been uh very very busy with other things, building the the framework and a lot of stuff with my day job. Uh which, you know, frankly, is is quite a challenging job. So, uh I haven't had as much time as I wanted to do bug bounty hunting lately, but I'm hoping that's going to change a lot more now that the framework is is in a good place and I should have an update coming uh mid November for that as well. I got some good stuff planned with it. Been using it a lot since Defcon and uh you have a lot of good ideas for things that I want to have in there. Um and then the community has given some great feedback as well, right? the discussions, the issues. I've gotten all kinds of good stuff. So, a lot of updates coming to the framework here pretty soon. But, all right, we're going to let that run and I will come back a little later and we'll see what results we have. We'll keep going through a few more manual ones and then we're going to start actually trying to test and see if we can't get some alerts to pop on these. So, um, and whether we can or not, right, like we're obviously not going to find an actual cross-ite scripting within this video. If I did find it, I wouldn't show it because I'm not allowed to or at least I would report it, make sure it was remediated first, then this video would take another probably 2, three months to come out. I don't want to do that either. So, but what I am going to show is ways that you can go in and test the different compensating controls like we were looking with the content security policy. We'll do a lot of stuff in the console. Um, yeah, give you everything you need so that uh you'll be able to test there and if I do find something, maybe I'll kind of hint at it and yeah, we'll go from there. But anyway, uh you'll see a cut and I'll come back with the results of the scan. All right, we're back. I have some fresh tea, which going to help with a little bit of caffeine here once it h cools down. And now this uh the scan hasn't been running for too long. I only left it going for about I think an hour and a half, maybe two hours here. But uh so you can see there's only a little bit of it that's gone. We'll let it keep running in the background there. But really, I only want to find one or two more because, you know, we got a couple of good reflected cross-sight scripting targets already. Um so we'll look through these. I want to show you know how we can identify attack vectors through the automated scanning as well. I'm sure later we'll have this find a lot more. Uh but once that's done, I'm going to move on to looking for stored cross-ite scripting as well. So we'll find a couple attack vectors there and then we're going to dig into each one of the attack vectors, get a lot more information about the compensating controls, uh and start to dig in and see if we can get closer to actually popping an alert and then you know again figuring out how we can weaponize it, testing out the content security policy and all those things if it has it. Um, you can see here we have 12 differentformational findings so far from the scan that we set up and it's mostly input reflected in the response. We have this one that's an interesting response. So now some of these like this one right here is not going to be within scope. You know, this looks like some type of uh marketing ad tracker domain that was picked up as part of the crawl. So we want to make sure we're not including those. So we're once we, you know, go in and test each one of these, we also want to go back to our our list of targets and make sure that those targets are in the list. You know, make sure that it hasn't come up through the the crawling to where it's not actually part of the scope here. So let's look at this one, which is 1688.com. Now, I am not familiar with this or know what it is, but we can find out. I'm just kind of looking at what the insertion point is there, too, to make sure that it's actually worth our time. But let's do this. So, we're going to c this again. So, we can print everything out in there. But, we will grap what was it? 1688 right there. And we do find it. Okay. And this is Oh, Alibaba. Sure. Sure. Yeah. So, we click on that there. This should go ahead and open up. Let's make sure that everything's within scope. Oh, this does pay bounties as well. Okay. Not uh Wow, they paid out a good amount of bounties. Alibaba, if I remember correctly, is I think uh an Amazon or I mean a a version of Amazon that's in China. I I think um we could do some research to find out. Not that it makes a huge difference there, but uh and then just to make sure that it is in scope as we said. Okay. Now, this is medium. Okay. So, once again, if we do find something, we're probably not going to get a huge bounty. However, this is probably not going to be as thoroughly tested. So, good and bad side there. So, let's go ahead and minimize this and let's see exactly what it found. Now, first of all, I'm always looking at where is that payload. So, it's coming up in a URL parameter. That means that we're going to be able to deliver it to our victim, right? So, this is worth our time. It's within the scope. It is, you know, it was identified in our testing uh public program here. And the value that we see returned is being reflected in the location here. So it's not being reflected in the DOM. Okay. So as it stands right now, we are not going to be able to use this to execute a cross-ite scripting. However, we don't know where that redirect goes and whether or not that's carried over. So let's send this to the repeater. Let's go and send this to make sure that we're still seeing the same thing. I'm going to change this to my canary which is going to be arson. And we want to make sure that we're doing this here. So, and it is good to know as well that any parameters that we put in are going to be passed on. It looks like the value is going to be passed on as well. So, if we do that, we should have arson equals arson. We do. Uh, okay. So, let's follow this redirection now. And now we end up on a git request. Okay. So unfortunately we see that our get parameters were not carried over from that redirect and we don't see anything coming from here. So at least through this get parameter we are not going to be able to inject anything into this DOM. Um, now because we can get control of the location, we could potentially test for CLRF, right? Which actually, let's just do CLRF uh injection. Let's kind of bring up something from OASP here. See if it'll give us a little more information just to help out. I kind of hoped it had like more visuals and everything, but you can see here, right? So, uh, carriage return, right? slash R and then or back slash R and then back slashn right here. The line feed. This is um there's these characters at the end of every single line within this HTTP request. If you haven't heard me go through the spiel, an HTTP request, even though it looks like a series of lines, it's actually a bite stream, right? These are all just one stream of code that goes along. And the way that the server separates each one of these lines is by looking for these uh carriage return line feed characters that are hidden, you know, and you can actually where did they put it in burp? Here we go. There you you click on that and you can actually see. So this is showing all of the raw bytes that are in here. So the one thing that we might be able to potentially do here is if we can inject the uh carriers return and the line feed in a way that would cause this server to read anything after those as part of the DOM down here. That's but it's very unlikely but we can give it a shot. Right. So so it's this one right here. So, let's try and do that in there. And then we will do let's just do an arson tag or even bold arson/bold. And then who knows, maybe something will pop up. We we may hit a laugh uh before that. That's why I was kind of looking for something more simple. But let's see what happens when we send this. Okay. And now we can see that those characters are not actually being processed. Now we can do several different encodings and things. we can do it, but that's a lot of additional testing and I don't know uh if that's really going to pay off. It's very rare that you could take this. A lot of times you could inject another header and maybe that'll help, right? Maybe we could inject another location and have it go to our malicious server and execute JavaScript there. That's a different type of attack. But for this one here, I don't see a lot of value in that. So, we're going to go ahead and move on from that. We still keep finding these here. This is uh so the way that the uh input reflecting the response works and you can kind of see that happening over here is it will first check to see if uh anything is reflected at all or if there's any parameters and then if it does find something it will do some additional tests um and it also does test for extensions and so these are coming from the extensions here. So even when you're running this you may see some different uh different results outside of just the input reflected in the response. again, it just it does some additional things. It's not gonna not gonna mess anything up that you're doing. So, let's come back over to the issues and all right. So, I want to skip these. I'm going to skip past that. I don't know about this. This looks like a a a Firefox thing. But let's just see. Let me copy this. Come back over here. And we're going to grab that instead. Okay. So yeah, it's it is part of part of Firefox here, although it's part of their bug bounty program. So public bug. Wow, they have a really good one. I haven't actually tested on theirs here. This is interesting. This would be a fun one. Okay. And then I don't know if this would be considered a critical or core site. Probably a core. Probably not a critical, but let's see. And this was some.org. A L L I Z O M. Let's see if we can't find that. Okay. So, uh the ad routing service. Oh, it's a critical site. Okay. So, this is going to be one of the it's going to be in the higher bounties because it's a critical site and that does include what was the one crash stats. I don't see that listed here. Let's see. Okay, here we go. Analytic site for all crash data test to be done on the staging instance only, which is crashed. So, that is the instance that we're testing. Good job. My script did sort that out. There has been one report that submitted, but it hasn't been resolved. It's listed under critical. So, okay. So, these are valid targets. So, let's see what we are finding. Um, oh, go back to Burpswuite there. There we go. And this is coming from this here, I think. Right. Okay. All right. So, let's go ahead send this to the repeater. That does look like a valid one. And this probably the same thing. Yeah. So, it looks like there's a login link and any parameters. Ah, so the path is copied over there. Okay. This is an interesting one. This is an interesting let's let's come over here again and let's just go don't run equals arson. Why not? And then we want to search for arson over there as we said. Okay. Now we're immediately seeing HTML or not HTML uh hex encoding there you know. So that can make it very difficult to break out. we are within this href here, which again we're we're going to have to inject a double quote in order to do that. So I'm, you know, fairly positive that once we send this, we're going to see a percent 22 on the other end. Oh, so a 400 bad request. I It could be something that's blocking it. What's that 1.1 varnish? That's still there. Uh, so this could be just an error. What happens if we do it again? Maybe it's the don't run that's screwing it up. I'll tell you what, let's do that. And arson equals arson. Let's see if we can just throw in another. Okay. All right. So, the don't run having Okay. Okay. So, having double quotes on the don't run parameter is causing a 400 response. It doesn't look like it's a block necessarily. It just seems like something's going wrong. So, that to me, and I don't want to go down a whole rabbit hole here, but that to me says there's a potential for a serverside injection. And that's a whole other video that I need to do about bounty hunting for serverside injections. But ultimately, what you want to do there is you want to break the application. You want to find out why it broke. And then you want to see if you can weaponize the reason that it's breaking. So, it seems that if we include a double quote here, then it breaks. So, what I would do to continue testing is try several different characters and see if I could get it to include a double quote, but somehow a combination of characters here after that uh will cause it to not break essentially and maybe that'll carry over. So, there's definitely something here. Let's see what happens. Okay, so send this. We don't have 200 now. Give me a double quote at the end of there. Do we still get We still get the 400 there. So, this tells me that it's maybe a 400 with the reverse proxy. I'm not familiar with this. Ah, potentially webc poisoning here as well. Looks like this is listed in somewhere. Oh, this is very Oh, okay. I talked earlier about uh cross- sight scripting combined with cache poisoning. And this is exactly what it's talking about. So, you go there, you find a way so that you can inject it. Man, I wonder if this X forwarded host is being used. Maybe that's something specific with it. I wonder why that's So that's specifically to do with cache. That 1.1 varnish must be something specifically to do with the cache. I don't know what exactly Oh, that's what it is. How to use varnish cache. That's what it is. All right. I haven't uh I haven't used that before myself, but okay, that could be fun. Just out of curiosity before we break it again, I just want to go x forwarded host. Uh, and then we'll do arson security.com. Let's just see what happens. Oo, let's show this response in the browser. Copy it. Bring this up here. I want to see what's going on here. Okay, so we have some stuff going on. I'm actually I'm going to put a pin in this. I want to cop this URL. We are going to record this. This is going to be probably a little more than I wanted to get into where we talk about doing, you know, potentially cash poisoning and everything. Maybe if we have time at the end, we'll come back. We'll at least poke around and play with it a little bit. Uh, all right. So, this is going to be a little bit different. Um, what do I even want to put in here? So, possible cash poisoning 400 response with uh, we got to make sure I know that it's that right there with a double quote uh, in par in get parameter value. And what is the other what's this response here? Is it still still a 400, but we get a whole DOM to go to go with it. So 400 response plus DOM with uh I'll just copy this over our X forwarded host here. Okay. uh all get parameters reflected in location. Is that right? I guess it's right. I'm losing my mind. Uh all get parameters located in the location header. And then also uh get parameters not reflected in final DOM after redirect which that location header that's literally all that it does there. So um yeah interesting one. This is probably a little deeper than we good grief it's finding a whole bunch of those things there that these are almost always false positives by the way. Um they just look for any type of a variation with certain characters in it. A lot of times you'll hit a W or something else. All right, let's see what else we have here. Here we have the path and it's going to a not found. We have uh X errors. We have another opportunity here for potentially doing a uh return carriage line feed. That looks like the only place that it's being done there. So uh worth it to test real quick. Come over here. Let's just try. Let's see how it handles that. Unsupported characters and path still unsupported. Okay. So, I assume those Yeah. So, yeah, it's not going to like that. It's not going to let us do it. Okay. Worth a shot. Worth a shot. Worth a shot. Um, here's another one here. Ah, so here's a place where we can potentially control a cookie value. Are we getting that reflected anywhere else? No, I guess not. Let's try this one. That looks like the hex value of the backslash there. Um, and we do see that reflected. Okay. So, whatever is in next. Yeah. And this is part of next.js. So, at a certain point, we're just doing uh security research. Although, if they haven't implemented it correctly, that's a different conversation. Let's see if it's going to let me do a semicolon. Okay, so we're getting a hex encoding. So my my goal was potentially we can come in here and then we could set additional cookies. Um yeah, but I'm not seeing that there. And the only match is up there. So okay, we can lose that. There's definitely opportunities here, but not anything that that I'm too excited about right now. What about this? Here's a reflection. And we got a PHP and uh and we are reflecting in the DOM. Now we're reflecting in the value. This is a hidden weird. What is the point of this? Some repeater. What's going on here? Let me decode this. I got to be a B 64, right? I would think. Let's do this. Grab the whole thing. Right click, send to decoder. Uh we'll do a smart decode first, which go ahead and get that. And then let's get this here. Uh decode as base 64. Uh we got a few of them there. What about grab all this? Maybe it's done a couple times. Now we go into that there. I don't know. I don't know if that's just a random character sequence or if that's actually meant to be something. Um, but let's see. Anyway, so it looked like, oh, you know what it is? You know what it is? Hold on. Go back off there. So, percent 3 delta. That's the equal. So, here's the canary that we sent in. But this part right here. So, that's it. You just you have this base 64 encoded something. So, maybe it's just a nons or something else that's added in there. But then why would it be destination? There must be some value in there. So, are they trying to actually obuscate the destination? That's kind of weird. Let's get rid of all this and let's just change the destination to arson. See what happens. Do we get a break? No, we don't. And we do have that reflected there. Of course, we're going to have to do this. Now, the problem is almost always this here is going to end up being hex encoded. Oh, it's so it's output encoded. It's not just naturally hex encoded. So, they are taking that and handling it and putting back out somewhere else. They're not just taking the whole URL and redirecting it in there. So, this is a this is a good one. Let's go ahead and record this one as well. I'm going to put it above this cuz this is again a bit more of a unique use case. Not that copy is URL. Let's put this back in here. Okay. And let's go back. I'll just let's just show the response in the browser. How about that? I just want to kind of bring it up and see what it looks like here. Okay, so we have a login page. Quite a bit of stuff going on here. So, authentication. Yes. CSP. I don't know if they have a CSP or not. They do. They have a content security policy. Oh, I love seeing. All right, so this is good. I tell you, let's do this. Let's get Firefox up and let's do uh Google content security policy. And there we go, the CSP evaluator right here. This what I was looking for. So, uh, Google has this great tool available that you can evaluate your own content security policy or as you're testing, you can evaluate other, you know, your targets content security policy. So, let's bring this up here and let's go ahead and have it check the CSP. Now, what we are looking for is anything that's not a green check. Specifically, this right here. So, this is great. Again, as I said, there are many, many different directives that can be put in. There's a lot of granularity with the content security policy. So, here we see and the script source is what specifically deals with our ability to execute client side JavaScript. We got object source as well, which can help um but that's not as bad, right? unsafe inline that allows us if we do get a client side injection we are going to be able to execute it because allowing unsafe inline we also have unsafe eval so if any custom client side JavaScript has eval being used there it will be able to actually inject code into the DOM whereas it wouldn't be allowed to if you could do that um now where is it pointing to so that only applies right so these two directives unsafe eval and unsafe inline only apply to Any this is just anything with av. What in the world is avincent or the Grenadus? Okay. So I mean is that just something that anybody can register? Can I register av domain? Yeah, I don't know. Yes, anyone can register as a I don't Yeah, I mean there's nothing that would say that it would need to be located in there. Anyone from anywhere in the world? Okay, so wow. Wow. Wow. Wow. Okay, so this is actually great. This 8 by8 is a great target for client side injection. And I'm probably going to dig into the rest of these um because what this is saying, so first of all, if we get a, you know, on any subdomain, we can potentially, you know, get that in there. I don't know what that is. You know, some type of DNS thing. But all I have to do Yeah, that's interesting. On any VC, then we can we can pull it in. Um, yeah. Sorry, my mind is going through the possibilities here. Like, can I register one and then potentially pull in another one, but I think the the directive would have to be a little bit different. Um, super interesting. All right. So, I love this one. I definitely want to keep an eye on it. We're going to copy this off. Actually, I don't know what the best way is to do this now. We'll just copy this off right now. It's going to be easier for our notes. Yeah. And we'll keep that there. Uh I want to do a little bit of research in a second to see exactly what this will mean as far as like bringing our payloads in from other places. Like is there a way that we can get a client side injection and possibly inject this in here somewhere else. But either way, if we get any type of a client side injection on this page, we're going to be a like my mind is already got starting to go to weaponization. I'm sorry thinking a little I should have been articulating what I was thinking a little better, but um you know, we already know because of this directive, because of the unsafe inline, the unsafe eval that if we can find a way to get a client side injection here, then we're definitely going to be able to weaponize it in just about, you know, a lot of ways that that we want to, right? What is the connection source there? Uh so, we're not going to be able to exfiltrate. Possibly could get something over there. Um but yeah. Yeah. So, I'm thinking about the different ways that we can weaponize it, right? Can I use this? Could I register avo and and so can I host it on av site and then if I can get an unsafe inline, can I pull in my external script? Which again, as I said, meant that I can do multiple different things, right? We're because of the connection source, we're not going to be able to just steal the cookie automatically. So, we're going to need to find a way to excfiltrate the data in a different way. um if we're going to actual trade data, maybe we can write it somewhere or maybe we can just use a curve.f. So we'll we'll check to see if they have any curve protections, but um can we force the victim to execute something that they didn't intend to execute? It looks like with this content security policy, we're going to be trapped within the site, but we can definitely get uh client side JavaScript to execute if we can find it. So that's very very good for us and I'd say would be very very bad for them. But we're not trying to do anything malicious. We're just trying to uh tell them if there's anything wrong. So, okay, that's a good start there. And let's come up here as well. I want to let's do this. Let's take some notes. Can do unsafe inline cannot xfill data or uh session to uh evil server. Let's just say that, right? right? If I'm going to host an evil server and then I can't just easily send that out there. But fine. Um, so let's come and take a look at cesurf, right? Because again, now that we know that we're going to have to force them to do an action, we need to see if they have any curve protection. Now, we're probably going to have to log in to do that. So, I may just put a pin in it for a minute. Um, and do we have the ability to to register, right? Let me just try and do this. See if anything pops up. I'm not seeing any ability to register. So, that's what I want to be able to find to do. I don't know if this 8 by8 super site I don't know if this is something that we can sign up for free or not. Um, but I definitely want to find out. I'm going to put a pin in this for a second. Again, the content security policy is what's very exciting to me. So, I'm always looking at these additional compensating controls. I'm not digging too far into it, but I just want to know, is it worth my time to continue testing everything that I'm writing uh and putting into my notes? These are targets that I do believe are uh worth my time and so that's the reason I'm looking at them. So, we'll keep that there. We can come back to it and let's see what else we've got. Oh, this went and found a did a whole bunch of other passive testing and and things in there, too. So, uh let's get back over here. So, we need to get to theformational. Okay, that's our path. I think we've looked at a lot of those. Oh, here's a 8.8.vc. That's interesting as well. So, this is the super site page there. And then we have this config.json, which again, ah, see, this is interesting logic stuff. I'm trying not to go down a rabbit hole. I'm trying to zone in on the the client side injection, but that's very interesting to me. All right. There's one more that I'm going to take a look at here, which is the 8 by8.vc. Now, this is not a uh reflected not identified as a reflected uh input necessarily, but it says there's an interesting response. So, let's see what that is. Oh, it's just identifying I think the Apple stuff here. Did they include any payloads? Okay, so no, this is this is just the app links there. Um, we could use this to do some testing on the mobile side. Um, this is not any sensitive information, at least not glancing at now, it just says like the app ID and stuff. So any of these well-known endpoints here, a lot of times they're related to OOTH in some way. So now it also has to do with like mobile things. There's several different uses. JSON web tokens use them a little bit too. Um, but it's easy to think that they can be sensitive and uh a lot of times they're not. So I don't know. But yeah, we we could test and see. Definitely gives us a little bit of information here. So, okay, I think that's good. You know, we found a few additional targets that are interesting. The manual ones are more interesting to me from the client side injection perspective, but these two are actually a little more interesting from more of a server side uh testing perspective. They're a little more complex, but more opportunity for a higher bounty, I think. So, okay. What I'm going to do, cuz this is going to take a little while and it's probably not going to be that fun to watch, and I don't want y'all to have to sit here and just watch me kind of poke around and talk to myself. We found four different good attack vectors in my opinion based on the existing compensating controls for reflected cross- sight scripting. I want to start finding targets for stored cross-sight scripting as well. Now, we can do some stuff. You know, you can do crawls and scans and start finding everything, but typically you want to find these manually. So, I need to go out in all of our results. So, let's pull that back up here. And I'm going to start just testing each one of these manually as you've seen me doing before, but specifically looking for anything that number one has authentication. And then number two, once we log in, we have the ability to store data within the database that is going to be rendered in the DOM, ideally for any potential user. Uh whether that's like a profile page, a forum, a comment, anything like that. So I actually started a scan on a lot of you can't see it as well there. Let me kind of go down to the bottom. There's a large number of WNBA domains down here. That looks like part of the one. You can see all the gray ones as it's starting to do the scan. But a lot of these appear to be WordPress sites and a lot of WordPress sites uh tend to have things like forums and stuff as well, blogs where you can put a comment. So, I'm doing some additional scans on there. I'm going to find targets that have authentication that have somewhere where we can store data within the database that's going to be loaded back and rendered in the DOM for multiple different users. Once I've found a few target applications like that, I'll come back on the camera. We will walk through the process of finding good attack vectors within that context for the stored cross- sight scripting. And then we're going to start digging into each one of our attack vectors and actually seeing, you know, a bit more of what we can do here. Can we circumvent the existing security control? So, I will see you in just a second. For me, it'll probably be an hour or so. All right, so we're back. uh I was able to find three different target applications from three different programs that we can log into. That's going to give us an opportunity to find some attack vectors for stored cross-sight scripting. So, we'll dig into that in a second. I wanted to show first of all, Burp Suite has been running overnight. I wasn't able to get this done yesterday, so I had to wait until today to get it done. Um but this was running overnight. You can see we still have quite a bit of scanning to do. So, there's just so many attack vectors in in this one scan that we set up to go through and test to see if there's any reflected input. But we also have 167 differentformational and we can assume that the majority of those are going to be some type of reflected response. So um you can see how powerful this is. We let the automated scanning again I you know you can do the cross-ite scripting scan checks and everything else if you want. It's going to take exponentially more time for everyone that you do. But for me the only thing that I want to know for testing reflected cross- sight scripting is uh whether or not the user controlled input is being reflected. And then I'll go in there and I will just like we did before, I will identify the compensating controls. I'll do all that. And if you know if I even find something in here where it's a valid cross-sight scripting or a valid client side injection and it does execute the alert, I honestly I mean I'll probably submit it anyway just in case. But the moment I see that that an active scan uh you know some type of automated scanner can actually find the the vulnerability, I just assume it's going to be a duplicate. somebody's already gone in there and found that stuff, you know, unless I'm really trying to find things quickly. But that's that's not really how I hunt, you know? It's I don't like waiting for a program to drop or a change to make and I got to run run to my computer and go, "Okay, good." Get all the automation stuff and everything build up. I like to take my time. I like to relax. I like to understand the application and then kind of go from there. So, um, but I did want to show real quick, right? Again, we've got many, many, many different items. I think there's probably some other ones as well. Yeah, some suspicious information or suspicious input trans uh transformation, whatever they call it here. These are great. You know, you can see that we're submitting hex values and then those are not actually being uh encode or they're being decoded and actually written into the DOM there. So, that tells us potentially if we submit uh payloads with the uh you know the special characters there that they may be written actually into the DOM as the character. So, um those are always good. Another thing that I wanted to show real quick before we move on to the stored cross-ite scripting is when I do have a lot of findings and and look a lot of times when I'm looking over multiple different programs, I can have thousands of different findings that that uh you know show reflected input, the main thing that I want to pay attention to because this is going to determine a lot about how it's actually being processed is the insertion point right here. So I will typically sort by the insertion point and anything that you see that is a get parameter that's being reflected. Well, again, you got to see where it's being reflected as well, right? Which, uh, is unfortunately not something we can do here. Although, maybe there's a way to set that. I'm gonna make a a note of that as well because that' probably be a good idea. But anyway, you can very quickly go through here now and see, right? These are coming from a parameter and uh uh as opposed to coming from, let's say, a well, this is an arbitrary URL. Yeah. So where where it's typically written to the location. I know the the one that I see a lot is um what's the best way to get to it here? Things like this where the payload is written in the path. A lot of times what you end up is just a generic 404. I don't know if that's actually what we're looking at here. Oh, this is actually kind of interesting. Uh okay, I'm going to end up going down a rabbit hole. I'm going to um Huh. I need to make sure that's within scope. Um, yeah. But anyway, a lot of times what you see, this will probably be more. Yeah, here we go. We see a 404. This is very common. This is very, very common where we see uh, you know, they'll come in and just put this was expecting the JS directory. We put a bunch of additional characters on it and as a result, those characters were reflected over here to say, hey, that just doesn't exist. That's very, very common, right? So, you'll get a lot of false positives. Now, you may be able to get a reflected cross- sight scripting on one of these 404 pages, but just remember they're going to be a lot more thoroughly tested than when if it was, you know, just regularly written into the DOM. Um, I'm actually a little bit more interested. You know, they're they're letting us know some of the framework than how it's written. You know, you can see it's using uh Spring Boot there. But yeah, so wanted to highlight that first. Let's move on. Otherwise, this video is going to be 10,000 hours and y'all are going to hate me. Uh let's bring up this here and we will also bring up our applications. So again, we're looking at reflected and stored. I'm going to come back over here and I'm going to do attack vectors and let's come down here and do stored attack vectors. Right now, it's really important to distinguish between the two and I would expect there to be a lot of opportunities for reflected cross- sight scripting within uh these applications where we're testing for stored cross-ite scripting as well, right? And I would typically make a note of both of those. But one of the things that you need to to think about as you're testing for reflected and stored and all these different client side injections, again, we're always tying it back to how do we deliver it to the victim. So the scope of who's a possible victim is very very different between a reflected cross-sight scripting and a stored cross- sight scripting. And the reason for that is a stored cross-sight scripting poisons something that users are going to see naturally. So if we look at our first application here, what I'm looking at is is John Deere. Uh it's program. I'll tell you what, let's make it bigger. It's kind of hard to navigate with that. Um very well-known program. It is a uh a VDP, right? Vulnerability disclosure program. So, you're not going to get any bounties. At least I don't think they they pay bounties. Um, but they have a lot of opportunities here. So, this is a great one to start on if you are new to bug bounty hunting and you want to get into those private programs where you start actually making money, right? And the reason for that is we come over here to the scope and and this is something I see a lot of beginners miss. Okay, you can see, oh, there's a a ton of different things here, right? They're eligible for a bounty, but that's fine. you know, you might come and see, oh, they've, you know, there's there's a lot of and and assume that the only targets are uh within this first page. If you look up here, and again, I've working with clients doing private tutoring, all that type of stuff. I've just noticed a pattern where a lot of people miss this. These are uh pageionated. So, there's not just a hundred of these. There are a,83 different individual URLs that are already listed out and included that are in scope for testing. Now, my script is going to pull all those out. And we've already tested all those. And if we go back to the script itself, as always, it would help if I could type. You're going to see up here just a ton of results for John Deere, right? And so, I mean, out of these over a thousand different URLs, we've probed every single one of them, and any one of these were found to be a good target. And we got a 95, we got 85s, right? Big group of 95s down there. Got a bunch of 65s, which is just kind of okay. That probably has a lot to do with the content security policy. But this is a great great program to start with uh and especially for client side injections because it looks like just the technology stack that they use uh is not very heavy on things like virtual DOMs and content security policies and things would make it a lot more difficult. So that was the reason that I chose this. And we're specifically looking at this setup builder here. So, let's come back and just search for it. And yeah, so we're looking at this one here, which is the critical. Um, you know, we can also go and test on these two as well. It' be a medium, but again, it's a vulnerability disclosure program. So, uh, it doesn't, you know, you're looking to just get some valid reports going into Hacker One, boost your signal, boost your reputation, then you'll be able to, uh, to get those private programs. Private programs where you're going to make the most amount of money, you know, just the way it works. So let's come back in and look at our application. Um actually let's no no I remember what else I was saying first get ahead of myself. Um so as I was saying your attack vector for reflected and stored cross- sight scripting is going to be completely different because your reflected cross-ite scripting is going to be delivered from the URL. remember. So you can deliver that to anybody and as long as they have a valid account and they have a session on the machine where they're they're executing the payload, then you can weaponize that. So if your goal is to steal their session token, well, you don't need to have an account for that. You can get your own account. You can find the reflected cross-ite scripting. You build your payload in a URL. You deliver the URL. They click on it. It leverages their existing session in their tenant within the application. You never needed to have access within. In fact, your goal through that reflected cross-ite scripting is to get access to that environment that they have. You know, so your goal was to escalate your privileges so you can get unauthorized access to their tenant. Whereas with stored cross- sight scripting, that payload is going to be submitted within the tenant and executed to users within that tenant as well. And a tenant is like an instance of the application, right? So here we have this this John Deere operation center. This is going to have multiple different users in it that are doing different things. They're going to have different levels of privileges, different access to different things. And so our goal with the stored cross-ite scripting within this authenticated environment would be to elevate our privileges or target a user that we know, right? This is something that would be leveraged more by a malicious insider potentially um or somebody if there's a very very low permission. Ideally, you can find a role that would still be able to execute the attack, the stored cross-ite scripting attack that is meant for external users. So, you see that a lot when there's like an auditor type role, um, you know, something. So maybe with John Deere here, maybe they have the ability to bring in contractors that can support it or anything, but you you really when you're doing stored cross-ite scripting, the best way to show impact within a an application like this where it's only going to deliver the payload to other users within your individual tenant. The the goal is to uh find something that has a very very low permissions, the lowest possible that you can still execute that so that you can demonstrate that elevation of privileges. If you come in and you're already an admin and you show that you can steal the session of a general user, but you can just create your own user with a general user, then there's not there's no impact there, right? So, you've really got to think about how you're delivering to the victim, who the potential victims are within the scope. And so, we're going to see as we look through these three different targets that I've found, uh, how that can change and what's a good versus a bad opportunity there. So, let's go ahead and open up our notes. And we're going to start with the John Deere here. And we're going to do basically the same thing. Uh, I'm not, you know, I want to find a couple places to to go in here. But before I even really start looking for an attack vector, what I'm going to do is understand a lot of those basic compensating controls. So, I'm just going to start probing and testing some different things there to try and and find out what those compensating controls are. Now, um here we have a general thing where we can set up a file, right? So, the file name itself is going to be our attack vector. This is when the file is it looks like it's being created. I actually don't know exactly what this going to do. We're going to kind of find out in real time here, but um when the file is created, this file name is going to be the value stored in the database and it's going to be reflected out most likely in many different places uh where other people can access it. So that's really my goal is I want to put in this canary to the database and then I'm going to go and find uh different places where it's uh input and output. Now I'm going to test the client side injection or there you go client side validation. So immediately we can see client side validation and I can just copy can't copy both. That's kind of fun. All right. So let's copy this and again just like we did here. And it just tells us, you know, again, we can easily circumvent this, but this gives us a little bit of insight into things that they don't want us to do. They don't want us to name this, you know, is that so does that mean that they don't have a lot of confidence in their server side validation and their W and everything else that they all the other compensating controls uh to filter this out? You know, that's entirely possible. So, that is going to equal a client side validation. put this uh another fun part about that that's a potential DOM based cross-ite scripting although I don't know how you would populate that but yeah I mean is it is it reflecting these here you know is it just showing I don't know I don't know or is this a hard-coded thing that it just checks for those so that's going to be our message there I think that's good to know just out of curiosity I Yeah. So that's there there is a JavaScript that's running locally that is constantly checking this probably checking it on every every key change uh or every change in it and uh looking to see if there's any characters they don't want and then it's just automatically reflecting this in here. So it would be very interesting to see you know could we get this to change? We'll talk more about this in DOM based cross-ite scripting. However, unless we can find a way within the URL with a hash fragment or something to automatically inject this into it, this would be a self cross-sight scripting if we did get it to execute because the user would have to come in and type it within this file name in order for it to work because it's only going to process that JavaScript is only going to process it if it uh sees that there's a change within the form there. So, all right, we'll go back and we'll just do our canary arson to start. I want to see where it's reflected and I don't know exactly what this does here. We've got some kind of thing over there that Oh, interesting. I don't know. Can I go forward on this? I'm just going to try to go. Yep, sure. Let's link our test tractor in there. No products, no operators. Uh, so here's one area where we see it reflected. Let's create this file. Let's create without sending first. It didn't like it. Create and send. I don't know if it's actually going to do it. All right. Sorry about that. Um had an issue with the proxy going through burp. I wanted to come in and see what was going on. Uh so let's let's do this. Let's come back here. I want to run through it again. I'm not sure why we're getting that error, but I want to at least see the error in Burp, and then we can go try to find somewhere else if this one's not going to work for us. But uh let's create this here. Now, yeah, I don't know if we have to actually create land. We do have the equipment that we got set up, but these should all be going through here. Now, this all looks like JavaScript though, I think. So, when I click send there, because we are going through Burp, I don't think these are actually sending requests. Let's just go and make sure if I click next. No. Okay. So, this is all JavaScript driven. Let's get that out there. Come back over here. Uh, okay. So, once again, we've got that there. Let's see if it's going to give us an error. Create without sending. Okay, we're at least getting the traffic there. We did get the error again. Let's see if we can figure out what's going on. What is the error here? Got a message going to the OOTH authorized. Yeah, we're just getting an unexpected error coming from that. Uh maybe it's an issue with the OOTH. Maybe I need to log out and log back in again. I know that this same session has been running for over 24 hours. So, it's possible that the session expired, but then they did not actually uh I don't know. They they didn't actually disable it or they don't kick you out. I'm not sure. Let's see. This is just CSS. Um, here we have a post request. It looks like it contains all the information for our Yeah, for our new file that was supposedly going to be set up. And yeah, once again, we do have the content security policy coming back there, which we can uh let's go ahead and evaluate that as well because that's probably good enough. Is that consistent? See, we're getting redirected back to the login page here. I think that I probably just need to log out and log back in. But I do want to grab this content security policy and just do a quick evaluation here. So, let's do that. Google CSP evaluator. We've been here before. Check the content security policy. Uh, okay. Script source. We've got our runs safe inline. That's fantastic. We've got our runs safe evals. Got some stuff there. default source as well coming from Google APIs. Looks like we can uh possibly use that as well. I don't know if that's going to over it shouldn't overwrite anything here because the default source kind of sets the the lowest standard and then any other directives that you come in and set will uh over basically build on top of that. Kind of like firewall rules a little bit. Uh connect source, we've got a lot of different opportunities. Um, got S3 there. Oh, they've got local host in the content security policy. So, that is a good sign as well. There's enough here. Once again, I'm always looking to see if this is worth my time. There's definitely enough here to tell me this is worth my time. Security policy PSP. And we will do this. And yeah, it's going to be a big blob right there. and we can keep that set up. That's great. Okay, let me let's go ahead and log out and I'll get logged back in. You can see I created this with the we are hacker one email there. It's having all sorts of problems taking its time to to even get me logged out. There we go. Let's see what happens when we do this. Redirects over to the sign in. I guess this is a different one. What happens when I go to the setup builder directly again though? Okay. Switches us back over to here now. It should be arson plus1hacker1.com. So they have a separate domain that they're using for it's almost like their own ooth implementation is what it looks or their own SSO implementation rather is what this looks like. So they've got this signin page that that handles all of that. Kind of looks like octa a little bit but it does look like our session was invalidated and that's at least part of the reason. Uh that should already be saved. I guess it was for somewhere else. Yeah, that's fine. It's a throwaway password by the I don't think that I'm actually putting any real passwords or doing anything here. You know, you're I don't care if you get on this and and you know, get access to discount here. Uh, all right. Uh, we're going to go with file name arson. Let's go through and try to do the same thing again. We're also going to pick up any of the additional information. Although none of these should be sending HTTP requests. What happens if I add field? Uh, I don't know. It freezes apparently. Oh. Ah, okay. Well, now we Okay. So, let's let's just see if we can create this first. It looks like But all of these, so creating a field, creating a client, all of these things are opportunities for us to create stored cross-ite scripting. I guarantee you they're going to be available for other people to use. I mean, just right here, right when I pick the name of the tractor and I just wrote in there test. So, this is another area. Test is essentially our canary. So when other users within this application are going through and selecting their equipment, selecting their land, selecting their products, all of those are opportunities for a cross-sight scripting payload to execute uh and and be able to be weaponized against it. So let's just find out if I can pick nothing. I want to know if it was a login problem or anything else. Create without saving. Okay, there you go. So that becomes the file name. Here's another place where it's reflected there. Um, go to the files. Now, we've moved over to files. Which I would assume is in scope, but let's just make sure it is. Okay. It's critical as well. That's perfect. Again, we always want to be careful. We don't want to do any testing on a target that is listed as out of scope. There's probably a very good reason why they've listed out of scope. And as I've said many many times on my videos, if a company is kind enough to allow you to come in and do security testing on their their applications and have the opportunity to uh get bounties, um, right, obviously there's a huge value for them as well. I don't want to diminish all the hard work that the rec that the researchers put in, but they don't need to do that. And I can tell you, having built my own bug bounty program, it can be very, very difficult to convince, you know, things like the legal team and people outside of security of the value of a bug bounty program in comparison to the risk. So I guarantee you if you see a public bug bounty program on hacker 1, there were a lot of security engineers on the blue team, the siso, the leadership, everything like that that had to work very very hard to get that implemented to keep it to continue showing the value of it. So I always want to be respectful. Um again, just kind of having been on both sides, right? Like I definitely, you know, the the value the research provide is huge. Um, but it's I don't want to diminish the hard work of the blue teams to actually get this out here because it's much more difficult to create a bug bounty program within a company than you might think. Uh, but okay. So, we have well does this it's not automatically. Oh, no. Is a setup file. There we go. So, you come in here to the setup files file uploaded by John Smith which is the name that I chose there. So, this is a fantastic target, a fantastic place. Um, there's a lot of different opportunities. We could go back and create the the products, all that, etc. Um, yeah. So, we come back and test with this in a bit. Uh, what I want to know now that we have that at least as much as we can. We got the content security policy. We got, uh, that there's some client side validation. I want to try to find information for any other uh, validation compensating controls that might be happening. So, let's come down here. Oh, and all these are being identified as having a JSON web token in it. Yeah. Yeah. So, a JSON web token here. external access. Looks like that's probably what's being used as their OOTH access token right there, which is good. Okay, have that go away there. I'm going to come back to we found the post request that actually submitted within the setup builder. I might need to filter these out a little bit. Let's just try real quick. We got to find that post request that created the files there. There we go. All right, let's go ahead and send this over to repeater. Send this and let's see what happens. Okay, so it looks like we have the ability to completely control everything in here. Well, no, there no errors. So, let me come back here. Ah, okay. So, we can have multiple files with the same name as well. I'm betting I am betting that if we go back and do setup file creator and I do arson now, is it going to tell me that that name has already been taken? No, I guess not. I was wondering if there was just like a client side validation, but yeah, I mean, so how are they differentiating these files? I'm sure they're not being stored as arson. I don't know. But uh All right. Well, let's see. We know that we had an error when we did this before. Ah, okay. So, we have added and we should see a third one in here. Why am I trying to open Chrome when it's Firefox? Do we see a third one in here? Let's go backwards. Backwards. Go backwards. I want to go back to just that general setup files page here. We have a hash fragment as well. What else? That tells me there's a potential for DOM based cross-ite scripting as well. Okay, so we added additional characters that were not allowed in our uh by the client side validation and we can see that they're getting stripped out, right? So we have arson. Let's just go test. Let's see what happens. Looks like it's stripping out anything past that. If I just do arson test, I would expect the name to be arson test.zip. It's not. Oh, shoot. Cuz I'm changing the wrong darn thing. This is changing our profile name. Oh, okay. Okay. Well, then let's try this. That could have an impact later, though. We can see if that changed anything that was being written to the DOM later. Uh, once again, stored crossite scripting, it's all about getting those payloads within the database. And then we're going to find all the different places that it loads up. We'll check the output encoding there. But first, we have to get some of these values in. Okay. So, we can circumvent the client side controls. If we come back over here. Oh, but it's not showing there. So, is is this being stripped out later or is it being stripped out when it's loaded into the DOM? That I do not know. Let's try a few other characters. Uh, single quote. Oh, double quoting. Whoops. Single quote, semicolon, uh, backslash, double quote. Let's see what happens. Now, we going to break something. We didn't break anything yet. Are these all getting filtered out here? I'm not seeing another one added. Yeah, I didn't add a new file at all, but we didn't get an error on this side. So, I wonder what broke it. could be any one of these characters. I'm just kind of reducing it down until I see another one pop up. Looks like maybe the single quote is still not allowing it to to go. Let's see. So if we do this, do we get six? No. No, we still have five. Interesting. Okay. So some type of server side validation is happening there. So let's come back over here. Let's put this in here. And what I would do over time is start to probe and see whether or not this is consistent across all of these. But I'm just starting to, as I keep saying, obviously for the sake of time, too, right? Like this, I can make a 20our video on this stuff. You know, it's like there's so many different little things that can impact all of this. Um, so yeah, just kind of trying to demonstrate it without like, you know, getting into a rabbit hole where I'd, you know, actually be testing and because it's going to be very meticulous. Go through all of the different attack vectors. You've got to, you know, try to put different characters in there, see how they load up in different places. But it certainly appears to me that uh this stripped from uh name before loaded in DOM. Okay. Okay. So, I'll put that there for a second and we can find out using Burp uh whether or not this is Let's go back over to the proxy. Uh we can we can figure out the answer to that, right? Is it um is it stripping it out before it's stored in the database or is it pulling these characters from the database and then it's uh trying to think and talk at the same time pulling these from the database and then doing output encoding or stripping it out within the the client side itself, you know, or before it sends it back. My the main question I'm trying to answer here is are these special characters being stored in the database or not? Because if they're not, it's serverside validation. If they are, then it's output encoding. So, let's turn the intercept on there real quick. And then I just want to load this up again. And we have the not that one. Oh, you know what? This is not going to work because it's a hash fragment in here. Let's just do this. We got to go back over here. Now we've got those coming. That hash fragment is telling uh the tool not or telling the browser not to actually refresh the page, not to actually send another HTTP request because there's additional characters after that hash fragment there. So a lot of this is happening in the DOM and then the HTTP calls are coming from uh from Ajax calls from our client side JavaScript here. So all right. So from that we should be able to go to the history here and see we have so many tools here to this. What I'm trying to find is where those arson are being loaded into. These are all the rum package. This is just going to be tracking no arson in there. All right. Where where is this name being pulled? Come back over here. Is it here? There's my names. That's it. Is it somewhere like way back here? You know what? Maybe it's being loaded from somewhere else, too. Let me get rid of this because it's possible that we're missing it because of that. This is getting annoying. Come over here. It's probably going to be coming back from one of these files pieces right here. Not there. What was sent after that? I don't know where these values are coming from. They must be loading up from somewhere. Maybe this is it. There we go. Okay. Good grief. It took me way too long to find that. You can see how like when you have a hash fragment, especially in these Ajax calls coming out left and right, it could be hard to kind of sort through that there, but uh that's all good. Okay, so here we have these. Do we have anyone that actually returns a quote? No. So none of So that is definitely server side validation. So those are being stripped out before they are being stored in the database for database. All right. So we have 100% that's going to be server side validation something that's happened there. We would need to we would need to find a a good target that we can actually submit special characters to to check the the output encoding here. I'm trying to think of a good easy way to do that and I don't want to spend too much time searching. Let's just come up here and see how this is rendered in DOM. Uh the value directly renders it there. But this is also something that would be reflected which is not exactly what I'm looking to do. Uh let's do this. Let's come up to Walizer as well because we do have React. Um I think that's good for right now. We found some good opportunities. There's all those different partners and clients and all these different pieces. So, what I would do and probably what we'll see on here, I'm going to choose one reflected and one stored later and we'll go through and do a much deeper dive in testing and I don't I'm going to pick whichever one is the most likely from our multiple targets for reflected and stored. So, we'll see if this one makes sense. Um, we come back to it in a little bit. I want to move on to the next one. But also, once again, I want you to remember that I want you to remember the scope of our victims, right? So, here we have the the tenant. we're only going to be able to deliver, I believe, these stored cross- sight scripting or scripting attacks to an individual that uh that already has an account here. Now, the the one thing that may be different before I move on to the next one, we come over to the the file creator here. Let's do this and two, whatever. That's fine. Ah, and look, we're getting some some other Oh. Oh, but we are getting values that are sourced. Okay. So, we can test the output encoding here as well cuz I I think these are probably going with React. Yeah. So, this is uh this is being loaded with React is being loaded in the virtual DOM. You see how all those characters are still there, right? So, uh what happens if I do this will let us know if we have a web application firewall as well. Just do the most basic payload there. Hey, that's getting in. That's going right there. So, it'll take a little bit. So, what we saw was that when we sent each of these, uh, there's multiple different places that it's done as well. So, let's see if there's any difference in the output encoding that comes from there. There's not. So, yeah, I'm I'm almost certain, in fact, I can tell with this. Yeah. So, we are using React. So, this is a virtual DOM. It's loading everything up and that's the reason that we're not getting any execution there. So let's note that as well actually. Okay. And as I mentioned before, anytime we see React, let's come over into the debugger and I want to take a look at the files that they have and we are seeing properly serialized minimize obuscated files here. So they have properly serialized the Webpack in a way that's not going to make it easy for us to get the raw react files. Unfortunately for us, fortunately for them, we'll see what kind of comes back here in a little bit. But uh All right. And I'm not seeing a web application firewall. Ah, there's that there. Okay. So yeah, once again, the script tag is not even being loaded or used. Let's click on this here. Yeah. So we can see it's being loaded within a span. would typically be a fantastic example, but because React uses JSX under the hood and that is what is handling the front end at this piece of the application, we're not going to be able to get a typical uh cross-ite scripting in here. So, um doesn't mean that that's consistent across the whole internal application. Very possible that we could have some custom components that are loaded in on top of the React components. It's very possible that they're using the set dangerously in HTML method that's built into React and we can weaponize it there. But this is going to make it more difficult. It's fundamentally going to change the methodology that we use to go through and test, right? Because even if we get something that circumvented all the other security controls, JSX is going to make it very very difficult for us to create something that can be weaponized. So all right, that's the first one. Let's go ahead and move on to the next one, which is Incitly, which Incitely is a uh CRM, I believe, uh customer uh customer customer relationship manager management, I think is what that stands for. Um but yeah, kind like Salesforce. It's like a competitor to to Salesforce I guess. Um I haven't looked too much into it here but but that's fine. Um the important thing to know from from our perspective is that once again you are going to have an instance of the application. You can only deliver this to users within that instance. The uh fundamental difference between this and the John Deere application that we just looked at is the John Deere application is really meant to be you wouldn't expect for external users to come in and use that. I mentioned the use case about contractors and everything else. So there's a potential use case there, but you wouldn't expect to have a lot of insight from or have like temporary pages or anything where you can get an unauthenticated user to come in and view data that's stored in the database uh within that application. Whereas a CRM, there's going to be an opportunity potentially to where there's data that's being shared between the CRM and the external customers. Uh, a CRM typically has to integrate with a lot of different applications, has to be used in a ton of different use cases because it needs to be flexible enough for the sales team to be able and and leverage it, right? To win. Like ultimately sales team, they need to win. They need to win deals, right? Look, win rate right there, right? I didn't even plan that. I didn't even plan that. But yeah, the win rate and being able to win deals is going to be really important. And if your CRM is not flexible enough to allow you to say deliver yeah maybe you can deliver purchase orders you know to a customer it'll handle you know we already see that it handles leads in here right so these are different individuals all these by the way are you can tell with a new lead or things that you can just store in there all these are an opportunity for a store cross-ite scripting so um yeah might be more opportunities to show impact and weaponize here but let's go ahead and get an idea of what it looks like at the compensating controls and all that just like we did four. I'm more bullish on this than I was on the others. Let's just take the leads. Let's go ahead and do this. We will do uh Adam Smith. He's a CEO of uh Noame Company LLC. Um we contacted Sure. Uh this is a sure five out of five. whatever it is. So, yeah, the email address is this going to allow us to reach out to them, you know, uh we'll just do actually let's do mine and that way insightly leads test. If you're not using plus notation to build out different uh email addresses when you're doing this so that you can identify it when it comes through, definitely recommend that. Do some research on plus notation. Maybe I'll make a video on it, but uh it's helpful. and then go take a look at Gareth Hayes uh Defcon talk from Defcon 32 I think would not not this year's but the last year's and I'm realizing now if you're watching this later my mix up he did a thing on email and and plus notation and additional characters and stuff that was really really great that's I'll shut up about that um a lot of different opportunities in here so all of these are places to put canaries in you know and and we can see I don't know if this has client side validation or Not. Let's just try and throw all this in here. The hope is that they don't have a lot of actual validation because they don't really care. This is all for you. We got a tag that we can create there too with Canary as well and visible to everybody. Okay. So again, now we have the ability to uh deliver this, right? We can determine who it's going to be delivered to. And I assume only the record owner there is going to be Yeah. Yeah. Yeah. So, so just us and administrators there. So, this would be good if we just wanted to target administrators, you know, lower the noise, lowered the the scope of attack, everything as well. So, let's just see if we can save this. I don't like that. Okay. Once again, we have verbose information that is telling us and we do have some client side validation. So, let's let's go ahead and document that. That's typically the first one that you find. I'm not going to test all of them because honestly, I don't really care. I can get right by it. Uh, okay. Let's just do this. I'm just going to type it out. It's going to be easier doing that. Come on. Gosh, they're making it really hard to copy and paste this stuff. Although, weirdly, I have noticed this before, too. So, it's easier to copy from the end of the string to the beginning a lot of times than than the beginning to the end. I don't I don't actually know why that is. I don't know why I open that up either. It's what happens when you talk and try and do things at the same time. Okay, that's fine. Just to see that we have it. Um, so yeah. So, this is we'll just change this to one, I'm assuming. But we didn't get kicked back for the phone number or anything else or at least not yet. That's it. That's the only one it didn't like. So the only client side validation that we had on there or not really any server side validation, which again is kind of one of So the only thing that we have validation for is the number of employees. Why would that be? Again, this is where the client this is where the client side validation is helpful. Why would that be? They don't care what the phone number is, but they care about the number of employees. So something must have broke. Something must have broken at some point with the number of employees where they had to come in and put that validation. Let's see if they have that on the server side as well because there's very little server side validation. I'm guessing it's this post request here or no, this one right here. The create. There we go. There's our lead. All right. Send this to repeater. Let's come over. Where's our one? Nope. You're going to be arson right there. Uh, I'm also typically when you see this. So, first of all, it's interesting that they have it set up like that. You really shouldn't have the fields, but I think that's a net thing. I typically see this inn net apps. Let's see what happens here. I mean, I don't think there was an issue. Let's see. Let's refresh this and see what happens. Do we have two Adam Smiths? No. I don't know if the other one is there like a redirect or anything or maybe it just doesn't create to Adam. Let's try Adam Johnson now. Let's see if it added another one here. Refresh again. No. So, it does look like we have server side validation to where it's it's not giving us an error, but it it looks like it's preventing the creation of that lead. Is there any error? Oh, it is. Okay. So, it's loading the DOM again. It's giving us that error. Okay. So that is both a client side and actually it may just be a server side validation but um that's good. Let's go ahead and mark that. So all right so yeah same as client side validation that'll be good there. All right. Do we have a content security policy? Let's just come in and take a look here. I do not see a content security policy listed within this. Now again it can be written in the DOM there. It could also be inherited potentially. So if uh if there's a single page application in fact let's come over here and if you do view source I'm not going to be able to view page source. Here we go. So this is the DOM that is first loaded up before the JavaScript comes in as a single page application and starts manipulating everything else. There we have a bunch of web 3 mentions there. That's kind of strange. We got some custom I believe custom JavaScript written in there. A lot of custom JavaScript. Anything? No, I'm not seeing any metatags that about it. So, I don't see a content security policy at all. I would be really surprised if they actually didn't have one, but again, I'm not seeing it. Let's do this. Let's come to pro uh this thing here. Let's just go to Insightly. I want to filter this down and see if I can find anything that's that's returning a content security policy. Okay, so here's one. And this is this is on the homepage. Okay, so this is just one direct frame ancestors. So does that have to do with iframes that can be loaded up? Is that the only thing that it's determining there? Let me open this up here. Content security policy CSP. We have that. And I'm going to notate here now. SLHome. I actually I think this just has to do with iframes. I mean, we don't have a default source, which is typically what you would do if you wanted to do something very small. Yeah, no object, no script, no nothing there. So, I mean, they you can layer it on there. If you have multiple different HTTP calls coming back, then you could potentially layer it. But, uh, all right, let's see. So that's really the only Yeah, I'm not seeing much else. The only ones that I'm seeing where we're getting a highlight there is that very short one. Is this uh here's another one. Oh, it says Google Analytics. No, so that's Yeah, that's the only one that I'm seeing. Okay, so very very permissive content security policy again. That makes me uh think that this could be a good one. You know what we look at or what we need to look at too that I I haven't really shown yet and I should have. I don't know why is we got to take a look at the cookie flags. Right. So if we are going to now we know that with the content security policy we can execute scripts. It doesn't have anything. We can exfill the data as well. There's nothing within the content security policy that would prevent us from uh exfiltrating that data and um and actually getting that that cost. Let's do we have web hooks site again? Let's uh where was our actual thing here? Let's reload a new one. How does it do this here? Whatever. That's fine. All right. We can just copy this right here. I was going to do a brand new one. There's got to be a way to clear this. I don't know why I'm not seeing it now, but um I guess just do that. Ah, there you go. Okay, that'll be fine. Uh, okay. So, let's come back to here. I want to go to the console and I just want to see fetch question mark q equals plus document.cookie. Let's see what happens when we try and do this. So we are getting the corores issue that we got before. Um but we got status code 200 right. So that corores issue if we come back over to here we did get oh look at all those cookies. So I don't know what exactly they are but you see when you get that corors issue corors just tells uh the the browser that it cannot load the data that's coming back. You can see here it still makes the HTTP request. It still goes out there. So let's see what cookies we got and what cookies we didn't. I'm seeing a lot of ones that have underscore underscore, which is typically more of a tracking cookie. Uh, but yeah, let's Oh, I didn't see the word session as well. Session preferences. D. Okay, there's a better way to do this. I just wanted to look and see what was in there. So, let's come into storage and within the cookies, let's see what we got. We're looking for our session token and maybe instead what has HTTP only. So these four are snap snapped ID I guess insightly apps which this is most likely the session token here. Let me go back and look at the the actual requests that are going through but there's no authorization header or anything. Let's figure out which one of these is the uh the actual one. Got to be an easier way to do this, too. Okay. Send this. Should see a typical thing. Let's see if arson is in the DOM because that'll make it easier. It's not. Shoot. Is log out. No. Log in. uh maybe a little bit more difficult to test this and I think um I do think this incitely apps is the session token here. Let's see what happens if I take this out. Is there any difference? Okay, it is. Okay, perfect. So that's the one. Well, not perfect because um that means that our Oh, this request verification too. Shoot. There we go. This request verification token is most likely a CSURF token as well. So, um, let's grab this. We're going to come back over here. All right, let's go, uh, curf. All right, then we'll do verification token there and then, uh, HTTP only, right? And that means that we're not going to be able to access that and go and modify it in some way so that we can uh, try to manipulate this cur, right? at least we're not going to be able to grab it with JavaScript. Now, that doesn't mean it works. We're going to go in here and test to see if it's actually effective or not against certain certain actions, but uh but yeah, at least we know that we're not going to be able to access it. And then going back to cookie flags up here, we can see that if we come up here, uh go back one. So, sending this request, it's going to give us a 200. But then if we come down to our Incitly apps cookie and we get rid of that, then we get an unauthorized. So that tells us that that's our session token that's being used or at least one of the ways that they're identifying the session. So um let's say that this cookie hon and I'll include as well session token so we know so that will obviously impact what we want to do the session token and the curve token both have http only on it um it's going to be difficult to it's going to be difficult to weaponize um what we're probably going to have to default to is data exfiltration, right? Because we want to get that session token out. Now, what we can maybe do, well, it depends on the sea surf, right? Because step one, we want to try to get that session token out. Um, but if we can't grab it with uh JavaScript and actually send it, then we're not going to be able to do that. So, next step, can we force a victim to do some type of action that they didn't intend to do? Um, the CSURF, if if it's implemented correctly, we're not going to be able to manipulate it with JavaScript. So, it's going to make it a little bit more difficult. We need to find out if that implementation is actually effective though. And a lot of times it's not. You know, once you find start poking around, but but it does have it. We need to take that into account. So, most likely what we're going to be doing is data expiltration. You know, we'll go in and grab some of these sensitive information, maybe some of the leads, right? Um, you got to think about what would be their nightmare scenario. It's almost like stealing this sales data might be valuable, but if you can steal the data that they've collected from several different leads and you can show that you can make that public and and that would be a much uh more devastating thing for the company because then they're going to have all those leads and people they're gathering data saying, "Hold on, hold on. So, I didn't even give you my information. You went out and found my information as a lead and then you lost it because your app wasn't secure. So that individual person had nothing to do with potentially their address, their phone number, their name, all this type of information being uh being exfiltrated. So that's probably the way that I would show impact from this one. But uh okay, so that is our second app. Again, we'll dig into this a little bit more once we start actually testing out some specific if we go to this one. Again, we're just going to go to one. Um I don't know which one I want to go to yet, but I want to talk about one more here. Um, and that's Steam. So, I did a lot of research trying to find the best case scenario for stored cross-sight scripting in a public bug bounty program and Steam was the one that I found that that I think was the best opportunity for that. And I want to tell you why. Um, first of all, just their metrics look good. This didn't actually come into it, but I want to call that out, right? 91% efficiency is pretty good. Um, the bounties are are not bad, right? They're not great, but they're not bad. as kind of a middle of the road and they got a pretty decent size scope here. 25 different things. Um, however, they have the Steam community here included within the scope. And if we come over here to actually look at what that is, that is well, this is not it right here. What happened? It redirected me. Let's come over here, Steam Community. It's a public forum that you can use. I guess when I logged in, it redirected me over there. But, um, yeah. So here you have a a forum, a public community that anyone can come that has a Steam account. So So you don't have to, you know, you don't have to be with John Deere. You don't have to be this uh, you know, have have a company and and be part of this company's organization that's doing, you know, work with these this John Deere stuff. With Insightly, you don't have to be part of the company where you're going to get an access get and get get an account uh to come in and do the sales work or manage this or anything else. Now, with Steam, anybody on the planet that has a Steam uh account can come in and log in here to the community and they will be able to post information. Now, the information they're posting, the comments, their own individual post, there are tons of different ways that we can come in and uh store data within the BA database that is going to be loaded back up uh by a different user, you know, and and so it gives us the opportunity to uh deliver our payload to several to a much huger audience. There's a much larger blast radius there um with with the potential impact, right? We can essentially attack if we can find a stored cross-ite scripting in one of these post or comment mechanisms, anything like that. Our our username is going to show on every one of our post. A lot of the information in our profile is going to store in our poster. There's so many different opportunities for us to go in and store data, user controlled input that's going to be loaded back up in the DOM later that anybody can see. So, um, I'm not going to dig too much into this right now just for the sake of time. This whole process already taken longer than I wanted it to in the scope of everything else, but I want to make sure I showed a good option for doing that that testing where you can deliver it to a very large group of potential victims. And the Steam community forum here seems to be in my opinion a great great example. So if you want your best case scenario here, I would definitely come take a look at this and see if you can find remember anytime you see something loaded in the DOM, try to figure out is it user controlled and then if so, you can go in test all the different compensating controls. Uh use the the methodology and the process I'm teaching in this video to try to get that to execute. And then being able to articulate the risk is very very easy because every single user, especially a lot of times you don't necessarily need to be logged in, but imagine if you are, right? if you're logged in, you go in and steal that. And and let's chain this together, right? Because remember what happened recently with Steam. There was the um the the little game that actually had a crypto miner in it. And there was that the streamer that was uh a streamer that was trying to raise money because the individual had a a very dangerous, you know, very devastating form of cancer. and uh they were, you know, they went on there and they were streaming some some things or doing a live stream and uh somebody convinced them to download a game on Steam that they thought was safe and it actually had a thing and there were went and stole all their crypto wallet uh keys and they lost a bunch of money. Now, thankfully that individual got the money back from what I know and take all this, right? I I've kind of just seen a couple videos on this, so I apologize if I'm getting anything wrong, but fundamentally, if you could find a way to upload a malicious game and then you can find a way to do a store cross-ite scripting that forced them to download that game, you now have the ability to deliver malware to every person who looks at your post on a public forum that has a Steam account, you know. So, that's that's the type of uh attacks that that I'm thinking through here. And it's completely different than a reflected cross-ite scripting. the reflected cross-ite scripting you you're you deliver it to the individual. It's much easier to do reflected cross-ite scripting and show impact in apps like this, right? Because I can get my own instance. I can find the reflected cross-ite scripting. I can deliver it to the victim. They'll click it and it will leverage their session. I never need to have access to their environment. Um here is where a stored crossite scripting is really going to be powerful because we can hit a large number of victims. Of course, we would never do that because we're ethical researchers, but we can articulate that to the company, to Valve, and explain why, you know, that that attack has that much impact. So, um, okay, I'm going to hit pause here because this has been quite a bit for today. Um, when I come back, we're going to look at some of the attack vectors that we have already found for reflected and stored cross- sight scripting, and then we're going to start digging in and trying to circumvent some of those compensating controls. We're going to look at manual ways to do it and we're going to look at automated ways to do that as well. So, I'll see you soon. Cheers. All right, we are back and uh it is now time for us to go back to our reflected cross- sight scripting attack vectors that we found before. I've got them both up on the or all four of them up on the screen here. And we're going to start to uh build out a plan for weaponizing these if we can get the alert to pop. Right. So, we're going to have our entire attack planned out before we even start to go in there and and test for different uh different payloads, different output encoding, bypassing these compensating controls, you know, different ways that we can actually get that alert to pop, right? is there's a lot of times that you can get that alert to fire, you can get the cross-ite scripting payload to execute, but you're going to find out later that because of the compensating controls, because of the scope of the application. I mean, there's so many different factors that can determine whether or not you're actually going to be able to weaponize it. So, we don't even want to go through the the work of trying to get that alert to fire until we know that once we get that alert to pop, we get that cross-sight scripting to execute, we are going to be able to convert that into a real attack that shows impact and that's how we're going to, you know, be able to submit it and it won't be a uh self cross-ite scripting as you hear all these different things, right? We're going to be confident. We know exactly how we're going to show impact as we deliver this. So if we come back to our reflected attack vectors, uh if you remember, we had four that we looked at, right? This Windstream, ResMed, 8 by8, and uh the one from Moxilla there that does some crashes. So um what I'm going to do, I'm going to go ahead and dial in on two of these just for just to make this easier. I'm going to delete these here, um because we don't need them. I want to focus on these two specifically, and I'll tell you why. Um these two different applications. First, they're they're decent opportunities from what we've seen from the probes that have been able to do, but they also represent two completely different strategies that a company will take to prevent client side injections based on the compensating controls. And it's from what we've seen, it looks like they've these two have gone in the complete opposite direction. So, I think it's going to be a great opportunity for us to show those differences, kind of document it and show how it impacts the different attacks. If we look at the first one, the primary compensating controls that we found were a web application firewall over here and then output encoding. A web application firewall if we remember is going to check patterns from the incoming HTTP request and if it sees a pattern that it recognizes that it believes is malicious. So if you just think about it like reax checks or there's typically pretty simple although some of them can get more complex then it will just block it out right before any part of the application has the ability to to process or or yeah to process that user controlled input. Uh output encoding as well. So the user controlled input goes into the application and it it renders back out into the DOM. uh it's designed to ensure that when that user controlled input reflects in the DOM, it will never be able to execute that alert in the first place. So both of these compensating controls are entirely focused on preventing that cross- sight the reflected cross-sight scripting from executing in the first place to getting that alert to pop. Right? We're not seeing any content security policy from our testing. The content security policy is going to determine what you know it will have an impact on whether it the alert can pop but it'll also have a lot of impact on how that can be weaponized. So for our first target here for the windstream target if we are able to get a client side injection to execute a reflected crossace scripting I believe that we're going to be able to show we're going to have a lot of opportunities let's say to show impact. Now, we need to go in and look and see, you know, who are our available victims. What are the types of attacks that we can do, and that's what we're going to do in a second. But looking at these compensating controls from the way that we evaluated it, I'm they have focused on trying to stop that uh client side injection from executing in the first place. They haven't shown uh a lot of interest in trying to stop it from being weaponized later. So that tells me that if we can circumvent these controls, if we can find a way to get past the Cloudflare W, if we can find a way to get this output encoding to fail so that it's actually going to uh render a valid payload in the DOM, then we're going to have a lot of opportunities to weaponize that show impact to potentially get something like an account takeover or anything. Now, we got to find out if that's even possible. If there's, you know, who's going to be that victim, whose account are we taking over? What data are we getting there? That's all stuff we've got to look into now. But again, it's just one way of looking at the compensating controls where this tells me, okay, there may be some value here because if I can get this payload to execute, I'm going to have a lot of opportunities, but I want to know exactly what opportunities I'm looking at before I even invest that time because the largest amount of time for a target like this is going to be trying to get that alert to execute in the first place. Now, if we come down here and look at the 8 by8, we see the complete opposite. Now, we didn't do a bunch of digging in into output encoding and server side uh validation stuff. So, it may have those additional steps in there, but just looking at the initial thing, if you remember from the CSUF, we did see a CSURF token which would prevent weaponization. We have a content security policy that and we're going to dig into all these here in a minute, but they're okay with, you know, they have unsafe in eval unsafe in uh inline things like that. So there there are a lot of opportunities for us to get this uh payload to execute. I actually think that getting a payload to execute on uh an 8 by8 or on a site like this is going to be much easier. However, you may find out that once you get it to execute because of the way the content security policy is configured because of the way the curf works um all these you know all the different compensating controls may preventing prevent us from being able to weaponize it entirely. So once again, we don't want to go through the process of going and finding a working payload, which can be a huge amount of time, especially for a bug bounty researcher. I want to invest my time where I know it's going to be worth it right now. Once we have all this, you know, everything planned and and you know, this is how how we're going to deliver it to, this is how we're going to deliver it, this is how we're going to weaponize it. Once you have that done, then you're going to step back and then you have to actually get the alert to fire. A lot of times that may not happen. You may not be able to get that alert to fire. So this is what testing for client side injection looks like, right? You have you have to, as I've said many times, you have to get the alert to fire. A lot of challenges there. You have to be able to deliver it to a valid victim. There can be some challenges there depending on what it is. And then how are you going to weaponize that? What are you going to target? So all three of those steps, we have to make sure that we have a really firm plan. We have to bypass security controls. a lot of things that have to come together for a client side injection for reflected cross-ite scripting specifically to uh to work. So uh okay, let's go ahead and get our pages brought up here. So I'm going to do this one and we'll get our 8 by8 brought up as well. Okay, now let's go ahead and Oh yeah, that's right. It's the search thing. Just kind of glancing at this. I always think I ended up on on Google or something else, but really looks like a clone of it. Uh, okay. So, for windstream.net and our search.wwindstream.net specifically, again, we are probably going to struggle with get the alert to to execute. Now, let's come up here and I'm just going to call it victim, right? Who is the victim? Uh, how are we delivering the payload? I think we can kind of start with that. So, we need to know who specifically is our victim. You know, whether it's an administrator, another target user, anybody with an internet connection. Yeah, we're going to figure out that. And how specifically are we going to deliver it? And then we'll come back in once we have this and and start talking about ways that we can actually execute it because we don't even know who we're trying to target at this point. So there's no reason to talk about how we can uh how we can get it to execute. I'm going copy this over here. We'll do the same thing down here. And we're going to do a lot more testing on the actual compensating controls as we go through. But um let's come back over here and just see. So this is a wide openen page. there's no authentication to get to this page. So that's good. It means that I can deliver the uh the cross-sight scripting payload in a URL if I can get it to execute in here. I can deliver it to anybody because any user regardless of their authentication, authorization, etc. will be a able to view this. However, then the question becomes who's our target victim? because if it's just anybody on the internet, I mean, it's just getting JavaScript to execute is not going to be a ton of value for us, right? So, um, and the main thing that I'm noticing here, cuz typically how you're going to weaponize a reflected cross-ite scripting is you're going to attack the authentication. Remember in the other one, we we found that it does have authentication. So, that's a thing there. This one, at least, the the search.wwindstream.net net does not appear to have that. Now, it doesn't mean it doesn't exist. Doesn't mean there's not admin pages, everything in there on this specific subdomain. Um, but we're not seeing that. Now, let's uh let's do this. Let's go ahead and get our things brought up here. I think we're still in the right directory. We are. So, let's cat XSS targets. And then we're going to pipe that into GP again. Still, I can't type anymore, especially when the camera's on me. Uh, and let's GP for just the domain. So, what was it? Uh, it is windstream.net. I'll just do Windstream. And what I'm doing here, all right, we've got a few of them. I want to click on this. Oh, my default has gone back to Chrome. That's annoying. I'll fix it in between this, but I'm not going to waste my time right now. Let's just come up here and do this. This should load up our hacker one page and should have this in scope. So, let's go back in and just confirm one more time. I don't know if search anywhere listed on there. Okay, so the search is not listed on there, but it's covered under our right. That's a net page. Let me just make sure. I think we we looked at this before, but where am I going? I think we looked at this before, but I just want to make sure. Yeah. So, search.wwindstream.net is covered under the windstream.net. It is within scope here. 17% of the reports. Okay. So, um we can also make the assumption that because of this, it's not even an assumption. We could see some in there that there's multiple different subdomains in this. So, this is applicable. We're going to look at the scoping of the uh cookies as well. If we can find a way to to log in, um we can start to find out what those cookie flags and everything are. But if you remember at the beginning, we talked about the same origin policy. So, as we're starting to look at how to weaponize this, when we find a page that doesn't have authentication, again, we don't know, maybe there's something hidden within the search and we can do some scanning and stuff to try to pick that out. Um, in fact, we'll do that in a second. But the other thing that we can do is if we can get a cross-sight scripting, reflected cross-sight scripting on this domain, the search.wwindstream.net, net it is possible that we can leverage that to send attacks HTTP requests to anything under the windstream.net maybe some other domains that they have right so this is where the same origin policy and corors implementation start to come into play so any uh any web application within their infrastructure that's designed to work with this search.wwindstream.net net we can potentially send requests to HTTP requests to and they may be they may allow you to pull that data back using cores and so we can ping off this search.wwindstream.net domain to target some more impactful domains and this now gives us the ability to li to deliver it to anyone without any type of authentication. So that's where my mind is going initially when we see this we need to find a way to um like yeah what's what's going to be our target here. So let's come back over and I'm actually going to add into scope. I want to just focus into win stream here. So let's add that. Let's come in and oh yeah, I had a custom script there. I want to show only in scope items. That'll be totally fine. And this breaks us down to just a few of them. We do have quite a bit of different tools that we can use here as well or different endpoints. So, one of the things that I'm going to do to start is let's go ahead. Let's do this. I'm going to send this to intruder and we're going to get rid of this entirely so we're just looking at the root domain. Let me send this to repeater first of all just to make sure that that's okay. What happens when we send this? It does a redirect. So, oh, it re redirects us to the dubdubdub. Okay, I don't want that. So, I guess this is redirecting us to the same place. So, is there a get request that we can use? I guess it's just the one that we've already been using is really the only thing that we can do. Yeah. So, this SCP is going to be good. Uh, what I'm looking for is an endpoint that is going to return a 200 response. We're going to use that as our baseline, right, for uh for everything that we're doing. I'm going to close these out, too, because the light is bothering me. Uh, all right. So, what happens if we get rid of these? Not necessarily that we need to, but I'm just curious. I don't want that to affect anything else. Okay. So, that stops it. What do we need? Does it need both of these parameters? I'm trying to make this as simple as possible. Okay, so it just needs the Q. All right, that'll be fine. So, we'll send that one to intruder instead. I'm going to get rid of our other one. This is not uh no authentication, no cookies, nothing like that. So, that's perfect. Um, and then I'm going to add our payload to be right here. Right. So, we're just going to do some fuzzing. Um, we can do this in the pan lab as well, but it's just easier to do everything through burp here. And let me go ahead and load up from seclist web content. And I'm going to do let's do raft small directories. I really like these raft ones here. Just has a bunch of different things. And my hope is and let's let's say this as well before we know we got to know what our baseline is. So if I do arson there, do we get our redirect? Okay. So we can assume that as we are fuzzing for endpoints, if we get a 307 response and that endpoint doesn't exist or the other side is maybe it has authentication and when it fails the authentication instead of returning an unauthorized or or forbidden or anything like that, it just has a redirect. We don't know the answer to that yet. We've got to figure that out, but that's what we're starting to to probe in here. So um we're just going to test a few of these. Let's go ahead and just hit start attack. That should be just fine. We'll let it start to run a little bit. Um, there's our search. So, yeah. So, the length looks like it's going to be helpful as well. Why are these Oh, these are not longer. Okay. So, the CGI bin is not Ah, okay. So, perfect. Oh, it's a WordPress. Oh, no, no, no. Okay, so we're getting hits with Cloudflare and preferences is a page that we can use. Interesting. All right, so we're starting to identify things. We're going to let this run for a little bit there and we will come back to it. The other thing that I want to do and what's our specific come back to our nose. Um, yeah, it's this one here. Just the queue in the home. I want to make sure we don't have any extra stuff we don't need. So, in addition to this, I'm going to rightclick just on this endpoint here. I'm going to go to extensions. I'm going to come down to PAM minor, which I already have installed. In fact, I'll just show real quick. If you don't have it, if you haven't seen it, you come in here, B app store, PAM minor. If you sort by the popularity, it's gonna be the top one that's up there. It's built by James Kettle. Uh yeah, it's fantastic. So, we're going to rightclick extensions, come down to param minor, and I want it to guess just query parameters right now. Eventually, I'll do a guess everything because it's possible that cookies, headers, everything's might be reflected, but really for us, how we're going to deliver it, we're going to need to be able to to like every value that we control is going to need to be controlled within the URL. So that's why I'm focusing on query parameters right now. But the goal is to find out what other parameters are included in here that have some type of an effect on this page because we may be able to, you know, find like circumvent the security controls in other ways. So I I'm just starting to gather information. I want to know what other endpoints exist on this page and I also want to know what uh you know if there's anything hidden that I can possibly affect it. Maybe something else is going to be reflected in a different way, etc. You know, that's that's what we're always going to want to do. So, let's go in and do the same thing for this page here. Copy this. And I'm going to start by adding 8 by8 to our scope. And that opens up a lot more. So, yeah. So, we can see the windstream is just down here and all of these are 8 by8. within the 8 by8 ecosystem. Looking at this, it looks like we're going to have a lot of other opportunities to bypass that same origin policy and have impact with our reflected cross-ite scripting outside of the uh individual fully qualified domain name that we're looking at. So, um and we are seeing some findings here with searches. Well, that's good. Let's go ahead and look at that before we move on to the other ones. Uh let's see. So the first one here, this is just a typical request. What was the difference here? Let's bring this over a little bit. So it looks like there's an unlin parameter which is this SC. When the SC is included, we get a 400 response code. Whereas when it's SC along with some additional garbage, we get a 200 response. So that SC is having some impact. Come over here. How far can I bring this over to make it a little easier? So our request typically comes in with a 200. request number two that includes this SC parameter along with just some nonsense gives us a bad request. So that is very very interesting to know. A bad request typically tells us that something is broken. So now this could also be a possibility for a server side injection. But now this is great to know. All right, I'm going to document that first before we move on. I don't think the other one. Let me send this to repeater just to make sure. I want to make sure that this cash buster didn't have any impact. It did not. Okay. If this goes to arson there, it's all 400. All right. So, we'll copy the URL. Come back over to our notes. And under here, I just want to know I'll just call this notes for right now. And this SC parameter equals 400 response there. Okay, good to know. We'll keep checking back in a second. And then again, like I said, we want to go ahead and grab this because I think I've copied something over it at this point. And let's do the same thing. Click this through just to make it a little easier. Come to the proxy. We've got it right there. We see arson being reflected in the response. Send to the repeater. Confirm again. Okay. So this is going to supersite by8.com. So let's come find that up here and demo login.php. So this is where I think we're going. Where is it? Here. Here we go. There we go. That's what we're looking at here. So okay. Um and then we've got we got this error as well. could be some different targets, but um let's go ahead. I think I get a 200 for both of these. Doesn't make a difference there. So, yeah, that's fine. All right. So, for you as well, extensions, param miner, we are going to do guess query parameters and that's fine. I'm not going to worry about fuzzing for endpoints on this one just because we have so many different options. If we need to get to that, we can. I've also already shown it, so I'm not going to worry about showing it again. Okay. So, let's come back over to our intruder attack and see. All right. So, we've completed and what do we have? What do we have? So, these ones with a 500 response. This is a forbidden. And this is coming from the Cloudflare W. So, I don't right just to make sure render this here. Yeah, definitely CloudFare. So that is these two error log and WP includes are doing that. So let's come back over to our web application firewall. And we'll put that right there. I like to have these in markdown so they're a little easier to see. Don't know why I did that. Already thinking about my next thing. Okay. Now when we come up to capture, we have a separate response. Looks like just trying to do this verify if it's a human. Now does that happen every single time? Come over here to repeater. We still get the 400. It just wants us to Yeah, it just wants us to prove who we are. Okay. So, that's not what we're looking for there, but that's fine. Okay. So, I don't think we need to document those. Um, I think it's just part of the regular Cloudflare, but it's obviously there's something going on there. So, maybe we can see maybe there's something we can do if they already have an authentication. I'm not sure. We may want to fuzz for cookies just to see how maybe certain authentication cookies has an impact to it. I'm not sure. But let's come back over here. Capture form seems to do the same thing. So, maybe anything that has capture in it results in something that we want to identify, which tells me that it could have something in there potentially. But, all right. All right. And then we already know that search works. That's one that we're doing. And then the main one that we have here is this preferences. Looks like it needs some stuff to render. But let's copy this URL. Come back over here. Let's see what happens when we try and load this up. And I'm not seeing anything. Now I'm guessing that means that this is a single page application. And there's some type of uh calls going on within this JavaScript. Yeah, potentially right here query arson. Yeah, let's see if we can see from the proxy what happens in the proxy here when we uh over here. There's Firefox. And first of all, let's get rid of this Q parameter. See how that affects it. Doesn't look like it makes any difference. Although we do have arson being reflected here again. And it's being reflected in a different place than the other one. If I remember correctly, this one over here, arson is being reflected within this input. Whereas this one right here, it's being reflected within the session payload JSON object. So that's good. So, I'm going to copy this URL and I'm going to include this within our testing for this one. Now, this is not really helping me too much, but I'm just going to have this as a simple because these are essentially two of the same things, right? We have the same domain, same security controls. It looks like is there a content security policy or anything being returned over here? This looks like I mean a lot of opportunities for JSON injection. Like this looks like a better opportunity for DOM based cross-ite scripting. Uh yeah, once again, yeah, we can see the cookies are scoped here. I mean, there's a user ID being put within a cookie, so it's is this value being reflected anywhere? I guess it really shouldn't be. Well, of course, just right there. Is it separate from what we're doing here? No, it's not. Okay. So, yeah. So, there's two different options here. We've essentially got um Yeah, I want to make notes about where it's being rendered because this one right here has Oh, wait. I'm looking in the wrong place, aren't I? Shoot. No, no, no, no, no, I'm not. Okay. Yeah. So in this search it's got multiple different places that it's being rendered but then in the preferences itself uh we have the only place where it's being rendered is a JSON object. So once again right like it's I've tried to standardize all my notes and try to put stuff out there. I can do things like this but really you got to be flexible with your notes. You've got to uh you're going to face completely different things based on the technology stack and everything else. So kind of be flexible with it and just kind of take what you need to have so that you can remember what you need to remember. So um all right. So going back to this, we need to come back and answer our questions. We've started to poke around. We've learned a little bit more. We need to know who is our victim and how are we delivering the payload to our victim. Right? Very, very important. So coming back here, I want to know just in general. Let's just do a Google search, right? And we've got our AI here to kind of show us what is Windstream.net. Um, yeah, and it does for that it is a web mail service for Windstream customers and is also the company's general service internet portal. So now we should have users with a a web mail of some kind that we can target. Um it's parent company of of that there. So So that's most likely you're you're really going to have two different uh and in fact I want to I'm going to copy this. I want to get this in my notes as well so that I can remember that. So that'll work there. Right. So with this context, I think there's going to be two different groups of target or two different yeah targets essentially that we can we can focus on here. Um the first is going to be Windstream users and then the second is going to be Windstream employee/adins, right? So is it are you because this this would appear to be and this is another thing that you typically want to think about as you're identifying it. Is it B2B or B TOC? Right? So does that mean is it business to business or business to customer? Now this company itself and actually you know what B2B or B2C I'm telling you Google can give you a lot of information. So it is both B2B to B to C. Perfect. So that would include another level for our victims. Right. So we have single customer B2C and then we have windstream users company C to C can't I there we go so now we have three different groups of victims that we could target and the impact on these victims is going to be completely different from every one because This is they do both B2B or B TOC. So that means that they sell from a business to an individual customer. So they provide their web mail and everything. That's probably something where you can go and sign up through an automated system. But then they have B2B all types of different stuff here, right? Wholesale and everything. So you're going to with this B2B function or functionality and delivering to other businesses, you're going to have a lot of additional things that need to be applied here. Right? You can see there's just like the residential service whereas a business, enterprise, wholesale, there's going to be a lot of other opportunities to potentially impact that business with your payload. Okay. So, out of these three, I want you to stop and think which one do you think is the least important. If we were going to show an impact, which of these would I probably say care or I would care about the least as far as showing impact? Um the answer and it might surprise you is the employees and admins. Now if we can leverage that access to get further impact on their users either company or individual then that's phenomenal and if we could have a larger blast radius to those but and this is pretty typical I'm not too worried about or I'm not too interested in finding this company's data and showing them that I can excfiltrate their personal data. I don't like it's it's what you will learn especially working on a blue team is that you know while a company certainly doesn't want their own data to be exfiltrated if they are the only victim then it's it's not as big of an impact to them you know now I mean with that being said if they have some type of intellectual property or something where the the company's built around that then that's a different conversation but what companies are afraid of is you impacting their users. They're afraid of ending up on the news. They're afraid of reputational damage that is going to have downstream consequences in their ability to grow their business and be successful in their business. So, if you just come to them and say, "Hey, I got your secret code and I'm going to spend, you know, the next 12 months trying to build up something that is going to compete with you, there's a lot of things that have to go wrong before that's going to have really any impact on them. It's not what they want, and there are a lot of ways to show impact with it. But if you can come to them and say and especially with this company to company, what if you can come to them and say every single company, every single B2B deal that you have done, I can exfiltrate th those company sensitive data or I can leverage your tool, your web applications to have a negative impact on those customers. Even if it's just one, that's going to be big. But if you can do multiple ones, if you can do across all of them, that is going to get them to jump on that quickly. So, this is where it's so important to understand who's your victim, right? We want to start to target these users. I'm not going to try to get something that has an an admin, you know, something like that. I want to target the the users. Ideally, these um Why did I put C to C? Good grief. B2B, uh customer to customer. Yeah, I don't know if that really makes sense. Basic we want to target the uh B2B customers ideally and then we can fall back to the single customers probably more on like the individual webmail and everything if we can right okay so that gives me a good idea here now we don't know specifically the we want to get as specific with these as possible but for this we're at least starting to get you know a good understanding now how are we delivering the payload this is fairly simple um we with a reflected cross-ite scripting you really only have one option The payload needs to be within the URL in some way so that they can click on the link or you can kind of redirect them. There's a few other ways that we can do it, but for the sake of this video and especially for the sake of time, good grief. Um, let's just focus in on that. The way that we are going to deliver this payload is uh payload in URL get parameter delivered via fishing or whatever else, right? fishing, malicious redirect, something anything where we can control the URL where they're going to or get them to click on is how we can uh how we can deliver that. Um so this is all looking pretty good. It's going to be a lot of work to be able to actually, you know, bypass all these output encoding and everything. It's in my experience is these these ones that try to prevent the payload from executing in the first place can be a lot more timeconuming and a lot more difficult. But we've got a lot of different options here. Um, so let's go ahead and do this. Let's move over to our 8 by8 and let's do the same thing. I think that was right here. Just move that over for the sake of it. Uh, now and let's come and take a look. I want to know what this is. What? What is 8 by8 super site voice calls video conferencing meta uh messaging collaboration tools? So so they provide a lot of different cloud communications I would think is 8 by8 B2B or B to C. Let's get an idea of this here. I would imagine they probably have both as well. primarily businessto business. Okay, so they're going to focus more on individual business customers. Um, by the way, this would be and where this one down here. What is 8 by8? I want to get the same thing up there. Yeah. So, we have this one right here is business to business mostly. And I'll just pull something from here if they have a little blurb or anything. And of course, it disappeared. You're going to make me work for it, aren't you? Just go back. I think the first one that we had is probably good. Unified communication platform. I'll grab that as well. So, yeah, cloud communication essentially. It's fine right there. And I'll just put a little bit of separation in between these two so it's easier to see. And that'll work. Okay. So then most likely for this one, it's it's a little bit straightforward because we've got an authentication in here. So Ideally what we can do our victim is going to be someone who has the ability to log in to this supersite.8by8.com page and then has in fact let's just go ahead and write this out. So um who has a valid account for my8.com and uh ideally has higher privileges than free account if you can get a free account because I don't know right we haven't seen anything that allows us to register and I want to take a look at that as well again Google's always going to be your friend registration let's see if we can find a registration pl page page. Nothing is immediately coming up. So, this may be a situation where we are unable to wrong one. This may be a situation where we're not going to be able to create our own account. And it it'd be great if we could because if we could then just like when we were looking at with the stored cross-ite scripting, we would have a lot more insight into understanding what the application is, what it does, and we can craft those payloads to maybe change their password or, you know, we can do all that without having visibility into it. We're not going to be able to do that. But if we can exfiltrate a session, if you know, if we can do anything there, there's a lot of different opportunities. So I think for this one it's going to be fairly simple. Uh and once again we're going to deliver this with you know it's it's the same answer here. If we find a better way to do it we can but for reflected crossite scripting typically that's just going to be the default. That's what I uh I typically focus on. And again the malicious redirect is another way that you can do it very easily. But ultimately you've got to get the the victim to do something. Um yeah. So, for this one here, again, looking at the compensating controls, we haven't dug in too much, but I don't think we're going to have as much of an issue getting it to execute, although there's a lot less opportunities for where it's being reflected. So, there's a lot less. If you remember this one, we've got all these different output encodings and all these different types of output encodings. Uh whereas this one, I think we just have the one place and it's a hex encoding, which can be a little more difficult. But if we can uh if we can get it to execute, then our goal is going to be to target somebody who has access to this web application that we don't have access to so that we can I'm thinking exfiltrate data. So it's I think that's ultimately we'll have to look at the compensating controls a bit more to do it. So um how to weaponize. Let's do the same thing down here. That's going to be our next piece right now. I don't want to start I don't want to get too far ahead of us and start, you know, figuring that out yet because we've got to actually get something to to execute. But just to talk through it, you know, for our one up here for Windstream, uh most likely what we're going to be doing is trying to leverage this to either steal an existing SE session token from something or anything or I I would think for this one probably we're going to try to do a session routing attack on a separate subdomain. So if we can get the execute or the uh the cross-ite scripting to execute here, then we can find a misconfigured cores or maybe they already have the two different subdomains already have a trust relationship between the two and so we could force that user to go in on a completely separate platform and you know send a request to uh to change their password or do something that didn't maybe maybe gather up a bunch of information and then send it in an email because it's an email client to a a uh email address that we control. Those are all different options. Um, and we'll have to do a lot of digging into we'll probably have to find the web client and figure out, you know, what those requests would look like. There's a lot of leg work and stuff to do this here. Uh, whereas looking at our 8 by8, our goal here is going to be to try to simply get access in some way to this web application under the super site. Now, we may go and test the other ones. There's definitely a lot of opportunities with different subdomains to uh go to to violate the cross origin policy to get more impact there. But this is a really clear impact that we can do. So um all right. So really at this point I would go back and look at these two look at everything all the information that we've gathered and just make a decision on which one is going to be the best use of my time and I would start with that or which one do I want to do maybe you know um between these two I think that first of all this one's going to take a lot less time to test and if we do because it's only got one attack vector and then if we do uh get this to execute I think I want to look into the content security policy a little more here, but I I think looking at it, it's per permissive enough that I think we have a more of an opening on this one. You know, um I think getting past the output encoding and a web application firewall together can be very very challenging and timeconuming whereas I can at least rule this one out as a good use of my time fairly quickly. So now in order to do that, I want to dig into this content security policy because it's it's all going to be determined. And let me just see as well before we do anything. Let me see if I can see any cookie flags. They probably haven't assigned us a session token yet. So there is a PHP session that has HTTP only. Don't know if that's the one. I don't know if that's actually what they're going to use for the session or if it's just something that's that's assigned in randomly, but I'm going to make the assumption that it is. So, cookie flags, we have this PHP SAS ID. I can put that on there as well. So most importantly, this has HTTP only, which means it's going to be we're not going to be able to grab it with JavaScript. So we wouldn't be able to easily just grab it and send it off. So not ideal. Do we have Yeah, secure is true. Sure. um and only scoped to supersite.com. So it doesn't appear that this session is being used anywhere else. Now again, they may have a completely different mechanism to to handle session. I don't know yet. But that's good to know as well. So that's going to frame how we're going to do this. But all right, let's let's come back over here and let's see if we can figure out a really good plan to weaponize this if we can get in it. So, and what we're going to do, we're going to go through the content security policy here bit by bit. So, let's tab that out. Uh, we've got our script source there. I'm dividing this by I think this will have to be entered as well there. Yeah. So, I'm dividing by the semicolon delimiter which separates the directives. So, that's what you'll do as well. source there form action. So as you can see client side injections are very time consuming. They require a lot of thought and a lot of evaluation and this is what it really looks like. Tab this in over there. Right. So when you see people online that are going in and throwing a bunch of scanners and coming back, oh check out this awesome cross-ite scripting I got cuz I knew this super secret payload. I mean, yes, that can happen if you know that super secret payload and it affects specific technology and for a little while you can spread that across. It's not reality, though. Pen testing, bug bounty hunting. It's not sexy. I'm sorry. I know a lot of people want it to be. I know people want to have the, you know, you know, music going on in the background. That was meant to be like techno music. I don't know how it turned into a drum solo, but anyway, you know, people want to be sitting in the dark with the the techno music and all the fancy LED lights back here. Oh, I'm a super secret hacker. The reality is bug bounty hunting, pentesting, honestly, cyber security, it's it's boring more times than it's not. You know, it just kind of is what it is. But, you know, if you sit down and go through the methodology step by step, first of all, it can it's still fun. You know, it's still fun to go through and do this. It's still super rewarding when you do find those vulnerabilities. You're going to find a lot more doing this. And when you go through and do it correctly, again, there's a lot of people that won't. So, you're going to rule them out. You're going to you're going to get ahead of them. Okay, I'll start rambling. So, we're going to look through this content security policy step by step here. And then from this, we're going to determine exactly what our plan is to weaponize this target. Um, looking first at the default source. Remember, the default source is essentially a fallback. Any directive that has not been given some explicit directions, whatever you call it, is going to to leverage whatever set for default source. Default source is just set to self. That is going to be the most restrictive that we're going to have. So if we just saw default source self, it's going to be really difficult for us to get a lot of things. However, we have script source, connection, image, style, form, object, frame, media, all of these are going to impact our ability to uh get a reflected cross-ite script or weaponize a reflected cross-ite scripting and they are going to overwrite what's written in the default. So I'll just go fall back will be written highly restrictive. So, we just know if outside of what's been written here, we're probably not going to be able to do too much or to do too much else. However, that's really good because one of the first things that we see, it's really good that we have these others because one of the first things that we see is our script source here, right? So, number one, it has unsafe eval and unsafe inline. So that means if we can inject inline JavaScript, it will execute. Okay. So what that means if it doesn't have this unsafe inline and then we come in here, you know, and we find some way to write in like I'm not going to try to do all that now, but if we inject into the DOM and we can actually write out script alert one script that is an inline script. So if unsafe inline is not set then that may not execute. Some other things will impact it but it may not execute. So first of all we need to make sure if we can get that and then we also have unsafe eval which uh if we it's more of a DOMbased type of thing but it sometimes I can go through there but if they're using eval we'll see more on this in the DOMbased side. If they're using eval and passing user controlled input to it this directive is going to allow that eval to execute in an unsafe way. Uh remember eval is evil. If you ever done any coding eval is evil. That's one of the number one things they say. Don't take us controlled input and put it in there. Don't you know if you're if you're this this happens a lot too JSON. So um you'll see people making the mistake where they they're getting all these different types of JSON objects and they don't know what it's going to be. And so instead of using JSON.load string, they use an eval and then have some conditionals on top of that. That's a pattern that I've seen a few times that that I've been able to ex or escalate. So, we're good there. Now, we also have the script source. And I talked a little bit about this, but we're going to dig into this a lot more. The script source tells the browser where these scripts are allowed to be loaded. So, this is separate from an inline script. If we can inject an inline script, that's where you have the open and close script tags. That's where you have the JavaScript written in the actual DOM itself. However, if you don't have unsafe inline it and you can load an external script from something that's allowed within the script source here, then you can still get that JavaScript to execute. You just wouldn't be able to do an open and close script tags. You would have to go script source and it would have to come from somewhere here. So, here we have, and again, I talked about this. We've got a fully qualified domain name, which I don't know, but it's probably not going to be able to get any access to this. Uh, I would certainly do some research on it, except the other things that we have, I don't need to. I've already got a path for it. But typically, what I would do is load this up and just see, hey, can I go and register an account to where I'm going to get my own URL and some type of web hook or place to send information that I can use that's still under this domain. Most likely, you're not going to be able to, otherwise it shouldn't be written like this. Well, I mean, it'll happen. I don't want to say that, but anyway, not going to do that here. we don't need to worry about it. Um, we have this as well. So, any 8 by8 page, we can uh import that. So, if we're unable to get a script to write here, if we didn't have the unsafe inline, we could potentially inject a a script on any of these other 8 by8 subdomains. And then if we're able to inject that in there or or essentially find a way to host a script, I should say that rather we'd have to find a way to host the script there. Um, I don't know if that's possible or not. We have a lot of different opportunities. But once we have once we host the script there, then we could potentially inject the script source tag and pull that in and it would allow it to come in with this 8 by8. And then the most important here with the start.vc again as I talk I did a little more research on it too. Anybody can go register this. So what this means is that I have the ability to either inject inline script or I can just host my own malicious page that's av script on it and I can import it in that way. So that's what I want to do and I'm going to go ahead and come down here and weaponize it. So I want to host malicious script on star.vc VC something that I register uh you know it's going to be a complex script and then uh yeah I mean I think that's fine right uh I'll just do script source equals evil.vc VC, right? Something like that. Just to show how that's going to happen. This allows us I can go and host that on any page that I want, you know? So, evil VC slash uh, you know, exploit.javascript. I can have whatever I want. I can have this do a hundred different things. And so looking at this here, because we don't have the ability to know what's on the other end, here's how I'm going to show impact. And this is one of my favorite ways to do it. By the way, I've already decided I'm going to focus on this one because if if you know, if we could get this to work, it'd be super cool. We we won't be able to show it here. But um here's what I want to do. I'm going to build out a whole complex JavaScript file and this is going to be included in my report if I've got any that is going to uh that is going to gather a ton of data leveraging victim session. Right? So I'm going to have this complex script that essentially starts fuzzing for different endpoints and starts sending requests to different places and anytime it gets a this is all going to happen in the background. Um and actually the first thing I would do the first thing I would do with this complex job file is uh overwrite document.body. So that's going to be the entire page of what the viewer sees with loading screen. So the first thing is going to happen again this is all going to be in my report. This is how I'm showing them impact. This is why I'm I'm going from, oh, there's an alert popped like, oh crap, somebody could do this today, right? I'm going to have a JavaScript in there that replaces the entire document.body with something that looks like it's loading. So, the user kind of just sits there. That'll give them more time to allow all of that to run. And then HTTP requests, fuzz for endpoints, valid responses. Right? So, we'll just kind of keep gathering there. And then I'm going to set up a database and API potentially. Oh, that may be more difficult as well. And I'll talk about why in a second. Okay, let's let's pause there. So, what I would do is I would set up a database or an API that I controlled and then as H didn't mean to write as, but that's okay. as HTTP requests get valid responses full sent to API. Right? So this is a type of an attack that I love. We're going to overwrite the body with a loading pay so it looks like everything is loading. Then we are going to in the background using Ajax, we're going to be fuzzing for all these types of different endpoints. And anytime we get a valid response, we're going to take that response and we're going to send it out to our server. Now the problem with that is that's exfiltrating data. So we need to look at some of the other content security policy things here to exfiltrate data. And the first thing that we see right here again unfortunately is connect source self. So that is going to make it much more difficult. The the connect source itself, it restricts where uh API requests, websocket requests, you know, fetch, all that type of stuff. It affects where it can go. It'll block it within the browser before that request even goes out. Remember that's different than cores, which the browser will allow that request to go out. It just won't pull the data back in. Right? So with connection source here, we have connection source self. That means that with Ajax calls, with HTTP, we're not going to be able to exfiltrate that data specifically to these. However, there are some other ways that we can do that. One of the ways that we can do it and why not exfil data with API calls. Now, these other directors are important because they do control how we can potentially do this or not do it. um the image source right here. What you can do actually I think I could potentially show it in here. Do we have an image object? Yeah. Yeah. So we have an image object here. We should be able to do instantiate it dot uh source equals let's just go. Right. So we can set this up. I think this works. I should have tested this out before but that's what I get. But you kind of get the point. Right. So, if we go in and uh if we can embed an image tag in here, then we can append within this the the cookies that we're trying to excfiltrate or even each one of these HTTP requests as long as we can get it within JavaScript. Um, so I guess this what I just need a new back here. There you go. So, here you can see we actually sent a request and then content security policy is blocking that. Now if we come over here the reason for that is it only allows for self to point to chart Google APIs there or this server something right there. So um so we cannot use an image beacon to exfiltrate data to our server but can we register something with these domains? Right. So, um, and it would really be one of these two. So, just I mentioned before, I would have to go to each of these. And I think the chart.google APIs is probably the most likely one I can do. Do I have the ability to set up my own web server under these domains by leveraging the actual service? And then from there, can I capture the HTTP requests that are coming in? You know, it doesn't mean that I own the server, but possibly I can leverage this service that they provide in order to bypass the content security policy here for for the image. So um there is some potential there right and I think what we'll see is if we come over here we go up one more time to do this again but instead we will go to what was one of the ones chart.googleapis.com googleis.com. Now we no longer get that issue. Now we're getting a separate where it's just like, hey, this doesn't exist, but we're not getting the content security policy because we or the violation of the content security policy because that domain is allowed within that. So that's one way that we can potentially exfiltrate data. And we're going to see that coming through a lot of these. Now style source on the other hand, we do have unsafe inline. So style source can potentially be a way that we can exfiltrate or I mean we can actually get the payload to to execute. Um I think as well let me see this. Yes. So this is new. This is a new feature of CSS to where you can actually put in this URL that would load in like see a background image. This is another way that we can potentially exfiltrate data although I haven't done that. I don't know how we would append those URLs on there to be honest. So it's a possibility. Um I'm going to say we will do execute. Right. This is also another opportunity where you can inject style and then uh the the style tag itself we can be executed to or can be escalated so that it executes JavaScript but we don't need to worry about that too much. That would typically be used to bypass if we didn't have unsafe inline up here which we do. Um maybe Xfield data with URL. I'll have to do more research into that. I remember hearing about it but I don't know uh I don't remember exactly how to to do that there. So all right wrapping up with these last few. Uh the form action here self just means when when you have a form and so so a form action anytime you have an HTML form there should be an action attribute within that form HTML tag that either has a an endpoint or it has a full URL. If it has a full URL it's likely sending to a different domain. So instead of going to I forget what we're on again supersite right instead of going to supersite.abya.com it may go just to you know uh off.abby.com or whatever it may be you know um this form action self over here says that those actions cannot be changed to go to a different uh different URL. So another way that we could potentially exfiltrate data is we could use JavaScript to write essentially a a hidden form into the DOM and then we would capture that and execute it all within JavaScript and it would send that HTTP request which is not an Ajax call. So the connection source doesn't matter as much here because it's it's sending out in a different way. It's not using JavaScript to send it. However, the form action itself is going to prevent us from uh using that to exfiltrate data. All right, so wrapping up with the last few here, object source. Uh this has to do with like Flash and and Java outlets and everything. I'm not too worried about that. Um this is going to allow us to import some, but that's not as applicable anymore. Some browsers will block that completely, so I'm not even gonna play with that. Frame s or Yeah. Yeah. frame source. Frame source determines where an iframe can be loaded in. So, uh there are some ways to exfiltrate from this. Again, we got the starv. So, uh I just want to make a note of that. It is possible if we can't figure out a way to exfull data anyway else, we can possibly register avo. So, this star.vc VC is really opening up a lot of opportunities that we wouldn't have had otherwise there. Um media source as well, right? You can exfil data potentially with the uh video. So if there if there was a star.vc again, then you can do the I think it's video thing there and uh source just like everything else equals evil.com, you know. But we don't see that. Um I'm not even going to bother with it. This can come back there. Actually, you know what? I don't need this cuz we're filling everything out. And then the last the frame ancestors which we've seen popped up a few different things. Um it can have some impact on the way that that iframes loads what what different pages we can load in. Again, this star by.vc basically negates it though because we can register it. So I do think that our data expiltration is going to be tied to the star.vc somehow. I want to find a way to and I'm just going to kind of put this up here. Well, I guess we've already got this up here. Yeah, but this is it. So, let's even go back one further. Register. Yeah. So, we're going to register a malicious.vc site, which looks like it's going to help us exfiltrate data. We're going to try and send these and then ultimately yeah, we're going to exfiltrate data through uh gaps in content security policy. So that's it. Again, I like this. Um I definitely want to go and just show here in a minute some, you know, some fuzzing on these different outputs and trying to get the payload to execute. So, we'll do it for both of them, but I'm going to do kind of some short ones here. Then, I'm going to come in and we'll really kind of dig in and try to get uh use multiple different strategies to try to get the payload to execute. But that's it. I mean, we have a very good plan here, right? Who's our victim? We're going to try to find somebody who has a valid account on this 8x8 super site, which is something that you can't register for. So, we know there's value there. We they at least we can't find a way. So, we know that they want to keep people out. We know that we only want uh individual like real users to be accessing this application. So that's the person we're going to target. Ideally, they can have a higher version of privileges and we can try to do some research on what those access controls and everything might be. But we are going to deliver it with a fishing attack where the payload is going to be included within this destination get parameter. And before we do that, we're going to register a malicious VC site. We are going to host a malicious JavaScript file that is going to be incredibly complex. And our goal is going to be to excfiltrate data in some way. So the two things that we need to do now is we need to find a way to get this to execute. And then if we do that, we need to find a way to get through these gaps in the CSV to actually exfiltrate data. So we've got two steps now to a valid client side injection on this one here. So, um I'm going to take a short break and come back and we'll actually go through that process testing on both of these and then I'm going to go ahead and move over to store cross-ite scripting and we will do everything that we just did there. So, I'll be back in a second. And I'm back. So, the last thing that we have to do for this target here, we we know who our victim is specifically. We know how we're going to deliver the payload to the victim. We know what our plan is, how we're going to weaponize it. We know that the way we're going to weaponize it is going to work within the security controls. We've tested the content security policy specifically here. So the only thing that we need to do is bypass output encoding and get this single or double quote rather to render. Now when we do this, let's come and just load this here. And we'll do most of this through B sweep, but just to show within the actual browser, I'll come search for arson now where our payload is being reflected. Right now, this is the only payload that we know we have. It's being reflected directly within the pay the uh the payload here. And it's not being processed. So, it's not being changed. No output encoding. So, this looks like the work of a virtual DOM. And I want to come back up here and see. Now, I don't see that here. So that's strange. It's being loaded in in a way that looks like it's not being processed or maybe these aren't actually being processed. It could also just be written in by something like an inner HTML or anything where it's not actually being rendered uh in and of itself. That is strange. I'm surprised to see that because I think if we check some other like if we do a greater than less than here and again we'll do the same search for it. Yeah. So now we're seeing the output encoding. So let's come back over here. We need to talk about the output encoding before we start worrying about curf. And what do we have? We have a greater than simple gets converted into I do it like this to make it a little easier. So our greater than symbol turns into amperand gt going on. So that's like some proper output encoding which you would expect to see. Uh and then it's going to be rendered in there. However, it is strange to see that does not uh get modified or encoded rather encoded. However, it does not get processed in GDOM as well. Right? So, the methodology that we're going to use to try and bypass this or get this to work is the same. I'm actually going to show that methodology up here because there's just so many so many different options for output encoding that I think it's going to be much more interesting to look at with this one. I think we're going to learn a lot more from looking at it. But ultimately, that's it. Ultimately, what we need to do is we need to get this single quote because of where this this payload is rendering within the DOM. it's rendering within an HTML uh attribute basically an attribute of an HTML element the the input element specifically we have to break out of this value here and then we can add additional attributes or potentially add a you know the the greater than symbol and then we could create our own elements within this div but fundamentally that's what we have to do we have our game plan we know how we're going to deliver it we have to break out of that so what we're going to do is a lot of fuzzing you know now this can be slow manual methodic fuzzing it can the automated fuzzing, right? You typically want to do a combination of both and we'll walk through those a little bit here, but that's really the goal at this point. If we can break out of this HTML element in some way, specifically the attribute, but ideally the entire HTML element itself, then we can most likely get a very effective working payload. So again, the methodology is going to be the same, but we are going to focus here on our uh uh windstream net where it has multiple different output encodings. Let's actually Well, we got those broken up a bit here. So, yeah, you can see on this one in the title, we've got a proper output encoding with the amperands. Over here, we have it uh oh, this is in the entire object. So, we are using uh Unicode down here. So, completely different way to do that. Uh once again, here we see the same encoding, although the actual encoding that we're looking at or that we're looking to find, I think, is going to be right here. the percent three Charlie and three echo because this was ultimately like an arson tag put in there. So here we have HTML tagging or encoding. We have a typical one right here and then we have yeah some typical ones right there as well. So let's kind of get these labeled right and I just I'm sure this has some type of a name but uh I don't know what it is off the top of my head and I think that is fine. Let's see images here. This one is going to be hex encoding. And then finally we have and type typical and typical right here. Okay. So that kind of helps us break it up. So we have five different attack vectors that are coming from or five different opportunities to bypass the output encoding for every single unique character that we have. So this is the reason that I like targets like this for trying to get the payload to execute. And remember, we're going to have to deal with the web application firewall as well. But this attack vector here is loaded in five separate places that have five different areas where they have to properly encode all the different user controlled input that could be coming from an attacker. So there's a lot of complexity. Remember, I love complexity. Complexity leads to vulnerabilities. So that's what we are going to look for here. Now, I'm going to go ahead. I'll tell you what, I can just reload this here. I got blocked. Did I include a payload or something? What happened? This is trying to go to somewhere else. I don't know why that happened. Let me come up here. Don't tell me I got put on some type of block list or anything. Oh, I must have gotten blocked because we were doing the fuzzing. Okay, so this this is why web application firewalls can be challenging. Um, yeah. So we have sent too many requests and now we're not you know that came from if you remember we were doing like our param miner and and we were fuzzing for these over here. So we just ultimately sent too many requests and we hit the distributed denial of service block on cloudflare there. So um let's do this. I am going to pause the video for a second. I'll get a VPN set up and then we should be able to test successfully there. One second. All right. So we got a VPN running um coming in from a new VPN. Right. It checks the VPN for uh the DOS protection on Cloudflare. So, we're good to go there. So, we can go ahead and continue our testing. We are going to do manual testing for the most part. So, uh we won't get that block again. But yeah. All right. So, we're loading this up. Let me go ahead and reload it here just so it's on the top of the browser. I'll tell you what, we can go ahead and close out of this. Just discard it. That's fine. I'm not going to use it here. Come to our proxy. And here we see the request that we want to test. So, let's send this one more time. And we see our arson. And actually, that's right. So, we need to find a completely new canary. Something that won't give us any results there. So, let's do this. Now, we have nine. Let's just copy the entire canary and see what happens because the arson may still be showing up in something. Oh, we still have nine. Okay. So that's more than I remembered having. Oh, that's right. But there's a bunch of ones that are very similar. So these are all going to have the same type of attack vector in there and that piece there. Okay, easy enough. So what we need to do is we need to start figuring out how the uh how these different output encodings are handled. So, I'm going to come in here and I'm going to add in a less than, greater than. We don't want to put in a full script or anything cuz that's going to get blocked by the web application firewall. We want these uh we want to put in a sequence of unique characters that we know we want to use to bypass the output encoding and just see how it's handling it. We've already done this to a point, but we're going to look at all of them back to back. So, let's really start with the three main ones here cuz it's right. we're going to need open uh and close uh you know to be able to open or close an HTML tag. So the greater than or less than or we're probably going to need double quotes for just about all of them, right? So this and let's make sure that covers all our payloads. So this payload here, we're going to have to put in an HTML tag in some way. So we are going to need that greater than less than down here. We're in JSON. So we're going to need the double quote in order to break out of this. Now can this value here be used to possibly do a DOM based cross-ite scripting or anything else? Yes, and that's something that we would look at as well when we combine this into an entire methodology. But for now, just looking at reflected cross-ite scripting, so we need a double quote in here. Same thing. We are in an HTML attribute, so we need a double quote in order to break out. Same thing in each of these. We're in the href attribute, so we got to get a double quote for all of those. And then finally here, we're in the middle of the strong that's in a div or a paragraph that's in a div. Here, we would need to have uh open or close there. So, so fundamentally in order to bypass the output encoding of V thing, we need to get one of these three characters to render. So, let's just see how it handles these. And hopefully the W is not going to kick us back. It's not. Um, so yeah, we can see they're all being encoded there. Here we've got the Unicode. Unicode, although our double quote there looks like it's not being encoded. I mean this looks like it's processing typically. Let me see what happens when we do a comma, right? Because the next value that we would need would be a comma here. And let's do a let's just do a whole thing. Parson, let's see if I can inject that. Okay, we're not getting kicked back from the W. We're coming through here. All of that is being encoded. So, they're definitely concerned about anything rendering directly in the DOM. Oh, you know, this would need to be a colon, wouldn't it? What I was thinking there? So, we see it's not really being processed. Let me let's show this response in the browser. Copy that. I mean it does look like it's doing something right here. You can see where the output encoding is being loaded in there but remember in the actual request we can see it. So this may look deceptive. Uh and then once it's actually loaded into the DOM, we see that there is some escaping happening there, right? So the uh backward slash here to start the unic code. So that's one character, that's one character, and then we have a backslash starting before our double quote. So that is preventing us from actually controlling or writing directly into the inline script there. Now again, there may be ways to bypass it. I'm actually more bullish about this one specifically compared to any of the other ones, but uh that's good there. And then what about in here? Here we're seeing all the typical output encoding. I'm not seeing that we're going to be able to break out of that. Same thing, all hex encoding. Hex encoding, ironically, is one of the most difficult ones to break out of as long as they don't do any processing on the back end. If they just take this raw thing, they don't ever decode it and they put it right back out, which sometimes they do. Uh, I'd say more often than not they do. Then it's it's ironically it's one of the simpler implementations, but it's also one of the most effective. All right, let's come down here. Whoops. 89 and number nine. Yeah, we've got codes here. So, out of all the ones, the the JSON payload looks most interesting with this one, but that's fine. Uh, we don't know for sure right here. So, let's go ahead and send this again. We've got all of our nine payloads. So, that's what I'm going to start doing. And um I know I have it laying around here somewhere, but you know what? I bet it's in here. Hold on. I'm going to do this on the camera. Forget it. Y'all know that everything in the background actually has used. Yes, that is. All right. This book right here, JavaScript for Hackers, Gareth Hayes. This is where you're going to use the methodologies in this book. This is the most effective. I got stickers falling out from Defcon. This is the most effective way to do this. This is what I'm going to do here. I would sit here for a while. I would go through this book. I would read through this book. I would understand everything about it and then I would come and try these manual bypass techniques understanding the way JavaScript works. That is the most effective. Very timeconuming, very difficult obviously, but I cannot recommend this enough long-term. If you want to hunt for client side uh for client side injections, you know, especially cross-ite scripting and everything, you need to get to this level where you have memorized this book and you have a manual methodology to go through and really apply the intricacies of JavaScript into your testing. So this is what that manual testing looks like, right? We would go in and use different codes, different payloads manually, one by one, and looking through each of the different outputs, we would find what the the results that were, right? Is it have any impact? are we getting to bypass anything? Um, that's obviously going to be way too timeconuming. That's a whole other series of videos and everything to do. So, I'm going to leave you to kind of go off and do your own methodology. It's also super advanced. Um, but that's where you want to get to. That's the goal. That's where the the field post or the goalposts are. But, let's go ahead and move over to some automated testing a little bit because the next thing that I'm going to do, I would go ahead and send this to the intruder just like we did before. or we're going to start a new one, but I'm going to put my payload here at the end where there's really no no characters or anything. And now I want to go ahead and load up some payloads from here. I'll go back in seclist. We're going to go to fuzzing. And within fuzzing, we're going to find some payloads here. So things like special characters. Let's go ahead and get that loaded up. Let's load up special characters URL encoding. Right. We'll see down here. We have a lot of these. Actually, you know what? Let's Let's clear these because I like having the Oh, cleared them all. Shoot. Didn't mean to do that. Um, okay. Come back here to the regular special characters. Get that in there. But I also want to do if we come up here to URI hex. Let's open this up. This is going to have every possible hex sequence including some of these characters like null characters and everything that we are not expecting. And so I'm going to come over here as well and I'm going to add in our three main characters. We're going to do the uh greater than or that's opposite you know less than greater than and then a double quote because some unexpected asky characters like this may end up causing the the uh application the output encoding to break. Right. it may ignore everything that's that's further on it. It may cause something to break and go into a try catch. And the try catch is going to allow that raw data to go through. Um, that's what I'm hoping. So, I'm putting the payload here where it's going to test some of these characters where I can see it. But then I also want to see if anything's going to break and possibly have an impact on that as well. Now, I want to keep uh adding in some different things. We have our big list of naughty strings is a fun one to do. This includes a bunch of extra stuff, but right, it just kind of gets to some more specific payloads. Throws a bunch of just different things out there to see what happens. Some of them are applicable to this, some of them are not. Um, I can do a command injection as well. You know, I typically just kind of try to feel it. But right, we're just throwing fuzzing is throwing unexpected input at the web application and seeing how it responds. So, that's essentially what we're going to do. And I think the last one I'll just come over here to the XSS and uh let's try some let's do some let's do ones with Jason hats. Why not? He's got a couple that are down there that are very good. All right. So, we've got a bunch of different unexpected input that we are going to throw at this web application. Let's uh let's go ahead and do that. But I am going to uh where's our resource pool? I'm going to dial this back a little bit so we don't hit a uh block. So, I'm going to do my low and slow, which if you've seen any of my live streams or other videos of stuff, you know that I do this a lot. Two concurrent. Uh, let's put 150 milliseconds between that with random intervals. And we'll do some automated throttling. Actually, the throttling itself, what uh what was the response that we were getting before when we were getting blocked? We were getting a 403. So, that's what we want. So, we want to actually forget this. we want to do if we start hitting a 403 then go ahead and start throttling it because uh we know that we're we're getting blocked. So, all right. So, let's go ahead and run that and it'll go a little slower, right? We'll let it keep going through here. And interesting, the length is 409 response there. So, okay, we'll come back and take a look in a second. I just want to let it go. And in the meantime, so the this is one way that you can do automated testing. you can go and throw a bunch of different payloads at it uh or a bunch of different characters, bunch of different sequences, right? You're going to do fuzzing and then we're going to go through and manually look at what the differences are. You can automate this as well. The problem with automating especially like known uh client side and like cross-ite scripting is that it's not going to fire the alert without you know seeing it. So you you have to have something that loads it up in a headless browser or you have to have an automated scanner that writes to you know a console log or anything like that. So, let's just do a quick search. Let's go GitHub uh XSS scanner. Let's just try that and see because there's a there's a bunch of different tools. I don't typically use these to be honest. I'm sure they're great. I just, you know, I have my methodology and I like to to use my This looks like a really great one though, you know. So, and you can see the types of payloads. I mean, they're going to be doing the exact same thing that I'm showing manually. It's just all going to be going through on an automated thing. I'm sure this has a headless browser component where it's opening up, but I would definitely do this. And you know, I'm not going to go through the process of showing how to install and run any of these. The the goal of this video is to show a and methodology, how to teach a methodology. Um, but at the same time, if if you're looking at this at this point, you're saying, "Okay, you know, Harrison, I need you to stop and, you know, I really need you to show me how to do this." You're you're not at the point where you can be testing for client side injections. I'm sorry. That's just the reality. If you don't if you don't know how to download, install and use a basic command line tool like this, then you need to pause what you're doing and go back and learn that learn some basic, you know, Linux stuff out like th that is going to be a critical thing that you'll need to know. So again, I'm not going to show these in the videos. Um, if that's something you want me to show, I would recommend hitting pause going. All you need to do is use it, right? Get a free version of Ki Linux, go through the things. It's it's easy, right? And it's got instructions on how to do it. like right here. This is literally how it's four commands to to install and use. So, um, but yeah, I definitely recommend using these, you know, especially in your in your automated system. But just remember, everybody else has access to these. So, if everybody else has access to these open source and everybody's using the same payloads, then your bug bounty hunting becomes less about uh finding something other people haven't found and more about speed. Now, that's you also go to heavy recon where you're doing a lot of recon to try to find targets that haven't been tested and then you can do these. But it's it's much less likely that you're going to find a target that someone hasn't found doing recon compared to finding a unique string in this unique set of compensating controls and their unique uh output encoding that will potentially bypass all of those things. That's just more they're both difficult, but that's just a little bit more likely. So, um, definitely spend some time going through and testing these. Uh, the other thing that I want to show is, uh, and I've talked about this in my first video, but polyglots. Polyglots are, let's just do here's one here. Let's look for a GitHub one. A polyglot is a really unique sequence of strings that is designed to execute in several different environments. So, this is something that I would definitely leverage as we're trying to get this payload to execute. And again, if you haven't seen part one of these, go back and watch part one because it's all about getting these payloads to execute. And that's why I don't want to spend too much time on this. I want to focus on weaponization. But polyglotss are great, right? You get all these different types of polyglots. Um, build them into a word list. There's a ton of word lists that are that are out there. In fact, let's just see doing some simple searches. GitHub word list. I mean, I know we have some just in the the seclist folder that we were looking at, too, but these have a bunch of separate ones in there. XS without an alert. Yeah, see there there's some good ones there. This looks like it'll make a call back back to a server. So, that's how they're detecting whether or not it's executing, which is another great way to do it. Kind of treating it like a blind cross-ite scripting, which is a whole different video. I'm not going to go down that path as well. But, um, oh, and perfect. So, uh, the last thing that I was going to show for the automated testing that in my opinion is a perfect middle ground between the two is going to be this here. So, you've got uh this this cheat sheet that was created by Gareth Hayes and and the team over at Portswigger that has just a a crazy I mean really like everything that you can think of to try to do different combinations of payloads and even ones that maybe only work for individual browsers. Don't for bug bounty hunting, you want to stay away from this. Stay with all the browsers. You don't want to do something that's only going to execute on Safari. It's they typically that's not going to be within scope. Very rarely is it. Um I don't even mess with it when it comes to bug bounty hunting. So stay within all browsers. But this has a lot of opportunities for granularity, especially let's say if you can get some of these characters to load, but then maybe it's still not executing or there's just one or two characters that that don't work cuz these have a lot of different variation to where, you know, if they're blocking on alert, well, maybe this console log will happen. You know, blocking on scripts. It's got, you know, here's one from videos, audio controls, SVGs, uh, anchor tags right there. So, all types of different ones. This is going to be my recommendation. And you can get the full, you know, you have all these here and you can copy the payloads to your your clipboard there. And when you come back over here to intruder, let's just do uh let's send this to Intruder again. So, we just have another one. And we can paste this. You can see it's super super easy to go through and build out your your different payloads here uh to populate it. So, this is my favorite way. I don't typically just copy and paste. I will go through and identify like what's working, what's not working. I start with the individual manual characters. I move on to this type of thing. I definitely throw a bunch of payloads that are known to it. But a lot of times that's I just assume those are already going to be found. So these are all the strategies that we can use to uh get the alert to pop essentially to find out that we have a successful client side injection. And again, if if you if your hope right now is that I'm going to dig do a real deep dive into this, um I'm not because I cover that in a 5h hour video uh part one. So, please you can go back and watch part one and that should give you all the answers you need to go through and and try to get this to execute. All right, let's come back to looking at here. We can go ahead and pause the attack. I don't want to keep going too far, but let's start by just looking for some variations just to see what happened. Uh oh. And I think we even Well, these are four. Okay, so we're getting 400 response bad requests from some things, too. So, we're definitely getting a lot of variation. All right, so we want to come over here to the response. We want to bring this up a little bit. And now, again, there's there's much better ways that we can do this with automation, but this is how I typically prefer to do it. Uh, at least to start with as I'm starting to see how these are responding, you know. So, here, first of all, the output encoding doesn't know what to do a lot of with a lot of these more complex characters. These are things that are going to be like emojis, uh, Chinese, uh, characters, anything that takes a a very large number of ASKI characters. It doesn't really know how to kick those off. Now, it's not affecting the other encoding that we have, at least not from what I can see. We're not seeing the, you know, we're not seeing anything break and then it doesn't find it. Strange that we have 14 instances of arson on here, though. Okay, so once again, coming into here now, we do see that. Was that always there? Was I looking at that early? I probably was. It's so hard to take everything in as I'm recording this is I go back and watch these later and I see things that I miss all the time and it just like I smash my palm into my my forehead. Uh sometimes it's painful to rewatch these for me, but it's good. You know, the goal is just to show what it really looks like. This is real bug bounty hunting. Um you know, and uh people make mistakes all the time or you miss stuff and it's Yeah, that's why you just keep hammering at it. Uh, okay. Not seeing any impact there. This just turned into a wild uh thing there. Oh, this is so the SC that we found earlier, it's it's being appended here. I don't know what we could do with that, but maybe that's why including the SC breaks it. That's strange. Yeah, I'm still seeing a lot of hex coming through there. And what I'm hoping to see is some of those special characters that we included actually written into the DOM here. I don't know if we saw this before. So, this is kind of strange. We're still not seeing any of those special characters. And this is just one, right? So, let's um you know, a lot of these because it's being reflected Oh, this was just something that was written in there. Okay, let's let's come down here a little bit. Let's find some more interesting payloads. And these are all trying to see any major variations in length, but let's just take a look at these. Right. So, we've got all these um all these different ones here, these different hex values that are going to be converted in. And and usually I'm I I'm like I really want to know what the null bite does. Let's just see if any values are converting here. Again, this is going to be super super tedious. Yeah. See, so there's a very strange Unicode character that I wouldn't expect to see, but we're not breaking out. Those are still all being encoded. Those are still all being encoded as well. Yeah, we're not seeing any breakout on this. Little bit of a different encoding going there. All hex as opposed to these are different. I'm not liking that. So, you can see how this is going to be a tedious time consuming process. Um, I don't know if null, what was the payload here? So, it's just sent null right before that. Yeah. So, that's just going to be written there. Um, do we have the Let's Let's go all the way down to the bottom. Let's see some very strange variations here. So, these didn't even work. And now that could be they could also just be taking a little bit, but let me see what happens here. Oh, it does. It's just hitting the I think I'm actually hitting a DDoS block now on this. So let me uh go ahead and switch on ProtonVPN. Once we see it connected there, we should be able to make that request. No. So I guess this is just being blocked because of the payload then. It's not actually the IP address or a DOS block. Yep. Yeah, that's true there. Uh, okay. Come back, show another couple. I just want to see if there's anything that's a really big outlier. These, uh, these 400 responses are strange. Um, oh, maybe it's just a space. It's causing it to do that. Wonder why. Let's see. Okay, so all these are 102. Any bad requests there? And then we come into the forbidden. So yeah, not a huge amount of variation there. Okay, so that's essentially it, right? Uh remember manual. Start out with your JavaScript for hackers. Get a manual methodology that's going to go through. You're going to try all different types of combinations, characters that can be replaced with other characters, right? In fact, I can do a quick Google search for that. I didn't know exactly how to to do that there, but yeah, here's a good example, right? So, if uh if it's expecting an A, we need to bypass an A. It's possible that some of these characters, you know, will work instead. That's typically more common for things like uh account takeover. So maybe you can register an account that will ultimately become the same username or you know same identifier that's being linked back to it or something. But this is something that we're going to try. Um yeah, but go through try all the different ways that that you know to manipulate JavaScript itself manually. You're also going to do all the different automated payloads. And ultimately you've just got to keep trying. It's just fuzzing, right? Fuzzing is throwing a bunch of unexpected input at the uh at the target and trying to find out when it behaves differently. you're trying to ultimately uh understand how they're doing that output encoding in all the different places, all the different ways so that you can come back and circumvent it. All right, let's come back over here to this. Open this up. Um once again, final time I'll say it. If uh if you want to learn more about actually getting that to execute, go watch part one. But for the sake of this part's already a lot longer than I meant to be, so I want to go ahead and and move on here. Um, we will I'm going to go ahead and get everything set up for our stored cross-ite scripting. And then that's what we're going to focus on. We're going to just going to look at the setup builder here as the last major piece of this first hunting session where we're looking at reflected and stored cross-ite scripting. Once that's done, we're going to go back. We're going to let our uh script find targets for DOMbased cross-sight scripting and client side prototype pollution. And we're going to go into the second main hunting phase. And then the final the third hunting phase of this video. This video is going to end up being like 10 hours long. I swear I did not plan to do this, but I really want to show this. We're going to go into Grammarly. We're going to put the whole methodology together. We're going to figure out real world ways that we can do an account takeover within Grammarly if everything goes wrong. We're going to find some targets, some attack vectors to go in and test. And then that'll be mostly it. You know, you'll be able to put everything together. So, uh, I'll be back. For you, it'll be a second. for me. It'll be a little bit while I get some stuff set up and I will record the final part of the reflected and stored cross-ite script uh scripting hunting session here. So, yep. All right. So, now we're going to do the exact same thing that we just did on our reflected cross-sight scripting attack vectors. However, this time we're going to focus on our stored cross-ite scripting application. We're going to put the whole thing together, right? And the other one we focused on two different targets. one for testing the output encoding and then other the other one for you know kind of looking at how we would weaponize it here. We're going to put it all together and and target our uh stored crossite scripting in an authenticated app. So I'm going to go ahead and come down here and we're going to add just like we did before who is the victim. Let's go with uh how is the payload delivered? And then finally, uh, how is the attack vector vector weaponized? Right. Split it up like that. A little bit different from how we did it the last time, but that's fine. Doesn't make a big difference there. Uh, okay. So, starting with who is our victim. As I mentioned before, with stored cross- sight scripting, it's different than reflected cross-ite scripting. Reflected cross-ite scripting, you are finding a way to trick a victim into usually clicking a link or going to a malicious web page going to redirect them to this other web page, right? whatever it's going to be. The uh whether or not the victim is authenticated into the application we're targeting doesn't impact your ability to deliver a payload for reflected cross-ite scripting. For stored cross-ite scripting, it has a big impact because in a stored cross-ite scripting, you are storing your payload in the database and the database is being rendered automatically to other users as part of the app's typical functionality. So different from before when we're trying to figure out who the victim is, well the victim has to be someone that is going to view these payloads. Now depending on where the payload is, if it's something that can be delivered outside of the application or outside without authentication, you know, then then you can deliver it that way. But typically, we're only going to be able to target valid users within this application, you know. So let's go ahead and start by doing a little bit of research here on what exactly this is. So, you know, we can make some assumptions. I know we talked about there's probably multiple different individual users that are in here, but let's let Google kind of just give it a thing there. I don't want the URL to be in there. And I'm hoping that Gemini is is going to pop up, but let's see. Setup builder is an alternative option for you to load your machine displays with the key information required for Okay, so that's interesting. So, so then most likely the target is going to be somewhere else on the farm. So, or you know you have a farm, you have some type of operation where you have multiple different John Deere products. Those John Deere products have uh machine displays and so it looks like what this what you can do is go through and configure it. So, this is like a unified dashboard for that. And you probably can give these out to a lot of different users as well. So most likely the goal would be to get access to this tool either by you know somehow you get access to this tool. You know you're either you're a lower privilege employee um you are a contractor you are an auditor you're something like that you know I I pretty much guarantee you that they have to you know give access as part of you know farms have all types of different things where governments come in and they get subsidies and everything uh based on if they're doing things correctly. So that can be interesting if we can also just exfiltrate the data about their the products and the location and everything. um you know potentially that could be helpful as well right it depends like the location data everything else um might be be helpful to an attacker right but ultimately the victim and uh I don't know we can keep doing some other searches here who uses there you go we're starting to get something uh is used by farmers to create and manage setup files for their equipment these files contain crucial information like fields oh another thing another way that you could show impact is if you could execute a cross-sight scripting that would force them to make an HTTP request that would modify an existing setup. What if you could actually impact the way that their farm equipment is working? Right? So, that I think is a really good one there. Right? So, you're going to have the farms farm operators, equipment managers. Um, so that's ultimately going to be our victim here. It's like first of all the victim uh has a valid account and they are probably farmer farm operator you know etc right equipment manager you know so and let's see let's see can uh can we set accounts to our, you know, let's just try that again. Well, I mean, I'm just pok I'm just brought in here. Uh, no, there's no temporary accounts. And you always got to take this with a grain of salt, too. You know, we go in and test it. But, um, uh, okay. Is there What are the roles? See if we can get information on this. Probably not. No. This is kind of last one. See if we can find any access controls in here. Ah, this is something that's pointing something. Okay, I'm not going to keep digging on that, but you can see how like we want to use the open internet as much as we can just to try to understand it. So, but I think we got it. So, the victim itself, uh, it's going to be they have a valid account, right? We're going to try to target some of these top level people. So you would imagine that a farmer, farm operator, equipment manager, these are going to be the people uh the user accounts that have uh more access to to a lot of things and especially probably the um the farmer itself you would think would be you know the most access there. So um and I'll kind of put a star next to that because you would imagine that there's some admin functionality there. And then ultimately, right, uh ultimately we're hoping that they uh have higher permissions. That's not right. I can't spell our account, right? Just something like that. Okay, it doesn't matter too much, but that's ultimately how we're going to try to show that impact. We need somebody through their typical use. And actually, this will come down to how the payload is delivered. The payload is going to be delivered through the typical use of the application. I thought I'd try to do that without talking to see if it made it better. Seems like it made it worse. Um so but anyway yeah so the payload is going to be delivered through the typical use of the application. The victim is going to navigate to a page. So somewhere like this we need to find public pages in this web application where that is going to be uh delivered. Now we saw in the files page that uh you know it lists out all the files that exist in there. So that's already a great area that we can deliver it. All right. And then now the big question how are we actually going to execute this attack? So, we have a fairly complex content security policy here that just like we did before in the reflected cross-ite scripting. I'm going to walk through this each individual directive at a time. And we're going to talk about how each one of these directives will affect our or impact our ability to weaponize this payload. But I also need to take a look at something we didn't see before, which is the cookie flags, right? because that's going to tell us if they don't have HTTP only on their main session token, then it's going to be super super easy for us to just, you know, grab any victim session token, next fill it. And I I love that if you can get the session token from a stored cross-sight scripting, that is a very wide range of impact because you're going to most likely you're going to have multiple different users that are navigating to this site, right? So stored cross-ite scripting can have a very very large blast radius. It always depends, but typically that is the case. So, we need to see, let's come back over here and find out what cookies do we have. What cookie flags do we have? And I don't think we have identified. There's another another subdomain here that looks like we're pulling in cookies from that. So, that's good. We do have only one that has an HTTP only, and it's this client one here. kind of a strange looking cookie as well. I guess that's really the question. Is this our session token or not? So, let's uh let's just reload this again and we can get this brought up. And actually, let's go ahead turn interceptor on there. Then we'll click on that. That should stop it. And it did. All right. Perfect. So, we've got our get request coming through here. Let's send that to repeater. I want and then we've got our All right. So, there's two different requests. There's one request that's sent to the uh home directory there and then we also want have one that's sent to the session. And it looks like everything else there's some views data being brought in from JSON, but that's it. So, let's go ahead and start for Oh, shoot. You know what? Should have forwarded these first. I don't know if that made any difference. We can find out. Doesn't look like it. Hasn't kicked us out yet. Just see what happens when we go here. All right. So, many more requests. So, it goes through and does the the home directory and then it does the sessions. And now we're coming into this signin. John Deere, which sends this or yeah, signin.jere. And we have I mean, you would imagine this is the session token. We have completely different session tokens here. So, and everything else. All right, let's go ahead and turn this off. Let's see if it's going to keep us on here. I think we're okay. And I think we got the three main pieces that we want to look at. So yeah, we have the get request to home directory, get request to session, and then finally goes over to the signin over there. Um, so what happens if we send this? So this loads in a lot of different JavaScript and that JavaScript is grabbing something and and using it. Now what happens? What happens if we just get rid of these al together? Does it automatically redirect me to a sign in? Looks like the same thing. Let's just see what happens when I show the response in a browser. And again, I'm trying to determine what the session token is here. So if we make that get request with no I mean the cookie would still be stored in the browser though. So I think it's even if it's not included within the request I think it's being used in the browser itself. Let's see what happens with the sessions or the get to session. So this seems pretty important. And we also have this JSON web token alternative token here. Man, a lot of good data and stuff. Then with this, we've got ooth scoping obviously. So yeah, I mean it seems like it grabs this. What happens if we get rid of the cookies here? Now this has to have subtype. Okay, now we're getting thing there. All right, so now we should be able to figure out what it is. What happens if we get rid of this? That's still okay. All right. So continuing to reinforce the fact that this client one here is that. So yeah, I mean we pretty much know for sure. Yeah. Okay. So, I was correct. Let's come back up here to inspect, go to storage, and sort by HTTP only. So, yeah. So, this client is at least being used as part of the process in order to determine whether or not we are authenticated. Now, it looks like there's a lot of data that's stored within there, but we're not going to be able to grab this with HTTP only, or we're not going to be able to grab it with JavaScript, rather. This looks like it's stored in this persistent header as well. So, this is maybe a domain that's uh we can set cookies across multiple different things. Again, that's really complex, which is interesting to me. Um, this looks like something that we can target though. And is that over here as well? Yeah, the Jot external access token. Let's let's gather more information about that. And I want to document both of these. I want to come back over here to where we know it's good. I don't care as much about the other ones, but let's come to our notes. And with our cookie flags, you know what? I don't need all the stuff in there right now. That's a whole different conversation. We also don't need these here. Let's just go with this. And I'm actually going to identify this as going to the slash session endpoint there because again this seems to be very critical as part of it. Um now something is there there's another step. So let's come over here as well. We've got this additional step that goes to signin.jandere. This is all part of the oath implementation. So what do we need to do for this? Is it just that J session ID? Because if so, there's got to be some type of token exchange. No, it's not. Okay, so it's not that session ID at all. Is it this? Oh, you know what? Let's do this. So, this is another JSON web token, or at least for the most part. We're missing a payload here, though. What does just this translate into? Looks like we have encryption key information in here. That's kind of strange. All right, let's see what's needed. Is this idx what's needed? They must be sending a get request first of all to here and it needs to have a valid client cookie in order to get this back. But really, it looks like we would be targeting this whole OOTH implementation here. So if we can steal, you know, potentially this and then use the value within here to send the next request. I think I mean that's what it would have to be doing is putting this putting this together. The data that's stored within here if it's needed. Let's get rid of this entirely. We're still good with the 200. Let's get rid of the J session these right here. So it looks like just the idx. Yeah. So the idx is what's needed for this. And let's copy the URL here. And we need to get this entire flow documented. Okay. So now the real question is can we build this idx cookie using the data that we have that we can access? You know, so you can see where this gets a lot more complicated while we're trying to exploit. So we may need to do some we may need to just do some data exploration is going to be easier way to do it or kind of force them with some session writing. This is a much more complicated because they have uh OOTH that they're using as essentially it looks like a single signon implementation. So this signon.jear.com facilitates their signin through all these different applications and it looks like this persistent header subdomain is also being used to store some of those cookies and things. So, and we'll be able to to use all of that. Uh, okay. So, what is why do we not have this? Let's go ahead and send this to the decoder. We don't need to grab the signature, but we can go ahead and grab the header and the value. Kind of hard to see. I'm looking for a dot delimiter. Let's just do this. Make it easier. There we go. All right, grab this. Send it to the decoder. We're going to grab first of all the I don't do the whole thing. First of all, we'll grab the header decode as base 64. Then we're going to grab the payload here. All of this decode is B 64 as well. And we have these values. So you have the sign in, we have a value there. Quite a bit of information, first name, last name, everything else. I feel like we could use this as a way to get I want to see what happens. Let me just grab this here and then let's go back over to our single sign on one. What happens if I replace this entirely with this cookie? No, not going to work. Okay, so we'll probably have to grab that and do some some uh manipulation with it. There's a lot of good information in here. So, even if we could just steal this, that would be showing quite a bit of impact. And I do believe that we could use the data stored in here to potentially be able to to upgrade or target that single sign on there. So, this is what I'm going to focus on at least if we're going to do a cookie exfiltration. So if we come back to here, this one right here might be used to form idx cookie for uh ooth. No, http only. And then this client larger session validation flow and HTTP only right there. And then let's try for the idx, right? Because maybe even if we can get a client side injection, maybe we can find some way to to grab it from somewhere else from that persistent headers which seem to be within scope here as well. So let's go to the do we have anyone that's still pointing at the sign on there? That's not right. John Deere.com. I think that was the URL. I'm not going to be doing any testing on this. I don't even know if it's within scope. I just want to see if this idx cookie has the HTTP only flag. And it did go ahead and log me in, but that's fine. A lot of things with the HTTP only flag in here, including the idx. Yeah, has a HTTP only flag as well. So, all right. So, stealing the session token is uh it's going to be a little bit more difficult here than it would be in places where it just has a typical authentication with the specific service, but that's fine. So, we're going to look at right now just targeting this jot external because it's the only one without HTTP only. We're going to have to do some additional steps to try to figure out how we uh elevate that if we get there, but we got a lot of steps to go before we can get there. So, all right, let's get rid of that one here. come back over here and come back down to our bottom. So that's the goal. Again, we're going to deliver this to another user within our uh within our tenant of the application here. They're going to navigate to it in somewhere like this where it's being rendered. And then the way that we are going to weaponize it, we are going to attempt to steal the what was it called again? cookie. So, we'll do that. Um, we could also try to modify existing uh data or settings might be good. and uh exfiltrate data about uh specific I want to do like location but uh farm equip equipment settings especially location you know I feel like that's going to tell a really good story if we could report this John Deere and say hey this would allow somebody let's say they have access to this to be able to even set up a script embed a script within this and you know one other thing we could do as well just completely separate uh crypto miner That's always another way to show it. If you can inject a crypto miner that's persistent and now every user as they're logging in, this application goes much slower and they think it's a problem with the application or their computer. Turns out somebody has injected a crypto miner into this and they're leveraging their work resources to be able to build up uh you know potentially mine, you know, Bitcoin or whatever they want to mine. Um you know, look, crypto mining with JavaScript in a browser is super slow, don't get me wrong, but it's certainly a way that people try to weaponize. Uh we have a few different options here. Now, as it always is, you know, now that we've got more information about the cookie flags, the content security policy is going to have a big big impact on our ability to to actually be able to weaponize it and finish these attacks. So, let's kind of walk through what we're looking at with our content security policy here, just like we did with our reflected cross-ite scripting targets that we were looking at before. And uh make sure I've got everything on here. um fairly complex, but we're going to see a lot of the things that we saw previously. And I'm going to kind of bounce around to the ones that I think are are more important. So, first of all, oh, make sure you get the right one. We're going to look at this the script source, right? So, we've got uh I'll just make a little room here while we're looking at it. Uh that's the first thing that I always want to look at when I'm doing a store cross scripting. So, um we do have self that's included. We have unsafe inline and unsafe evout just like we did before. So once again, that tells us that if we can inject an inline script or we can get our user controlled input to be processed by an eval on the client side, the content security policy is not going to prevent us from executing any JavaScript that comes from that. That's good. That's always something that we want to see, you know. Um then we look at where external scripts can be loaded. Um first of all, having local host on here is wild. Now being that's definitely there just out of debug. you know, that's something that should have been that should only exist within like a development environment, not a production environment. So, that's just a pointer that tells me that things are not quite right here to where it's worth my time to dig in a little bit further. Um, however, there's not going to be an easy way for us to actually weaponize that as part of our our thing there. Uh, Google APIs, maybe um, we could host a JavaScript somewhere ourself. You know, that's obviously part of it, but it's, you know, I don't want to get married to that. Yeah, the Google APIs is probably going to be one of the easiest ways. I'm not Yeah, sorry. I'm thinking out loud as I'm doing this because we've got the the the John Deere. So, if we can host at any of these wild cards, we can get it. And then, like I mentioned before, I'm going to come into each one of these individual URLs or these specific domains, and I'm going to find out if they have existing functionality that allows me to host a script myself. And if so, I can pull in a much more complex script. But even if we don't have to do this and we don't have the freedom that we did in the reflected cross-ite scripting target where it allowed anything with the VC right so we come back up here we had so many instances including the script source where we have a star.vc so is we can go and register our ownvc that's included in what we can do but we don't have that freedom here within our script source. So the most likely way that we're going to do this is we are going to store an inline script within the database and it's going to be loaded for every user who views it at as a at a specific attack vector. All right. Um what do we want to move on from there? We've got the image source which was another good one here. So right here uh very open image source and also specifically allowing you know uh the the data URL there. So a data URL this is going to allow us to store a lot of data within this if we want to exfiltrate it. So, I'm really liking the idea of finding a way to exfiltrate location data for these different systems, uh, these different, you know, farm equipment and and any other thing configuration data. I don't know, there's probably a lot of, uh, valuable information in there. I would have to do some research, but, uh, this is going to be very helpful for us to exfiltrate that data. So, if the session tokens don't work or if we need to take that cookie and we need to exfiltrate the data in that cookie to go and create another one, right? Um, so I like seeing this type of a permissive image source directive there. Connect source. Where's our connect source? Quite a a big one up here. A lot of different granularity there. So remember the connect connect source is saying where can we reach out with JavaScript. So if we do grab this data and we do put it in JavaScript, we already have our image source out here which I think is going to let us if we can write an image tag or anything to the DOM, it's going to be pretty easy to get that in there. However, we've got a lot of options for just straight Ajax calls, you know, HTTP calls here. Um, we've got some S3 buckets. That's not going to help us unless for whatever reason they don't maintain those. So, I would first of all check to see if all these S3 buckets exist. And then if they don't, potentially we could create our own and we would take over that. That would be an example of a subdomain takeover. And I might might apply that a little bit differently when it goes to a report. We can chain those together. Um, we could do a websocket on local host. I mean, you know, if you can find a way to get access to their machines and have something running locally, then there's a potential there. But at that point, they've got some much bigger problem. Same thing for the HTTP. Um, there's a data dog here with a starred subdomain. So, if we can get any subdomain that uh can potentially host a script with something like this. I mean, in order for these domains to be there, there has to be an expectation where we're loading the scripts in there, right? So each one of these whether or not we can get the specific domain. But when we have generic generic domains like these, you know, these ones here, assets, S3 buckets, everything else, then there's a lot more freedom for us to potentially get in there. So I do think that we are going to need to uh I'll kind of put this in there. Post a complex script. I don't think when we're looking at these here, aside from this stealing this uh jot access token, everything else is going to require a complex script that's probably going to need to be loaded in externally. So, if this connection source, if it was like the one we were looking at before, where the connection source is just self, I would be a lot more hesitant to, you know, I wouldn't see such a clear path to exploit this. But with this one, I I do see, you know, a fairly I see a lot more options basically, you know. Um, so we have default source right here. I'm not going to, in fact, I'll kind of close a few of these out. Um, all of these other ones, the smaller ones tend to have like they they affect really specific data exfiltration opportunities that we have, right? So, but the default source, this is, remember, this is the fallback. So, it's not going to affect because we've got so many other things, connection source, script source, everything. It's not going to impact a lot of the ones that we need, but even seeing anything outside of self in the default source is good, right? We have some flexibility with this Gstatic and Google APIs domain there. Um, and then I think the I frames was another one. Uh, where was it? Where was it? Yep. So, the I frames here, we have a little bit more flexibility, right? They're all in these John Deere ones. So, we're not going to be able to go and host our own necessarily unless we can get control of one of these domains, but um has a little bit of flexibility there. So, I think that's I think that's the most important ones. I mean, again, the the style source again um we have unsafe inline, so we have the potential to get an injecting through a a style uh you know, injecting CSS instead. But for the most part, everything that we're seeing with the content security policy is in line with what we would be looking for to execute this, right? And I think the easiest way is probably going to be to steal this cookie along with any other valuable data that we can see. We've got the image source with the data that's going to allow us to xfill data. We've got a lot of options with connection source is probably going to allow us to xfill data. So, I'm feeling good about that. I'm feeling good about exfiltrating data from the cookies as well as data from the application itself. And then that would give us an opportunity to show impact a lot of different ways possible account takeover or you know getting access through that OOTH implementation as well as just gathering the data um from the the thing that maybe we wouldn't have access to otherwise. So um we have a good plan now just like we did with the others. So the last thing that I would try to do is now we've got to get this to execute, you know. So in the same way that we did before now because it's stored, you know, we've got our different areas here that we would uh we would go in and put these in. Let me come and see what it looks like one more time. And we do have the virtual DOM which is going to cause a problem. So this would be a much more time consuming process because this can be reflected anywhere. So, what I would need to do is just go through and start putting individual payloads everywhere that I can find. And I'm just going to kind of click through. It's a lot more important to go through your enumeration of the application when you're doing a stored crossite scripting here because it's going to be, you know, it's not just a reflected where we're we're looking at an isolated HTTP request and response. Now, we're looking at the larger uh application itself and how it works and all the different ways that it can go in. So, um, I would go through here. I would find as many different places that I can store a payload, store anything within the database, you know. Um, here's something where you can download something, you know. Yeah. Again, I don't know all the different pieces. And we are jumping around from these. So, setup builder looks like it's entirely encompassed within with this piece here. We'll get this to load up in a second, but yeah. So go through you're going to find and just submit data with your canary along with the uh you know the anything that you're going to need with uh uh a typical stored crossite scripting. So, your greater than, your less than, your single quote, your double quote, um any characters that you can think of, a backslash, you know, I might throw a couple null bites in there, but um as opposed to what we were doing before where we were just sending the request and immediately viewing the response, it can take a lot longer to fuzz through different characters. When you're in the store cross-ite scripting, you can see I'm even kind of as I'm clicking through. Gosh, we have all these different connections and everything. Um, let's find one more place where we can throw some input at this. And we will do the same thing we did before. Remember, we're going to do the manual with unique characters. We can do fuzzing where we send a lot of different unique characters. And then we were going to go in and use those cheat sheets, polyglotss, everything. Keep building it up. Ultimately, we're throwing unexpected input and we're trying to break this uh output encoding or here it would be breaking out of the virtual DOM for anywhere it's being added into the virtual DOM. All right, there's a lot of things are happening there. Let's see if I can store Come on. Give me the opportunity to store data. There's an export as well. I don't know how that would affect everything, but sometimes with exports, you know, you can put in uh depends. All right. Sorry, had to do a couple refreshes there. Um the application was running super slow, so I had to get a couple things squared away to to stop that. But should be should be going a little better now. Uh and I think I found a good target that we can use fairly easily. So we're just going to come in add a staff member and uh we'll do arson plus stored xss test at wehacker1.com. And we'll hit next here. Looks like they've got just some access levels that we can configure. And that should be good. So, we should now see this coming in. Now, what do we have the ability to do? Because right now, the only thing that we can do that we can control is this email here. So, let's come into edit. Uh, and it looks like we cannot edit until we approve it. Let me see if that's come through where I can approve that real quick. And it looks like it is. I'm going to try to copy the link from the email and let's see if I can get it to work over here. Actually, this might end up screwing everything up because it's going to check for my valid session and that that might cause some some issues there. But yeah, see there you go. Um, so what I need is a I'll just validate. Let me just validate over here. All it does is open up a single link. Well, but now when I try to do this, it's asking me to sign in. That's kind of strange. You can see here. I'll just pull this off real quick. So, yeah, it's just taking us over here. Let's see what happens when I do this. It's going to give me an opportunity to I don't have a password. I do not understand. Oh well. You know, that's fine though because we do have this target right here. I don't know in the access. Maybe we can manipulate that as well and get something that's user control. Let's see if we can come in and find the post that we did to do that. Let's maximize this over here. Come up to the settings. Filter for deer. And what I'm trying to find again with stored cross-ite scripting, which is more difficult. I'm trying to find somewhere that I can easily test. I can easily just start kind of tossing these in. Oh, our intercept is on here, too. Why is that? Didn't realize that was going there. All right. So, we've got a get a get get I may just go add Let's just go add another one real quick to do it. Add. Let's add a staff member to prhacker1.com. Now, let's see. I'll try and route this through Burp. This is Burp Suite has also been making this run a little slower, which makes it difficult, but these are all the the challenges that we always run into, right, when we're doing this type of testing. So, um, and it's certainly taking a while. Let's do this. Instead of this, let's come down here to the network. And I'll just click done. There we go. And we can grab this post request. Let's just come and take a look within here. See what it is. We have the same content security policy and the request is going out. So, there is a lot of areas that that we can potentially control this here. And it goes to the ad staff. So, this is one that I would definitely test. You know, we'd want to go through and see if we can put uh different payloads, different commands in here. We did see some server side validation at the end, but uh or on on the previous testing that we did, so we would have to see if it's on here. But um you know, for the sake of time, I think I'm going to call it on that for stored cross-ite scripting. I think that y'all probably get the point and between what we showed on reflected cross-ite scripting, we can continue to do that. But um just to reiterate, right, you're going to find areas where you can put these payloads in here. And then what I'm going to do from there, I'll bring this back up one more time. As I talked about with the previous one, JavaScript for hackers, you're going to go through and manually try uh double quote, you know, let's see how this is actually rendering in the DOM because the scope is always very helpful here. Rendering within a DD. Oh, so these are a lot of custom elements here as well. DD you got to think, has something to do with data dog that's pulling out. Um, yeah, I think there's a a whole rabbit hole here, especially with how long this application is testing. But I think you get the point. I think that's, uh, that's kind of the scope of it. So, um, no matter what it is, let's let's get our notes brought back up here. All right. No matter if it's stored or reflected cross- sight scripting, the three main steps here are ultimately the same, right? Like figuring out who the victim's going to be, how are we going to weaponize it? Um, again with stored cross- sight scripting, you've just got to remember that the way that the payload is actually going to be delivered is very different because now we're going to be delivering it through the natural use of the application. But everything that we talked about with the testing before, so doing that uh manual testing of several different characters, seeing what the output encoding is, seeing if it's rendering in a virtual DOM, you try to bypass that. Understanding how to bypass the content security policy, and then ultimately just making sure that your your plan for who the victim is, how the payload is going to be delivered, and how that attack vector is going to be weaponized. You got to make sure that you've got a very good plan to to execute that. So, all right. This is already way longer than I I meant it to be. Um, so I am going to go ahead and call it here for the first hunting section. Um, I need to do a lot of editing on this. I'm also going to need to do some work on my script. You, this will just be a second for you, but it'll be a little bit of time for me. I'm do some work on my script so that it can also go and find good targets for DOMbased cross-ite scripting and client side prototype pollution. And we're going to come back and start an entirely new hunting session looking for those attack vectors. and ident, you know, talking about the differences between testing for that and testing for what people are a lot more uh comfortable with, which is the uh reflected and stored crossite scripting. I think you can tell I'm getting kind of tired by the end of this. It's been a couple hours, you know, altogether today, more than that when you consider all the extra stuff. But um I'll be back as soon as I can. I'm going to keep working on this. Um I'm going to keep releasing clips as I'm going. Um yeah. Ow. All right, I'll be back. All right, I'm back. Uh, I know I said we're going to go ahead and move on to the next hunting phase. Uh, and we are in just a second, but um, I wasn't really happy with the way that the uh, stored cross-ite scripting hunting phase on that that John Deere target went. I had to cut a lot of it out because the application was running so slow and there was just a lot of issues with getting things to work the way that I wanted. So, it really didn't highlight everything that I wanted to highlight. So before we move on real quick, I'm going to speedrun doing a stored cross-ite scripting test on a couple attack vectors that are on this one page you see right now. Uh which the the profile page most common p place that people test uh stored cross a scripting. Uh we're going to do it on the steam community uh page that I mentioned a while ago mentioned mentioned uh earlier. And remember the scope of this right? So this is very different from the John Deere one. the scope of this, we have a public page where anybody can come make a free account as opposed from John Deere. This is an isolated tenant that somebody has to be given account an account from somebody that already has uh uh access to that uh instance of the application. So, um but yeah, we're going to run through real quick just focus on the main compensating controls, get a quick plan of attack together. I want to highlight a couple things that I didn't get a chance to highlight. Uh I do already have my script running. In fact, I'll bring this over here real quick just to show it's been running overnight. Testing for good targets for DOM based cross-sight scripting. Let's find here. Here we go. Uh DOMBM based cross-sight scripting as well as client side prototype solution. So, we're going to jump in that in just a second, but again, I am going to run through this real quick just so that you can see this is a much more typical uh I don't know what you would call. This is typically what you would see uh when you're testing for stored cross-ite scripting. the the John Deere one had a lot of additional complexities. We had the OA thing and everything else. So anyway, um so what I'm looking at here, I just went in and created a free account. All you need is an email. You can go in and create as many different free accounts as you want. I did use my we are hacker one account, right? You definitely want to do that. Unfortunately, it doesn't allow you to do plus notation on here. So, but that's fine. You only need one for this testing. It's not like IDOR or access control where you typically need multiple different accounts. Um, so as we've said many times, stored cross-ite scripting, you're going to store your payload in the database, and then that payload is going to be rendered in the DOM in multiple different places across the application. And our target, our victim is going to be someone who just views those payloads that are rendered in the DOM through their normal use of the application. So this steam community.com, this is a platform for members of Steam to communicate with each other. They can share screenshots, pictures, make posts, comment on those, right? It's a public form like a social media, you know? So, that is an excellent opportunity. If we can get a stored cross- site scripting within here, we're going to be able to affect a lot of different users. We're going to be able to show a lot of impact and that's going to lead to a very large value for us. And that's always what I'm looking for when I'm doing stored cross-ite scripting. So, again, this is your best case scenario for stored crossite scripting testing right here. So, uh, let me go ahead and get this brought over here. I'm going to grab this. Again, we are going to do the abridged version. I want to go very quick because this is already so much longer than I thought it would be. Uh but that's fine, right? Okay. So, we have our profile page here and we're going to focus on any data that can be stored within our profile just in this page here. Right. So, we have our profile name, real name, a custom URL, which you can already see being reflected down there. We have this country which uh probably won't mess with too much but one of the things that I would try if I had once I had a little more time is I would try to inject something other than one of these. You would expect this to be uh what's called an enome which is basically there's a uh list or a set uh yeah essentially a set list of results that can be stored. So if there's a light switch object, that light switch object may have a uh you know on or off state uh variable essentially that's either on or off and the enum would be one of those although you'd use a ben for that. That's a bad example but that's fine, right? So you would expect each one of these to be an option and if any other string is stored within the database then it would uh it would kick it back or it's tried to store it and it say no no no it has to be one of these items in the enum. Um hopefully they would just because it's easier, right? We're always looking for the path of least resistance for the developers. That's that's what adds complexity and that's what eventually leads to the vulnerabilities. Hopefully they just said, "Hey, instead of building this crazy big enum with all these different countries, uh we just want to allow any string and then maybe I can store a string maybe that doesn't have validation on it and I can store uh a crosscripting payload and then this will be loaded up somewhere else completely differently." Right? So, but that's always what we're looking at is those downstream uh where it's being loaded up from the database. Summary, same type of thing. So, what I'm going to do is I'm going to update this uh I want each one of these to be unique canaries, very unique canary, something you know that there's not going to be uh in the application at all. And each one has to be separate because what we're going to do, what you have to do after this, and I won't be able to show a lot of it, but I'll show the basic process is you've got to crawl through the application, walk through the application, do everything that you can, and you're going to populate all of those requests in Burpuite here. There we go. And then you're going to come up and use the Burpuite search feature to search all of your HTTP responses. Remember, we don't care about the requests cuz this is not a reflected where it goes out and comes back in. We only care about the responses that contain our canary and that's how we're essentially going to do this testing. So we'll see that in a second. First thing, let's come in here and let's go arson profile name, arson real name, arson custom URL. Right? You can see immediately that's being reflected. That's going to be an opportunity for DOMBased crossite scripting. We'll talk about that in a bit. For my country, I will uh come down here and select, do we have the United States? Sure, we'll put that right there. Ah, and we have some additional options as well. So, sure, we'll put Alabama faster. Great. So, we have some additional strings we could potentially poison as well. There's more attack vectors. And then arson summary. Uh, I'll just type in unique just in case. Um, and then we have that as well. That should be fine. So, let's come over here to the proxy. I'm going to set intercept is on. We will hit save. See that captured there. I'm going to send that to repeater and then we'll let that go. Perfect. And now we see all of those values have been saved. If we come over here to Bertswuite and we search, now we're going to come over to just response. Well, we'll keep headers as well, but I wouldn't expect that. And if I do arson profile name and search that, now we see that it is coming only in the response to this here. And there's our content security policy that we'll need to grab in a second. And I see some proto. Okay, there's some fun stuff here. Anyway, so yeah, we'll we'll come back to that in a bit. Let me come over here to the repeater. Let's close out of this. And you can see what this request looks like. Interesting. I expected it to be JSON, but they've got these, you know, boundaries here. Um I'm trying to remember what framework that is. This is a this is a specific framework that I've seen before. Anyway, um but that's fine. So, we now have our canaries laid. And I'm going to come over here to our notes and let's start putting everything together. So, we got to have the same uh three questions. Who is the victim? How is the payload delivered? And finally, how is the attack vector weaponized? All right, same thing that we're going to do every time. Now the victim as I mentioned before the the benefit of this target is that the victim is going to be a typical user of this application and there's a wide wide range of possible victims. So any authenticated user, right? Cuz we don't our goal is going to be to target those authenticated users and try to get the data they have access to that we don't have access to, right? So that's why we don't we don't care about our payload executing if somebody's not logged in or it's just some random person because they're not going to have the sensitive data that we would want to steal, right? Uh we can't or we can't force them to take an action on their account if they don't have an account. So we want an authenticated user. That's really it. any authenticated user and how is the payload delivered? It's going to be delivered through typical use of the application again. So right there we have the the two, you know, and it's the same thing as before. You know, the victim will navigate to the page where it's rendered the DOM. It's almost always going to be something along these lines for stored cross-ite scripting because that's just fundamentally what a stored cross-ite scripting is, right? So the last thing we have to decide, we need to go through these compensating controls and figure out how we want to weaponize this attack. That's really the only other question that we have. So um you can see with targets like these it can be very easy. So and you know we we'll go through we would go through all things. I'm going to completely ignore getting the payload to execute for this cuz like I said I'm trying to go real quick. We're just going to look at some of those compensating controls that are going to directly affect how we're going to weaponize this attack vector and then we're going to build our plan for it and that'll be, you know, essentially good for for showing what I want to show. Um, so we'll go content security policy and cookie flags and then potentially seurf and cores. We'll put that in there. I may want to find out, but it'll depend. We may not need to look at that. Those are essentially additional things. If we can't figure out how to excfiltrate the um the session token or some sensitive data or anything, then we may look at trying to get them to do actions uh like modify their profile or you know their privacy sections. If we are going to force them to do something like in fact, let's let's find out. I want to make my profile friends only. And it looks like that actually went ahead and sent a request. Is that correct? It did. Okay. So, let's send this over here as well. And we see the same request here. Is there somewhere that says friends only? Gosh, this is a lot harder to read than I thought it was. Is that the correct thing? Yeah, that's the correct one. There's the how we edit our profile. So, okay. Yeah, we'll come back and look at it in a second. I think it's in here, right? Privacy pro two privacy privacy. So, they must have integer values that are going in here. By the way, this looks like an interesting part for server side prototype pollution if their backend was in JavaScript. But, uh gosh, I'm going to go down to 100 things. But, this is a possibility as well, right? If they have their profile set to to private, let's see what that is. And it looks like that goes to a lot of ones there. So potentially we could do, you know, three threes. We'll have to play around with that to see. But this is another option where we could show impact. It's not a huge amount of impact, but if one of their users wants to keep their profile private or between or only among their friends and you can force a whole bunch of people that have it set that way to set public and then you can maybe start gathering data from them. That would certainly be an unfortunate situation for Valve. Um it's probably something that would get a little bit of news. It's a a pretty decent way to show impact. But anyway, I want to get data. I want to get access to somebody's account. Um, typically anytime I'm doing client side injection, my goal is to get an account takeover in some capacity. That's, you know, I I try to add up pointers and additional, you know, chaining bones until I can get that. All right. So, I saw our content security policy. By the way, I'm going to get a another little desk here so I can set this in because as I'm editing, I hear the kind of weird sound every time I set it down. That's why you see me doing it so gingerly. But, uh, so I'm going to fix that. you know, one of the many things I need to fix. Uh, all right. So, these calls are going to a separate API. Now, it looks like it's still Yeah, it's still under here. But, so the API itself is not returning a content security policy because it wouldn't expect to. The content security policy is already loaded in the browser from the initial request that we did loading up this page. And then the this is just pulling in additional data to that DOM. So, the content security policy still applies to these calls here. Typically, you're going to want to look at a get request. Uh, and that would contain content security policy if it's not going to an API again. So, it's um where's one of the ones? I'll tell you what, let's just do this. Let's come back over to general here. I'll hit refresh. And if we come click on this here, see exactly. So, the the page that we loaded, this main page that we loaded that that pulls in the DOM that allows us to then submit the request to change it. You can see here we have the content security policy. So, let's go ahead and grab this. Goodness gracious. By the way, there's a local host once again, 127001. Um, there's a lot of stuff going on here. I swear somebody does not want me to make this a short video. All right, that's totally fine, though. Oh, this is good. I'm seeing some good stuff, though. I don't know if you're seeing it already. Hopefully by now you've started to pick up some of these uh more important things that we're looking at. This is fine. There I don't need to get a whole bunch of stuff. Yeah. Frame ancestors. Is that it right there? Is there only a few directives? I think so. Right. Oh, interesting. Okay, cool. But again, I'm seeing stuff. So first of all default source means that if any of these directives are not set this is what the content security policy is going to fall back to. We have data we have HTTPS. So we can do a combination of HTTPS calls going going out go back. We can also have data URLs that are embedded within the DOM itself. We have unsafe inline and unsafe eval by default. Great. That's what I'm looking for. Fantastic. Then we come down here to script source. Right. Unsafe inline again. Unsafe eval. If we have the ability to inject something into the DOM, it will execute. If we have the ability to inject uh custom code into a JavaScript eval statement, if we find one, it will execute. So, we can do all that there. We can also import scripts from any of the domains here. Now, if you notice, we don't have any wild card domains. So, it's a lot of specific uh domains there. So, what I would need to do is go to each one of these. The YouTube is interesting. I don't know if there's some way that I can host something myself on YouTube, but probably not. probably not. I would need to go to each of these and see if there's a way that I can host my own script. If there's not a way to host my own script and and looking at these, I don't think there is, then what we need to do is we need to do unsafe inline or unsafe eval. So, that does limit what we can actually execute a little bit because it's you can't have this crazy complex script that goes into a URL. Uh there's a limit to how many characters can be in an individual URL and it's not that long. So, um, it would take a little bit of time to confirm that. And actually something that, well, I don't know. I don't think it'd work, but uh, just at a glance here, I would suspect that we're going to rely on unsafe inline as the most likely way that we're going to do it. Um, object source none, that's okay. That's not going to have a huge impact on what we're doing. Connection source, right? So, this is how we're going to be x-filling data out of it. um looks pretty open, but when you actually come in and look at the individual things, a lot of the domains look like they're owned by Steam, Steam Power, Steam Community, Steam.tv, everything. And that's actually what you would want the company to do from a security standpoint here. It makes it much more difficult for us because we would need to have control over something within here to be able to excfiltrate that data to send HTTP requests to it. Um, we got a couple on local host. It's not really going to help us. So, I mean, I I think it's possible, but the great thing about this uh the the way that this application works is we have the ability to post. The users have the ability to post. We have this chat function that we can do, and we're going to talk about this in a sec. We'll go ahead and go over there. We can leverage this chat function. Do I still have intercept on? No, I don't. It's just taking a minute. We can leverage this chat function to take any data that we have. If we have a valid account, now this is noisy, right? But we can take our valid account and have that user steal that data and send it to us through this chat function potentially. Again, not being able to import a script makes that more difficult. So, we will have to see if that's possible, if we can do it within a single inline script, but that's going to be most likely the way to do it. I'm either going to use this chat functionality or have the individual post a a comment on one of their pictures, screenshots, post, whatever they have that would include the data and then I would be able to exfiltrate it that way. We would need to change if their profile was uh if it was private or anything, we'd have to change it to public first, but we can we can certainly do that. So, uh that's I think the way that I would go here. We've got the I frames as well. the I frame potentially. Well, no, because we're still going to be blocked by the script source even if it comes in there. So, yes, that's not going to help us get a more complex script. I don't think I know. So, I think that's it. In we need to do an inline script. So, first of all, let's say uh inject an inline script to the database. And then as it's rendered, we can uh change their profile to public. And every person that views that, it would just automatically send that request, that post request in the back end to try and modify that. Now, in order to do that, when we changed our visibility here, come over here to the repeater. We need to make sure that there is no curve token on that. So, let's come over here. I know we talked about it. Let's go ahead and send this. Can we continue sending them? We can. that's going to keep updating. So, is there any cross-sight request forgery protection on here? We have country, things like that. There, uh, what I would be looking for is typically some type of a unique code that's embedded in here that would prevent us from essentially when that request is sent because the attacker wouldn't know what that unique code was at the time. Then if the backend validates it, it would say, "No, this is a malicious request because it wasn't sent the way they expected it to be sent. It wasn't being sent through this form." Um, and also this type, this may offer some protection as well, the way that they're actually sending it because this is not a typical API call. Although I do figure that we can recreate this uh well, we can recreate this in some capacity within JavaScript or because Yeah. Yeah. No, this will work. I should have planned this out, but no, this will work. This is cool. you're getting to see what it is in real time. Um, they don't have any form action set on here. There's no form action directive. If you think a while back, we had that um when I was talking through some of the initial content security policy stuff. And the default source doesn't prevent that in any way. So, what I can do is use JavaScript to submit the form. I can use JavaScript to have them navigate and submit the form. It's going to be much louder. Uh, they're going to see it happen. And I would probably I'm trying to think of how I could offuscate that by like modifying what they see, but then doing this in the back end would be very tough, especially in an inline script. We would re I'd really want to find a way to import this in to really weaponize it. But ultimately, we can use JavaScript to submit this form as well. So I think that's something that I'm going to do. Ajax might not work. All right. All right, looking at what that request actually shows. Um, so yeah, make it public and then uh Xfill sensitive data using chat or and by the way, you know what that sensitive data could be? It might be that chat, right? They're going to have private conversations. That is a fantastic way. If you can leak private conversations of a user and especially multiple different users with the stored cross-ite scripting, that is a huge amount of impact. that is something that the company would definitely care about uh using chat or u posts I guess we'll call that right and uh private chats private posts you know anything like that anything that if if the user sets it as private that means they don't want it getting out and we want to try and show that it can be leaked so that that will demonstrate the impact that is something that Valve and the company would definitely definitely definitely care about. Whereas, if you could find a way to charge them $5 a day, Valve could not possibly care less. I promise you, right? It's all about that data. It's all about sensitive data of the customers. Uh, okay. So, this is really this our attack, right? We're going to find a way to store it in the database. Our goal is that a a you know, let's just say multiple right there that a large number of authenticated users are going to be victimized by this attack. they are going to use the application normally and without their knowledge a JavaScript uh the the DOM will load and JavaScript will execute that the developers never intended to execute it is specially crafted by me right so it's going to as they load it up and what it's going to do is inject an inline script within that DOM or ideally we can pull out an external script if we can find a way to host on any of these URLs here that is going to first Navigate to the form, populate the form with the values that I want to have. Submit that form so we have the correct uh uh formatting here for the request. That will switch their profile to public. Then we are going to navigate over to the chats or posts. You know, see if we can gather any information and then leverage either those chats or posts to uh exfiltrate that data to send it to us in some way that the attacker can capture it. If it's a post, we'll probably submit it and then our script will immediately send a get request to go grab that data before the user has a chance to delete it or anything. If it's a chat, it should come straight to us. We'd probably still want to grab it immediately. But if we're actively engaged in the attack, then it should be okay. You know, store crossex scripting again, it's not like reflected where you deliver it and you expect it to execute. Here, you're going to put the payload in, you just take a step back and wait. So, you have to have some way that it's going to be grabbing those. you have to probably have something that notifies you within the JavaScript every time it's executed, etc. But, um, okay. So, I don't see, going back to this, I don't see any Curf protection. It could potentially be built into the cookie here. And by the way, I'm getting some good ideas about the cookie flags, but um, or at least the the session tokens, but I don't see it. So, just at a glance, because we're speedr runninging this, I'm going to say no sea surf protection on is it both of them, I don't see anything there as well. Yeah, again, they may have it and I just don't see it. But, um, yeah, on profile edit or uh privacy settings edit. So, those are both two options. We could also go in and just change their name to person that I do not like. And you can replace that with a less family-friendly version if you want. Again, that's not going to be as much impact. It's all about data. It's all about stealing customer sensitive data. Stealing customer sensitive data. Every single report that you submit, whether it's cross-sight scripting, serverside request forgery, no matter what the vulnerability is, always tie it back to exfiltrating sensitive customer data. Cool. Um, all right. So, no curve protection there. Corores, do we have any cores on the responses here? Where was the No, because it's not a cross origin request. So remember course cross origin request forgery corors is implemented when you want to make these uh HTTP requests to modify data or to pull data back in that is outside of the initial uh domain. So it would mean it would violate the same origin policy. Coors is so that you can send those requests when you need to violate the cross origin policy. This does not violate the cross origin policy at all. Not going to be an issue. We don't need to worry about cores for these. So at least for our attack not implemented same and let's go same FQDN right not just same domain same fully qualified domain name because the same origin policy is based on the full fully qualified domain name FQDN not just an individual domain or subdomain root domain anything like that all right so let's go in and take a look at the cookie flags here's the last one let's go back over here. Inspect. We'll go to storage. And it looks pretty simple. It's possible this session ID and actually let's sort this here. Okay, good. So, we've got two with HTTP only, two without. It's possible the session ID is being used as a CSUF token. And we can test that very quickly by just coming over here. What happens if we get rid of it entirely? that does go to an unauthorized. So it's very possible that this session ID is being used as a Curf token. So we'll document that. However, and you may have already realized this, hopefully these are starting to kind of come into your head before I say it. doesn't have HTTP only. So no HTTP only. What does that mean? That means that there's nothing stopping us from in our payload grabbing this sessionon value and injecting it as the um as a as a CS service cookie. Although I'm realizing as I say this why I kind of stumbled over it. If the way that we're talking about submitting the form, it's not going to matter. That's going to be submitted automatically by the user. So it would have no impact as a uh individual session or as a as a curve token. This is also interesting too. Let me just see. We have a bunch of Oh, we have a bunch of information stored in there. Interesting. Okay, this is a fun one. I may go and actually test on this one a little bit myself. I wasn't planning on it. I was just looking for a good target, but very cool. Um, okay. So, going back to our cookies real quick. So we have these are the two wonder why steam country has that. So the two that have http only are steam country and the steam secure login which is this is very clearly the session token and it looks like it does have an embedded uh object. So data actually stored within that. So let's come up to the cookie flags this right here. And actually let's do this we'll sort it this way instead. So, HTTP only, Steam Country, and Steam login secure. And I do believe that this is going to be our core session token right there. Um, let's just do this. And it also includes base 64 encoded data object. There we go. That'll work, right? Okay. So, we know that the session token has HTTP only. So, we're not going to be able to just grab that session token and easily send it out to a server that we control. The connection source is going to make that a little bit more difficult as well. Um, so, but that's okay. That's okay. And then the ones that are no HTTP only, that's going to be your session ID here. That's going to be your browser ID right here. And finally, it's going to be your time zone offset right there. Where do we go? Perfect. Okay, so that gives us what we need. We have a very good plan of attack in a very short amount of time. I've only been recording for 30 minutes here, so that's not too bad. Um, yeah, we we're good to go. So, what I'm going to do now, and I'm just going to show a few pieces of this, right? But I'd come over to community. I'm going to be navigating. I'm going to be searching for stuff. You know, let's go to the discussions. Anything that is under this steam community.com or anywhere else that it might be loaded, right? Here's all these new places that we can come and comment. So, I would go and make some comments. I would make some some posts, you know, responses. I want to populate as much as I can within Burp. Um, this is kind of funny. So it it shows the profile name. So there's one automatically and we can do some comments here. Test. Let's post this comment. Right there's been so there's so these are all places that it's going to be populated here. You know, posting that subscribe to a forum that's going to have the data that we included. Anywhere that you think that uh data that we just stored for the profile is going to be included would be a possible Oh, this is interesting. uh would be a possible place that uh we could get a cross-sight scripting, right? We can get an injection. So, every single place where our payload is loaded within the DOM becomes an attack vector. So, what I'm going to do, like I said, I would come back here. I'd go burp search arson profile name right there. I would do this for all of these. Oh, wait, hold on. Sorry. I don't want the request. Let's go ahead and let it search. I would expect to have more and we do. So look, we have all these different places here. Let's make this larger. Let's pull this up. Looking for arson profile name. Let's come over here. We're going to autoscroll. And already look, we have six different matches on this one discussions page where it's being loaded. Here's where it's being loaded within the uh uh HTML, right? So we have to be able to inject a double quote to be able to break out. Here it's being loaded in the middle of a anchor tag for an href. So we would have to be able to inject an HTML tag. get HTML injection and then escalate that to a cross-sight scripting once again within outside we're within the HTML tag there we are outside we could try and inject most of these are very similar here within a here we're within a button we're in the name of a button and we're back in the HTML tag so that's just one example you know here's another one here's one where we're injecting directly into JSON but we're injecting it looks like HTML so we're adding on to the complexity we're injecting htm HTML values within JavaScript. It's contents HTML. This is going to be rendered. So, can this is a great opportunity. This is a downstream effect. You know, can we inject HTML into here that maybe isn't sanitized because they're worried about sanitizing for uh the the JSON object. They don't want you to break out of the JSON object. Little do they know, you're able to get this to load later in the DOM, and that would execute. All right, everyone. So, here's where we're at. That wraps up reflected and stored cross- sight scripting. We still need to do DOMbased cross-ite scripting, client side prototype pollution, then put the whole thing together and a uh client side injections methodology and take that to I want to do one of the major programs. Uh thinking grammarly now, but I I'll see what makes sense at that time. Um video is about 7 and 1/2 hours long now. I don't know if you noticed, but the video started kind of skipping at the end. uh my PC, which is a very powerful PC, haven't had this issue before, seems to not be able to handle such a large uh video file and kind of putting them all together and everything. I don't know what's going on. I'm going to get some more RAM and some stuff, too. That's an easy fix, right? That's not a big deal. Um the other situation is, I guess, to to say, I'm leaving in a week and a half to go on a month-long trip to Asia. I'm going to go visit some family there, and we're going to be jumping around to a couple different countries. gonna be great. I'm really looking forward to it. But, you know, I really wanted to make this one long video and it was it's probably going to end up being like 14 hours now looking at what it is with the other hunting sessions. Um, so I'm faced with two options. I can either keep it as one single video and hit pause here, not release anything other than the clips that I have, maybe a couple more if I wanted to. go on my trip, come back mid December, you know, probably be jetlagged, go through the holidays and everything, and realistically probably not get the full video out to you until early February. Or I can end it now. We can call this part two. I can go on my trip, kind of relax, give you all some time with with this 7 and 1/2 hours to to learn here, and when I come back, go ahead and get started building out essentially a part three, which would cover the next two sessions. You jump in there. So, um, obviously you're watching the video now, so you know that's what I decided to do. So, we're going to go ahead and, you know, end it here. Um, you obviously probably looking at the runtime knew that as well. So, but, uh, but yeah, um, I think there's a lot of great content in here. I'm also, uh, reading through the comments of the clips that I've released, uh, I saw a couple people mentioned that they wanted me to cover blind cross-ite scripting as well, which is essentially stored cross-ite scripting that targets an internal application that you can't actually see and test on. So, I'm going to add that as well. When we come back to part three, we'll do a very short presentation on blind cross-ite scripting because that wasn't included in the first one that I did in this video. And then we're going to jump right into the hunting phase for DOM based and client side prototype pollution. We'll do a a blind cross-ite scripting and then take all of that together and go to a major program. So, that's going to be part three. was planning on doing a part three, but they I I want to make sure that this has just all the information I can possibly think of from start to finish so that y'all can go and test client side uh injections so that we can move on to other things as well, right? I'm really excited to do videos on like AI, bug bounty hunting, things like that. So, um I hope it was helpful. You know, I got to tell you, I'm I'm very very proud of this video. This is uh it's been a lot of work uh kind of going in over the past like month and a half. So, I hope it's helpful. I hope you like it. Uh I hope it holds you over for a little bit. And again, I'm going to go and enjoy my time with my family and the holidays and everything. And the first chance that I get really when I have the time, uh, the bandwidth there, I'm going to come back, get part three for you, and then we can talk about what the next steps are going to be there. So, um, thank you again for watching, and, uh, I will see you soon. Cheers.