Bug Bounty Hunting for Client-Side Injection Vulnerabilities | Part I

all right so I wasn't planning on making any videos on injection vulnerabilities for a little while until I went through some more uh logic testing but honestly I mean I I get probably nine out of the the 10 questions that I get on the Discord Channel or or nine out of 10 requests that I've gotten since I started making these videos are a question about crossy scripting and one thing that I've noticed is that almost all beginners seem to for whatever reason grav at uh to cross-site scripting maybe because it's it's just well known as a as a vulnerability but um there's a lot of nuance when hunting for cross- site scripting especially in public bug Bounty programs that is never talked about um you know a lot of the videos and education material that's out there show you how to do these really complex uh types of payloads or they'll they'll talk about like getting in and popping or possibly filter bypassing and everything but it doesn't do a good job of accurately representing what what the experience is from the researcher to go and hunt for these vulnerabilities so that's what I want to show in this video I want to show what it actually looks like and that's not uh just finding reflected input and finding that you can put a script tag somewhere or anything it's understanding how you can inject malicious uh malicious data into the Dom because ultimately what you're doing with a crossx scripting or or with any client side injection attack is you're looking to uh inject malicious data into the uh the document object model so to start it's really important if you're going to do testing for client side injection attacks that you understand the Dom and you understand how uh client site JavaScript works with the Dom so um and actually take one a step back further from that in order to understand the Dom you have to have a basic understanding of object-oriented programming so so just very quickly as a as a refresher hopefully or just if you're not familiar with it object-oriented programming is uh the way that developers will represent uh objects in real life through code right so uh a good example there is imagine you're making a like an adventure game right and and the user gets to create their character and their character has different attributes and they're going to go out to this world in this game and they're going to get to to fight enemies uh Etc so if I'm going to build that game as a developer the first thing I'm going to do is I'm going to sit down and need to create some objects that I can work with within the game so I'm going to create that user character object right now that that character is going to have and that's what we can call it right we can just call it a character object so now that we have that we would need to give it some uh characteristics right some some attributes so for for our example in the game right there's probably that character is going to have a certain amount of of health and maybe that's you know 100 for the character that's supposed to be up there fighting right in the front and then it's maybe that value is 25 for the character is supposed to be back healing people or casting spells or anything uh they're going to have plenty you know anybody who's played a video game would understand this right you're going to have like probably strength and dexterity and Agility and and your magic and whatever it is all these different attributes for each character so that when the user does go and create that character what's happening programmatically in the game is that character while the the program is running that character object is uh what's called inate instantiated so when an object is actually created in running memory that's called instantiation just means we're creating an instance of that object so when I create my character and begin playing uh the game within running memory the game is going to say okay well he has this character so this is now working and it has this amount of Health this amount of this and it's going to start manipulating those values as the game progresses for various reasons you know if my character gets hit then my character object's health value is going to go down when it heals it goes back up Etc that's that's really the the principle of objectoriented programming so if we take that back to the idea of a document object model so it really what it is is in the name so you have a document object and then the model is just this is how we're modeling the way the data is handled within this but uh the document object is meant to represent the current state of a web application that you are accessing within your browser so what happens is when when you go to a web application to test and you type in you know if you go to our program flowcast doapp uh you type that in there it's going to make a request out to that server but before the request even goes out the browser is going to instantiate a document object and that document object is going to have all types of basic attributes and information that is going to represent the current running state of that application right so initially uh the object is instantiated it just has things like you know uh document.location uh so the location attribute of the document object that shows the URL that you typed into the the browser there uh but when the HTTP request goes out to uh the the server the server is going to return data that is going to be added to that document object model and that's how a web application works as these HTTP requests are going back and forth between yourself and the server uh the data that is returned is added to this document object and the the changes that's made to the data within the document object uh cause changes in the application within the browser there um now the other way that you can make changes to the document object is through client side JavaScript so no request is actually going out to the server but there's client side JavaScript remember so when you're looking at a web application the HTML is is the nouns right it's the individual things that are there the uh CSS is the adjectives right it's kind of giving it its its color and it's its attributes and things and then the JavaScript is the verbs the JavaScript is telling the application what to do it's representing actions so the client side JavaScript can actually accept user controlled input and and use that to manipulate the document object model as well without ever sending a request to the uh the target server uh for it to send a response so these are two different ways that we can manipulate the Dom but ultim ly for a cross-site scripting for Prototype pollution for for any client side injection attack your goal as the attacker as the bug Bounty researcher is to be able to inject malicious content into that document object so the first thing you're going to do is you need to find a way to inject anything into that document object and so I just mentioned the two ways that you can do that you can either send a uh user controlled input to the server and the server will respond respond with that same user control input reflected in the response and that reflection will later be added to the document object or you can have what's called a source a JavaScript source which is a JavaScript method that is going to uh grab that user controlled input directly from the Dom and then use that to manipulate another aspect of the Dom and an example of that would be uh you know window. location. search I think is is how you get there but right so so so the the do search uh as part of the document object is going to access all of the uh query parameters in the get request um if you do the has uh then that's going to grab everything with a hash fragment ever it so those are going to be our sources that would go into that client side JavaScript and then if that client side JavaScript later passes that user controlled input from The Source into what's called a sync which is just a vulnerable method that allows you to either execute JavaScript or write to the Dom uh manipulate the Dom in some other way way and they don't uh sanitize or or you know the user is able to get a malicious payload uh to write to the Dom through that client side JavaScript you would be able to to deliver that attack as well now in order to hunt for these client side injection vulnerabilities we're going to be uh taking three different strategies uh to do that so and this is something I want to start talking about more and more in my videos right is is the strategies that we're using and what I mean by that is are we looking for uh a program with uh across all of the different subdomains within a program and we want to find a program with a very large attack surface uh with a lot of different subdomains we can possibly find a hidden one of those are we looking for a program with uh authentication where you can register your own accounts you know for the idors and access controls we can really only employ one strategy which is to find a uh an application that allows you or a program that has an application that allows you to register for accounts and then you can go and test the boundaries um client side injection attacks are much more open right so um anyway so the first strategy that we're going to be focusing on is the one that I just mention we want to do a very very wide scope and we are looking for uh any unauthenticated route that will allow us to inject some type of user controlled input into the Dom so what that means in practice is that just like I said we need to find a program that has a a large number of subdomains that we can potentially test and we need to work under the assumption because this is really going to be the case that the vast majority of unauthenticated pages have already been fuzzed to death right um client side injection vulnerabilities are quite easy to find or at least have some type of an alert that it could be there by automated scanners so uh you know if you're going to uh we're going to do our testing on Starbucks uh program there so if you're going to just the Starbucks log page and trying to to test for client side injection vulnerabilities you're probably not going to find anything there right because that's being scanned constantly so our goal with the first strategy we're going to employ which is the unauthenticated routes is to find hidden subdomains or hidden applications somewhere Within These unauthenticated routes that we can uh inject user control input and and manipulate the Dom in a way that would be beneficial to us um the benefit of finding vulner the benefit of this strategy is that unauthenticated routes can be delivered to anyone they don't have to be logged in in order to deliver that uh that payload so it's very easy to show impact to the the program owner right if it's a page even if it's an obscure page on some subdomain that nobody ever touches well if I can ultimately what we're going to be doing with this once we find a cross-site scripting the way to weaponize it is you have to deliver that to a victim in in typ typically a URL you have to force them to to go make this request that's going to trigger that action to happen in the Dom because remember the expit is is it's executing within their browser locally it's not happening on the server side so you're going to have to get them to execute that somehow um if they don't need to be logged into anything and you can either get them to go to a malicious website or you can deliver them a URL that that would have uh that payload within it and it will go and fire every time that's going to have a significant amount of impact to to the uh program owner whereas if it would only affect users that would be able to access that page if they had an admin role and that's a very few amount of people obviously it will still have impact but it won't be as widespread so first strategy unauthenticated routes where you're looking for hidden subdomains hidden applications that may not have been tested by other users and then or other researchers and then we are going to try and inject user controlled input to manipulate the Dom in a way that the developers did not intend our second strategy we're going to employ out of the three is we're going to be looking for authenticated routes and within that we're going to be looking for either hidden end points or hidden functionality because again we have to assume that if you can go in and register for your own accounts there's already been fuzzing done on basically every attack Vector on most of the end points that we can find so we want to try and first of all find some attack Vector some endpoint some function ity that that is not as easy to find because that is going to increase our chances of being able to find an actual uh way to inject something into the Dom into the client side uh you know as opposed to testing pages that have been done often they've been tested a lot and you probably won't be able to to find much of anything there the third strategy that we're going to employ and and the previous two uh focus on reflected uh responses from the the server right so with unauthenticated or authenticated routes you're going to be sending a request to the server the server is going to respond with data that somehow includes the user controlled input that you sent to them and that's going to be written to the Dom so the third strategy that we have is we're going to look for custom JavaScript files that we can potentially uh inject into the browser itself so that goes back to when we were talking about sources and syncs right at that point no request is going to be made to the server um now I I say custom JavaScript because if you're looking at the the chunk files or uh you know any existing uh JavaScript library that's being used almost certainly it's going to be tested uh and sanitized for any crossy scripting now you may find a zero day cve but that's essentially what you're doing if you can find a cross-site script if you're looking for cross-site scripting in an existing uh JavaScript library you're actually doing SEC security research you're doing cve hunting you're not looking looking for just a misconfiguration within the application and so I see a lot of people when they're first starting out they get in and try and find these vulnerabilities within JavaScript that's coming from react or angular or these these third party packages and uh you know they're essentially doing security research and one of the most challenging things to do as opposed to just looking for a way to manipulate the application itself uh to inject that data so um we're going to be looking for custom JavaScript files that ideally have somewhere when ideally they would have to have somewhere within that file uh to grab the user controlled input and then somehow later use it to either execute JavaScript or write to the Dom so we're going to look for that now one additional piece of this that I kind of tie into that custom JavaScript the third strategy is uh we're going to be looking for npm packages that do have a known cve so this is where you'll see those uh the the scan results that will say uh jQuery has you know this vulnerability these methods and everything and we'll talk about how you can potentially test those but what I want to make sure I talk about with that strategy and the reason I tie it in the rest of the strategies is in almost all cases you will find that that the uh scanner that has recognized that vulnerability supposedly exists it is recognized that a specific package is being used on the client side with a specific version but it does not mean that they're actually using the vulnerable method right when you have a cve of vulnerability in these npm packages in almost all cases it's going to be a vulnerability within a specific method within there right so like with with low Dash with prototype pollution it's the fact that they're using low Dash as an older version doesn't mean it's going to be vulnerable to prototype pollution they have to be using one of the methods that at the same time does a deeper recursive merge without sanitizing the user objects as well so I kind of fold those in there but we will take a little bit of time to show how to test those and I just want to make sure in set expectations that if you're finding those cuz these are questions I get all the time right if you're finding those scan results in burp or something else um does not mean You're vulnerable uh or you found a bug in in most cases you have not you'll need to go in and find out whether or not they're actually using the vulnerable method and the real way to do that is typically through fuzzing um so if your fuzzers are not finding it then there's probably not going to be uh too much there so so those are our three strategies that we're going to employ to look for client side injection techniques and the last major thing that I want to cover in this video and we're going to be taking a lot of notes about this and talking through it is compensating controls and this is the biggest Gap that I see with beginners that are trying to tackle these client side injection attacks and again almost always that's Crosset scripting right is uh the researchers that are starting out do not take the time to understand the compensating controls that will affect whether or not the client side code is actually going to exit execute um there's a lot of different compensating controls that can be put in place in an application to protect uh that application from malicious JavaScript firing and it's it's always layers I think this is a big part that people miss when they're first going in is they see that their reflected input or their user drone input is reflected in the response and maybe it looks like it's not uh sanitizing the characters right they can see that greater than less than in their script tag in the Dom but yet the JavaScript is not firing and they don't understand why but they believe they found something they're going to keep testing the reason is these layers and layers of compensating controls it's it's a principle called defense in depth that every blue team is going to have as a core tenant of their security practice right they want to make it as hard as possible to get that JavaScript to fire they're only uh they're not only going to try and stop those characters from coming in there's going to be layers and layers within uh the browser itself when when the request goes Etc so in this video video we're going to be going through seven different compensating controls that will have a a dramatic impact on your ability to sucessfully inject malicious JavaScript into the Dom through this client side uh injection basically to popping alert right that's what most people call to popping aler um the first is going to be the cookie Flags um so remember that when you are uh when you have cross-site scripting any type of client side injection that uh exploit is going to execute in your victim's browser so you're going to have to deliver that payload to them so they can click on a link somehow get that link that URL to execute within their browser when that happens your goal is going to be to get that malicious ex uh malicious JavaScript to somehow steal sensitive data within that application that you didn't otherwise have access to right we are not concerned at all with getting any type you know there's no uh injection to get a remote code execution through here right right we're not we're going to be all of our exploits are going to be isolated within the sandbox of the browser we're not attacking any of the application servers at all this is all about manipulating our victim which is a user a client to have JavaScript they don't want to execute execute within their browser so when we do that one of the most common ways that we can weaponize uh a a cross- a scripting or client side injection to show impact is to steal that user's current session time token um and then we can obviously use that to either get access to more data or we could log in as them Etc our ability to access that uh cookie and append it as part of a request to steal it is going to be entirely determined on the flags that are added to that cookie um specifically the HTTP only the HTTP only flag is going to decide whether or not that cookie can be accessed by client side JavaScript so if we if we have a session token with the HTTP only flag we don't have the ability to just grab that value with JavaScript and depend it as a query parameter and send it to our server so we can steal that session we have to get more creative in the way that we can do it so the cookie flags and that's just one example but the flags on our cookies are going to have a big impact on our ability to execute a cross-site scripting or client side injection so one of the first things we have to do is go in and find out what are the cookies what are the important cookies we want to steal and then see what uh what flags they have on that um we're also going to look at the browser security headers right so when uh a request goes to the server and the server responds that response has several headers that can be included that are going to tell the browser what it's allowed to do and what it's not allowed to do and some of those headers can impact whether or not clients side JavaScript can execute so we want to take some time to look at what the uh server is responding with what headers to find out whether or not they have any additional protections there um the third that we're going to look at is a Content security policy and a Content security policy basically tells the browser where scripts are allowed to load now it's not just isolated scripts but right so the for the purposes of client side injection techniques where we're really only interested in uh the script Source directive within the content security policy right it's going to decide can can scripts be loaded from anywhere if they can then I can load an external script and and have it you know I just do a script tag source equals uh evil.com and have that load in uh but most applications are going to have a Content security policy that would prevent that it's obvious to see that if you get a Dom injection the game's over you can do some some nasty stuff so they'll put a Content security policy in place to try and prevent that and then you as an attacker you now have to find a way to inject your script within the confines of the content security policy one example of that is well maybe they allow uh injections or they allow scripts to be executed from uh a specific Cloud uh Cloud front instance in AWS but then also they have allowed that that's a dangling C name that's a vulnerable to a subdomain takeover and able to go and get that and you're you can uh then host your payload and inject it that way you need to understand the content security policy and the and the guard rails it's putting in place so that you can know how to circumvent them later um the fourth is a web application firewall um I'm sure everybody uh that's watching this has heard of that at some point um a web application firewall will sit at the uh entrance before the application and it will parse all of your requests that are coming through and uh if it sees anything that it believes to be malicious it will typically just block you outright from being able to send that request which will stop the malicious response from coming back and that that user control input from being written to the Dom um very common expression uh in application security is uh if you want to make an application less secure put a web application firewall in front of it um we'll talk a little bit about why that is but uh you know first of all obviously you can see that's not going to do anything for uh our third strategy which is trying to inject uh something into the client side JavaScript because that request never leaves the users's browser they click on the link and it loads the client side JavaScript but then the user controlled input is all maintained within the browser but then also there's it's always a cat and mouse game just like with any other cve that you have um you know you're always going to be looking for bypass techniques and and Etc so um web application firewall is very very common uh control that the people are used to testing against um so we won't spend too much time on it but again I think it's it's important to note that this is just a one control in in a much bigger picture here and typically is not one that the team is even relying on very very much um so you know um the next two uh are essentially user controlled input validation so uh you have uh client side validation and server side validation this is again protecting against a cross-site scripting or client side injection that would require a request to go to the server and then come back but the developers are going to put in sanitization uh at different points throughout that process to try and make sure that no malicious characters are coming in if they're doing it correctly there are layers and layers and layers of this so there's going to be a client side validation just to see before the request is even sent those are obviously very easily bypassed by just using a web proxy or sending a cural request or anything directly um but they are an additional control that we want to be aware of the server side validations are going to be the much more common things that we're going to have to bypass so that's where you send a request with user controlled input that has your script tag and it comes back transformed in some way maybe those greater than and less than symbols or URL encoded or or a unic code or something else uh something on the server side has manipulated those characters so that when it comes back and it's written to the Dom it's written in a way that the developer intends to be safe intends to not be able to to be weaponized there um and then the final one and this is this is uh really commonly confused with the client side and server side validation but it's really important that we understand the difference because bypassing this is a completely different methodology is output and coding right so as opposed to sanitizing characters and trying to replace malicious characters or detect them Etc um there's also just generic encoding that can happen to a uh to to the user controlled input when it's written to the Dom um that's typically like if you see the you put in a greater than a less than and it comes back with the ersen GT semicolon or something or or maybe it's automatically converted to to URL or B 64 whatever it is so there may be an additional compensating control to where the the developers have said hey we don't need to worry about sanitizing this because we know that it's going to come out encoded again completely different methodology because now we're not trying to bypass something we're trying to find a payload that would that would circumvent the encoding which is something the developers didn't think of we're not trying to break their sanitization attempt we're trying to just find an an output encod an option that would uh happen to to create this Joba script injection so anyway I think that's enough time talking uh hopefully that gives us a good amount of upfront information but let's go ahead and hop in here I want to do some actual testing as quickly as possible because uh I'm very excited about this one all right let's go ahead and start by getting my framework running sh right there and we should see this open up here in just a second perfect okay we don't have any data in the tool currently but uh fortunately we can use the new updates from the alpha 002 to be able to go ahead and get that in very very quickly so uh like I mentioned earlier we're going to start uh we're going to look on the the Starbucks program today this is one that if you watched my videos before you should be very familiar with this is uh one of my favorite programs to to test on so um nothing really that we need to do to prepare for this they've got a pretty open pretty welcoming program here which is one of the reasons I like to test on it there is one thing that I wanted to call out here though that I thought was very interesting and I'm always I'm always talking about building impact uh when you're submitting your reports and if we come down here to some of the I think it's the helpful hints that they have let's see it's a little further down here uh perfect um so they have just a bit of information here to uh help you kind of think about the types of things that that they're worried about and I had I had noticed this before but I I saw it as I was getting ready for this video here and I think this is really interesting um generating fraudulent Starbucks cars finding a way to steal money from Starbucks this is not a critical issue to them uh now this is something that that a lot of people would probably think would be right if I can create a gift card and and get free coffee and everything they would think that Starbucks would be very very concerned about that but they say right there they're they're not and honestly it's probably because Starbucks they make a ton of Revenue every year so uh and they already have uh the expectation that there's going to be some loss uh through fraud waste and abuse you know whatever the the cause is and they work that into their overall budget so this is not uh you know having a bit of additional money go towards that doesn't have as much of an impact so what they are concerned about is uh the data that's stored there they're concerned about their customer data they're concerned about if it was compromised how that could impact them from a compliance standpoint um you know these fines that can come from that how what would happen to their reputation you know if all of their customers personal data happened to be stolen uh Etc so anyway I wanted to just kind of call that out I think that's interesting when you're thinking about how to show impact remember that it can be completely different from one uh program to another you know so whereas typically you would think of being able to to get free money as a very critical issue to a company like Starbucks is just not that big of a deal uh at least not to where they want to be a critical issue but okay moving away from that uh the two domains uh in particular that we're going to focus on is the Japanese and Singapore version of Starbucks right so you got the Starbucks Singapore there this is actually in English which is great uh and then the Japanese one which is not in English but that means that it's going to get less testing in there so um now as I mentioned earlier with our strategies the first strategy that we're we're going to use is try to test un authenticated endpoints and specifically finding hidden subdomains that would have an unauthenticated endpoint that likely hasn't been tested so in order to do that we want to use my bug bounty hunting framework to collect a large number of subdomains so we can potentially find some that haven't been tested on um now typically that would mean I would need to come in here and add in you know starbucks.com orsg whatever it's going to be but again like I said I have already done this I've already run a scan against these domains uh and I have uploaded them to my arson framework scans repo here so if I come up here to my GitHub come to repositories arson framework scans and you can see here add scan data for client side injection testing video click on this and we can upload this data so let's go ahead and clone this down should take just a second there there we go and now if we come back to the framework I'm just going to browse for the scan file that I downloaded and in here we have arson framework scans and we're going to go ahead and grab the data for our Starbucks programs and hit add and that quickly we have all the information we need to go ahead and start testing we've got our Singapore and Japanese version here you can see we've got 190 live us URLs here and then for the Singapore uh 30 so uh much smaller attack service for the Singapore version compared to the Japanese version we're going to be looking at the difference but remember we're starting our strategy by looking across this uh the attack surface of both of these domains to try to find any hidden subdomains any hidden applications that have possibly not been tested and then from there we're going to try to find a way to inject user controlled input into the Dom in some way um so we'll go go ahead and start looking through these and let's see if we can find a good candidate uh or start getting a list together to to find good candidates to begin testing for that now in addition to this as always we're going to go ahead and get our notes set up let's go back here and I will do touch uh client side injection. MD and we'll go ahead and open that up in VSS code here all right telling you I can never type while I'm recording I don't know what it is about it uh all right so let's go ahead and get that saved get that brought out there and we can come over here and we can start looking so the first thing we're going to do here is we are going to look through each one of these unique subdomains that also is a live URL so they is giving a valid HTTP response when we reach out to it and we're going to put them into different categories based on what we think we can do with them um and those categories we'll go ahead and start getting a few of them there I don't have preset categories I mean I definitely have you know seven or eight that are in my head that I typically play with but a lot of times what I do is start looking through uh the enumeration text tab over here and uh just kind of start classifying them uh based on what I'm seeing and and build out the categories that way but there's there's some that we can go ahead and and that are going to be pretty Universal across uh any program so the first uh and let's just do subdomains with valid HTTP response and we'll start getting up these categories here so uh the first one is going to be no functionality so we're getting some type of a response from the server uh typically these are going to be uh like a a 503 error some type of like bad gateway error or something but uh so essentially there's a DNS record and it is uh getting to some type of cloud infrastructure some type of infrastructure where it's trying to find an application but there's just no application there right so these are ones that we're probably not going to spend much time on while we're testing um but that's fine we can go ahead and get those sorted out the next is going to be restricted access right so this is where uh the application is returning a valid response but there is clearly an application there but we can't access anything we go to the root domain we go to any domain it's it's a 403 or or somehow they're they're blocking the access entirely so we can't seem to get to any functionality aside from that basic uh unau unauthentic iated or or you know unauthorized response there the next one is just going to be an API right and a lot of times what this is going to look like within the enumeration tab over here and we can actually get moved over there to it um what it's going to look like in the actual page is we will get a valid response from the page uh but we're going to be typically getting a 404 uh which means the the endpoint is not found and the reason for that is most apis they're not expecting to somebody go to the the root directory uh an API an application programming interface is designed to allow applications to talk between each other and manipulate data so any requests that are coming into a subdomain that is specifically designed only for API calls is most likely not going to have a root directory it's only going to have specific endpoints that a developer would know about beforehand so that they can send requests to it they would also you know you would expect the developer to know the the uh parameters and how that data is is accessed and manipulated um but we can still try and figure that out through different fuzzing we can fuzz for hidden endpoints we can fuzz for parameters and try and figure that out and if we can find some functionality that maybe other researchers weren't able to find we can potentially leverage that to get our client side injection vulnerability as well and keep in mind uh with a client side injector with the API it's easy to think that with an API since there's not going to be a Dom involved you're not uh you don't have a chance to get a client side injection but you would be surprised it's it's fairly easy to misconfigure the way those responses are coming back from the API to actually have that render as text instead of being a Jon or have it render in an insecure way and you can still get that uh client side injection that's actually something that that uh is a pretty uh common occurrence uh in in bug bounty hunting so probably a good idea to get that situation uh put in your head there so but anyway I digress uh so we've got API application programming interface we got no functionality we've got restricted access now uh we're going to have basically login Pages uh that we don't have the ability to log in on in fact that's what we're looking at right here right and and this if we look at what the domain is Right autodiscover anybody who's familiar with withn net and and Microsoft Tex STX is probably going to be familiar with that as well uh but you can see the C name also so the autodiscover is a cname so basically an alias for this autodiscover.xml Let's uh oops try that one more time what do you think leave that in the recording because screw there we go so the other side of that is an internal service right um so as opposed to finding something like this that's actually a Microsoft service if we were to find a login page to an internal service it was like Starbucks admin or maybe they had uh some type of uh internal web application for their employees to access to to track uh what the different stores are doing what their inventories are how much money they're making how much paying their employees that would be a a fantastic Target for us to try to leak data uh and the first way to do that for your client side injection we could try to get AC Crosset scripting on that unauthenticated login page or some other unauthenticated endpoints in that subdomain that we would be able to find there and then the last category that I'm going to go ahead and create to start is full app with Authentication [Applause] right and this this is going to be our main Starbucks application right so somewhere in here should just be the basic uh yeah the Starbucks Singapore it's a basic a record that goes there so that we open this up uh we would be able to log in we would able to register for account so this is where we're going to be able to get in and start doing our deeper testing but uh first we're just going to look at the unauthenticated routes and that would be uh our additional uh additional category there so this gets us set up right we've got six different categories that we can now start going through and uh sorting these URLs that have been discovered based on which category we believe they fit in here so now let's go through each of these one by one and uh we will do our best to put them in one of the categories we've already created or if we need to we'll create another category and uh see what we end up with here so uh we've already looked at this right we already know that this is a login page that we should not be able to log into and uh it's an external service so we can hop back here and just drop this one here and if we come down to campaign uh so campaign is another C record or C name record but it's going to an elastic load balancer in AWS so this looks more like an actual application that we would expect to see uh looks like it's actually a redirect here to the dub dub dub as well so from what I'm seeing I think this is actually it's from an HTTP as well I think this is probably just a hard-coded redirect that's what it looks like at this point so I'm going to put this down as the full application uh and then in parentheses I'll just put core app right there actually let's do redirect redirect core app right there and we'll find out if that seems to be true uh same thing over here right this just has the port uh embedded we don't need to do that here's another example of an external login page we shouldn't be able to log into this right here is uh looks they're involved we're involved with their uh you know net their a Azure infrastructure so we'll go ahead and copy that now it's not that you can't find vulnerabilities here or you can't find client side injection vulnerabilities here but in most cases with these external service login Pages you're going to be looking at known cve um and with a cloud environment like this it it gets even more uh unlikely that you'll find something there if you do see Cisco uh you know routes or anything if you're not if you're seeing it to where it's like self-hosted and you think you're actually accessing a physical device or something that they have to maintain an update definitely take a look for cves and you can do a little bit of testing um but I would not expect to find just a generic uh client side injection here on on an endpoint like that um here's another one very very similar you've got enrollment and registration here but this once again this is a a c record for a windows.net domain so this doesn't look like an external login page necessarily it does look like endpoint not found so this tells me it's probably an API but a standard API I'm actually going to put this under no functionality here just because it it doesn't look like a prime target for our client side injections anyway it's probably not something that I want to spend my time testing on uh now the link discover we're not getting getting any response at all from that I'm not sure why this showed up in our live URLs um but this is also part of the Microsoft services and and redirects over here so we can just grab this one and put it as no functionality as well I don't expect to get much from that so so far this campaign not Starbucks is our only good Target we're hoping to find a few more uh but that's fairly common you know you may not find uh too much so okay and this is this is interesting um so you have a uat in the domain which typically is indicative of a testing environment I don't know what the mop stands for that's not a typical convention and this is a c name record but it's going to this Starbucks domain with fastcash.net now we can you know come over and do a search for Fast Cash which is what I typically would like to do if I saw something like this um you know we do a little bit of research and we'll find that fast cash this is a way to uh basically improve the performance of uh applications built on the net Tech stack um at least that's what I found through a little bit of uh little bit of research I'm not an expert on net by any means uh or Microsoft in general so uh somebody please correct me with the comments if I'm if I'm off base about that but uh the important thing is right we come here and we're seeing a 403 so what this means for us now is this looks like a restricted access now it's still an external service and even if we could get past this it would probably just get us to a login page P or or possibly an API or anything but uh really what this means to me is it's not a fantastic Target um right here once again we have an external login page hopefully this is starting to kind of give you an idea of how these categories make sense this is always one of the first things that I'm going to do uh when I'm going through Target in general right this is one of the first things I do is I'm going through enumerations I want to document and try and figure out what category each one of these fit into now this one this actually looks legitim let me ahead and open this up and make sure it's going to open up again because it's another uat so this I would imagine is a staging environment for their shop and it looks like a completely different application yep in fact I don't even see well there's the option do a login page so it may not be exactly a different application but it's fairly close enough I actually don't want to that let's grab this here just to make sure we get the correct protocol uh and this I'm going to put this on the top here because this does look like a great Target now it's got authentication um that's probably a shared authentication with the core application but at least it seems like some additional functionality there so that's our first good Target and we've got the shop as well okay so here's your staging environment you've got different featured items uh most likely I mean it may be that that was just cycling through when it took the screenshot but uh this one does look a little different so this is the non- staging environment but that is an entirely different Target for us right because they may have pushed out updates in this staging environment that have not made it to the core environment we can find the client side injections there and that'd be a great thing to do for for the owner of the program right because now we can catch it before it actually gets into production they shouldn't have any sensitive data in here but we can still show them impact and say hey once this rolls out into production it's certainly going to uh be able to be weaponized so um that's just a good if we can catch something in their staging environment before it goes to production that's a great way to uh kind of show that we're we're partnering with that company and trying to help them as much as they are helping us by allowing us to test uh okay so we've got the main uh application right here now obviously we're still looking at HTTP right now but I would imagine it's all going to redirect uh and I'll just go core app just so we can track that and let's see what else we got down here uh back to a [Music] campaign shop shop we've got a sip endpoint here which sip can be voice over IP a Voiceover IP protocol I don't know if that's what it's referring to here uh looks like it's just not responding at all so just get that added in there that should be fine uh ah okay and here's possibly an API now the the naming convention is weird uh to do dubdub one starbucks.com but uh this is typically what I would expect to see for an API that's just strictly an API right is there just no root directory this also is an a record straight to an IP address so not an external service not anything else so um I'm going to go ahead and grab this and ask myself the question is this an API and we can come and fuzz for hidden end points possibly find hidden end points find a way to actually get user controlled input going into it maybe this hasn't been thoroughly tested to where we can force this API to return uh an actual rendered script tag and and actually execute JavaScript there uh let's see if we have anything else on this end this looks like just another instance of the core page um here's the this is most likely just the generic staging environment for their core app uh so let's go ahead and this is a restricted access so we would want to bypass that restricted access to try to get you know somewhere that we can some attack Vector that we can inject uh something into the the client but I think that's about it you know this is a a fairly small attack surface it seems like a pretty consistent teex stack right we're seeing a lot of stuff with with net we've got the the auto discover the link discover end points um everything that I would expect to see from a typical net application here so I think we can go ahead and move on from the Singapore and let's go to the Japanese version of it which I have already done some poking around and they have a completely different technology stack I think it's really fair to say that these are completely different development teams completely different technology Stacks they likely don't uh work at all with each other um so we can treat these like completely different applications they may have different code patterns different breast practices that they're following here in the Japanese instances that the Singapore team are not following and vice versa so we're going to treat this like a completely new application but we're going to do the exact same thing uh we're going to go through these live URLs these unique subdomains and we're going to try to find uh try to put them into categories to find any uh unauthenticated endpoint that nobody has done testing on yet so we start out we're getting these initial uh error messages on these what looks like staging environments this has like a UDP so that's a you know HT HTP streaming HTTP requests as opposed to to TCP there um potentially I don't know that could be another internal thing um let's go ahead and put these first two in the category that there is no functionality is what it looks like right uh we don't know that for sure but it appears that this is just a broken endpoint now what that could mean is they've registered the domain they've set up the load balance there there's no application behind behind it it also could mean that this is hoping for a specific uh header or value or we we there's something that we should know to send with this request to have it not return this error so that's another thing I would be trying to do when I'm looking for uh an attack Vector that no one's found yet if I can circumvent these server errors figure out what would make it not error I can potentially find somewhere to inject uh user control input into the client uh this one on the other hand these are a records but the this looks like an S3 bucket and then we also have the asset subdomain as well um so probably yeah Amazon S3 right there so um we're just going to kind of skip over that uh that's an external service I'm not interested in testing aws's environment for the possibility of a client side injection this one okay here's another redirect so they still are using Outlook over here so likely still have uh you know the office uh Suite Microsoft office although it looks like they're not hosting anything in Azure at least not the the pieces that we've seen but uh we'll drop this in as the external service login page as well let's keep going down now this is a very interesting one so we have a redirect and it just loads oh it's redirecting to the login page okay so this looks like an internal ser service that is lever it maybe it's an internal service it it appears to be but it's leveraging their core applications login page here so is this something that's just meant for employees and employees have a special account in their core application I I hope so because if so then maybe we can abuse that trust relationship somehow uh register for an account ourselves and then get into this uh privileged area here but maybe it's not maybe this card is just involved with the gift cards you know we really don't know but for now I'm going to make the assumption that it's an internal service and we will go from there we also have a card two and card two is returning something different and I do not know what that says but let's go oops Japanese and by the way there's extensions and a hundred other ways to do this better um but I just want to do this this way for now uh okay so this one seems like it's just not available so card two is maybe a test environment or maybe they're working on a new instance of this part of the application but this one I'm going to add for no functionality right now but again even in all these no functionalities we can still do some fuzzing to try to find some functionality there see if maybe there is something hidden behind it but these are probably the least likely these or or these are the least likely to find any client sided ction on all right let's find some good Targets this one doesn't seem to be loading H that's kind of strange let that load for a second see if anything happens is there anything in the dawn there is a basic Dom there's basically nothing I can't tell if anything's loading or not I'm going to skip that one for now but I'm may come back and do some testing on it let's try the same thing here this one doesn't even have a DNS record ah it's just basic HTTP um yeah you're unless you've got the username and password for basic HTTP off it's not a very secure off but brute force is not going to be in scope for this bug Bounty program so there's not anything else that we can continue to do uh all right let's see we have a few more of these uh these are generic 403 so let me go ahead and grab this here this is going to be another one that is restricted access we can try and bypass that 403 there lots of Dev 3 cart 2 Dev 2 forbidden forbidden so a lot of other oh this is interesting here discover your favorites okay so does this have authentication I think it does share authentication yeah it is sharing an authentication here although I'm I'm not authenticated right now I don't believe um but completely different functionality so I'm going to add this in to this right here the full app with app I think this is a piece of the core app and we can come back and find out later um but it does look like there's going to be some options here to manipulate the Dom and I'm actually thinking with with something like this where yeah we can click and and make some adjustments here this I am really hoping is done with some custom client side JavaScript and we can start looking for Dom based cross site scripting we can bring out the burp browser with the Dom I forget how you say that whatever their extension is to kind of mess with the Dom and everything too so um this looks like it could be a prime target for custom JavaScript uh just going to make a note there remember I don't have any really good uh format for my notes I kind of just do whatever feels right while I'm while I'm going through it uh here's another one the green apron club and we've got looks like a number two that we're not allowed to access so I would want to try and bypass that and we also have this one here which appears to be accessible and anywhere that we can potentially have user controlled input that can make it into the Dom we want to test that so this takes us back into login page but it certainly seems like this is a possibility uh that we could inject something in there and it does have authentication as well it just shares that authentication with the core app which again you know is this the green apron Club it does that mean that they are Starbucks workers are this is this an internal employee portal uh that you can log into and in which case if it's leveraging the session from the core uh application and their employees are told yeah go right for the core application then you can come and it's essentially a single sign on implementation to get in here that's big for us as bug Bounty researchers because that means we can very easily show impact we can Target the session of the core application but we can Target uh uh Starbucks employees that would have access to these end points under the green apron Club as well that are probably going to be more sensitive have more sensitive data to them so this is going to be a very very good Target there we'll come through a a few more um ah this is uh HTTP uh basic okay great and then here's the actual instance of it too cuz this again looks like a completely different application now I don't know if there's authentication but I'm going to assume there's you know it's at least tied into the core app there somewhere and most importantly there's probably going to be somewhere that we can inject uh into the the client side so let's come through and see if there's any more but I think that gives us a good amount to work with right we've got some with no functionality at on we'll do some basic tests just to try and see if anything can can uh return a valid response um so here we're looking for just anything aside from these General you can't do anything and if we find that we're going to try and get uh user controlled input that's reflected in the Dom somehow restricted access so we're going to do any type of 403 by passes we're going to try to do like the X forwarded four or anything there try and trick it to uh give us access to these pages and then if we can find that obviously once again hoping to find user controled input injected reflected in the Dom and we'll go from there this API will do some fuzzing for endpoints just to see if we can find anything if we do find endpoints uh we'll go we'll be looking for any endpoints that return Json data with the content type text it's a very common misconfiguration that we can find client side injections in for the external Services we're probably not going to touch these I may look for a couple cves but I'm probably just going to skip right over these this internal service we'll look for some additional end points we'll do some general fuzzing but not going to spend too much time on that and then these URLs right here are going to be the uh main part of my testing and actually there's one that's missing here is the core application for the Japanese instance here so that should just be got to be here somewhere right that one kind of looks interesting too we play with that later uh also a product let's grab this so you can tell I'm doing this live like I typically do I want to test that one as well uh and then where's the where's the core application here there we go no should be starbucks. JP let's just come over here to what happens if I open this now still gives me a forbidden it is not okay so uh my scanning must have uh gotten me blocked temporarily um so unfortunately we may want to come back and test all these 403s they may not be 403s it could just be a the cloud flare uh or Cloud front WFT that's that's catching it there but uh anyway this is the core app here so let's go ahead and copy that and I'm actually going to get this let's do this I'm going to move this one down here as well as well because we will do testing on each of these first and then when we move down to these two this is actually going to move from our unauthenticated endpoint strategy to employ our authenticated testing strategy we're going to go ahead and create some accounts and we will try to do fuzzing for hidden endpoints hidden mechanisms hidden fun functionality within those authenticated routes of the application there and talk about how we can weaponize that too so let's start going through these one by one and the first first thing we need to do is get burp sweep brought UPS we're going to be using that to capture our sitemap and and be able to send requests just like we always do and we'll do a new project and let's call this client side injection right there without an equal sign and we use the burp defaults there and now we'll go ahead and come over to our sit map and I want to add two different settings to the scope so let's do one for each here we've got our co.jp copy that real quick yep that's fine there and then we also have uh com.sg so different top level domains there different name and Convention we'll get that one added as well and we'll leave both of these as in scope for now. SG but this is going to allow us to switch back and forth uh between them as well so uh we'll get that set up and other than that I think everything within burp site will be good we may come in and add some additional resource pools if we need to um we're definitely going to add some extensions later as well but there's not much that we need to do right now so let's come back to our notes and we're going to start by testing these no functionality end points now these can be kind of difficult to test in burp site because a lot of times if they're not sending a valid respon response it's not going to be put on the S map and and things so we're going to grab it with the proxy we're going to send these to the repeater and then we're going to see if we can try and find any functionality from these endpoints that are seeming to not have any there so let's come back over here and we'll just pull up random one and let's see got to make sure that all of our requests are running through burp and I'll go ahead and send that there uh okay so we'll come in burp site let's make make sure that's going to our proxy it is okay so we have a 404 response um saying that it can't find the endpoint um this may be you know some type of API we could fuzz for some some hidden end points there we'll definitely try and do that um but here you can see we don't we don't see it on the site map actually that could be because we don't have this here but I think yeah even if we're filtering so we would show 404s the proxy is not actually going to add this to there so let's just send it to repeater and we'll get the the rest on here as well make sure I go to the right place now let's try this one if I remember correctly the link discover yeah that one didn't didn't show anything at all yeah and so this one especially right like it's not going to add anything to the sitemap because we're not even getting a valid response from the server um and this is part of the uh net stack so most likely we're not going to find anything there but we'll get it added to our repeater anyway the Sip I think was the same no response yep same thing as well but we'll still add it to repeater see if we can get a valid response now these I believe were server error if I remember correctly so these are the ones that I'm most optim yes it is the one okay these are the ones that I'm most optimistic uh that we may be able to find some hidden functionality here because I think that these may be looking for uh some type of a header or uh parameter something to say that it's authorized uh to make this um the server errors a lot of times this is a way to off youate that you're actually just unauthorized or it's an unexpected uh request there so let's send this to the repeater as well send this again just to make sure yeah so we can get that I think the other yeah the other JP was the same here okay this one is an account UDP um yeah I don't know what that means I don't know if it's streaming account data outward it's accepting streaming account data into it um or it may just be a different name and Convention and I'm assuming that that's uh talking about the protocol and actually has nothing to do with it all right the last one we got here is this card to I don't remember oh that's right this one is a is a redirect it redirects over to here and uh yeah looked up that message and it said uh basically you can't use this one right right now I believe all right let's make sure we can get that I really only want to look at this one here and so this is actually I don't know if this would be considered no functionality right when we send a get request to the root directory we're getting a hardcoded response so my question is is that the only functionality that we have here is this card 2 just designed to redirect over to this uh this domain right here or are there other endpoints other functionality within this card 2 domain that we can possibly do some testing on that I don't know um but yeah if we come to the Target right we don't have anything in here really the card was the only one that uh is showing up in our sitemap because we don't uh we're not getting a valid response from anything else that's totally fine all right so we'll move past here we'll come over to the repeater and then again we're going to try and find any way to get a different type of response from this endpoint here so I'll start by just sending request so again the the 404 makes me think that maybe there's some other end points here so let's start by fuzzing for some hiding hidden end points uh and we'll do that two different ways so first let me come up to extensions and I got to add Pam minor here scroll down scroll down where we at param Miner here we go also can sort by the popularity because you can see this is one of the the most used ones for anybody that's not familiar Pam minor allows you to fuss for hidden parameters hidden headers hidden cookies it's uh created by uh Port swigger um really phenomenal extension here I this is definitely mandatory for for any bug bounty hunting uh so we'll come back over here and now once you have that extension installed right we can see here that it's been installed and it's loaded then we can come back over to repeater you can also do this in the sitemap but we don't have this in the S map rightclick extensions Pam minor guest pams and now again we're sending a request to this endpoint and it's responding with a 404 but that 404 it's it's clearly from a Windows service so um what I would do with an endpoint like this we're just trying to get any type of functionality I'm going to do this to each of the uh endpoints we're testing or domains that we're testing here um I'm going to try and just guess everything I want to throw this at it you know a bunch of random parameters bunch of random cookies random headers and let's just see if we can get any type of a variation in response cuz param miners going to do that for us let me hit enter through those four there param Miner is going to do that for us param Miner is going to go through and it's going to send chunks of uh various different uh parameters very different headers right so um it'll send a request to say you know test equals test and blah equals blah and Fu equals Foo right and but it's going to have probably like a hundred different parameters there and what pram Miner is looking for is is there is there any major variation in the response from the Baseline you know this is our Baseline so is there a difference in the content length is a difference in the amount of time it takes to come back difference in the response difference in the actual content that is coming back anything that that would tell burp site that there could be an impact with uh one of these uh parameters or again you know it's also going to do forwarded for colon you know blah whatever it's going to be um but yeah can we send this and is it going to give us any type of a response oh and this is interesting actually just doing that it's uh it's breaking it somehow so I wonder how well that'll happen it doesn't seem to like the parameters there well now it doesn't seem to like much of anything uh I am not sure did I just mistype something as well let's see I don't know anyway if it does happen to find anything though uh we will see a uh finding come up in here or will probably be added to the the site map as well when it does find that but um so yeah it will have a responsible come up say hidden header hidden uh parameter Etc and uh we can go in and do our investigation from there so um we'll let it continue to test that uh the link discover as well so we're not getting any response from this so I certainly don't want to do any active fuzzing or anything against it same from the Sip um let's come down here to this one these we can come back and and play with a little bit honestly if they're not giving any response at all though I'm probably just going to drop these out um you can definitely do some slow testing to try and see if you can get a valid response uh but with these also being right Sip and Link discover I'm not expecting there to be anything there so we'll skip over those and let's come do a little bit of testing on these uh endpoints for the Japanese instance of the application because this is where I'm the most optimistic and we're going to do the same thing again right so I'm going to come down here to Pam Monitor and I'll ask it to guess everything same thing over here cuz remember these could be oh this is our that's right this is our hardcoded one sorry so let's not do that one yet let's keep testing on this one um Okay so we've got Pam Miner running against our uh Japanese version here and we're going to let that run in the background for a while and now let's see if we can figure out what's going on with this response here and if anything pops up where we do get a response from Pam Miner that would be great but yeah we'll just have to wait and see so first thing I'm going to try I'll probably keep that for right now I want to just try Googling this error message and what I'm trying to figure out and that kind of answers my question but is this a custom error message that the uh Starbucks team in Japan they've created um it certainly looks like that but this could be a generic error message to where where I can identify what technology is returning it and possibly figure out how I can get uh how I can get functionality here now obviously if you look at this there's not a lot of responses we're not seeing stack Overflow articles we're not seeing medium articles things like that so this looks like a custom error message that they have created to respond when this endpoint just doesn't get a request that it expects right so um hopefully one of the ERS or one of the parameters or values here is going to send a different response let's just play around a little bit with it let's come up here see if there's any difference from removing the cookies we still get the same thing there um yeah there's not too much else that we can do we can go ahead let's send this to Intruder and let's also see first of all I'm going to build a resource pool that's much nicer to the servers here so let's do our low and slow remember we want one maximum concurrent request I only want to send numb lock helps one right there and we'll do one every let's do 750 milliseconds so almost a full second but then we'll do some random variations within that and then we'll make sure to back off if we start getting any any bad responses there so um I'm going to go ahead [Music] and let's do arson yeah that's fine arson right so we'll just put an arbitrary header there and just first of all let's make sure let's see how it responds to a generic header being there interesting it doesn't seem to like that what happens if I come back here doesn't look like we're getting any response at all um ah so the problem I think let's cancel this let me say hit enter right there send ah and now we're getting response okay um so the reason that was happening let me come up and hit this button here so an HTTP request has a very specific it's actually a bite stream it's a stream of individual bytes here right so every one of these characters is a bite you know uh we can be converted into to hex there so um and every line here is ended with this return carriage and line break that's what the server is expecting that's how it knows because this is not you know it just comes as a a stream of information it says okay uh this return cares line break that means okay that one's done and now let's start reading the host header okay that's done now let's start reading another header etc etc the way that the server knows that the HTTP request is done is if there's two return carriage line breaks one after another at least if it's a get request if it's a post request obviously then it's going to be looking for a body or or things like that but in this case it's only going to be look or once it finds those the return carriage of line break then it says okay the request is done and now let's send the response if we go back and remove that additional line break right there which is we actually had it like this before then the server doesn't send a response because the server is waiting for that second return carriage and line break in order to send the response and then it's like okay now I know everything is done so that's the reason that we didn't get a response there if we hit enter as well now we see that we get the response um so that's just something additional to know uh didn't think I was going to run into that but uh can be helpful if you run into it so anyway um so that's fine let's see how it likes our arbitary header now that we can do arson arson see if that has any impact and it doesn't Okay so that's perfect so that means we can do a little bit of fuzzing there so I'm going to add this is a payload here and I'm going to add a second payload that's going to be end points there um so that will allow us to do some testing and then instead of the sniper I'm going to use Pitchfork so we can use a different set of payloads for each one let's come over to the payloads the first one that we have right um sorry first one that we have is our endpoints there uh so what we want to do simple list we're going to load this up with the uh seist right seist Discovery web content and I'm going to come over here to the raft and we're going to do directories we'll do raft small directories uh the reason for that is I'm just hoping to find any type of variation and I think the directories word list is going to give me the the greatest chance to do that so we'll add that in there and then for the second one remember our second payload is going to be this header let's come in and see if we can find any headers to use here actually I don't think the headers are in the web content now that I'm thinking about it let's go back to se list and I believe this would be under miscellanous uh and then source code am I right about that no that's probably not right um web that's what that's right okay web okay and then we've got a few different ones here uh should be within this folder come on open for me perfect Perfect okay and then I know we have some that are okay so we got an IP address non-standard examples we've got fields and examples right there so I think what we want to do is the fields if I remember correctly that should be the server names it is perfect okay so we'll go ahead and get that one loaded up uh we've got the non-standard and the standard I think that's good that'll give us 67 payloads there so okay so we have a uh we have two different payloads here we're going to be fuzzing for end points we're also going to be fuzzing for hidden headers um we are doing two of the different word lists there uh with the Pitchfork so it's going to run them at the same time and then we're going to do our low and slow resource pool so this is just slowly going to send these requests as well hopefully something will pop up that we'll see a variation but again anytime we're doing this automated testing we want to get it running in the background just to kind of help us we never want to overload the servers we don't want to overload our own machine as well although we can always reboot that um but it's good to have this running in the background while you're testing so that you can come back at different times and and see if uh see if you do see any variations that could potentially point to some hidden functionality so we'll go ahead and hit start attack there and we're just going to let this run in the background and you can see our Baseline right in fact let's come up here to the columns and I want to take a look at the response time as well but uh you can see our Baseline right we're getting a 400 status code we're getting you know taking around under 200 milliseconds for the response which means this is almost definitely being kicked back very quickly there's not a lot of processing happening on the other end and then we've got our 885 for our response so any variations in those numbers any errors any timeouts anything like that could tell us that there could potentially be some impact to the request that we're sending there so let's go ahead and minimize that there um the Pitchfork is going to end quite quickly so if that one doesn't work I'm just going to start one more after that doesn't look like we're getting o interesting okay let's send this to the repeater you see that we have a variation in the response when we send a get request to login we are getting redirected to this https are we using HTTP for this one or how is that one working H thank you robot for calling in the middle of that and then hanging up that's great I'm going to leave that in the recording because that stuff is really really annoying and it happens all throughout the day so that's phenomenal uh oh there's a redirection here that's what I'm looking at okay so follow the redirect we still get a bad request but now is it time okay so this is a little bit of different functionality right we're getting the response directly from Google so so this endpoint that we thought had no functionality now we've actually found through our Intruder that if we send and I wonder if we need that header as well let's try that let's come back over here it's doing accept language twice I wonder if that has something to do with it um I'm guessing not I'm guessing it's just the login so let's get rid of this here let's go all the way back right just this get rid of the accept language we're still getting the Google redirect here stage out login okay so this login endpoint is causing us to get redirected where we were not able to find any other functionality so let me go ahead and copy this over and that is under the stage two right I can check for the UDP as well all right so we're going to do that and then we will say uh returns 301 hard redirect to uh we'll just call it 400 and then we'll capture this okay so now under our no functionality right we have found some type of functionality we don't know what it does in fact it looks like it doesn't do much of anything but this is we went from having a URL that we felt we could get no interaction to it and now we found that it does have the ability to interact with it and specifically if you make a request to uh this login endpoint so I want to know now is there other hidden functionality with other endpoints right is there an entire application here that we can start to interact with if we can just find the end points that that uh the server will respond to so let's go back to our Intruder again uh we're going to get rid of the attack that just ran with our Pitchfork and instead we're going to come through and do we'll just do a sniper here we'll run through for each one and uh if we come back over here so this will do a total of 40,000 requests we're going to keep our resource pool in here everything else will be the same um you know what I'm actually going to get rid of this too cuz we're already fuzzing for headers I think that's fine let's just get rid of that payload and let's just see what happens because we found the login endpoint let's just directly do some fuzzing for the endpoint so I'm going to let this run in the background again um I want it to be very low and slow and I'm actually going to move on to another URL but uh the great thing is we're starting to find it we're starting to dig in more and more and this is what you're going to do you know it's it's up to you whether or not you feel like this is a good use of your time while you're doing client side injections you know you may want to come in and spend a lot of time fuzzing into these endpoints that have no functionality because other researchers are probably going to skip over these uh but there may be nothing there and you may be going down a rabbit hole and you may spend hours and hours not find anything so it's really up to you whether or not you you think that's a good use of your time but we'll continue testing on this one um I would imagine that this uh well potentially has similar functionality let's come over do I have that one I don't think I have that one captured in here let's try that same one and then we'll move on to our card to so that gives us the same response we come back over to our proxy send to repeater and then if we go to login do we get redirected we do so and it's the exact same response so this is almost definitely these two are very similar applications so let's get a little bit of room here and we'll put the same thing here except we'll change this to UDP that should be fine okay so now we have a new Target you know we have this login inpoint here and we don't have to follow the redirect we can send it straight to it you know so I want come back in here you know now we'd come back in and do the Pam Miner again now I'm not going to do this right now cuz I want to let the others finish running I want to give it a little bit of time um but the next thing I'm going to do is start fuzzing for for get parameters right I'm not as interested with the headers although it may give some respons actually with this Google it may be a good idea to S responsible with headers um but for now we're just going to let those run in the background uh we'll keep checking in on them and we're going to continue to poke at these and try to find anything else that's going to be hidden so I want to move this back over here and uh let's move this with it where's our card too there we go uh okay so for this one we already are at a redirect um so what is causing the redirect is there any additional functionality that we can get outside of this let's see first of all do the cookies have any impact on it doesn't seem like it most likely it's going to be the end point here let's just see what happens if we give it an arbitrary endpoint doesn't seem to mind we don't see anything redirected here so this very well could be just a hard-coded redirect uh interesting that it is forcing us to have this cookie here um but yeah I would really just go and do the same thing right we're going to fuzz for end points we're going to fuzz for hidden headers um see if there's anything else that we can do the last thing that I want to try that's different from anything else that we've done is let's see if we can just give it let's send this to Intruder actually let's see where the redirect goes first that's right okay so it's to an entirely different domain so let's send this to our Intruder as well and uh we'll get rid of this arbitrary value but I am going to add a payload here and coming to the payloads I'm going to do some actual fuzzing we'll come back to the fuzzing library here and I'm going to try just throwing some unexpected input to this and seeing if that will disrupt the way that the uh load balancer is processing these requests you know if I sended a null bite in the past or or anywhere else is it going to make any difference here so um let's do where are we at um the URI hex right here so this is just the hex encoded version of every possible asky character and then we'll do the same thing with the Unicode uh version right here right so we've got all the different unicodes now we've got a double uh you or double hex en coding right there for that um so let's come over to our resource pools hit the low and slow and we'll send that we'll just let these run as well and we will wait and see if there's any type of variation in what's coming back it's a lot more payloads than I expected there but that's fine let's go ahead and start this attack we'll go and check on our other one real quick looks like we're still getting that 301 from the login but I don't think there's anything else no 500 response nothing there anything that's taking much [Music] longer doesn't look like it okay so we'll let those run in the background oh no don't do that sorry we'll let those run in the background and in the meantime we can go ahead and move on so let's go ahead and jump into our next category here the restricted access and we would expect each one of these to return some type of a 40 3 response and a lot of our methodology here is going to be trying to bypass that 403 response so this is similar testing to by bypassing access controls because ultimately that is some type of an access control we just have to figure out what access it's trying to control right what it's trying to validate is it trying to see if we are coming from a specific IP address if we have a certain uh session token if we have a certain user account we don't know we don't know but for some reason uh Starbucks has decided that we as an unauthenticated client should not be able to access any of these URLs so uh since we are you know ethical hackers and we're trying to make the application do something that the developers didn't intend for it to do we're going to try and access them anyway so we'll do the same thing as before we'll come up here and we'll just get them populated in the sit map or at least in the proxy there okay so we do have a 403 let's kind of close out of some of these here want to keep that so we got a 403 for the mop 403 for this one as well I actually want to document that because anything outside of a 403 would make me question whether or not these are in the right spot unless it's just sending a different response but uh is still forbidden um okay so this one's a 403 and I want to do Cloud front right there because it's different this is just kind of generic and this one here I think if I remember right was the same thing oh no this one's an HTTP uh so we would actually get a 401 I believe that should be a 401 unauthorized yep 401 response right there okay so 401 basic HTTP off um and unfortunately there's not a lot that we can do to get around this um we can try and do a little bit of fuzzing but usually if you're going to attack basic HTTP off you're going to do it by trying to brute force it um but yeah so we'll see but let's come back over here to bur suite and let's make sure that each of those has been added into the proxy right so which ones are we looking for mop dub dub dub both of those both of those are uat let's try and grab those first that's right here and we are getting uh the the fave icon from that so uh that's good it's letting us at least get to the application itself I would think uh unless the Lo this looks like it's coming back from the load balancer so maybe the load balancer is loading up the fave icon too maybe from a cache but uh anyway I digress okay we'll send that we've got the uat send that to repeater um the dev was another one correct yeah the dev was the one right there uh and then this is our basic off send this to repeater as well um so if we send this with the basic http P it just goes straight to the unauthorized from the repeater so we can do some fuzzing on that let's get the responses on each of these just to see again Cloud front right there so we could also attempt to bypass that and here we just have a generic 403 um all of these are coming back from the load balancer right we've got a bit of a variation here got another hop header so definitely want to do some testing on some uh hot by hop headers to see if we can get some different functionality as well uh this one's coming from the ALB this one from cloudfront this is basically HTP off so we have four different URLs all of we're being told through all of them that we should not be able to access this for whatever reason um but we're going to try and access that all looks like it's different uh technology or something different than we're actually trying to test so um let's come up here to our extensions probably the easiest way to do this so we come up to the top there's the 403 bypasser extension here and this is going to to run through several different options you can see within the URL it's going to do some header payloads um just automate a lot of the same processes here that would be documented let's go here we'll go to book hatrick uh 403 bypass and 401 bypass as well so a lot of the techniques that are going to be listed within this page here and by the way if you're not familiar with book. hack.xyz cannot recommend it enough this is the unequivocal resource uh for everything you can possibly think of for offensive uh knowledge um but yeah you can see several different techniques that we can use to try and get the load balancer the application to allow us to send a request even though it's trying to block us this extension will do pretty much the same thing automated um oh looks like we're going to have to get our Standalone jython set up up I've done this in other videos but I can do this here as well I may actually already have it downloaded now that I think about it yeah I actually do so that's good so we'll get that downloaded um remember to get it added go to extension settings go to the python environment and the location of the jython Standalone jar we're going to select the file there and yeah it's in the downloads I did already have a version of it uh all you have to do is get it added there you don't have to click anything else you can close out of it and then from here remember you just need to click off off of the 403 bypasser or whatever extension you're looking at and click back on and you'll see now you have the option to install it so let's go ahead and do that and we'll come back to our repeater and so we've got 1 2 three and four we're going to get that running on each one of those so we'll right click uh go to extensions 403 Bypass or bypass 403 we will do that for all four of them and the last okay so we're going to let that run for a little bit um I'm not going to show this in the video just because it's you know already going to be a very very long video but what I would also do is come through here and manually test each one of these right pretty much any time I'm doing automated testing I'm going to come back and do manual testing as well um so I'm not going to show it in this video but i' strongly recommend coming here to book. hack tricks um come to this 403 and 401 bypasses and when you're trying to test if you can get any functionality with these restricted access uh URLs or end points that you're finding you can use these techniques to try and bypass that so we'll go ahead and let those 403 bypass scans run for a little while uh or 403 and 401 I guess um and in the meantime well we're going to move on to API but before we do that let's jump back and just check in on a couple of those Intruder scans that we had running for this no functionality because I think these three up here we're not going to get much of anything but these two could pot potentially uh have something there especially obviously this has some some different functionality uh ultimately what we're looking for I'll come back to this one first here uh ultimately what we're looking for is some way to inject uh user controlled input that's going to be reflected in the Dom so here right now we're just looking for any type of response outside of this generic hey we can't get any functionality at all if we find that response then our next job is to be able to uh go through and try or at least try to find some way to inject user controlled input and have that be returned by the server so but the first step for for these uh no functionality end points or domains is that we need to find any type of a valid response so some of you may have already seen looking up here that after our scan is run we actually got two uh pretty big variables here you know everything else let's get rid of that one there everything else is returning a 400 response and uh the length is about not about is is 940 characters that's our server error thing there so we were looking for any variation to where we might uh be able to get some type of other functionality and we found two end points that return a 200 so we've got this verify endpoint as well this is very interesting right it just says verifying uh success as the response I don't see obviously anything that's being reflected in the Dom yet but maybe there are some additional parameters that we can send to be able to to make that happen you know it clearly seems like it's verifying something um I can't imagine this request is just designed to take this so uh we're going to try and find some user controlled input in there the same way that we have been right just kind of fuzzing throwing a bunch of different payloads at it and seeing if it responds differently that's a a big part of what testing is at this phase um so this header right here is interesting to a test header but anyway let's send this to the repeater we also have this EnV endpoint here which is showing us the environment that we're at um once again we don't have anything that's being reflected but maybe there is something maybe they're waiting for certain get parameters or or maybe we can send a post request or a put request and have this do some type of different functionality you know I don't know so um but we're just getting deeper and deeper right this is all part of the process if we want to as part of this first strategy where we're doing the unauthenticated testing against a wide scope we want to just keep seeing if we can dig further and further into this and then obviously each of these uh targets that we find would be uh something that we could test for any other type of injection testing or or really anything else as well this is this is really Recon enumeration what we're doing at this point we're just focusing on the the client side testing strategy um so let's get this one sent to our repeater as well and from these let's go ahead and first of all make sure they're still sending a valid response that one is there same thing here do they both have the test they do um we can try and figure out what that means um we're getting a bit of insight into what this could be supposed to or could be designed to do based on this content security policy as well but uh so now there's two different types of tests I want to do first of all and we've obviously done this already but we still need to find some way to have our user controlled input reflected in this response right here so we can potentially be rendered as a script tag there so and obviously we don't have any user controlled input so I'm going to come down here to the extensions and we'll go to param Miner again and we'll just try and guess everything that we can find we'll do the same thing over here on the EnV uh where we at and hopefully something is going to come up there um another thing that we can do is we can come down here and change the request method so uh right now we have a get request get requests are typically done for for read although uh obviously you can do you know parameters St it's not always done for read but uh typically that is a convention so what I'm hoping is that potentially there's some other functionality based on if we do a post request or a put request that would be more indicative of the server expecting uh user controlled input to come in that would later have to to process so um and we can just do some generic stuff here we'll also try this I know that doesn't have a zero but that's fine uh also we're getting a 400 again here um which again the 400 really seems to be basically a 404 right just says it it can't seem to find it so um I'm going to go ahead and we'll tell you what first of all before we do that let's change this over to Json and let's just see if maybe it's expecting any Json input doesn't seem to make any difference because it's responding in Json I'm going to assume that that's the format that that it's looking for so uh in addition to this I'm going to send this back to Intruder and let's go ahead and set this here and we're going to do the same thing again but with a post request and this is what you're going to do when when you're doing this unauthenticated testing on a wide scope you're really looking for any type of hidden functionality hidden end points a way to uh inject or a way to send user controlled input to the server that's being processed that hopefully other researchers haven't found before so it's a constant process right and there's no road map for it you're going to come in and you're just going to keep digging in further and further when you find something it'll tell you to go look or you know you could potentially go look for something else Etc so um you know I'll try to show as much of that as I can in this video um but you're it's always going to be unique ultimately I always say just get dug in like a tick if you continue to do this eventually you're going to find some stuff that people haven't found before for let's come back up here to Discovery web content and I'm going to go back to our raft small directories like we were doing before go to our resource pool we'll do another low and slow and we're going to go ahead and get that running in the background as well and hopefully some different end points outside of the EnV uh and I don't remember what the other one was verify uh aside from those two we may find some other things that are looking for a post request but this one on the other hand doesn't look like it's doing that and we can do a put nothing patch right update just see if we can get any type of functionality Al so this one's unsupported um which means that the other ones are now that's probably across all endpoints in the application but maybe not so we're getting a little bit more information here let's go ahead and go back to our Notes too and under this one which one is this this is the staging so let's take this this back to the git request I want to copy the URL and under the staging one we are also going to list that this works and we'll do a let's do it this way get request there and I get request here okay and now we know that we can potentially use those as injection points but we have to find an attack Vector somewhere on there so we're going to continue to let that run we've got one other Intruder that we were looking at here and this was for that that card redirect that we had and we did get an interesting response from this one as well if I come over here and send this one to repeater so most of the Unicode that was hex encoded is coming back with a 400 so the server is having trouble actually processing that that um same thing with a null bite so that's interesting right it does seem that it's processing it and it seems like this is breaking something on that end and then other than that we typically get the same 301 you know so we have uh 301 it's a hardcoded redirect to our uh SB card info endp point there the one outlier that I found when I came back and looked through these was our get request to this per to Echo and that's an interesting hexing coding um um if we come over here what we got a repeater now let's just take it to repeater let's take this and highlight it you can see that that is a single dot decimal right um so essentially what we're saying is uh this is the current directory here so when we send this now what we get instead is a 302 we're not getting our 301 right so this is a 302 this is actually taking us to the same uh route so if we follow this redirect it's going to strip out this percent two Echo uh and it's going to now send us to our 301 does that mean that we can potentially find an attack Vector in here and and uh you know inject something to the client side probably not I don't see anything like that that's probably just the the uh behavior of the load balancer I mean it's it's almost definitely coming from the load balance here here you can see that it's setting a refer header so potentially if the refer header was used somewhere El else we could possibly do it um but it is good to note and I want to come back here and I'm still going to go ahead and get that documented because you never know as we continue to dig in and test these you never know what you're going to find right this may end up being uh a great way that we can find some hidden end points on this domain that we weren't otherwise uh allowed to access you know that's what it's talking about when you come up here is uh now we're not seeing that this path is necessarily blocked but having a hardcode to redirect on the path that is is similar to have it being blocked you know there's no difference from the developer standpoint the question is is there anything behind that to find can we trick the load balancer into sending us somewhere letting us access a page that we shouldn't be able to access so um we're going to try that as well I'm going to come back and actually let's get these closed out because that one's fine there um we go ahead save this in the project file I think that'll be good we get one more in here just discard that one because all we need is the percent two Echo and we have our other scan that's running there now we're going to send this to the Intruder and just like we have been we're going to try to find some hidden end points but we're going to do it with this percent to Echo in the front and see if it sends us to somewhere that otherwise we wouldn't be able to get to and once again I'm just going to stick with my raft small directories I think that's fine for this demonstration but obviously if I was really testing this endpoint I would come through and do a bunch of these right this would be days and days and days that I would be going through and looking for this just trying to find one place that I can inject uh code that probably hasn't been tested yet and then if I get really lucky maybe it's reflected in the Dom and everything but we got a long way to go before we can get any type of client side injection so we'll let that run there take a look at our other one real quick just to see if there's any major variation we're still able to get to our login page there which is what we would expect um it does it with a post request though we have a response so that is very interesting too let's just take a look real quick come over here to repeater send follow redirection oh what do we have here let's show this response in the browser okay come up this way I'm going through burp ah so it's redirecting us to the login page that we've seen before so uh this is where we're going to do our testing down here so there is a connection between these two and sending a post request to that login endpoint seems to redirect us here so is there a way to inject something into this Dom going through this endpoint you know I don't know let's do this oh wait it's not the uad oops so sending a post request to that endpoint there and we will go just so we know which one this was oops go back one and our note is that redirects to login page at okay so I'm going to go ahead and clear these out here I'm not seeing anything so far that's telling me that those are going to be worth our time uh I can do the same thing here in burp site right these are the ones that weren't returning much of anything but we're starting to get a a picture together here so all of these could potentially be attack vectors we'll come back and start scanning for uh reflected input in a bit um we have our uh 403 and 40 one bypass that's been running for a while on these two domains uh unfortunately I do not see any luck there but we do have a couple secret headers that are being found on this staging environment too so this seems like one as I mentioned before I had I had pretty high hopes that I was going to be able to uh find something here that at least expand the functionality a bit and we're starting to see that right we s to get request to this verify endpoint and we get that 200 if we send it with the proxy connection value here we get oh there's no response at all so if it's just an arbitrary value you can see request two goes straight to request three so the proxy connection nothing comes back from that but in request three we don't do the proxy connection now we do get a valid response but it's forbidden which means we've probably sent too many requests there uh cuz we did see remember while we were scanning it gotten blocked so I do feel like there's web application firewall in front of this so um we also have the transfer encoding uh seeming to have an impact with that so this looks like a good uh Target for uh HTTP request smuggling as well um any type of desync attacks could be potentially effective here um yeah we see that we have the ability to do that so for client side injection along with this you know do I have the ability to do an HTTP request smuggling attack that's also going to you know this also to that second request is somehow going to inject something in the Dom that would not have have worked otherwise um but you know that would being going down a whole Rabbit Hole there so we'll avoid that for now I don't see any other information for the 403 bypasses so it doesn't look like we're going to get lucky there but we'll continue to let those scan again we would do a bunch of manual testing as well but I think we're starting to get some things put into place um so let's go ahead and move over to the API that we found here I'm going to copy this one we'll continue to let those other scans run and as expected if we remember the reason that we thought this was an API was because it returns with that 404 so our hope is that there's some additional end points behind this so with API testing we want to fuzz for those end points uh and and any other hidden headers or anything like that I would certainly probably come in and do param minor just to guess some headers because most API we going to expect some type of authorization header or something to be appended as well um I'm not going to do that for the sake of this video because this unauthenticated testing has already been very very long to come and do our enumeration but that's fine um let's move on to this let's send this to Intruder as well and we're going to add another payload just like we have to do our fuzzing um but instead of doing the raft words like I have been before I'm going to come to the seist Discovery web content and then API and we have several different end point points that we can do here so the first one I'm going to do is just this API seam in the wild and this is several different known actions and endpoints that can be there um I'm also going to come and do where is it API endpoints right here and you can see here this throws in some version one version two some swaggers graphql a lot of like more common naming conventions like API so as opposed to just individual actions this is making the assumption that there could be some additional end points uh or directories as part of that that we would need to find first um so that can give me kind of an inkling into that so I think that'll be good for now we're going to come back and do the low and slow there and we will let those run obviously it's going to take a little while so we'll let that run in the background just like we have everything else um let's also come here is there anything that we haven't documented I think just with this one where are we at here y I want to just finish documenting that so let's do a get request to that and well that's what I started to do here uh that get request uh does a 302 to this which is a 301 let's go ahead and follow this real quick 301 to this location here clean this up a little bit I think that's good all right and that'll just kind of help for me right I know that if I send this then it goes to a 302 through a 301 um so we're going to let this run and see if we happen to find any other API end points that we haven't found yet I think that one is down there and we can come through and sort real quick and just see if we are finding anything no changes in status no changes in length nothing yet um the other thing that I like to do with the API endpoints is try and find any type of public documentation for it and let's actually just grab the domain because that should be fine right now and let's come up to Google here and uh API documentation now I would use several different ways to to do this um no you don't even know my location um but really I'm just you know there's there's no roadmap for this it's really just trying to find something uh within Google within showan within any type of public resource to be able to figure out what this API is um now this is you know kind of interesting we got a blog post recommending that they make their apis public that would definitely make our job easier um but I don't think that they've done that and I'm not seeing a lot of additional information so you know this is um ideally we'd be looking for something like let's say maybe Swagger Swagger documentation open API documentation um this looks like their own site map that was mentioning Starbucks uh but no very few coming up so doesn't look like we're going to find any public documentation we could do open API maybe open API is a standard that's typically used with that but no there's not much of anything coming up so unfortunately uh we're not having any luck with documentation so I'm not sure we're going to find too much there we can just kind of hope that maybe something's going to get picked up here but in the meantime we can move on um yeah we can move on to our external Services there now uh uh like I mentioned we're coming in here we're probably not going to find too much with this um you know because they're known Services you know they've got entire teams that are that are working on specifically just protecting assist these are their unauthenticated routes but there are two checks that I typically like to do with these external service login pages and that's first of all looking for any like known cves that may exist with it that you know could correlate to a vulnerability I could possibly test um usually that's going to come with like a syst VPN login is is a common one usually it's it's uh software that they have to update themselves if you're looking at cloud services it's probably going to be much much more difficult to find anything let's just take a little bit move this over here and let's see if we can find out while the others are running so let's grab autodiscover and uh let's just see if anything comes up so you can see that this is for uh an exchange server and there is some information on some remote code execution vulnerabilities this one was back in 2022 right if anybody doesn't know the name of convention cve the year it was released and then an identifying number so it would be very unlikely that this Exchange Server would be vulnerable to this if it was something that was being maintained in the cloud um but we can try and figure that out right let's let's come back over to my framework I don't know why I made it smaller let's come back to my framework and the domain itself that we're looking at autodiscover Starbucks SG so let's come back over here and let's see if we can find that within our infrastructure map and the hope would be that amass picked this up it was able to identify a DNS record and an ASN and we can very quickly identify whether this is in Microsoft's Cloud environment which is where we see a lot of their stuff is hosted right Microsoft cloud but ideally we can find an ASN that is something that they own themselves which means it could be something that they have to maintain and update themselves um that looks like one there in Hong Kong so we're distributed all over the world we've got some glute uh Google Cloud we've got some Amazon uh I'm not seeing anything stand out there let's see if we can find the actual DNS record to it and I don't see that coming up as well so um I'm not very bullish on this being anything that they can maintain themselves okay so here you go here's the a couple of the ones that we were looking at here's your auto discover um this is it right autodiscover starbucks.com perfect okay yeah so all we have is the C name record going over there so it's an outlook.com which if I remember now we we looked at it before so um I wouldn't expect to see any cves that would be able to Target this um I would certainly go through and try some of the other ones you know we can maybe try and figure out what this one is here and potentially there's a 2023 cve that could be here but again if this is in Microsoft Cloud environment I would expect all these to be taken care of so um I'm not too bullish on any of these I don't want to spend too much more time the only thing that I would do in this situation is I would actually go to hacker one and any type of uh where we can publicly disclose uh other bug Bounty reports and I might actually search for some of the keywords that are in here as well right so the autodiscover is a really well-known thing let's just see what happens if we search autodiscover we do see one blind xxe that came through it's written all in Russian so that's going to make it pretty challenging to to use but we can at least see this um looks like potentially there was an end point with the autodiscover XML and they were able to inject something into that um so I mean we can give it a shot you know doesn't hurt let's come back over here where was our Auto discover I may have already gotten rid of it didn't I yeah I did or may have never added it either way you go away that's going through burp let's get you in there oh helps if I copy it it helps if I copy the URL so let's load that in proxy grab it from the proxy send to repeater than I think I just did that twice on accident I did okay and the activity report that we found is claiming that you can do a get red Quest there and then somehow do an injection after that let's just see if this happens to work do we get any type of a different response here to that uh it is moved so we can go forward there and we have a 401 Okay so let's copy this URL um we have to do some more research into what that cve actually is oops numlock always helps 401 response right so from here I would want to come over extensions 403 bypass 403 and let's get that one fuzzing as well maybe we can get past it um the cve itself did they list the cve they didn't list any cves or anything there so okay I mean we'll see maybe if we can bypass it I'm guessing the fact that it's unauthorized is the fix so that's showing that it's not vulnerable but it doesn't hurt to to go ahead and test that so um that'll give you an idea of some of the things you can do here with these external service logins but again I mean a lot of these I'm just not going to be not going to spend much time on I think there's not a ton of opportunity there um once we get further down here to these Targets this is where we're going to get a lot more opportunities to uh to actually find injection points before we do that though let's go ahead and check out our One internal service login page that we found so we'll copy this I can go ahead and move away from this report here and this is doing a a redirect as well I think this one though because the other one that did the redirect it didn't actually load the login page so this one here let's come back over to the proxy and what actually happened so we sent our get request to this uh card Starbucks account it loaded a significant amount of JavaScript files before it did anything oh no it redirected first sorry so we had a 301 and then once this page was loaded now all of a sudden we're loading a ton of clients side JavaScript so or not yeah yeah client side JavaScript so this may not be a great option for uh our first strategy for the unauthenticated testing against our wide scope here with with the sending a request and serviceing response but with our third strategy remember in the beginning we talked about uh strategy one was what we're doing now we're trying to find hidden subdomains uh that nobody has tested and maybe we can inject something to the Dom that way strategy two was to go get dug into an application with full authentication we're going to try to find hidden endpoints hidden uh functionality and then option three is going to try to inject something directly into the Dom we're not even going to send request to the server it's all going to be processed by this client side JavaScript so to see that when this page is loaded here we have all of these different big JavaScript files that are being loaded I'm immediately wondering do I have the ability to eject something through this card Starbucks co uh JP domain that will be processed by this JavaScript in some way to allow me to inject either JavaScript to execute from uh the existing script or uh write something to the Dom and and have the JavaScript execute that way so other than that we're just eventually redirected to the login page here which which we're eventually going to be doing some testing on this as well so um looks like we also got an aoth implementation I think the best thing to do for this one is I'm going to come back and redirects to I'll just grab the domain from that that'll be fine LGE JavaScript files the good Target for Dom based xss okay so we'll put a a pin in that one for right now and we'll go ahead and move on to a few of these down here but I definitely want to come back when we're doing our client side JavaScript testing to see if we can get anything malicious to happen as part of that but for now we'll just leave that alone and the only category that we have left to test at this point is a generic application or full application with authentication so and there's no special methodology that we need to do for these we're just going to open the application we're going to click through them we'll probably have burp do a little bit of crawling just to see if he can find anything in the background with our low and slow but ultimately what we need to do is just find as many unauthenticated endpoints in these existing applications as we can and then from there we'll try to find parameters anywhere that we can inject user controlled input that will be reflected in the dawn so we're going to populate these the same way that we have before right we'll just come back over here bring up another tab make sure everything is running through burp and we're just going to load them up one by one so this one I remember being interesting because it's the uat it's also loading as an HTTP so that may allow us to bypass a couple things that we couldn't on this actual shop so and just real quick I want to make sure that this is still going through it is perfect the purpose of this is just to capture it with burp and actually let's do this as well I'm going to go ahead and get rid of anything else that I'm not using I don't need that one as well we'll keep the framework let me pin this I don't need GitHub as well but I'm actually going to leave each of these tabs open because we're going to start clicking through them to identify the end points that are available to us so let's go through each one of these and I think that's probably good for the purposes of the the video here right so we've got a few different options so um let's come back over and take a look at our site map real quick uh obviously it's starting to expand out a lot more we've got some other grade out domains which means we haven't actually made a request to them yet but the crawler the spider actually so uh the request and response in the Dom that are running through the proxy is automatically identifying that there is a request in the Dom that goes to this uh URL or endpoint there so um we're getting a lot of good information there uh let's just go ahead and come back over here now and we're just going to click through anything that we can find okay that redirects us to our login page this comes to a favorite endpoint there doesn't really matter what we're finding just anywhere that could potentially have user controlled input uh for uh not exactly what I was talking about but uh interesting timing this looks like the uh user registration page which we'll do that in part two when we're actually going in and doing our second strategy which is the authenticated testing looking for hidden end points but we won't worry about that for this one here um this goes back up to the top there we've got few different options so actually a good amount of end points here I'm hoping let's see what our site map is looking like is this mostly a JavaScript heavy thing here not bad at all if we come and look at our site map right we already have several different parameters we're starting to pick out although they're mostly that fact I think they're all that niid so that may be our only injection Point through that but that doesn't mean it doesn't exist let's um let's go ahead and get a base basic crawl running against this here unauthenticated crawl we're just going to come down and tell it to I we'll crawl for 30 minutes right and uh just you don't need to stop if there's any application errors and we'll go back and do our low and slow as well so uh again with this active scanning with the crawling and everything coming from burp we're not going to rely on that we're not going to be hammering all the servers with a bunch of request but we can use it to slowly crawl in the background and who knows it may find one or two things that that we haven't found yet yet all right so that's why I'm running that there we'll click through a little bit more that should be fine with that one let's come over here to this uh Starbucks Singapore version and again we're finding more attack vectors now so this publish date this keyword as well what happens if I type in arson as part of this does that get reflected somewhere in the Dom I don't see it immediately but it could be hidden somewhere in there uh so that is definitely something that I want to look at um there not sure if that's reflected or not let's try opening this separately it does strip it out you can see there that uh we have our keyword is arson uh but if we come over here and when we when we load that URL right so if I come in and load this URL with arson you'll see that it will do the search but but then all of this gets manipulated that's being manipulated by client side JavaScript that's being processed as part of the Dom that's not happening with any requests that are going out to the server at least it's very unlikely that it's going out in that way so that can be an excellent opportunity for our third strategy right to try inject directly into the Dom uh that keyword here may be processed as you know something that could be passed away to the Dom but I think what's more likely is that this keyword may be processed and could potentially execute as JavaScript right so we're not looking at a DA based cross a scripting but maybe we're looking for a client side JavaScript injection it was passed to an eval or something would be would be perfect for that um so that's one of the things that we're going to look for uh let's try and we'll add this to cart as well um sure 100 how much of this do I need to do just want to add it to the cart okay so again this looks like a fantastic opportunity for some injection opportunity and this is all we're not even logged in yet so we're able to get to this point and uh add all of this data to the Dom right here's reflected input we're starting to find reflected input within this and this is going to be uh available to us in here as well let's move away from that one and this one is the shop is this the regular one or the uat this is the regular shop and here you can see several different options for attack vectors right any of these with parameters here all of these are going to be attack vectors anywhere that we can see this going through and being reflected in this response we are going to be able to test for client side injection so um this is where I was saying these are obviously going to be uh rich with attack vectors whereas the other targets that we were looking at are not you know these here we're lucky if we'll find a single place that we can inject that into that's the same thing for restricted access I'm fairly confident that we're not going to find or we're not going to be able to bypass any of these that would be a bug uh in the first place right if we were able to bypass this 403 we would already have a bug there and then potentially if we can do cross-site scripting as well or some type of JavaScript injection that would just be expanding the scope or chaining bugs so so probably not looking for a lot of success here you know for the API we can potentially find some end points that'll work but a lot of things have to go wrong to get a client side injection Point here too right we have to be able to uh especially because we don't have documentation we have to be able to access endp points they have to be unauthenticated end points for a a non-public API that's very very rare so I'm not expecting to find too much here I've mentioned this before very very rarely unless there's a known cve or you're going to find something the external login Pages this one didn't show too much this is going to be where the vast majority of my testing for client side injection is going to be but these are going to be the ones where we have a much lower opportunity this is where if you do find an attack Vector you have a much much greater chance of actually weaponizing that attack Vector so when you're doing this unauthenticated testing for client side injections against a wide scope like this and you're looking for hidden subd domains you're looking for something that other researchers haven't touched in an unauthenticated endpoint you're you're if you do find a way to inject something and it's coming back in the Dom through these uh endpoints that you're having to do all this work up front to even find some type of functionality it's going to be much much more likely that you will actually find that injection whereas when you come down here to this fap authentication and this is why we divide these up into the different categories these here you're going to find a ton of places to test but they're also going to be tested by a lot of other researchers there's going to be additional compensating controls that we have to deal with that might not be available up here uh so the testing itself just becomes more complex instead of searching for those attack vectors now we're looking at circumvent and compensating controls which we'll get into here in a little bit so that's the reason we divide these up into different categories you can see here it's very very different methodology between these different types of of applications even though we're still Within in our first strategy right even I think this video is probably like two 2 and 1/ half hours long at this point and we haven't even talked about going into the second and third strategy we haven't even started fuzzing these parameters yet so that just shows that this uh unauthenticated testing against a wide scope is a lot more about Recon and enumeration than it is about actually bypassing any compensating controls we'll see that shift dramatically in part two when we start digging into a single application uh and trying to find hidden end points things like that as well so now we have several different targets here in our sit map right and we have the the full applications like this shop uh we have the hidden end points that we've discovered like these we've got a good mix of everything that we found and anything that does have any type of a valid response that we may be able to inject uh user control input into the Dom through uh would be in our site map here so uh we're going to continue this process that I've shown or I'm going to continue this process I've shown over and over and over again but the last thing I want to do do before we do a little time skip here is go ahead and get a scan running specifically to look for any user controlled input that's reflected in the Dom because remember that's step one of us going in and finding these client side injections so let me go ahead and highlight everything that we have here and I'm going to rightclick and I'm going to come down to scan and we'll hit audit selected items and you can see all those individual pages that we've discovered since we've started doing this video are listed within here so we're going to test all of the individual attack vectors on each of those just to see if there's any user control input reflected in the server response that's the only thing we want to look for and the way we're going to do that we're going to come to scan configuration here uh and we're going to go to new right so we can come in into uh whatever we want and we're going to just call this reflected input scan right um so we can leave a lot of these uh mostly open um I do want the audit speed to be thorough and I want the accuracy to minimize false negatives right so we want to get as many uh correct responses as we can we'd rather the scan take longer but be accurate um most of everything else we can do uh for the issues reported right instead of coming down and just selecting individual ones we're going to select an individual issue here and then what you can do is actually highlight all of these this took me a little while to find out by the way you can highlight all these right click and disable them there and then we are going to be looking for just one specific check right now and that is reflected input input reflected in the response I'm going to have to find it in real time because I do not remember what it starts with here we go um so here you see four different uh scan checks right there's the input reflected in the response there's reflected and stored and then we've also got suspicious input transformation so these two right here here are going to check through every attack Vector to see if we can force the server to uh respond with any user controlled input that we could potentially control and then ideally we would see that rendered in the Dom uh as well so it could potentially be an injection point so we're going to go ahead and highlight these these will not actually test for cross-site scripting there's other checks for that uh but we just want to see if anything is reflected because the first step in getting a client side injection any type of client side injection is just seeing that user controlled input injected in the Dom so this is going to find every attack Vector send a unique string probably like an md5 sum or something and then if it sees that unique string returned in the server response it will go ahead and let us know so we don't have to do all that manually and then the other two we're going to highlight is this suspicious input transformation check here and what this does is we'll send certain encoding so remember one of our compensating controls is output encoding so this is going to allow us to test and see if there's any uh encoding Transformations that are going on on you know if we send a URL encoding is it registered somewhere having been decoded you know is being processed that way do we see the opposite do we send a string and see it come back with like a unic code or base 64 or anything like that so this will automate those checks for us make it much easier for us to find and everything else should be pretty easy so I don't want to uh have this fail out let's do this let's say if there's 250 consecutive audit checks that don't work we defitely got a problem but other than that we're going to let this go in um and then we can pause if let's say 150 right there and then we'll just do do one right there everything else we can keep the same um insertion points we want to insert it to everywhere um we can do some modifications to parameter locations but we don't usually need to do this because we're already going to be hitting everything not for these types of checks um we don't want to ignore any insertion points um yep that's fine fine there that's fine JavaScript analysis it's already going to be doing this I will give it 60 seconds as well just so that uh it can take a little bit more time especially for the static analysis we'll see what comes up and we'll just leave that the way it is so I'm going to save this to the library so we can use it again and now we have our reflected input scan and then finally we're going to come and do our low and slow right there because again we don't want to be hammering all those end points this scan is going to take a very very long time to complete we are not going to rely on this as our only method of identifying the user controlled input that's reflected but this will hopefully we'll let it run for for a day or so and then uh hopefully we'll have several different responses that we can come in and do further testing on so let's go ahead and come back to our notes and we're going to come down here I'm feeling pretty good about what we found we've got several different options in each of the the categories that we can come in and do testing on ultimately now we need to find attack vectors within these applications then we need to identify the compensating controls within or that that will affect that attack vector and then finally uh we will actually attempt to do some client side injection uh and again that that attack Vector is any user control input that's reflected in the Dom [Applause] so we go ahead and get that set up in our notes and for each one of these we will identify the attack Vector we'll take some notes about it we're going to go into the application where that's being rendered we'll find the compensating control and then we'll see if we can circumvent that so but I'm going to go ahead and let everything run for a little bit and you'll do a a quick skip forward in time here for for your experience and we'll come and start digging into these these findings all right we are back uh it's about 24 hours since uh the the video cut there um and I've basically just been going in and doing the same thing you've seen me do it for the past again probably about 2 and 1 half hours over and over and over again right just just com com you know going through continuing to fuzz into these looking at every different category now I haven't added anything additional to my notes but you can see my site map is dramatically expanded here so we have a ton of other subdomains that we can continue to test and I would just continue to do this over and over and over again so all of these grout subdomains are another Target that I can potentially get in there and do everything that you've seen me do up until this point you can continue doing this over and over again that's why I'm separating these by strategies because again this is when we get into an individual application it's going to be a completely different methodology so it's really important that we go through this Recon and enumeration methodology first because this is how you're going to find those end points that nobody else has touched and then potentially get that client side injection from that um so one thing I want to do here before we start moving everything else um let's do this too I'm going to go ahead and get rid of anything that is not found and then I'm going to select another big group of these just like we did before and I'm going to go ahead and run one more scan the same way that we did before so that should be plenty there we're not going to do everything but the reason I want to show this is because as your attack surface expands you're going to want to be able to deal with those so I'm going to open my scan launcher again we're going to come back to the audit selected items and you can see we have a huge number of items here and a lot of these we probably don't need to to deal with so I'm going to hit consolidate and we're going to remove any duplicates we'll remove anything that's out of scope I don't know why there is one in there it certainly shouldn't be um you can potentially I would say definitely leave uh the no parameters open because an attack Vector can be a value in a header it can be an value in a cookie um so we don't want to just scan things with parameters same things here you'd be surprised you could actually get client side injections from these JavaScript files or even from CSS files I've seen that before where they still accept some type of a parameter and still reflect something uh in the Dom dynamically so we will go ahead and get rid of any duplicates here if you are going to do scanning against a large number of targets if you as you keep expanding your attack surface you're going to need to be able to deal with those uh so once again we're going to come in here scan configuration now we already have our reflected input scan set up right we we built it before so now I can just do that and we'll go to our very low and slow right there and we'll go ahead and let that run in the back end so in the meantime we're going to come over here to our dashboard we're going to come to the issue activity and remember the main thing that we're looking for the first sign that we could potentially have a client side injection is we're looking for input that's reflected in the response from that scan that we did so I'm going to go ahead and just search for input and you can see that returned and now we have our potential attack vectors let's kind of clean this up a little bit don't care about the source don't care about the action got a good idea of what's going on there I definitely care about the host and the path and the insertion point that's really the most important thing get rid of the time get rid of that there okay perfect so now you can see we have one two three four five different domains out of everything that we've searched for that potentially have an attack Vector that we can inject this in now that doesn't mean there's the only one out there and we're going to this is a constant process right I keep saying if you hit a wall go back start your recon enumeration again come back and hit all these different uh domains that you haven't touched yet um but we have a lot of things that we can go ahead and start working with here so um each one of these is going to be the same uh the same finding right and if we come in and look at the request it will highlight so uh they have injected this unique string here into this cookie and the cookie value I'm guessing is just one that's included in there is quite a unique cookie name but that's fine uh and then in the response it will show you where it's being retired all right so we only have one highlight on this one and it's within the cookie so nothing is being reflected down here in the body of the response and even if it was this is all JavaScript this is a Javascript file that's being returned so for this attack Vector specifically we're not going to be able to Target anything we we could potentially have a uh JavaScript injection but there's no Dom being rendered to where our user controlled input uh would be able to go in there whereas and I can try and find another one kind of guessing here but um so this right here is coming from this return URL and in response perfect here's where we can see it's actually being written to the Dom I took a guess there and I thought this might be one that we could use for the example that's perfect um so this is an example of a potential attack Vector we found reflected input so now we can start to see if we can get an HTML injection or any type of other client side injection this is a perfect opportunity for a client side injection so let's come down here to our tack vectors and uh let's see let's minimize that a little bit we don't need our inspector for this one just whatever is going to make this easier to do it but okay let's go ahead and copy this URL and we will have that one there okay and that is automatically reflected in the Dom so let's continue going through these we'll come back up to the top once again we have a Javascript file and in the response we can see it in the cookie now this is actually really interesting if you look here we've got a cookie value and it ends right there and in the response we see that value but it's being appended in this larger cookie that looks like it's storing data right we've got this pipe character that looks like a delimeter we've got a one a one and then some type of a sha 256 maybe that looks too long for md5 something but anyway so this data this definitely has the potential to be a stored cross-site scripting if this data was being stored somewhere and then later rendered in the Dom on a different page there's a a possible opportunity there but I'm not going to dig into that just for the the use case of this video um here on the off login we have three different options look at this with the code challenge method parameter code challenge parameter and the redirect URI parameter that are all being reflected there and it looks like they're being added as parameters to this now the reflection is happening in a login URL here in a Json object so right first thing we want to check here is it actually returning content type Json if this was content type uh text HTML oh we have a fantastic attack Vector that we could start digging into but since it's not and since this login URL was almost certainly being used uh to uh decide what where the next request is going or or potentially being added in as an anchor tag this is uh at most going to be something that we inject in the Dom but it uh it doesn't look like a good attack Vector for an actual reflected cross- site scripting so we'll go ahead and skip over that but we get to the Dom based crossy scripting our third strategy where we're trying to uh manipulate the JavaScript itself the client side JavaScript I am definitely going to test again to see if maybe this login URL is processed by the client side JavaScript and used to add as an href attribute for an anchor tag or possibly it's passed to another method that makes an Ajax call and maybe we can get some type of client side injection on that end uh so let's come down here to the shop uat remember this shop was one of the ones that I was really really excited about because it had a lot of different parameters and especially this uat looks like it had uh some some broken functionality the wrong way to say it but uh it was just a little a little janky so um let's see what we have here these are requests in get parameters and they're coming back as once again Jon um so let's go ahead and check it is rendering that correctly so yeah so again we don't see this being rendered in a Dom yet um so we're going to have to rely on the client side JavaScript in our third strategy to be able to do that um this is going to be the same thing right we've already seen this pattern before and what about this yep so we have oh this is this is interesting content type problem Json I've actually never seen that before I want to Google search that real quick that is is that an actual thing yeah I guess it is I guess that's an established pattern maybe I've never seen that before that's that's super interesting um but once again there's not going to be anything that we can inject to the Dom here without having some client side JavaScript that's going to grab that so that's not going to help us um we have the same thing down here and oh perfect here we have another example so we have a get request with this call back value and in response it is actually appended to two different points within the uh the Dom here so this is going to be a great additional attack Vector let's come over here the request we're going to copy this URL okay and I need to make sure that we we know what's actually being reflected so for here it's going to be that value and down here it was the end of this so that was starting at the six and ending at the S right there okay perfect so that gives us two Targets we're going to hope that the scan that we're running while it's going is going to find some additional targets for us but in the meantime let's come into here let's get rid of a second extra one this will work and we're going to start to identify what the compensating controls are that are going to be affecting this attack Vector because at this point we have everything we need to get a client side injection the question is just are they doing anything to prevent us from doing it when we start to send these malicious characters and when it's actually written to the Dom what have they done to stop it so we'll dig into the two of these and see if we can't figure that out and just to make this process easier let's go ahead and hop back up here and I'll actually tell you what let's get it in here we're just going to do a list uh to remind us whoops to remind us uh what are the seven compensating controls that we're going to be dialed in on that could potentially stop us from getting a client side injection into one of these attack vectors um so the first one right is the uh cookie Flags is there uh are there any cookie Flags we Pro us from stealing the session both of these domains have uh authentication right these are our main endpoints so we want to go in and see if we can steal the authenticated user session there or any other cookies that may be helpful um number two are there any browser uh security headers that are being returned uh that would prevent us from doing that what about a CSP right there a Content security policy it's there uh that content security policy would prevent prevent us from actually weaponizing the client side injection if we were able to get it uh what about a w right a web application firewall this is almost certainly Something That We're going to run into we've seen cloudfront uh kicking some things back we've seen getting that 403 when we've been sending too many requests to the Japanese instance of Starbucks here so that's almost certainly something that we're going to have to deal with on the barrier to the application right they've also got the validations right remember client side and server side validation we'll go through and check each one of those and then finally we have our output encoding right and that's what we're doing tester now we haven't had any responses come back uh that said that they were able to uh actually find transformed uh encoding so we'll find out maybe that means there's no way to to buy pass it maybe that means they don't do a lot of output en coding we don't really know so far but um we're going to be taking the these and let's actually replace this here put this in here and uh we'll be able to go through one by one and identify whether or not they have implemented these controls and then if they have how is it going to impact our testing there so we'll get that set up and let's go ahead and get our applications brought up as well I can go ahead and take out these others that we were working with of course we can always come back to them and let's just get this application here and our Japanese application hopefully just takes a second to load there we go uh okay so we're going to look through each one of these applications and we're going to try to identify which one of these compensating controls they could potentially be using but we're also going to do that through uh testing where do we go all right sorry about the smash cut there we had a little bit of issue with burps graphical user interface but I was able to get that sorted out sometimes that happens where it uh you minimize it and it'll just turn into a tiny little thin uh bar there is it still doing it no not doing it anymore okay um but yeah just had to find it and open it back up so once again we're going to go into each one of these applications right we're going to go into these requests specifically and we're going to try to identify what compens in controls they are using so let's go ahead and send those close out of any other requests that I do have in here for now although we can always get them back and let's see now with this call back go ahead and put arson in there and there we see the two places that it's uh being reflected so that is one attack vector and our other one here and we see our match as well okay so both attack vectors are being appended to an hre attribute this one is going into a link element and this one is going into a form element and is actually changing the action for this so between the two this is likely to have more impact if we cannot break out of this um although still there's probably not going to be too much so um okay we'll start with the co.jp and let's go ahead and start identifying our compensating controls here and we'll go to the Japanese one okay so the first one that we have is the cookie Flags right and we're going to need to get logged in in order to do that let's see go ahead and get brought up to the profile page here okay and now we have the opportunity to log in now when I record part two of the client side injection videos here when we're going to do our second strategy on authenticated testing and looking for hidden endpoints I'll go through the process to show how to register for an account here but just for the sake of this video I'm going to go ahead and just get logged in so we can identify what type the cookie Flags uh and everything else we need to uh we need to deal with so let me get logged in there and that's the first thing we're going to look at we're actually looking down here the first thing we're going to look at is uh our cookie flags do we have uh any Flags specifically on the session token so let's go ahead and get our developer tools brought up and we're going to come into storage and you can see we have a very large set of cookies here so let me go ahead and sort these by the HTTP only and I'm specifically looking for anything that said is a session now it doesn't mean that the other ones I don't care about but at least for right now when we're looking at weaponizing and building impact it's most likely going to be this session token and or whatever this other token is here I don't know what that is the name of it is an md5 some but um but yeah that will give us all the information we need for this first compensating control right so we've got two different session tokens in the cookies that uh one we can potentially access the other we potentially cannot um so but that's going to be more about weaponization so right now we're just kind of starting to put the picture in our head so let's come down here now and let's take a look at the browser security headers and we can do that in burp Suite here and really any one of these uh now that we're authenticated one of these authenticated routes here let's try and not do a JavaScript response where is just a here we go this is the request to the actual Reserve page we want to make sure that we're doing a page that actually has a Dom that loads because that will uh the the content security policy that returns it may be granular depending on the type of page or or especially to The Domain but um but yeah it just depends on how it's implemented here so this should be an endpoint that would show us uh what compensating controls as far as the browser headers and the content security policy we're going to be dealing with now that we uh once we get down to start actually trying to inject into it so we'll take a look at the response and start to pick out some of these security headers first right so we've got the x-frame options right here actually we got two up front XF frame options and then the uh xss protection is almost definitely going to be something that we want to be dialed into oops uh so this xss protection header uh there's a few different options here I think this can be 0 one or two um I'm trying to remember exactly what the difference is I know that zero means there's no protection but this will actually provide it with a little bit of protection so um we this may restrict us it may not for now we're just going to go ahead and document it um we do have some cache control as well uh not typically thought of as a security header I wouldn't argue but I want to put that just because if we do get any type of client side injections one of my favorite com ation of vulnerabilities it's a client side injection combined with webc poisoning because if you can find a way to poison the cash with a response that has that alert firing you have dramatically expanded the impact now you don't have to deliver that payload uh to a victim you just have to poison the cash and everybody that EXA accesses that page through the cash is going to get that malicious JavaScript to fire within their browser so I always want to pay attention to the cach control headers as well uh just to see and now skipping ahead a little bit here but typically find these at the same time we've got two different we sorry not two different we've got our a Content security policy now the content security policy is listed as report only that is very very good for us let me go ahead and bring all of these down here and we'll just get that pasted in so we can use it later but the reporton content security policy that means that it's not actually preventing anything from happening this is uh oh wow and even within this content security policy we have very permissive like script Source un unsafe eval unsafe inline um this is exactly what we're looking for um this content security policy first of all the report only it's only going to alert them uh when when we're able to bypass this or we're able to do or when we do bypass it right um but then they also have an incredibly per permissive uh settings here you know the the script Source like I mentioned before is what we're going to look at unsafe eval unsafe inline is exactly what we want to see and let me actually come in here copy this out let's do this just to kind of demonstrate my point go to the Google content security policy evaluator and let's just see what Google thinks about this I think it will work with just pasting the header yeah so this yep we have script Source look at all those warnings unsafe inline allows the execution of unsafe in page scripts and event handlers that is exactly what we're trying to do they are not going to prevent us from doing this even if it wasn't report only if this was an actual content security policy it's not going to stop any of those scripts from loading and look at all of the other Pages we can potentially load it from any Twitter page we can load that in and you can see here we can post Json PN points from here so we can use this as a delivery system for external scripts if we can possibly write uh onto the Dom a script uh with a source tag as part of that um yeah AJ go apis I mean we just have uh so many options here that we can use so um as far as uh client side injection testing if I see a Content security policy like this I am very very interested it really feels like it'll be worth my time um in fact for our second strategy I'll probably focus a lot of my testing on this Starbucks the Japanese Starbucks if that is the one that that uh or if the only one that that has this content security policy this is very very exciting um okay we've got a couple other things in here a couple other security headers we've got our uh no sniff uh content type options um right so what that's going to do is it's going to make sure that the browser doesn't try to guess what's called the mime type or the content type so um and that can just cause unexpected things to happen right so in our request here um it doesn't list you know it tells you what to accept if uh where's a post requ I have to find a post request but basically if we were to send uh something without a content type that had some user controled data it may try to infer that uh and infer in the wrong way and that could have unexpected potentially malicious consequences if we don't have this header not a huge impact um but it will uh it could could have something that would affect our testing and then we have the uh hsts header right there as well so that just means that this domain and all their subdomains uh you're going to have to have a valid certificate in order to be able to access uh Etc we can see here for our caching too it's happening through Cloud front that's good to know uh where was our other cach one here we go just want to get that next to it uh okay and I'm I'm fine with that um the security headers aside from this one here um which actually if this is configured in the wrong way it can actually cause cross-site scripting to happen that's a whole other video um these are not going to have a huge huge impact but it's kind of just putting the whole picture to me together this content security policy is going to be very very impactful if we can actually find a way to write to the Dom um so with this content security policy with looking at the headers here I've at least seen enough to make me feel like this is going to be worth my time to continue digging in uh okay and let's see if we can find the web application firewall I mean we have uh already seen I think the the cloud front instance we've got in fact if we come back to our framework if I remember correctly let's go to the Japanese go to enumeration and the last screenshot that we took should be where was the one for the dub dub dub yeah so this is our web application firewall we can we can open this up here and we should see a valid response we do okay so we do have a cloudfront w right there and let's go ahead and do GitHub WAP bypass there's a great repo right here the awesome laugh that I'm going to go ahead and bring up and then when it gets to the point where we may want to try and bypass this we can come back and use the information here here you can see the detection method and then doesn't look like we have any way to actually bypass that which is not surprising um but we'll we'll do a little bit more searching so um just for the sake of it let's go ahead and guess we can't copy a link from there that's fine okay not going to use that right now um Cloud front laugh okay so that's The Upfront work that we need to do for the compensating controls now we're going to come back into burp Suite we need to get into our repeater here and uh we're going to start sending requests with a payload and we want to see if there's any CL client side validation any server side validation and are they doing any encoding to the output when it's actually being written to the dawn there but before our request actually reaches the application code where any of this validation or output in coding could happen it's going to be evaluated by this cloudfront W and and almost certainly what the W is going to do is check for any potentially malicious strings that are coming through within this request so one of the things we want to see first of all is uh is this uh WF configured to try and catch those type of attacks so that we can see cuz this may be a compensating control that we have to circumvent to get any malicious JavaScript to execute in the first place you know everything that we've done up until now for these compensating controls this is uh trying to identify how we can weaponize this cross-site scripting if we do happen to get JavaScript or any type of clide injection if we do happen to have uh if we do happen to find an injection that works um so this was kind of evaluating whether or not it would make sense to even try to get a client side injection to get this against this point there's enough misconfigurations here that I'm interested now that now uh we've got to actually put it into practice right so if we come back over to our repeater and we see that our payload here is arson let's see what happens if we just do a uh the most generic uh crossy scripting client side injection payload that we can think of you know is it still going to be taken through and written on the Dom or or is the web application firewall and almost certainly it's going to be validated and coded but or is the web application firewall going to prevent that HTTP request from reaching the application at all that's what we need to know right now so I'll just do script alert one we want to be as generic as possible we want to use um a payload that we are almost certain any web application firewall would catch so again script alert one and script should be good and it looks like we got it let's come over here we show response in the browser and we should see we do okay so one of the compensating controls that we are going to have to circumvent and this is almost always the case with with public bug bouny programs is a web application firewall that's checking for those common strings right so for now we're just going to document this let's give burp swe back over here and blocking basic strings and I will go ahead and put the payload that we put in here just so we can remember okay we'll save that so now we can move on and try to see because most likely and again this is always with um what what any application security team is going to do or at least any good application security team they're going to layer controls throughout the application to ideally stop your your payload from executing in multiple different places they're going to put as many different layers of security in place as possible so that hopefully if one of them doesn't catch it another compensating control will catch it so we now know that we're going to have to craft a payload that will buypass this web application firewall but even if we can do that we haven't even touched the application yet so now we need to see now client side validation is more for our own benefit but especially the server side validation and the output encoding both of these are probably going to have some hurdles that we're going to have to overcome before we can get a uh a working payload at all a any type of malicious JavaScript or client side injection to execute and then once we get that in order to show impact we're going to have to come back up here and see how all these other compensating controls how the uh cookie Flags how the browser uh security headers in the content security policy are going to affect our ability to actually weaponize that uh client side injection so let's go ahead and move on here to the client side and now as the attacker the client side validation is not actually going to affect us at all right because it's we can send the request to burp we can send it without the browser so this client side validation is not going to prevent us from sending any type of payload but the reason that I I always include this uh as part of the compensating controls we want to document when I'm trying to obtain a client side injection is the client side validation can give us a good idea of what the developers are trying to prevent and then we can go to the server side and we can see if they have replicated those validations because you know sometimes they're only implemented in the client side sometimes they're completely different teams and maybe they're not communicating to each other uh but ultimately the the client side validations typically tell us what the developer wanted to go back to the server and then a lot of times they just may not think about the fact that well we can just circumvent those controls and send it to the server so we can try and figure that out real quick we don't want to spend too much time on that and especially looking at this uh this request you know it's an API call to the get Nick uh get nickname. PHP right it's got a call back thing so this looks like something that is just executed automatically as part of the typical browsing if that's the case there's not going to be any client side validation because client side validation is only going to be uh applied to some type of a form or input field where the developers expect a user to be able to input anything in there if uh if the developers are not expecting a user to control it or if there's no you know user input at all then there is no client side validation um and then once again we're going to be delivering this payload through a URL so we have to make sure that the way we're delivering our payload is um the payload will execute without uh needing any interaction by the user if the user has to go enter anything into a form in order to execute this client side injection it's just not going to be helpful so but let's just real quick we'll come back over here uh let's get rid of our request that has the uh payload in it I think this was response so when we just load the page itself um yeah it just kind of gives us this generic error here that's totally fine um let's click back and I just want to see in the proxy if that get nickname endpoint comes up let's actually come over and copy this and we can filter by a search term so let's apply this and now we can see every request that has this get nickname now ideally we would actually see it within here but we're also finding some places that uh that have that as uh part of the Dom that's being returned let's just kind of Click around and hopefully we'll see where that request is coming through I'm guessing it has something to do with like the my page oh we got logged out there so maybe when we log back in that's one of the requests that's coming through if it'll let me log back in certainly taking a minute there not seeing it coming through let's let's go to my profile go to my page still not calling it h well based on the fact that the request is going to an API everything that I've seen shows me that this is not a request that's coming through with a form it is it is designed to go and access uh more information specifically the nickname of the user uh information about that user itself so um I'm going to put no client side validation API call and that call is going to be originating through client side JavaScript so I'm also wondering if there's any way we can control this through another injection but that's conversation for another time uh now if we did let's go ahead and get logged out here and we'll go back to the login page and I just want to show if if this request did originate from a forum or form or something else where there would be any client side injections then what we would want to do here click back on this and it should take us to the login page it does um we would want to come in and test these input fields to see what's allowed and what's not allowed right so we would expect this to be looking for a username or an email so do they have any client side validation that would prevent us from going in and putting something like this right and immediately we see that we are getting uh a response for that so um let's come over here oh kind of thought Google would take take care of that for me but that's fine let's go with this one uh okay so some type of translation to say the email address format is is not correct so um they are validating for this if again if if we want to go through this so I would want to check for all types of different characters because we get this great immediate response right when come over here and uh you know we can do test test.com and it's immediately okay all right so what happens if we put this it doesn't like that what happens if we put it within the address it doesn't like that either okay well what about a single quote double quote single quote right does it allow a plus it does allow a plus because that's within the email naming convention right does it allow numbers numbers are fine um whoops refresh this page real quick right we're going to use this validation that's put in here and we can start to make assumptions about what they have on the back end so they are expecting an email address press you know I would probably go through and check every single one of the the you know different asking characters that I can find does it do anything with uh URL encoding it seems like it doesn't allow that at all do email addresses allow percents that's a question that we could answer let's click on that right there should say it's fine um you know underscores not okay course okay Etc anyway I think you get the point um if this was a request that was coming from a form here I would first come through and Mark one by one you know if there was client side validation uh for bidden characters a I can't type you know and then it would be this one doesn't work uh I'm sure I'd find a better way to do this but that one there uh we can't do single quote double quote I keep getting those mixed up but that's totally fine um Etc right so we're going to start putting the picture together here of what characters being sanitized on the front end and what characters not and then like I mentioned we would go through and test uh or or this would allow us to make some assumptions about what they're going to do on the server side and then we would just need to go in there and test to confirm those assumptions right but we don't have that so we're not going to have any insight prior to our testing so we can go ahead and jump to the server side validations get a little more coffee there so we already know remember this is not a server side validation this is being caught by the web application firewall so let's get rid of this here and let's see what happens when we send a request with this uh what would essentially be opening up uh an HTML element okay so we do not get a 403 which means we are getting through the cloud flare WAP the cloud flare W is not just grabbing any request that has this uh character which would make sense right cuz there's probably a lot of use cases well not a lot but there would be some use cases where you might need that or maybe it's just something they haven't thought of so now let's come down here and we see where we're reflected has two different ways of encoding this let's open up our inspector again come back down um so right here we have both characters URL encoded it looks like cuz cuz yeah it's URL encoding the Amper sand as well it's URL encoding the whole thing whereas over here this is double URL encoded so we have it being reflected in two different places in the Dom now we don't know if this is server side validation or output encoding right because this could just be a a natural process that that happens when this uh you and these parameters are taken through the server side code and then when it's reflected in here it may just be reflected as URL and coded because they they encoded it to process it and they just never decoded it right because they didn't expect or didn't think they needs needed to to be decoded in order to be written to the Dom there wasn't planning on users being able to write to the Dom in this way so it's entirely possible that this is encoding um and we can potentially bypass that um again serers side validation would we would usually see these being stripped out so I'm going to go ahead and assume that on this end point there is no server side validation at least not on that character and we're just getting encoding so uh one encoding we're going to do this and for each one we're going to have to do a separate one so on one injection we can see here and on the second injection in the link we can put that right here and then I want to come down and really isolate my payload as well oops again whatever notes you want to take take them the way you like this is just kind of what's working for me right now we'll do a space there and a space there okay now we can put URL encoding and over here we have double URL encoding perfect so that's just one character but it's giving us some insight you know it's the fact that these are different there may be some way to to play with that right what happens if we were to send this URL encoded here you know so we've already got the uh percent three Charlie does it URL encode all of them no it stays at a percent 3 Charlie it doesn't modify it at all so we don't know what that means but it's certainly interesting you know that means that there is some additional Logic on there because if it was just converting everything to a URL then uh to ur encoding then it would encode this most likely um so they're probably decoding it and then encoding it and then this must run through through twice uh so that could be a way to potentially weaponize that as well what happens if I send a double URL encoded now we have the W URL encoded reflected there and then a double double down here okay so let's try a different character let going through we can expect the same type of thing for uh closing the tab let's see how it responds to a double quote there we're still able to get past the web application firewall and here once again we have the single and double URL encoding so um let's go we can continue when we see the exact same behavior we can just start to kind of make lists of those but overall it looks like uh URL encoding uh two different ways one is meta element uh single URL encoding and the second is link element double URL encoding okay now can we get any other Behavior here what happens if we get a single quote doesn't look like much else there let's go ahead and send this over to the Intruder again and we're going to set our payload to right there we're going to load and oh good we're still in the fuzzing but we just want to send like we have before all types of different characters and this time I want to actually use the uh let's see where are we at let's try a double URI hex right there and let's also do the special characters there it is y special characters Library as well right so we've got several different double URL encodings and we're going to see how if if there's any variation from what we're already seeing right that's what I'm looking for because we're just about ready we've got two things to bypass we've got a web application firewall that we're going to need to try and bypass uh some filtering there and then we're going to have to try and find a payload that will have uh an output that's not encoded this way so I just want to see if we send some of these w encodings if we send a bunch of these different characters do we see any variations to this encoding is anything being stripped out is there anything that we're missing about what we need to know before we start trying to bypass these and inject JavaScript into the Dom right so we'll come over here to our resource pool we're going to do our very low and slow once again um we're also going to make sure and keep our Canary uh which mine is usually arson a canary is just a unique string that you can use to easily search for the Dom because we're we're going to be able to uh automatically go to that and see very quickly as we scroll through the uh results whether or not there's any major variations to it so let's go ahead and let this run for just a minute and we'll come back look through that and assuming there's no major variations we can go ahead and start working on bypassing some of these compensating controls and get some JavaScript to execute within the Dom all right that took about uh about probably about 3 minutes 3 4 minutes to run there so let's go aad and come back over and we'll click on this we're going to go to the response and then like I said before the reason we have that Canary we'll come back in and hit autoc Scroll once again we're going to do arson and now we'll be able to go straight to uh exactly where our payload was injected in the Dom for each request and now we can very quickly just cycle through and we're looking for again any major changes now sending this with no payload yep we're getting the same type of thing right we got the single URL and the double URL so are there any variations I'm going to go ahead and click through this and it doesn't look like we're seeing any major changes scroll through scroll through so again this just reads to me as output encoding you know if any of these were being decoded and for whatever reason they were well not for whatever reason they were trying to prevent a a malicious payload from being processed by the server side code so they're stripping certain characters out or doing any major modifications uh of certain characters then we would expect to see variations in this so this is really solidifying my assumption that this is only output encoding I don't really see anything here that would tell me that this would be server side validation um now here once we get down to the individual characters we can see we're still double URL encoding down here but up here it's only URL encoding some characters so we can start to get an idea of what characters are allowed and specifically which ones are not allowed right so this actually reads to me more like a server side validation because we have certain characters now are these just the characters that are built into the email I don't think so right it seems like some of these were strategically chosen although I don't know what the carrot there would be absolutely so the fact that some of these are URL encoded and the others aren't I don't know because uh that could also be that they're using different libraries Oh look The under the underscore is not URL encoded in either one of those so are they using a library that's just choosing certain characters and this one's much more strict or maybe it's running through twice it's kind of hard to tell I don't see any reason why that would not be URL encoded right a comma should never be in a URL if this was being run through a library that was actually uh that was just designed to do URL encoding for uh to make sure that the URL wouldn't break I would not expect to see this so I think there's enough evidence here for me to make the assumption that oh look we do have some service side validation now because now when we send a a DOT now this instead of being wurl encoded just has oh wait or was the % always there oh the % was always there sorry but now we're not URL encoding the dot in this one H so again it's kind of hard to tell exactly what this is telling us but there are some variations I think that the top one here because the dot is is supposed to be in a URL I think that's why that's not being URL encoded here I think the top one that we have is verver side validation and the bottom one is output encoding I think this is being output encoded as well but it's not you know this is obviously being processed multiple times that's why it's coming out with a double URL encoding um this right here I think can just go through a single validation and then only certain characters are being encoded so and and I could be completely wrong about that as we go through this we're constantly trying to figure this out you know we don't have that insight into what the developers meant we have to continue to assume but based on what I'm seeing here in the response is I'm actually going to take this one and strip it out and add this as a server side code so or a server side validation so I'll actually copy this one first um we can do this right here and and then we'll go ahead and grab this I'm sure I'll come back and clean this up at some point but we'll get there so now Begins the tedious process of going through and identifying every single character that either is being encoded or isn't being encoded it's kind of up to you how you want to do that and I won't go through and show the whole thing but usually I would be identifying characters that are being encoded uh or are being validated on the server side which is what we think is happening here so right here we have a hash that's being encoded I'll just go through and identify a couple of them so you don't have to sit here and watch me for a long time um percent is not being encoded we have the carrot we have the Amper sand right and again we're looking down here anything that is coming out as a URL encoded so that's going to be a star oops parentheses are not being encoded nope nope nope a plus is and let's get one more and then I'll be done we got plenty of them here too curly brackets curly brackets curly brackets right there so um kind of makes me wonder looking at these characters you know I'm looking for patterns now right like what are they trying prevent what are these characters used for obviously this can go into a URL this can go into a URL but the carrot can't the star is not usually going to have a big impact the curly brackets as well so the question we have to ask oursel here is are is this validation if this is server side validation is it designed to prevent client side injections or maybe are they trying to prevent some type of serers side injection with the uh you know some type of code injection in that serers side code based on the langage language that that this is written in you know we know that this endpoint is a PHP endpoint some of these characters here would have much more of an impact if they were injected into some type of PHP expression than they would if they were injected into the Dom so and that's something you got to always think about as well right this server side validation they're not just trying to prevent client side injections they're trying to prevent server side injections database injections any way that you can get malicious characters to have something on on anywhere within the application act in a way that they did not intend to they have to try and prevent all those types of attacks with these validation and that's why it's so difficult to do that when you have these granular validations uh and that's why it's possible for us to to potentially bypass that as well so so now we've identified uh most likely three different compensating controls that we're going to need to bypass in some way uh to get a client side injection on this target now the first we mentioned the web application firewall it's a string check so we'll go through and test all types of different variations of strings to try and bypass that and then here whether this serice side validation or an output encoding we don't need to bypass both of these we just need to get our payload to render in one of these injection points right so we have our attack Vector which is coming through the URL here specifically at the end of this uh call back get parameter this is our attack Vector it then travels to the application and is affected by multiple different compensating controls before it eventually is rendered on the Dom right so we'll go through we'll see if we can bypass that and then if we can and we can get any type of JavaScript to execute now we get to come back here and deal with these compensating controls and try to find out how we can weaponize it to show impact uh on the uh on the program there so we know based on our testing that when we send a payload to the application before that payload reaches the application code in is process in any way it's going to be evaluated by this web application firewall looking for malicious strings so we need to start by testing this web application firewall to figure out what types of things it's intercepting what it's looking for to see if we can potentially bypass that so let's get this minimized over here we'll come back to our instance of burp site now the payload that was being blocked before was this uh basic cross site scrip rting payload here right so we're just sending uh script alert end script everything you can possibly think of this would be a very very easy way for uh a web application firewall to catch a potentially malicious uh request there so uh we send it through we see that we have a 403 now what we need to figure out is why is the web application firewall picking this up right because almost certainly has some type of Rex check or or something to see uh you know if the request contains this then return to 403 otherwise you can go ahead and redirect it onto the application itself um so before we start looking for any ways to bypass this we need to figure out what is causing this let's get our notes down here I didn't mean to put that um so I'm going to put catch right here and we'll start to document what is being caught and then I'm going to come back over here and I'm going to put bypass and uh this is where we can try to identify some strategies that would allow us to bypass uh the catches that we're finding here um so let's see let's just get rid of this and we're going to start testing individual characters right is it just going to block everything that comes with uh a you know open or close bracket no definitely not and and I would be pretty surprised if it did that so what about uh the entire script tag there it's pretty common for uh a web application firewall to catch request like this because why would a user need to send a script tag at least in the get request here it's pretty uncommon so let's see if that's that is uh blocking it what happens if we just get rid of everything else here if we just send the script okay we're getting the 403 now is it the entire script no it doesn't like it with that is it looks like we do need the whole word script I'm guessing it's not it's going to require that open though as well it does okay so if we have an open and script we're getting the 403 most likely because we could potentially put Source or something here and then and it would fire uh without everything else at least could potentially do that um let's see what about image is it blocking on any type of elements no it's okay there so it's not okay we do know that we have one catch here perfect oh that's going to change all our stuff okay let's do that just to make it a little bit better okay perfect um it's catching on the script how does it feel about just the general alert is it going to block that too no so this is fairly permissive um h i wonder about SVG that is blocked as well okay so we have a catch for a few of the more common ones right we have uh an SV G which could be broken and then on an onload or on error on Mouse over whatever it is it would uh cause that client side injection to fire um script as well interesting that image is not let me just confirm that image is not coming up as well yeah so image is allowed I want to actually note that uh no catch let's do that yeah because the image tag is very commonly used to do client side injection I'm surprised to see that that one's not being blocked there but um okay so let's just come over here we'll put script back in and we'll get our 403 and we can start to see if we can get any bypasses for some of these catches now this is almost certainly not going to be all that it's catching but we can start to get an idea of what the logic is uh behind the web application fir wall and maybe some ways to potentially bypass that and I want to go ahead and bring up a couple of uh couple of resources here too so um let's come back over here one thing that is always a good idea to keep with you when you're trying to do these client side injection uh bypasses or trying to figure out the compensating controls uh I always do oosp uh cheat sheet xss filter bypass didn't spell bypass right but it should find it it did perfect so oasp has this great resource and and remember right what we're trying trying to do is we're trying to circumvent the compensating controls that The Blue Team the developers and the the company security team have put in place to try and prevent us from uh exploiting this application in some way so these blue team resources things from oosp are phenomenal because this is a lot of times what the blue teams are looking at right so we can go through these and get an idea of what they're trying to implement so that we know what we're trying to bypass this makes it very easy for us to show impact and understand exactly what we're trying to circumvent while we're doing our testing so I always recommend to come in and take a look at this this will give us an idea of some of the things that we can do right we can do a malformed image tag like I mentioned before right anchor tags we haven't tested to see if anchor tags are included so let's uh split that out is it going to let me it will okay perfect I want to send this over here and get burp site over here um what about just a general anchor tag is that one being blocked no an anchor tag is not being blocked so we're already starting to see some options that we have here right there's no catch on the anchor tag uh okay what else could we possibly do here I wonder if it would catch this JavaScript colon which is pretty typical for a uh data URL which would allow us so that's what you're seeing here right the source is a data URL um JavaScript there it's not blocking that as well so this is again this is fairly fairly permissive um anyway so one thing that I would do is I would go down through each of these I would do I would do this process that I'm showing right now for an extended period of time and really try to go in and understand it now you can identify the type of uh web application firewall we know that this is a cloudfront w um and it does have some inherent characteristics that we can do research on so I would certainly do that as well but ultimately we want to figure out a lot of these have custom configurations on the back end certain strings and and things that they're looking for so ultimately we need to figure out what the uh WF is configured to catch and what it's configure to block and that will again give us insight into uh what they're trying to prevent and also allow us to potentially circumvent it um so going through these are great um another thing that we always want to bring up especially when we have variations with different tags and I've shown this many times but the port swigger xss cheat sheet good I've already got it in my history there uh let's bring this over here as well and bring burp suep back up so Port swigger has this great resource too so if you start to see that the compensating control has variability and blocking depending on the type of HTML element that's being uh set in your payload then a resource like this is fantastic because you can come through and filter out you know we've seen that our SVG and script tags don't work right so we don't want to come and use some of these that have all these different script tags but we found a few that do right we found that an image tag actually is permitted so now we've got all these different resources pre-built uh payloads that we can do we can copy these out we can add them into Intruder we can do them manually so this right here gives us a lot of different options that we can start to play with to bypass this first compensating control which is the web application firewall um we can do the same thing for the anchor Texs right there's going to be a ton of different options so when you start to see this variability where it's accepting some of the tags but not the others then I always gravitate to this ports scker cheat sheet and start to get uh a list of payloads that could potentially work or at least bypass this one compensating control here so um I'm going to put uh Port swigger sheet sheet uh and then let's just do different elements I guess it's early in the morning right now I can't type even worse than normal uh okay so yeah just kind of note for me to know that there um now outside of generic things like this and and general lists and and payloads and fuzzing and polyglots and all that the next thing that I want to do is I'm going to manually start making modifications to this block to see how the web application firewall handles it right so let's get back to where we have a block and let's just go let's do a full script tag right there um I want to make this as loud as possible so we'll go back to our initial payload right we're sending the full script in the alert we know that it's going to block this so now um and look there's there are tons of different ways for how you can try to buypass this by doing different you know types of characters and special characters and everything um I'm sure that's a whole different video and I would always miss a bunch of them and everything the bottom line is you'll there's tons of resources out there for that do research on um you know just look for anything that has filter evasion bypass ultimately what you're going to need to do coffee down here for a minute ultimately what you're going to need to do is you're going to need to get your own list of different ways that you can do it and most people do that by you know a combination of experience where you're going through and doing the testing like I am and uh finding public resources you know so if you come in and just do uh General like xss uh filter evasion uh GitHub you'll probably find a lot of resources that are in here right people combine theirs together some of them are good some of them are not good um a lot of them are going to be wordless like this what's more important than getting wordless like this and throwing the payloads at it is understanding the general concepts behind the the variations right understanding like the categories of of variations that you can do so I can demonstrate that here right we can actually come up here make it bigger for a little bit um um so we send this one of the most common variations that I do here uh I think just about everybody does first of all let's make modifications to the case right how good is it at uh recognizing when there's you know kind of strange variations in the case of these uh these strings here so instead of a script like this we can do s c r i PT you know and maybe close it out we go uh s c r i PT I kind of play with the pitch there a little bit but let's send that through okay doesn't have any impact now we can keep whittling this down the right because we know the smallest possible one that we have is this here so we're not going to be able to bypass everything maybe it's catching on something else but let's see if this variation in cases is going to change the way the web application firewall blocks this string which we know is the smallest uh portion that we can do and it does not okay so I'm to come back here and uh let's go worked and then did not work I didn't think at all about what to name these before I always change it to something else it's usually something funny to be honest or something that makes me laugh at the time um okay so we are not able to bypass with a change in case um and let's actually do not work um change in case and then we'll do that right there that did not work get my little things over there perfect okay um now let's see what happens if there's two of these in the beginning um if you've seen my uh video on building your own web application with client side injections I think that was specifically for crossy scripting um and then protecting it and then breaking it again and protecting it one of the things that I show is the common misconfiguration where they use a JavaScript method that uh replaces this character but it the inherent nature of the method and sometimes developers don't know this the do replace method only replaces the first character so if you put two of these then uh ideally it's only going to replace this first character and sanitize it and the second one will still be there as opposed to if you use the replace all which would cause it to uh obviously replace all of them so we'll send that um now nothing's being replaced we've still got a string Rex and most likely that one's not going to work this type of technique is going to be usually more effective on server side validation so we'll certainly try that again um but we know that this one did not work as well so the overall concept there is uh to additional open uh we'll just put that right there and then we'll do that perfect well not perfect because it didn't work but that's okay um okay what are some other options here uh what if um you know what if we have an additional Open Bracket over here maybe that'll break the Rex it does interesting okay so if we send this with an additional Open Bracket I wonder if the case is having any impact here it's not okay so adding an additional Open Bracket here does you know you would think that the Rex would still capture this but it doesn't I don't know what that means yet but I am going to document this because this this works so additional open uh I don't what what in the world the character I guess you would call it um well obviously is a greater than anything but I'm I keep W to say element or open tag or something but it's not the whole tag right it's just the first character in that tag so okay we'll go ahead and put that there um you see this is the the process that we go through and I I could probably again do an entire video on this um but let's see what what are some other options I want to make sure I include uh some of the most common ones is this doing any type of alert or any type of block on the alert it doesn't seem to be okay because one of the ones that you can do here and we can go through this more in the uh client side validation but you know you can do uh back ticks instead of parentheses I wonder if it picks up that no it's totally fine with that um but we don't need to bypass that cuz we're only looking to bypass I think this uh script block here um what about what if there are just a bunch of extra characters written into the uh the element there that are you know completely useless because that would still be accepted as just generic uh parameters right so um we would have to add them afterwards though so it would need to be a space and then maybe like uh I we just do let's just see how it accepts that we're still getting a forbidden um you know I would imagine too that the reason this worked you know if I put another one there it's probably still going to block it so maybe the reason this worked is because there's no way for this to render in the Dom I'm going to make a little note of that um Can this render in the D uh let's do telling me cannot type in the morning can this render in the Dom uh yeah just a note right there because I think that's probably something that they've thought of there um okay let's go back to that we know that the uh additional characters um adding extra characters did not work and uh oh can I get back here yes I can not that not this okay so that's an option there um let's see typically we would try and uh or we could try and concatenate these as well you know so if there's a way that we could uh possibly do you know something something like that we are able to bypass that but again will it render in the Dom I would keep that you know same type of thing here um because it it all depends on how this is processed right if this plus is turned into a a space and later that white space is removed is some type of TR catch or additional thing then that could work there um it's possible that uh it's possible that we could put uh you know this could be processed as individual St strings so maybe when this goes through the server itself at some point it checks to be a string it would convert this over and then combine them but again it's it's going to be a bit of a stretch there to get anything like that um what about this one fun one that I really like is uh line break so i' I've I think I've mentioned this on this video um although gosh it's been so long since I started recording this one um if I haven't mentioned this before maybe it'll just be redundant right but there's uh return carriage and line brakes as part of uh you know just just any generic HTTP request and these convert into hex to zero Delta and zero Alpha uh if I remember correctly so the uh carriage return right here is going to be zero Delta and then the new line character is going to be zero Alpha um so one fun thing that we can do is see if we can break this up instead of with trying to do a string or a plus to concatenate can we break it up with a new line character uh or a a carriage return character that could potentially it would allow us to buy bypass the W but once it's actually written to the Dom will just be thrown out or uh it could be thrown out before it's written to the Dom but it also just might not be processed on the Dom there so um we can do that with our URL encoding so percent 0 Alpha and let's see if this will allow us to bypass this check it does allow us to bypass the check now we will need to see let's do this let's send that by the way this is another one that I would test just what happens if it has no closing tag sometimes that will still still execute there but um we're going to try and alert arson I know it doesn't have any parentheses that's totally fine I just want to see if I can get this written and what happens okay so when it's written to the Dom and this is where we're going to start to to come in and look we're still getting these URL injections uh or I mean these URL encodings here just like we were seeing before so this does allow us to bypass the web application firewall but looks like it's not going to get us around this output en coding again so hopefully this highlights we've got to continue to test you've got to recognize all the different compensating controls and you've got to find ways to bypass all of them this is what is so difficult about finding client side injections in public bug Bounty programs they have multiple different layers they have been tested thoroughly for all of the easy types of CET side injections so you've got to really dig in you've got to really understand what they're trying to prevent you to do how they're trying to prevent you to do it and then find ways to circumvent that so but with that being said I don't think we need to do anything too creative to get around this because we have the ability here to uh inject some other elements right we can do the image tag we can do the anchor tag those are super easy to escalate into some type of client side injection for for JavaScript there so I don't think think the laugh is going to be much of a problem against this attack Vector I think our real issue is going to be either if this is server side validation uh and then the output encoding really seems to be the most challenging thing that that we're going to have to get around here and it you know honestly may not be possible to get around it at all um as I'm looking at this I'm starting to get less and less excited about this uh endpoint because the combination of the output encoding and where it's written the Dom we can definitely do a little bit more testing here to try to figure it out uh before I'm ready to move on to another attack Vector so let's look one more time at where our user controlled input is being reflected in the do right if we come over here we see that it's being reflected in the URL within an HTML attribute so an attribute of one of these tags what does that mean to us as an attacker it means that we are going to have to find some way to inject a double quote into the Dom there is no other way with an HTML at least not one that I'm familiar with to break out of an attribute string like this without actually getting a double quote to render now does that mean that if we send a double quote and it comes back with a percent 22 it's not vulnerable no absolutely not but we only have one alternative here and and again I keep saying this over and over again this is why where our payload is reflected in the Dom is so important right if it was reflected outside of this if it was just generic string we would have a lot of different options to try to create an HTML element out of nothing that we could uh cause clients side JavaScript to execute but within this uh part of the Dom there's simply no way to write anything else to the document object model without breaking out of these double quotes so um that's the only option whether this is server side validation or whether it's output and coding it really doesn't matter we as an attacker we have to do this we have to find a way to get a double quote and if we can't do that we're not going to be able to break out of the attribute we're not going to be able to write anything else to the Dom because it all will just be included in the attribute itself and the the string that's being passed there so um with URL encoding uh it can be surprisingly difficult to break out of that because it's a fairly simple process the server is just taking user controlled input and saying if it's these certain characters I want these characters to be URL encoded um we can play a little bit with what type of uh force it to do a different uh you know like UTF encoding or something like that but those attacks typically only work on certain browsers and are not great for bug b programs usually hard to to show impact so um ultimately we need to find a way to cause this end point and I can get rid of this as well because all we really need now we know that we can get past the w we know that if we can find a way to inject into the Dom we've got options to to play with here with some other elements so I definitely see an opport opportunity here but we're going to have to get this percent 22 and this percent 2522 to render in the Dom as a double quote um so you know we could potentially try some other variations of it um these types of things typically don't work but uh let's go ahead and get this so it's Auto scrolling as well um yeah it may be a single quote somewhere within there is uh converted into a double quote or what would be probably more likely is something like a back tick or just some some strange characters there obviously um so here we see the back tick directly reflected it's not URL encoded in the one that we believe is server out validation but it's still a back tick so that's not going to help us at all um so that's one option that we have there to bypass the encoding another thing that we can do is is the fuzzing that we've talked about up until this point so let's go back we'll send this to the Intruder again we've already done similar uh types of attacks but let's go ahead and put this double quote there and we're going to add a payload we can do it in a couple different places I'll go ahead and add the payload between the RS and double quote directly before the double quote and we want to come and use any of our fuzzing uh word lists here that we believe we're basically trying to break it right there's a there's a very simple mechanism within this application to take this user control input input and convert it to URL encoding before it's returned and later written to the Dom uh so we just we have to try and find a way to break that if it's possible so what I'm probably going to do is I'm going to come over and do just throw a bunch of payloads at it with unexpected data that it it may not be looking for you know one that I'm definitely going to do and we've talked about this before is the URI hex um we have the URI double hex there um any additional Unicode that we can do um I would just throw a whole bunch of unexpected input at this and then try to to find out whether or not it's going to uh you know is it actually going to ur on COD can we break uh that operation on the server side to somehow force it to Output that um you know we've got our special characters here that we can maybe see as well um yeah I mean I would go through and try a whole bunch of different stuff I don't want to get a ton here you can see several different characters we've got every asky character encoded and uh really probably the most likely one that's going to have the impact here would be something like the null bite um something that would potentially break that encoding and ideally still return the the input now one thing that you can do as well and it all depends this a little bit of an advanced uh topic here but um you do have the ability to do a grep uh match as as part of the returns now this can be a little bit complex considering what we're trying to do considering that the payload is going to change every time but if we're able to write a Rex within this that can identify when we have arson and then you know whatever the input is going to be so we do a Rex to put in there but more importantly we want to uh alert whenever we have our Canary and the character that we're trying to uh see in the response right so we would change this to a Rex we would go in and put you know potentially like any character uh between these two and then we would have to actually close it out so we would have to do you know and then after that it's going to be you know double quote and a a close bracket we'd have to find some way to make sure we're not getting a lot of false positives and again that's probably a video for another day um considering how long this one is already but this can be a great way to not have to manually go in and validate each of these tests here because we know if it reflects our Canary along with this double quote after it uh that's not the one that's expected in the Dom then we know that our payload is worked because in every other instance where it's not going to work through the encoding we're either going to get the percent 22 or we're going to get the percent 20 22 so again I'm not going to bother with that now but that would be a way to kind of automate this process a little bit but um let's come to our resource pool we hit very low and slow hit run the attack and we'll let that run for just a few minutes we'll come back and see if there's any results all right so that scan took about 10 minutes or so we got everything done here so just like we always do right we want to try and find any major variations with this so first of all it looks like we really really only got 400 and 404s coming back so either it's not finding anything or we're getting a bad well the 404 is fine the 404 means we've got it reflected right so we probably don't need to worry about the other ones let's come down here and do our Canary so we can automatically jump to it and we D the auto scroll right there so we know that a 404 is the correct response um everything else in here all of these 400s we're probably not going to need so let's see we're not going to be able to filter them out though unfortunately uh yeah so we can do uh obviously if we did the GP it would pick it out um we could do show only highlighted items right here uh and then that would kind of go with that but I think that's fine we'll just kind of sort it by the 404 and then we're just kind of going to have to start scrolling down um now this is interesting that uh these unique characters are not being you know any type of URL encoded or anything they're just coming down as a question mark But ultimately what I'm going to do here is just scroll down and I'm looking for anywhere that we have our double quotes reflected as opposed to a percent 22 right um and it's going to be different for everyone so we're going to just have to scroll down these larger payloads make it a little bit more difficult but my hope is that something within our payload broke this to where it's going to do a different output and actually we see an example this now look at this so typically we see this uh our our payload that we set here's our double quote at the end of this along with the unique string and now all of a sudden we're not using uh double URL or uh yeah double URL encoding remember before we were getting the uh percent 2522 every time but now all of a sudden we have this uh this is a a server side validation right this is specifically being sanitized from something so that tells me that we've affected something I don't know what right we've got to figure out what that is but we're not seeing the same type of encoding that we saw before didn't affect this one at all but for some reason something to do with that double en encoding caused this to come down somewhere else and then and the double quotes are being processed differently so that's the type of things that we're looking for any variation in where that that uh the URL encoded double quote should be reflected and then then you know do we see something different ideally we're going to see that double quote reflected somewhere so great that we're already seeing something look here's some more like that it's not being double double URL encoded if we scroll down to some of the more typical ones right here uh now we're right back to that percent 2522 so what is it about these unique characters that is causing that to break that ends up with these question marks I'm guessing it's the uh you know some type of output en coding on the back end that is breaking and we're ending up in a try catch to say ah well okay we don't want it to to return a server error every time so just return these question marks and then run it through some type of validation or something so by sending these double quotes now we could have or sending these unique characters we now could have the ability to send some additional payloads here that could help um so I do want to go ahead and get that documented under here uh and this is in our second one right the WL encoding it is right so um we'll take a note and we will say uh in fact we'll tab this out a little bit just for the sake of it oh wait no we're already out are we so that's the right question okay so uh sending unexpected characters and I will kind of do this right here so we can grab them causes the double URL encoding to break output is question mark question mark question mark and double quote are sanitized to and then we'll grab that double quote value right there come on give it to me make sure we get the right one all right so at this point usually what I'm going to do is I go through all of the different compensating controls I start to put the picture together like we have um I have a pretty good idea of what's going on here pretty good idea of what compensating controls are being used and what aren't and maybe some approaches to do it but remember this is just one attack Vector I mean we haven't even started testing the other attack Vector on a completely different application so we'll go through this exact same process on the other application um but there may be plenty of different attack vectors within uh this application as well that are similar to this but we may have uh we may not have to deal with all the same compensating controls we may not be reflected in an attribute anymore we may be reflected uh in just an open area of the Dom which is much more favorable if you're trying to get a client side injection um within this application you know there's there's a lot of different variations that we can find here so what I'm going to do at this point and as I'm going through and finding these different attack vectors and doing the evaluations you've seen for for this video is I'm going to start getting a mental note and maybe even you know for the sake of it writing it down um but I'm going to kind of give these a a score in my head based on these and and you know so let's say like a 1 through 10 what do I think the likelihood is that I can bypass all of these compensating controls and actually get some type of a client side injection because there's I could continue testing this for hours and hours I can make a whole video on just how to test this and keep going further and further and trying to figure out how we can break it but does it make sense to invest our time in this endpoint or would it be better to go and find another endpoint that we can Target so let's just talk through these a little bit uh and I'll kind of give you an idea of where my score would be based on these compensating controls right um we've got two different session tokens it looks like um the cookies themselves right we got the HTTP only and secure but I still think we're going to be able to show some impact so that's good weaponizing is not going to be an issue we can possibly leverage this but there's some other ways we can get to to customer data as well um we do have some browser security headers that are going to be pretty strong this one specifically but we can uh talk about ways to play with that this is uh definitely a hit uh definitely you know not uh I guess we give it a lower score but not by much um the content security policy being uh report only you know safe inline everything else that's a huge bonus that's a huge Plus for me so this is what initially remember got me interested to start digging into this attack Vector specifically uh web application firewall doing some basic sanitization I feel like I can get an image tag or an anchor tag in there if I can break out of the uh attribute uh super good big plus is there so I like that um client side validation don't really care and then the server side validation the output and coding this is especially the output and coding this is what uh is the the biggest uh negative for this end point um I'm just going to tell you when you've got URL encoding going into an attribute it's very very difficult because like I said you've got to get a double quote there's nothing else you can do you've got to find a way to convince that server to return a double quote in its raw form that's going to be rendered on the Dom otherwise you've got no chance so if this if everything else was the same but our payload was being rendered somewhere you know just an open part of the Dom that we had lot more things to play with I would be very very bullish about this endpoint but based on everything that we have if I was going to give this a score of 1 to 10 I would probably give this one about a four or a five and I'll just say a four right there um if it wasn't for this I'd be a three uh but because we did find a way to cause this to go over what looks like server side validation I feel a little bit better about possibly being able to break out of this my strategy would be to try to find a way to leverage this break that we have and this difference in functionality uh where we're seeing the quote sanitized as opposed to URL encoded I would try and break this to get the actual double quote on there if I can do that I would leverage uh probably an anchor tag or an image tag to uh try and reflect uh actually build to the Dom and get our client side JavaScript to fire um so that's really my mindset on this one um I don't love it but it's not terrible either we could be in in much worse shape but I think at this point the best thing to do is to move around and take a look at some other attack Vector so before we take a step back and this will be one of the last sections in this video before we take a step back and go back and revisit our strategies remember we've got the three different strategies and for for right now we're focusing on the first which is finding hidden subdomains uh you know unauthenticated end points that we can inject this into um so we're going to take a step back and look through all those results from all the different places within within these applications to try to find an optimal attack Vector to inject in but first we need to get an idea of our other application like I mentioned this Singapore version has a completely different Tex stack so let's come up to this uh this attack Vector here and go through the exact same process we did before and we'll go ahead and give it a score we'll search through the other findings that we have and then I think we can pretty much wrap up part one of this video so uh let's do that right now now just minimize here we can come back over to our repeater and go from there so let's go ahead and get the uh second application brought up here and come to this open that up I think it'll yeah bring us to a login page there and now I have just like before I've already set up my account so at we racker one.com nice little throwaway password there we're going to find out if I'm a a robot un sign it there seems to be some debate about whether or not I'm actually a robot in the Discord but that's uh that's totally fine um at least I'm able to bypass CES which is good all right so we got logged in um we're going to start looking for the comps sating controls first thing just like before come down to inspect go to storage cookies and we are going to look at how the session token spefic specifically are being handled uh now here oops click the wrong button where'd it go there we go better as you can see It'll be able to see better if I can do this um we have completely different session tokens here so before we had a PHP session now we've got our off token along with this ASP net core um probably already know this just by that nameing convention but it's very obvious that this is going to be a net there you go teex stack right there um looks like it's hosted in Google Cloud as well so completely different Cloud as well we still have react on the front end so it's still going to be uh they're still going to be using jsx for a lot of rendering which is going to make it more difficult but that's totally fine so on these Let's see we have HTTP only for this uh antiforgery token but we do not have nsecure but we do not have HTTP only for this off token that is great great great for clients injection that's a big plus when we're doing our final scoring for this uh for this attack Vector because if we can get a client side injection and this is different than the other one remember down here we had HTTP only and secure on this session token this asp.net token right here this is a um A Cerf token essentially uh but the actual authentication token does not prevent us from accessing that with client side JavaScript that's probably because they need it they probably have something within their application where client side code is grabbing that value and you know sending it off somehow or or appending it somewhere we don't know what's going on but we know for some reason they were not able to add that HTTP only flag which is huge for us when we're trying to get or trying to weaponize a client side injection so let's come down and do the same thing we did before right see we're going to that there uh actually we'll grab the off first let's just do off equals just by glancing the values look pretty similar but we'll just have to see and then under this no HTTP only but we do have secure right I think that's what we saw somebody tell me if I'm wrong even though nobody's actually watching this yep so we do have the secure flag we just don't have the HTTP only flag uh and then we'll go ahead and grab this one as well it actually has a DOT delimer at the top there I don't know if that's part of the typical naming convention just looks weird to me all right we'll put that there and this HTTP only and secure all right so uh big big plus right here when we're looking at this attack Vector because like I said we can potentially steal the users off token um that already makes me more excited to do testing on the Singapore version as pairs to the Japanese version but we'll take a look at what the content security policy is too let's go ahead and get our browser headers there any security headers that that might be there we can let's just go ahead and send this through again we'll go to burp proxy and uh oh I think we've we've gone through and routed everything there but that's uh that's totally fine let's come over here and we'll set it up this way we just take the burp proxy come over here close out of this and let's see make sure our proxy is on it is turn this on send this through and there we go we'll send it to repeater go ahead and let the rest of those go through and this should allow us to grab all of the headers and the content security policy as well um I'm immediately noticing that we have an actual content security policy on this one right it's not report only so if we do happen to get a client side injection it is going to be more difficult to actually weaponize let's go ahead and copy this down here actually better way to put this is how I did it below where we just do it within a code Block it's a little bit easier to see once we actually preview it and now the security headers so let's come back through let's see content type Etc content type is text HTML that's good um we have some cach control along with pragma for that so we're not doing any caching locally as well looks like there's no caching whatsoever um so that's going to take away some of the options that we had before let's see this one should come over here um if you remember I was talking about using webc poisoning to potentially uh be a delivery method for our reflected cross-site scripting that would dramatically increase the impact because everyone that hit that poison cach response would be a victim as opposed to one individual that we just delivered the payload to but considering the cash control on here I don't think that's going to be possible we have two different implementations of hsts uh so that's kind of strange there's no vulnerability necessarily with that but uh always good to see you know why is that this one includes subdomains this one doesn't so I assume they want a different age on that than we have down here you know always just thinking about why that possibly could be um we have our xss protection we have frame protection um so most of the same things that we had before the uh no sniff down there as well so let's say go ahead and do that and same thing down here perfect um so going through this again because again these uh first three compensating controls we use to decide whether or not it's going to be worth our time to continue digging in right we've got a strict content security policy we've got a lot of strong security headers but we've got an off token a session token without httv only that alone is enough for me to at least spend a little bit more time testing because if I can get this to work we're going to be able to show a lot of impact we're going to be able to get some money off this right that's where you can do uh you know you can steal that cookie uh and do a lot of fun stuff with it so plus I'm going to continue anyway just to to demonstrate a lot of things we want to demonstrate so um let's come back here and with in repeater we'll find our request again so if we send this come down auto scroll and let's see where our actual attack Vector is uh okay so we talked about this a little bit before unfortunately our our payload is still being rendered within an attribute now it's within the form action which has a little bit more of an impact because we can potentially control where this form uh where the data from this form would be sent to we could also if we could really get a a complex client side injection in here we could also add in Hidden input that we could potentially uh inject JavaScript into and grab that and have the you know hidden data be sent to our server uh as opposed to where it was supposed to go with this action but ultimately same thing that we had before we got to get a double quote working we don't have any other choice that's the only way that we can break out of this so let's just see what happens if we send a double quote first of all and once again we're seeing that encoding right there I don't want to get all of this let's just grab the action and the end to the post and let's show that um once again this looks like output encoding so uh URL encoding that to per 22 and we'll go ahead and just put that right there this is going to give me two which I don't want but there you go okay so we're kind of in the same boat from what it looks like now we don't know if it has a web application firewall let's go ahead and come back to that actually we can test that in burp as well that should be fine right we're just going to do the exact same thing we did before we're going to try and get this to fire so if I was going to do the basic uh payload here close that out open up script alert one SL script right if there's any web application firewall that's doing uh that's parsing this request checking for malicious input there's no way it's going to let this through and once again we do see that now this is a different type of web application firewall though this is coming back from Google let's see I don't know if I see anything within the request immediately to tell me what this is Let's uh show this response in the browser whoops I accidentally copied that show response in the browser paste and we have just a generic 403 Forbidden this is certainly uh something that is oh AWS I was going to say this looks really familiar um I thought they were in Google weird cuz this this is going through an AWS maybe they have a maybe they're leveraging a Google redirect um so all the requests to The Domain are going through Google and then eventually ending up in AWS um we do some more testing there but um this looks like a straight AWS uh web application firewall not a cloud front or anything else um so that means that they are actually uh going in and probably using terraform to manually configure these individual checks um so we do have a web app firewall it's a strict AWS WF uh and it is locked we'll go ahead and grab this payload here okay so let's do a little bit of testing real quick with the web application firewall remember that's the one that we're going to have to bypass first make sure we can get there and we'll do the same types of things right is it uh we first first of all let's get rid of those um we know that we have to have a double quote though so let's leave that double quote in there um let's go down to what we had before looks like it may be blocking in the same way yeah definitely looks like it may be blocking in the same way we're still getting a block on this script so same thing that we had here right um all we don't need to do that it's what happens when you take notes over multiple days while I'm recording [Music] um this one right here is also blocked uh so let's try some other tags right let's see if the image tag works on this one because I was pretty bullish about that and it does that's really good so not blocked what if I do a whole Source equals uh yeah blah blah Plus on error equals alert one let's do the whole thing now it's blocking it okay so it doesn't like that I wonder if the other one would block that too let's check that out real quick we'll take the same payload put it in there that one's actually blocking as well so we can do an image tag but we start to run into errors when we do uh a full one there so uh anyway just good to know looks like it's using very similar logic between the two we don't know if it's exactly the same but there's a lot of similarities here right we've got the web application firewall I still feel relatively certain that we would be able to bypass it let's um let's come back down here uh let me save this let's come down to the output encoding and server side validation just do the same testing that we were doing before let's see if we can break that at all with some of these variations so let's come up here uh server side validation as well just in case that and let's get back to where our one was working I think that's fine if we just do this because ultimately this is where we need to get to right and it's only being reflected in one okay perfect um so yeah we can do our the same fuzzing that we did before right we can come and try some of those additional um variations that that we were doing um I'm trying to think of some of the ones that that maybe we haven't uh done before you know like let's see but I mean even if we can get the script tags and everything else because most of the the uh techniques that we were looking at before to uh bypass this all this here none of this is going to mat matter to us even if we can get it cuz we're going to have to break out of this attribute tag so the only thing that I'm really going to test here is the same test that I did last time uh where where do we go I'm all turned around uh here we go so I want to do the same testing that we did last time to fuzz and see if we can potentially break uh this percent 22 here so um let's send this to Intruder we'll do the same thing again we're going to put a payload right before that and we'll send a couple creative let's just do Straight URI hacks right we're just going to do a few payloads come down here we'll do a low and slow because it's a very small number and let's let this run for a little bit I'm not even going to stop the recording I'm just going to come down um because again I mean we have basically the same thing we have a web application firewall looks like it's even though it's a different W has a lot of the same checks that it's using we're still going into an attribute and that's not my favorite place to go anytime I'm going into an attribute and I'm dealing with URL encoding it's it can be a real pain to to try and get around that uh all right let's go auto scroll let's put our Canary in there um looks like the null bite is not doing anything for us which that's the one that I'd be most bullish about uh let's just scroll through and we're looking for any changes in this percent 22 right is it all still a percent 22 um and this is not the only word list that we could use but it's you know we can see where some are being not URL encoded here's one that's being double URL encoded which is kind of weird don't know what that would be but it doesn't seem like these are really having any impact and we're almost done no changes no changes no changes no changes okay so given that uh we're still reflecting into an attribute an HTML attribute given that we've got URL en coding which can be hard to get some double quotes in there we don't have a lot of uh area to play um I'm not going to spend too much more time on this now I want to be clear there's there's Tech techniques that I'm not covering here so there's probably I don't know if anybody really experiences actually watching this long end of the video but if anybody really experiences watching this you're probably screaming like I would try this I would try this I would try this there there are some things to continue here and I I definitely want to make a video some type in the future really digging into like the whole wide range of different things that you can do but ultimately the the muscle that I'm exercising right now is using uh this evaluation of the attack vectors and compensating controls to decide whether or not this is even worth my time so we've got a very similar uh security posture really for this attack Vector um as we do for the other one the main change is with this the content security policy is much more LAX but the or was much more strict sorry on the Singapore version but the session token does not have HTTP only in it um so that means that we could potentially access this authentication token but we not we may not be able to send it anywhere you know we uh we may not have the ability to actually get really effective JavaScript to execute this content security policy if we come down here to the script Source this is going to be much more difficult we don't see uh a lot of those same directives that we saw before although we do whoops we do have that unsafe in line there um I gave the other one a four I'm actually going to come up and given everything that we've seen given this strict content security policy where it's being rendered everything else I would give this a three I not not very bullish at all on this it's also one of the things I'm considering as well is how much testing do I think has been done against this endpoint this is a very very common endpoint here and remember for our first strategy which that's what we've been looking at we want to find hidden end points as opposed to or at least find attack vectors that haven't been tested as much this one is almost certainly been tested thoroughly by uh researchers here um now this is not not to say that this one wouldn't be but this is a little bit of a more obscure call as opposed to something that's part of the the login flow is going to be very front and center for any researchers um so between the two right we've got a four and we've got a three uh if these were the only two attack vectors I could find and I wanted to continue testing which especially for for this one down here I do think there's a good reason to continue testing I would probably invest maybe you know a couple days uh just on and off fuzzing trying to see if I can get anything weird to happen um but that's about it that's about it neither one of these are wildly exciting to me um so I think what we can do from now let's go ahead and we don't need to hang on to this I want to come back to the dashboard because if you remember a long time ago at least from my perspective and probably from years two if you're watching this video we started a scan uh that we created to uh only check for reflected input and and transformations and if you come back over to the dashboard you see I've gone ahead and searched for reflected here we did find several different areas where user controlled input was being reflected had a little error there I don't know what happened um anyway uh I think I'm probably running out of memory on my VM here I should probably restart but uh okay like I said we have several different areas where this is being reflected so every single one of these findings is an opportunity for us to uh actually get a uh a client side injection you can see here it's actually claiming there's some cross-site scripting so we can validate these so what we're going to do is just scroll through these and we're going to look at each attack Vector based on the information that we have and we can actually uh we can start to to build up the skill of glancing at a lot of these and get a general idea of whether or not it's going to be uh a good attack Vector for us to test and probably what youve started to realize now is where that uh payload is being reflected in the Dom is very very important so what I'm looking for as I'm scrolling through this is anywhere where my payload is being reflected in an open area of the Dom right so it's not or if it's in a script tag that's even better you know which which does happen occasionally but um anywhere where it's being reflected where we don't have to do a lot of additional breaking out whereas like in an attribute or even if it's actually reflecting an element that can be much more more difficult here so let's start looking through these one by one and we're going to see where our input is reflected and see if we think it's worth our time and if we click on this it'll actually automatically highlight to where this is going so we can immediately see and also want to let's let's get this cleaned up a little bit right I don't care about the time don't care about the task the action what I want to know is even the issue type let's just make sure it's the same one but I want to see what's the domain what's the path what what is uh in the response right are we uh reflecting in a Javascript file are we reflecting right right here is apparently in a uh jpeg that's being responded or responded actually this is kind of weird what is this this has got a whole Dom that's returned when you just make this request to the image itself uh although this is probably a 404 I'm guessing yeah this has got to be something that just says like oh we can't find it it's probably looking for that path name there but either way it's going within this hre parameter again so that's not something we want to look for let's come down past these jpegs JavaScript as well right 404 not found same type of thing so all of this is starting to starting to look like a pattern you know in fact this especially looks looks very very similar um JavaScript JavaScript jpeg right there all of this is looking like mostly the same um really it seems like if we get a 404 a lot of these that's what this is but okay now we're getting to to something a little bit different yeah these are all JavaScript files now here we have again a 404 and by the way when talking about this when you see your payload returned in a 404 error here here you need to try to figure out is it a custom 404 uh that they have made or is it something that is already pre-built right this one here we can see is uh pre-built within the cloud front instance right I'm sure a lot of people recognize this here so even though this may look like a fantastic place for us to continue to test because the response is wide open in the Dom right this is typically what we'd want to see but it's coming back on a cloudfront instance so we would basically basically be doing uh research for a new cve a new actual registered vulnerability in Cloud front if we were to try to bypass this this gets tons and tons of testing whereas something like this where if I right click show response in the browser I am fairly confident well it's going to help if we run everything through burp what do you think I am fairly confident that this is a custom 404 response and yeah we can see that right there so this is something they have custom built there's going to be a better chance that you can find a client side injection within a custom for 404 but keep in mind uh these are still going to be tested thoroughly by researchers so there's nothing here that's telling me uh this is worth my time yet um now we've got one in the cart uh I don't know why it's highlighting that down there but once again we're going into we are going into and oh no it's did it end that right there no it didn't so we're going into this is actually not bad right here so we are reflected into uh a script now we're still going to need to get a double quote Oh this is actually a really good let me go ahead and send this over here send this to repeater um what's the attack Vector the attack Vector is coming through this cookie with just a unique value so if we come down here and we type in arson on this and send it let's see where arson ends up here so this may look about the same at first glance at least it did to me but if we come down this is actually within a script tag so we are able to write a value directly to this directly to uh this this script here now we still got to break out of this double quote but we're not in HTML anymore now we're writing in JavaScript so we can potentially have some different functionality there so I love this for an attack Vector let's come over and we can document this one why I'm over here what am I doing come back up here gosh telling you my brain is starting to to melt after all this uh okay copy this URL here we come down and we're going to start a new attack vector and now the payload is going to go through this cookie here like we said um which one was it this one right here here we go all right so good to to come through and show show this let's do that there we go that'll be fine um so with looking at the way this is reflected in the Dom like I said this is a really really great option unfortunately we also have to look at where that request is coming uh from here so our payload is coming in through a cookie we've got to think about how we're going to deliver that to our victim if we're going to get a client side injection and deliver it we can't force them we can't force them to have a specific value in a cookie by clicking on a URL so now we've got the optimal area in the response or at least a pretty good area in the response but a really bad attack Vector location to where it can be really difficult to weaponize this now there certainly is a way the way that I would go about weaponizing this if I didn't want to go or if I did want to go after it would be uh I would have to do a watering hole attack right try to get them to a malicious page that I own and then I can send a uh a request where I can control the cookie in the background that they won't uh they won't have any knowledge of right but I've got to be able to get access to this cookie specifically there's a lot of complexity that's going to come with that that I don't really want to deal with so while the location in the Dom that my payload is being reflected in is fantastic the place that the payload is originating in is quite difficult to actually find a way to weaponize so I'll move on from here for now also for the sakes of the video but I would I would dig into that a little bit I probably just with that information I'm about a four we'd have to go look at all the other uh compensating controls but I'm starting at about a four on that one okay let's come back here let's keep looking through the response once again we've got our custom 404 which is certainly not what we're looking for uh here's two responses and this is in a 200 but once again uh we've got a meta and a link and we've got those URLs being appended in there probably going to do a URL en coding not interesting enough for me to want to dig into it let's keep looking we've got a JavaScript our generic 404 all of our generic 404s there uh this is being reflected in a Json response so we're not going to be able to break it out as long as they've got our content type so not a lot of help there uh another generic 404 can't find it being reflected in Json not going to help us ah well no no no no man these I don't know what these other things do I don't know what burp is doing uh but it's throwing me off so yeah once again we've got reflection oh okay so we've got a reflection in this attri these attributes here and then we've got another reflection like the other one so this is a much better position we are in a script tag we're actually in this uh Json declaration so this could be if we could get any type of user control to this and break out of this uh string then we could definitely have some impact on the uh the application itself so where is it originating and it's originating from here so this is a little bit better send over to repeater now when we think about the compensating controls is this not a 404 anyway because how is it finding this this has got to be a 404 I think it's just a 404 that returns a 200 right should response in the browser it is loading so this must be some type of a a path parameter um unless this I don't know what exactly this says right here uh by the way uh there's some good you know extensions that you can use as well I've just chose not to do that for that um yeah so this is actually an injection Point okay so just looking at that I thought it wouldn't work but the path parameter does does seem to accept anything within here uh as an injection so um good let's see where's Arsenal over here let's make sure it's still being reflected it is uh one two and three so we've got our thing there so um talk through this real quick you know we can come back and see we've got a report only so this is this is my favorite one so far um I love where it's being reflected I well I like where it's being reflected I like things about this I don't love it uh where it's being reflected within the script tag is helpful is definitely going to be easy to break out of there it's also within something that we can deliver in a URL now the problem we're going to have here is that uh almost everything is here and going to be is going to be URL encoded so trying to inject anything in here is probably going to be just about impossible because the output encoding like we saw before but this could potentially uh they could potentially handle that you know so we can do a little bit of testing we can just try and send a double quote and see how it responds is it even going to ow us to do that it will [Music] um now we don't see the value reflected at all so this is much more indicative of serers side validation than it would be output encoding right we're we're not seeing anything being encoded they have completely removed this value at all because they've come through and seen that this was potentially malicious character what happens if we do a percent 22 I'll just try some very basic checks on this do we suddenly have arson coming back we don't I didn't have to type that twice um can we do double URL encoding and we're still not seeing it reflected so it looks like it's going in check and see if we have anything malicious and if it does it just completely strips that out otherwise we're just going to have it reflected in this area here yep and now it has come back let's go to that previous one just to make sure this still let's giving us a 404 all of a sudden so why is that H I don't know this is a good attack Vector I'm going to come over whoops didn't mean to do that go away I'm going to copy this URL as well and we'll come back over to our notes and we will identify let's get rid of this first let's identify our Canary in here there and uh again this one right here is now by far one of my favorites we're going to keep looking through let's go to the request this is most most likely the same thing yep cuz those are the same path parameters um and we see the same behavior there uh back to the custom 404 404 ah here's another good place for the injection and this is in a very unique end point okay I like this one a lot this one is my favorite so far this is my favorite so far let's come over here I believe this can be replaced with arson cuz it's the at least I saw the value of the get parameters what's being added there uh oh yeah so we've got several different options here um this is being injected right as part of the script in this config value um once again we're still going to have to find a way where we can break out of this we're still going to have to do the single quote double quote looks like it's not being stripped out we've got our URL uh encoding here some output encoding but doesn't look like it's doing any sanitization let's just try WL encoding just trying like the absolute most basic ones here we see that's directly reflected um so yeah so we have a and and any of this value is being being reflected here that's great um because we can assume that these parameters these parameters are typically not as processed uh through the encodings as the actual domain is these are easier to control so the fact that this is happening within a g parameter it's being reflected here now if they were just stripping the value out and putting it here as opposed to copying everything that looks like it's in window.location do uh search then that would be better because then potentially they're using the actual value as opposed to just copying and pasting right this is most likely just taking this value and copying and over we want them to actually intentionally be using it um but we're getting closer right this just at a glance I'm at a six or a seven for this one right here um we know the web application firewall isn't too restrictive we're still under the same web application firewall that we are for the Singapore version here um we don't see a strong directive for oh well you know what aside from the fact that we see this here so once again this looks like it's going to be a pre-built uh a pre-built thing so this looks like it's part of net so unfortunately we're looking for custom things I mean again we can do cve research if we want but if this is uh all standardized through Microsoft we're going to have a much much harder time getting anything to to alert there um let's come back down and see if we can find any other ones to the response [Music] and well where is this one being reflected repeater Let's test this one manually this still looks like let getting a menu item let's see if we can get arson to reflect here we do um is this all the same type of thing this is in so we're we're in this data page thing here um we're still in an attribute but we can potentially control some of the content with this this is a whoops went too far this could be really interesting this is where we start talking about some really really complex stuff right if the values within this string are later being uh injected into the Dom somehow and it looks like they're all being separated by you know not with double quotes we could potentially inject something into this string which is later injected into the Dom through client side JavaScript so um pretty complex but it is an option for us let's just see I'm really hoping to find one here that'll be a wide openen refle ction in the Dom that's really what I'm looking for mostly this JavaScript remember always when you see JavaScript like this reflected always check the content type make sure it's actually Json uh burp will potentially show you no matter what um so you should see something weird in there anyway let's keep coming down here Json Json Json does not mean that these are not vulnerable they're just not what I want to start with right now um here's another one that's being injected within JavaScript and it's a 200 response um oh but it's being injected in okay so again we're getting to some more complicated things um this also going in the user agent that's very interesting this could be a good option for uh if we have a webc poisoning you know imagine if we could control or inject some value into this Javascript file through this user agent and then this Javascript file is loaded for everybody that goes to the page as long as that cash is poison that could be a phenomenal way to get a very complex high impact uh client side injection um but a little bit too advanced for uh the scope of this this video here so let's keep going we're almost running out of room here come down come down um this is reflecting in the cookies that are being set so uh not a client side injection but we talked about this before we could potentially inject and Control Data into this cookie we need to see how that cookie is being used but if we can find a way to show impact with that that may be good um I'm just kind of scrolling and talking as I'm doing it and hoping that one's going to come up here if not I'm going to have to go out and look for one and come back click click click what about this one here that's similar we've seen that before in the Javascript file um this could potentially be an open redirect if we can control this but it's going with the Office 365 so not too interested there that's right that's the autodiscover um and here you can see some of the other uh values coming in here's an example of the suspicious input transformation right so they sent a couple URL encoded values and in the response it was decoded in this URL so that's giving us a little bit more insight maybe we could you know potentially weaponize that um but again just not enough value that I'm seeing not enough risk to really try and go after that um here's our get nickname which we've already tested before so it looks like we're not finding anything that's reflected wide open in the Dom which is going to be the best opportunity and if I don't see anything in these results I'm going to go out and find one so I can have it for the video let's say JavaScript most of these which and I mean this is pretty common right it's pretty rare to see our best case scenario where something is actually being reflected directly in the Dom here's a 400 different responses can sometimes help to um that's a Json that's a Json response this is in a graphql um so we're not going to see this render in here but this is an opportunity for a database injection that's another video for another day but yeah ultimately so we've gone through and run uh this against all these different end points that we found these are the ones I believe just in the JP as well oh no we've got the Singapore ones in there's too but um so we have run our custom scan against this and I'm not finding our optimal value so the best uh injection opportunity that I think we have is against this menu option right now but I'm going to pause the recording for a minute I'm going to go out and do some hunting myself and try to find an example of our optimal uh attack Vector within this program and either way we'll come back and then we can go ahead and start wrapping things up all right so I'm back um and unfortunately for us uh fortunately for Starbucks I was not able to find the uh optimal uh situ sitation where uh our payload is being reflected in the Dom where it's just wide open in the Dom um but that's pretty common right I'm only looking on unauthenticated routes and we'll spend some more time uh when we move into the authenticated routes in part two of this video um where we're looking for a hidden functionality hidden endpoints within the authenticated scope of the application it's going to be much more likely that we can find somewhere where the developers had a use case where they needed to take user controlled input and actually reflected in the Domino response that's typically a much more complex uh workflow um a need that would be within an authenticated version of an application there's not a lot of times where developers need to do that on unauthenticated routes so and remember just back to what we were talking about in the beginning it's going to be very difficult to actually find a reflected cross-site scripting or any type of client side injection on unauthenticated routes because they're thoroughly tested and they don't usually have a ton of functionality so in part two when we dig into the unauthentic the authenticated routes will have more opportunities but right now if we were able to find anything that was a good uh attack Vector we probably would have a much better likelihood of being able to uh exploit it and especially grow impact if it was something that hadn't been hadn't been found before but um a couple things I do want to point out that I found on other uh just kind of through the the process of uh testing here this would have been another great example of something we'd be looking for right it's wide open in the Dom it's not contained within an element not contained within an attribute now this is another uh 404 this is coming from Google this is not something we're going to want to test but I just want to show what uh we would be looking like and one other one that I found here what we' be looking for rather um so the first one was reflected directly in the HTML Dom and then this is a really cool uh other type of injection that I found where this is where you're you're uh not looking for uh cross-site scripting right because this is an application this is Javascript is coming back but it's a great opportunity for us to potentially get a JavaScript in ection a JavaScript code injection instead of this remember it's a completely different methodology for testing this we're not going to be trying to inject an element into here we're going to try to maybe inject an eval method into it instead right so I don't want to do a ton of testing here because this is not within our scope but I just wanted to show if I did see any user control input reflected directly in an application JavaScript response like this I'm going to think first of all8 out of 10 super excited definitely going to try and get get something here this is going to be top of my list compared to everything else that we found uh if it was in scope there but it's not going to be a cross-site scripting remember that this is going to be a JavaScript code injection we would come in here and we would try to inject so that this probably worked successfully and then at the end of that we would try to inject also whatever malicious JavaScript we wanted to and our hope would be that this Javascript file is loaded as part of the regular uh operations and we would be able to to execute that now delivering that to a victim it's going to be a very different uh very different process I'm almost certainly going to be looking for uh cash poisoning or some other way to deliver it because sending a URL is going to be hard right if we come back in here and look at that it's coming through the cookie once again hard to control it but at least if you were to see an easily controlled user controlled uh input right like if this was coming from a get parameter and coming into here oh we got a a great thing that we can get the opportunity to play with but okay it's been a long time this is a very very long long video I think that's good for part one um hopefully that covers everything I was hoping to to cover there but let's get this uh screens flipped up here and uh take a little bit of time to talk about what we've learned I want to summarize everything and I want to really lay out my methodology for for hunting for client side injection step by step and hopefully you'll have everything you need to uh to be able to go and hunt for client side injections on public programs so uh let's do that all right so super easy quick short uh short video right um I when I set out to to make this video I actually did think it was going to be like an hour hour and a half and as I kept you know kind of doing a little planning and digging into the program itself I real I got to add this I got to add this we got to talk about all these individual compensating controls we got to go through some of those different strategies that we can do to bypass the filters etc etc so um it kind of just kept growing and growing eventually I realized that this was put in into something that I'm actually uh I'm really proud of you know I think that this is actually a really good uh methodology at least for this first strategy I think there's this kind of puts all the information in one place um hopefully so uh I guess we'll see with the comments and everything but let me know if there's anything I missed and obviously we're going to continue with part two and part three with our other strategies here in just a bit but um anyway so just to go over the methodology one more time so when you're looking for CDE injections in public bug Bounty programs uh and remember our our first strategy which is what we walk through with this video is we're trying to find attack vectors in unauthenticated routes uh which will have a a greater impact if you're able to find an attack Vector that does work be able to actually get malicious JavaScript to to be injected because you can Target any victim they don't have to actually be logged in or have access to like an admin page or anything else right so remember we started by doing a lot of Recon and enumeration we started by running the the framework uh to go through and find as many different hidden subdomains that we can because we want to have a wide wide attack surface to try to find some of those hidden uh subdomains that maybe haven't been tested by other researchers because I I cannot say this enough 90 to 95% of the questions that I get from beginner researchers uh are about client side injection that's the reason I wanted to make this video and try and cover all of my bases um but what that means to you is that there are a lot of other researchers out there that are doing that same type of testing right and there's just a limited amount of vulnerabilities this is why I I try to focus on things like idors and access controls where there's more opportunities there there's more attack vectors and uh there's many or much less uh researchers that are actually going through and testing it but uh if you want to test for client side injections and it is a great thing to test for um you just kind of have to understand the strategy but so you're going to go through and do that Recon um once we had that we had identified some subdomains that we wanted to Target we then went in and tried to find as many unauthentic ticated end points that we could find remember we did some scanning we did some fuzzing but it it's enumeration right enumeration uh to try and find as many of those endpoints under those hidden subdomains we can find and possibly find an attack Vector um which is step three right step three we went and we were uh trying to identify anywhere within those unauthenticated routes that user controlled input would be sent to the application and then reflected in the response that's the only thing you're looking for when you for at least for strategy one everything we're talking about here this is not talking about Dom injections this is uh some type of client side injection where the request goes to the server comes back and the data that comes back from the server is what's appended to the dawn right that's what we're looking at so you want to find user controlled input uh you know it could be your path it could be parameters get post anything parameters it could be cookies anywhere where data is stored within that HTTP request that goes in the server the application May in some way take those user controlled inputs and reflect them back in the resp response which is later added to the Dom within the uh the victim's browser and the client browser that's what you're looking for once you find that you've got to try and find a way to determine whether or not the compensating controls are affecting it right and we went through all those different compensating controls remember the first thing you do or the first set of compensating controls give you an understanding of whether or not this is even worth your time right and that's going to be your cookie Flags your browser security headers and your content security policy if you go through those and they are all solid and you don't see way to actually weaponize this vulnerability then what's the point why are we even going to try and bypass these filters and everything it doesn't make any sense it's not a good use of our time we want to find something that if we do happen to get malicious JavaScript to execute we're going to be able to weaponize that in a way that allows us to show a lot of impact or at least any impact right um to be able to get a valid Bounty but ideally we can use that to steal a victim session token or force them to make request that they didn't intend to that's combining cross-site scripting or or any type of JavaScript injection with uh cross-site request forgy it's called a session riding attack uh where we can go and have them do things without them them even knowing right um if you go through those that first group of compensating controls then you find that it is worth your time remember the next thing that you're looking at is what compensating controls are in place to actually prevent you from getting that JavaScript to execute and that's going to be first of all is there a web application firewall on the end that's validating the request and specifically strings within the request looking for a potentially malicious payload within those strings if it is it's going to block it before your payload even getss to the application there's no chance that it's even going to be returned and reflected in the browser right um we're also going to look to see if there's any client side or server side validation client side validation that's not going to affect our ability to send the the request or do anything to actually get the JavaScript injection but it's going to give us some insight into what the developers intended to uh intended users not to be able to do right and then we can go into the server side validation and find out if that's been recreated because what the developer should be doing is putting layers and layers and layers and layers of Defense throughout the application so that in multiple different places we're going to confirm that that user controlled input is the right data type that we're looking for it's not it's the right size that we're looking for it's not an insane amount of characters we wouldn't expect and it doesn't have any malicious characters which is typically applicable uh mostly for client side injection uh techniques there and then the last thing that can prevent us remember and we saw this a lot is output en coding this is something that's very often uh combined with or misconstrued to be server side validation but it's not it's just the nature of way the application works and the encoding that happens through URLs as they're processed and how their later return to the Dom can actually be a very very powerful uh mitigation for client side injections but on the other side if we see developers that are only relying on the client side and output en coding and we're not seeing those same practices repeated throughout the application in the server that's where things can go wrong we can circumvent those client side controls and we can try and send a payload that will make it through the server be processed come all the way back to our uh client our browser rendered in the Dom executes we've got crossy scripting and then we can go and uh you know go and report that bug um couple things to remember where your payload is coming from and the request has a big impact on your ability to actually weaponize that if it's coming from a post uh in in the body of a post request and somebody has to actually send that themselves to get the uh to get the JavaScript to execute you're not going to be able to send that to a victim and have and actually weaponize that it's that's what's called a self-c crossy scripting I see those a lot with reports that are are coming into to my program flowcast um so very very important where the payload is coming from ideally you want to have something in a URL so that you can deliver it to your victim very very easily um the other thing you need to remember is where your pay Lo is reflected in the Dom has a huge hu in the response right in the response uh within the Dom has a huge huge impact on your ability to actually get that attack to work you know if it's reflected as we saw in uh uh HTML uh attributes then you're going to have to break out of that attribute to get some JavaScript to fire unless you can get some type of a data URL or something else to go in there which we're going to talk a lot about data URLs in our next video because there were definitely some options to Leverage data URLs and the testing we did in this video and I just made the conscious uh decision to uh to save it for the next one so um really important where your payload is coming from in the request really important where your payload is reflected in the response everything about that everything about the tech stack what the frontend library they're using to actually render it all of that has a direct impact on your ability to inject JavaScript into the client side so hopefully this video has showed that it is much more complex to try and get some type of client side injection than to Simply you know take payloads and and send them through there's no secret you know I think that's really the main message that I want to get off here there's nobody's holding on to some secret payloads I mean they may have some polyglots that are pretty effective that they're keeping in their back pocket or getting it but if you want to find if you want to focus on client side injection testing so that's cross reflected cross- site scripting Dom based cross site scripting client side prototype pollution um you know client side template injection which is actually a newer thing that's been coming out um any type of client side injection if you want to focus on it there's no shortcuts there's not there's and again I'm saying this because 955 probably percent of the questions I get are something along the lines of you know here I see I have this reflection how do I bypass this I can't answer those questions it's just not possible it's you know I I need to know everything about the Tex stack you need to spend the time going in there and and testing it for hours and hours and hours you can see how how much time I spent on this one um I can tell you cand about took me about a week Al together to get these uh probably going to end up being five hours recorded so um there's no shortcut there's shortcuts to other ones there's shortcuts to other vulnerabilities there's shortcuts to a lot of vulnerability server side request forgery things a lot of server side injections there's there's shortcuts um you know even I would say idors and access controls are pretty simple client side injections are not simple they're not simple and so that's why when I see beginners that are gravitating to that and they're getting frustrated say oh I can't seem to find a vulnerability where you're jumping into an expert topic and you're and you're not learning what needs to be learned to do that you know it's uh I think there's people that just want there to be like some secret output that you can put into every payload and it will magically get that JavaScript that alert to fire um it's just not it's not the way it works um but what that does mean to you right now if if you're watching this is if you do want to focus on client side injection techniques if what I showed you in this video was interesting if you've happened to pick up uh the JavaScript for hackers and you enjoy reading that if you enjoy client side injections and you really take the time to learn how client side JavaScript Works how it's used within different applications different text Stacks the different fronting libraries if you really put the time to go in and do that then you're going to be well ahead of the vast majority of researchers that are testing for client side injections and look 100% they're out there on public programs 100% it just is a matter of somebody really taking the time to go in to do the Recon do the enumeration do the fuzzing understand where the payloads coming from understand where the payloads going understand the compensating controls find exactly what types of things are being sanitize right remember all those different fuzzing that we did changing the characters around we'll talk we'll have a bunch more examples of those in the next video video as well cuz it's I mean I've got a list it's it's probably about that long and I can share it with everybody as well but um anyway I think that's good um if you've sat down and listened to this uh entire probably five hour video and you're here with me thank you um that's really amazing uh major kudos to you uh major Kudos um uh yeah I mean if you have any questions I didn't cover in here let me know part two uh I don't want to give a timeline on part two we got to see I'm going to jump back and do the idors and access control part three which I want to come out sometime here in early to mid January um but yeah we have to say this one kind of got away from me a little bit so anyway thank you so much um arson framework Alpha 002 is out now remember you can down or uh Import and Export the scan data so you can go in and start testing on exactly what I have there I'm going to start getting some fresh data out in that GitHub repo sometime soon too um what else uh Discord server if you want to get on the Discord server you want to go do any uh you know hop into the live stream and and interact with us there or go and interact with the community if you need any help with the framework you want a group of people to do bug bounty hunting with that's all going on in the Discord server definitely uh jump in and join us there um I think it's about it my methodology is still available at arson security.com methodology that's arzin security.com back methodology you can see that there um other than that yeah hope to see you soon hope it was helpful cheers