Manual Hacking FULL GUIDE | Bug Bounty Explained transcript

From a highle perspective, there are essentially only two ways to make money from bug bounty. One of them is automation hacking and the other is manual hacking. I and many other bug bounty hunters choose to focus primarily on manual hacking for a number of reasons. One of them is that it requires less initial investment to actually get started. So you need to invest less of your own money in order to actually start making money from bug bounty.

The second reason is it often leads to higher severity vulnerabilities. So more in the high to critical category. Well, not always, but a lot of automation hacking tends to look for more medium type vulnerabilities which don't really have a lot of attack chains or anything like this. And the final reason is that honestly I just find it funner. I just find it more interesting to manually look at an application instead of build some like bot that's going to do it for me.

Those are the main reasons that I focus on manual hacking. And in this video, I've collected three other videos on my channel that talk about manual hacking and are hopefully going to help you get started in it. Now, before you click off thinking that this is just a repost of videos that I made before, I've added some additional commentary to the videos of things that I've just learned about manual hacking, some new tools that I found or some new techniques that I've discovered.

But even if you've actually watched these videos before, I think it's worth going over them and watching them again. This is a pretty funny AI generated picture generated by me by Chad GPD. Thank you very much. And you can see here have a bit of ground. And if you imagine, just use your imagination that the ground here is the target that you're hacking on. It's like all the attack surface. It's like all the possible things you can find, all the features, like every button, like every source code, like all the domains, just all that is this ground, right?

And we start from the surface. We don't we don't know anything. We don't have any recon. We don't have any reconnaissance. Someone's underground. Right. This this diamond here is going to be our vulnerability. It's hidden somewhere in like a feature or something like that. There's like some kind of parameter that's going to allow us to exploit some kind of vulnerability. That's great. There's diamond here and we're trying to find that diamond.

Basically, if I was hunting for this diamond, there's two ways you can do it, right? If you think about it, you could either start excavating this like top surface on the ground here and hope that the diamond is somewhere like near the surface. It's like surface level, right? So you excavate like a wide area of ground and and you check if the diamond's there, right? And the second way to do it is to just like start drilling deep.

Like you think that diamonds are like bedrock level or something and you basically get like a drill and start going all the way down like and then hopefully you find the diamond somewhere deep underground where other people aren't looking. So that's basic oops that's basically the two ways that we can approach any target. We can attack a wide surface area. So we can attack a load of subdomains like a load of end points.

We can have a load of scanners set up. You can have automated stuff like this and hope that the vulnerability is surface level. It's a vulnerability that doesn't require a lot of human thinking. It just requires like machines to go in and like find stuff like that using subdomains. The other approach is the deeper approach. You hope that one area of ground that that one particular area if you go deep enough into it, you'll find some kind of vulnerability.

So you're praying that this that the diamond just happens to be on the column that you're digging at. And hopefully if you go deep enough you'll find and hopefully it's not a massive waste of time. Right? That's kind of the two approaches that you can take. The best approach is kind of a combination of both. You don't want to just spend your time going into like one feature of of a program. But you also don't want to just go completely surface level because the diamonds at the surface are always going to be kind of smaller as well.

You know like deeper you go in the bigger the diamonds are going to be. So if you kind of imagine that analogy hunting a program, you [snorts] want to dig deep enough that you kind of have these bigger diamonds here. But if you spend too much time on one feature, then you might be limiting yourself. You might be going too far. Maybe it's time to check another area and go a bit wider. Right? That's kind of the mentality I want you to have.

So when you're going wide, there's a couple of things that you can do, right? So the main thing is finding subdomain. So enumerating subdomains and basically trying to find more attack area. Another thing is scanning, automated scanning. That's trying to like deep a little bit surface level trying to get like some easy like XSS vulnerability or something. So unless you're running like a custom template, you're probably going to dup to be honest.

But unless you also find a lot of sub doains, you can find a lot of sub domains then you can maybe find some some dup. So something like nuclei here like a nuclear template on your tag and trying to find something. And then just general forcing a kind of general for not like it's not specific, right? So if you're like specifically fuzzing for like a parameter that's different. But if you're fuzzing like a subdomain that you know nothing about and you're just trying to find some like exposed like environment file then that's what I would call wide.

So you're just trying to find like a specific kind of endpoint on a domain on a subdomain and you're just seeing if it's there so you get that quick vulnerability. Right. So that's kind of wide. And then deep is when you're actually going into the features you're actually understanding the application. Right? So you're trying to enumerate the features. You're trying to find parameters. So there's actually elements to fuzzing when you're going deep as well.

It's not just like just there like you're just thinking about something. You also kind of want to do discovery, right? So you want to find parameters. You want to try and test out like new feature maybe like fuzz headers as well. Those kind of things will help you get a general understanding of the application and source code analysis which is another thing. Mostly I'm talking about JavaScript here. So JavaScript analysis.

But if this is an whitebox test, then maybe actually reading the source code is going to actually be possible. Or if this is an open- source tool, then you can actually read the source code as well and get an understanding of that. So I'm going to mostly be going into the deep side today because I think the wide side is already fairly well covered by a lot of tutorials, but I think this deep side actually is a little bit still unexplored for a lot of people because it requires a bit of thinking, requires a bit of target specific knowledge.

Well, I feel like the deep side actually is made a lot easier by AI. And I'm going to show you how I use AI to basically dig deep into a target and without having to use a lot of my own brain. But now I'm going to hop into a live example. I'm going to show you how I would do recon on hacker one with some of these deep tactics. So this is hacker one. Probably not a new site to most of you. So you're probably used to this program.

First recon I would definitely do is just to actually get used to using the the platform. So, I would spend one or two days just using this application and figuring out how to actually use them. If you followed my guide where you choose a target that you already used before, then you can skip that step. But if this is a completely new thing, then you should spend some time getting used to how the application works and what it even is.

And that's the first bit of recut I would do. The second thing [clears throat] which I think a lot of book bounty hunters don't actually do is to deploy some kind of reax. So reax regular expressions is something that basically will match some kind of terms in a bit of text and context of a website we're going to mostly be looking at JavaScript and obviously HTML as well but mostly JavaScript right. So, there's this tool created by another hacker called Linkfinder that's kind of nice to use and you can create some offshoot reaxes from that that I'll show you in a minute.

First of all, I'm going to show you the actual code for this. So, the code is here. I've edited it slightly just to suit my needs, but you can probably get the unedited version sometimes. And the goal here is that this what this will do is this will just find links on the website and then it'll return it to us. So I'll just show it to you what it looks like for now. So I open up the bookmark and I'll run linkfinder and this will just grab grab all like the endpoints on the website.

And why we want to do this? Well, this is useful to find APIs, find unused API calls, just generally get an understanding of the features and then find other links like internal links potentially on JavaScript as well, which is all very useful. thing is a lot of people are running this tool already though and definitely on something like hacker one a very popular program you can see that probably most people have already discovered a lot of these endpoints what we want to do is try and design our custom tools tools that other people aren't going to be running at the moment that's the ideal goal of rejax right so see I have my own custom tools designed here and I'm going to show you exactly how you can do the same thing right so with this JavaScript here what we need to do is just edit the reax so just So it will return the data in the same format but will give us a different type of result and this is right here.

We want to edit this right here. Right? So this is all the redex that we want to edit. And I'm just going to I'll link this in the description for you. Actually there'll be link in the description hopefully if I don't forget. But we want to place our template in here basically. And how do we design templates? Well best way to do it would be to know reax and then go in and make it yourself. I don't do that though because Red X is kind of complicated especially on minified JavaScript.

So we can consult our best friend here. Consult our best friend Chajb to try and design us a reax here. So how would I go about doing this? The ideal way is to try and design it yourself first and then get Chad to improve it. But I'm not even going to be bothered with that either. I'm just going to go type in here. I'm going to say uh design reax for me. that will, let's just say I want to try and find all the strings on this web page.

It's kind of random, right? That will find all the strings from minified JavaScript. I don't know why you would want to do this, but just to give you an example, you can find anything. You could maybe find like path traversals or something like that and all the that will extract extract all the strings from minifi JavaScript. Now, an important thing to do is to tell Charg to think because if you use just the default fast version, it'll probably give you reax.

We want it to think and actually give us some code reax. So, we go in here and let's just see what it gives us. We'll say design some reax for me. It'll hopefully think for a moment. And while I do that, I'll just bring back the code. And we're just going to inject it in here right when gives it to us. And then we're going to create a new bookmark, right? Seems like we've gotten some reax here. Let's see if it works.

Sometimes tragic PT will make a mistake in terms of reax. So you might have to tweak it a little bit and tweak tweak it, but we're going to just test it out first. We're going to paste the reax into the It's already given us the brackets here. So we're going to copy paste this. Now with the new reax, we're going to go here and we're going to say add a bookmark. We're going to say like string finder. That's usually what I call this.

And then we're just going to copy paste this into it. We've saved it there. Now let's run string fightinder. Let's see what string finder returns to us. So give it a few seconds there. And there you go. It seems like it's actually returned all the strings to us. Wow. You see? And now we have Oh, [laughter] okay. Some of that is very long. Sometimes, especially with minifi JavaScript, the kind of results you get might be a bit dodgy.

You might get some garbage, but on the off, but most of the results seem to be accurate here. We managed to get all the actual strings here. So now we can uh basically look for stuff here if you wanted to. Like you see, we have device width. We could basically copy them. And now what you want to do when you have this result actually is you want to go into the source code into the debugger want to search and actually locate that.

One of the really cool tools that I've actually discovered recently especially useful for JavaScript analysis is called JX Scout. And what this will basically do is it will download JavaScript files that are being loaded by your browser onto a Visual Studio folder and then you can access it from Visual Studio using an extension. And if you're running Reax the way I recommend in this video and then looking at it through the Chrome or Firefox dev tools, it's not really going to be that great.

And the reason is because the dev tools are absolute are pretty terrible at actually looking and analyzing JavaScript. What is ideal is using something like Visual Studio which is going to format the code for us. It's going to actually beautify it and then it's going to load source map source maps for us as well. And JX Scout is actually going to help us to do that. So what I would actually recommend is instead of running the reax and trying to find it inside of, you know, the what's it called the dev tools, I would actually run it and then try and find the feature inside Visual Studio instead from a JavaScript file that I've loaded in before.

And I would even go as far as to say that you can even run the reax in Visual Studio itself. Visual Studio lets you run reax as well on a number of different files. And the reason I think this is great is because when you run a JavaScript bookmark, you run it only on one aspect of the website, right, on one page. But if you run it on Visual Studio with all the JavaScript files downloaded, let's say you were just navigating to the website and you just downloaded all the JavaScript files in the background, then you can run it on all the web all the pages simultaneously, right?

So you can get all the results for it. And this is important because a lot of websites use Webpack. They use chunks to break down the website into a number of different components. So instead of sending one user the entire website from JavaScript, a lot of companies say that this is not safe anymore and they use Webpack to split the website into chunks. So what I will do is I would use Visual Studio Code to actually use Reax to search the entire website and then try and find it in the code and look at not the minified JavaScript but actual prettier looking JavaScript, right?

Maybe they show like an example of it. Yeah. So this is what it looks like, right? So in instead of having that like garbage minified stuff, you get it like nicely loaded in. You get it, you know, formatted and sorted for you, right? This is usually what it's going to look like. The variable names are still going to be not useful at all. However, it is going to at least be formatted for you and it's going to be like highlighted and stuff like that.

And then you're going to get this thing on your right which is also going to show you some stuff that you might be interested in to look for client side vulnerabilities. So this is what a tool that I would recommend to use instead of using the regular dev tools to actually look at the JavaScript code. I do still see value in using the JavaScript bookmarklets just because when you run the reax on Visual Studio Code, you're going to get a lot of results back and sometimes it can be a little bit overwhelming and sometimes I just prefer to look at one one page instead of like hundreds of different results.

I prefer to just see a few different endpoints that are going to be relevant to the feature that I'm actually looking at at the moment. That's also something to consider. I would keep using the bookmark list, but I would switch to using Visual Studio Code for your actual JavaScript code analysis. Actually, locate that somewhere on the web page, right? Hopefully, it's somewhere here. [snorts] Maybe like with device or something.

Okay, I don't know why that's not finding. Okay, I'm not sure why that's not finding, but what would you do? What you would do is just go in there. Maybe let's try something that's like UTF8, let's say. table search. Okay, there you go. For example, UTFA. You go here, you find where the source is, then you start reading the JavaScript. Fortunately, this is minified. Most programs will use minified JavaScript because it just takes up less memory.

But you can still read it. You can definitely get used to reading minified JavaScript. It's just a bit of skill that you have to build up. But then you can try and search for vulnerabilities like that. That's one of the major bits of recon you can do. And you can see here that let's go back to this opportunities page here. You can see my bookmarks. I have a GraphQL query finder. This will basically return all the GraphQL queries from here.

I have a don't even know what this does. I think this returns all this returns any string concatenations. So in JavaScript, you can basically do like a thing where you have a template literal and maybe I'll run this. Yeah, sorry. This template literal fin. Yeah, that's what it is. This finds all the template literal strings. So basically where variables have been injected into strings. This just helps me find client side path traversal vulnerabilities.

So maybe you could go in and try and test all this for path traversal vulnerabilities. And then the last thing is client side path traversal finder. It does something similar as the one on top, but this basically finds wherever strings are added together with a plus. So this will tell me where two strings are added just directly with an actual like string concatenation. So without using template literal but just using the pure concatenation.

And yeah that's the tools that I run these custom tools and I think they've really helped me stand out from the crowd in terms of finding recon and finding data. So that's one of the bigger things I want you to do. By the way, no pressure but I have some links in the description which are to my labs. So, these are hands-on practical labs that I've designed. If you know my videos, I always use a live example to demonstrate the concepts because I really believe in practical knowledge over a kind of PowerPoint or something like that.

Especially in book bounty, you have to do do things. You have to actually do things yourself to actually get the idea and find the vulnerability on real applications. It's why I believe in labs as well. I've designed my own labs based on usually vulnerabilities I've found myself or vulnerabilities that were found by other book bounty hunters that I've replicated in the labs. They're really valuable. They're all online.

You don't have to download anything. They're basically in the same format as my usual labs where you just go on a website and then you start hacking it basically. And it's just more created. It's kind of more professional instead of the usual like you know kind of the patch of labs that I usually deliver on the YouTube channel. So if you're interested in that then link in the description but no pressure on. Okay. So I ran my reax.

I have my all my GraphQL queries. Now there's a lot of these GraphQL queries though and reading them would take absolute decades. You can see how do I sort out the actual kind of useless GraphQL queries when the ones that we actually want to look at and what we can use again is AI. So watch this. This is this is one of the is one of these cool things that I think I actually found which is you come in here you save the actual web page as a HTML page.

You save it here. You go into Chad GBT right and you say I'm I'm testing my website for vulnerabilities. These are all the GraphQL queries on my website. What vulnerability should I test for? If you're looking to integrate more AI into your workflow as a manual hacker, then I honestly think that at this point this is a must for you, which is Shift agents or some kind of agentic AI testing system. What shift does is instead of just telling you things that you should look for, what it will actually do is it will go and test it itself.

Right? So if you click this agent tab here, you can say test this endpoint for cross-ite scripting and it's going to go and actually try all the payloads for yourself. And what you can then do is you can store your prompts here. You can use different models as well. You can store like prompts. You can like add another prompt. You can add prompts for different vulnerab. So maybe I'll say like this is like race condition or whatever.

I can find like a prompt for race condition and I can say like send this request in parallel or whatever. Burpuite has something similar with with burp AI which is something that I also recommend using but I have really enjoyed using shift agents for a while. Just using chat GPT is okay. Listen you can go and ask chat GPT what should I test for? But this is really like the new meta at the moment. is basically just putting this into like AI that's actually going to do some of the work for you.

Because although Chad GPD can generate a lot of payloads for you, it's nice to have an AI that's going to test individual payloads and then iterate on it itself, which is going to be super nice. In terms of creating something like reax patterns or whatever, you can actually like feed a request into the AI. So you can say like generate a match and replace or turn on this feature. And in this case, what is going to happen is that it's actually going to receive the entire request.

So if you want to have context, you want to give the AI context based on some kind of request, this is also really nice to do. And those if you're looking to integrate Chptd into your manual recall or like manual hacking stuff, I think this is also great and it can also help to find some leads. Now, obviously, this isn't going to hack everything for you. You're not just going to be able to say, you know, start hacking this website or whatever, and it's going to find you a lot of vulnerabilities.

What this is going to be helpful for is whenever you have a situation where you suspect there's a vulnerability, but you're not quite sure how to exploit it, or you need to try a lot of different payloads, then this is really going to be great. And obviously, it's just going to also save you some time by creating your match and replacements or whatever. And it's really honestly not that expensive. I put about $40 into my like uh what's it called?

Um like worth of credits into the provider and I've used about like 30 cents of it over like two weeks. So really, it's not expensive at all and it's also really useful. So if you're looking to integrate AI into your workflow, then this is where it's at. And what GGBT will do is using the file I give it, it will suggest things I can find. So vulnerabilities I can find from those requests. And this is good because most people are going to try and sort it by hand.

But we're going to use AI to identify the highest priority requests that we need to look at. And it's going to suggest that basically just a pattern recognition, right? And most of the time the things that it will suggest will be the highest priority. So instead of wasting our time on some like random like you know change profile picture request that's not really going to have an effect right [clears throat] we're going to focus on the requests so the API endpoints that are going to give us the real value and that's what I want what I want you to you to actually focus on you can do this with all of your reax with the link finder you can do it as well you can pipe straight into jbd and ask it for vulnerabilities to find this I think works the best with something like graphql though but it can also work with the client side patch traversal and you can find it works with anything that you design yourself based on the program and experiences that you have personally built up.

I've just asked HGP to basically read this file now and this is what it's saying. So we look for broken access control privilege escalation looking for private objects and then it's basically giving me the query and telling me to basically try and look for some kind of privilege escalation. I have mutation authorization bypass. So basically looking for mutations seeing if we can do basically same kind of broken access control or injecting some kind of uh introspection exposure maybe try introspection that's another thing you can use or for example injection so into string markdown or LLM prompt see it's identified everything from the actual content and the ideal thing you can actually do is you can modify this prompt I've just done this prompt as an example but really I would build up a much more complicated prompt so for example will say give me like ready to go curl request that I can just straight away fire in like and you can do something like that.

You can do you can ask it to give examples from the actual document. I just haven't. But it's just it's giving me some examples anyway. But if you want specific like you don't want kind of waffle, you can give it you tell it to give specific examples and injection DOS file attachments. Yeah, you can go straight testing all of these things. And I think the most time-saving way that you can start testing the endpoints is by just piping the information directly into AI.

You can even try Claude. Although I think Chajbd is actually better for hacking because Claude is a bit and it doesn't like want to give you uh vulnerabilities. So I really prefer using charg but you can definitely try out the other AIS as well. And yeah, that's really what you want to do once you have your read to reax you want to pipe it into AI and then you want to basically examine those vulnerabilities. So that's where the real hacking begins.

This is this is where recon ends and then the real hacking begins now where we're testing actual vulnerabilities now. So this is all our recon done now. So, what else can we do for recon? Well, some people also like using the wayback machine. The wayback machine allows you to see old versions of the website. So, we could allow you to see old API endpoints. So, if we go like, let's say hacker one here, we'd go in, we'd find hacker one.

We find hacker one as well. And we'd say we find like um we go back like three years in time, see what the API endpoints look like now and then test them again. Maybe pipe them into charges between the current API endpoints and the old a and the new API end sorry we can find differences between the new API endpoints and the old API endpoints. Once again we can probably use AI for that because it's just a timeconuming task but it's something that you can use.

Guess this is loaded up. You can go like researchers opportunities. Maybe we can go back in time to like 2023. This might not load up though because since this is an old old um endpoint and it's using older APIs, it might not work with the new API. So it might just like the API endpoints probably won't work. But even if the API doesn't work, note that the JavaScript is still there. Right? If you see this spinning wheel, that means the JavaScript loaded, that means there's nothing stopping us from going here, running our GraphQL query finder, and just doing basically the same thing as we did before, right?

So, finding this, piping it into CHP, and then comparing it with the results that we found here. So, that's not stopping us at all. That's one way you can use the wayback machine. You can also use it to find secrets, hardcoded secrets. companies sometimes put like API keys into JavaScript by mistake. That's you can do can do a bit of recon on them. But the main thing is to identify older API endpoints. The last bit of recon that I usually end up doing is just actually reading the documentation that the website gives us.

So if you just Google API oops hacker one going to go here and it's going to give us some kind of documentation. Nowadays almost every platform will have some kind of documentation whether it's hacker one deliveroo or I don't know US department of intelligence they'll going to have like API documentations now just because most websites use integrations and stuff like that it's just better for the internet that way and with documentation it's going to give us a lot of intelligence on what the api endpoints are for instead of doing like random parameter fuzzing most of the time you can just go here go into like resources something like that and you can just like find API endpoint here and it's just going to give you the like the the parameters that are accepted.

Now that doesn't mean that more parameters actually aren't accepted, right? So if this API endpoint like this API documentation tells us that these parameters are accepted than they probably will be, but that doesn't mean that there's not more accepted. Sometimes companies will allow more parameters in like by accident maybe, which is going to lead to vulnerabilities. So that's where something like parameter mining is going to come in.

But normally this is going to just make our life easier because it's going to tell us how we can actually use the API endpoint with the curl. So instead of getting tragic to do this, we can just go here and use it ourselves. Usually it's going to require some kind of API token which you can get from logging into the platform. It shouldn't be too hard. And with that you can test like all of these API endpoints. You can actually pipe this into charging PSL if you want to and you can ask which of these will be the best to test out and stuff like web hooks. you know there's a decent bit of vulnerabilities and things like this.

Um what else we have like use cases sometimes like resources you can obviously get like privilege escalations ID doors are a big thing here if you have someone like uploading files which maybe it's somewhere here like assets yeah importing files uploading files and you can start having like S3 misconfigurations which I've talked about previously in the channels there's a lot of really great vulnerabilities that you can look for in these API documentations that's why I always take a look at this because it can give me a sense of where I should go next, what vulnerabilities I should attack, and which vulnerabilities I can attack that actually suit my hacking style as well.

So, that's really good. And yeah, I think that's most of the recon that I do. It's just going to run down to running the reax, running it with GPT, getting some idea of where to go next, getting some features to test on, [music] and then reading the API documentation to basically try and find out what I should do. Sometimes what will actually happen here is that in the API documentation there'll be an AI as well. So sometimes you can actually ask the AI like what whether there's like a parameter somewhere if you want to ask it like can I do something then you can do that.

So I can clarify some things for you to help you find like business logic error vulnerabilities which they're not like technical vulnerabilities but they're kind of like assumptions that developers made the kind of cool vulnerabilities. Right. So, here I have my demo example, and this is just a very simple blog website that I may or may not have stolen off the internet, but we're just going to use it. I've coded in a few vulnerabilities here, so we should be able to have a look at them, and you can actually follow along with this.

Uh there's the link for this should be in the description. The website is up on a public domain, so you should have no problem accessing this. It's built in ExpressJS, so nothing really crazy there. So I really encourage you to follow along actually and try and find these vulnerabilities yourself. And if you get stuck then you can watch this video later. So what the feature centric approach centers around is trying to identify smaller components before we dive into actually testing these massive features.

So once you've picked a subdomain that you consider to be a valid target like this uh app.jacob Jacob Jen uh book bounty domain. Then we're going to hop in and start identifying features here that we can test on. So most websites actually have a lot more features than people think. So if you look at this login feature, then that's going to be a feature by itself, but so is the registration feature, right? And each of those is going to have a different flow to it.

And each of them can have very serious vulnerabilities. So we shouldn't we shouldn't uh discount any features like for example signing up because if we sign up then we might be able to override other users or access your details as well. So every feature is worth looking at and the features that are often most overlooked actually sometimes carry the most critical vulnerabilities. So definitely it's worth analyzing all of them extensively and the way we're going to do that is using a HTTP proxy.

So hopefully you have one which is either going to be Burpuite or Kaido. And if you don't have one then I've made a video about how to set them up. So go watch that or any of the other tutorials online. But before we actually start hacking or actually looking at any of the features, we want to actually set up a few accounts because to actually to actually unlock some of the features, you'll need to go a few extra steps.

So the number one step is obviously just going to be registering to the website and actually creating an account. And what I like to do is actually create two at the same time so I can test things like idors and privilege escalation. So I have something here called uh I think this is called Firefox containers something like that. But basically uh I can just hop in here and I can basically open up two containers and this is going to separate my cookies on each of these uh platforms which means that I can have two different accounts open.

If you're going to lean very heavily into testing authorization, so things like idors and broken access control, I would definitely recommend you to get a plugin to actually test this for you passively. And this is just going to speed up your process a lot rather than having to go in and change the cookies every time. You can just kind of passively use the app while testing for things like doors. And the way you're going to do that is I've just done this on Kaido, but there's also a really similar plugin on BYU, which basically does the same thing.

You're going to like see how the application authorizes each user. And then you're just going to come in here. You're going to like add a cookie say you're going to have one user which is going to be like your admin user. have one user who's which is going to be like your say your like um normal user. Okay, that was supposed to be a hookie or whatever. And then you're going to come in here. You're going to turn on your passive scanning.

And then as you're using the application, the authorized plugin is going to be actually testing the things for you. And it's it's going to be doing this for API requests as well as can get a little bit annoying and there's a lot of configuration for this. You're going to want to probably not have this running for every single endpoint. But this can also speed up your process a lot. And I do recommend using plugins for something like this.

I'm not a really like aggressive idler hunter or I don't really specialize in that area. So I don't really use a lot of these plugins myself. However, if you are going to do that, if you're a beginner and it's one of the only things that you can really look for, then I would recommend at least getting a plug-in for this, right? It's just going to save you a lot of work. And in the end, that that's going to help you find idors that other people are missing just because if other people are wasting time doing stuff like this, then you might as well not be and then you're going to find more books, right?

If you're going to lean into doing like the two user thing like having the user and the admin and you're going to test like every feature for an idor and you're going to go over and make like your Excel spreadsheet then at least for the love of god have this plugin actually helping you out as well. There's one more in kaid though I know that allows you to quickly switch between your users inside actual request which could be very handy as well.

Honestly, that that's probably even useful if you're not doing the all the like what's it called the idler stuff I think. Yeah, this is called autoify which is going to basically put like two buttons on like your request page. Like here you have like a request page. It's going to add two buttons here to switch between your user and admin and it's going to let you do that very seamlessly. But honestly, that's probably worth getting as well.

I don't happen to be using that one at the moment. But yeah, do use plugins to make your life easier, please, because then you're going to be finding more idors. I think this also works as an extension in Burpsweet where you can have like your requests colored, which is pretty nice. So, I'm just going to create those two accounts now. And maybe make that password a little bit simpler. Like so. sample I will say again to Gmail 2 3 4.5 6 already registered apparent five sure [laughter] okay we have two accounts now set up see that we've immediately unlocked a lot more features so if I was to kind of write down everything that I can test on this website what I would say is we can probably test this profile, check the email.

We can test these blogs here. We can test creating a new blog. We can test this log out feature to see if the session cook gets removed. We can test signing up to see if if we can sign up as an existing user or uh potentially like a pre-account takeover and test obviously logging in. So, there's a lot to test on this website and instead of looking at them at once, we're going to analyze them individually. So starting off with creating this blog, right?

So different features will probably have different vulnerabilities associated with associated with them. So like a web hook feature might associated with something like SSRF while creating something like using an API might have more like door type vulnerabilities. So the way I would start doing this is to basically just use the website normally but include some payloads in here. So including payloads like uh XSS is a big one and then another one is something like serverside template injection which is less seen nowadays to be honest.

So I would probably focus on the uh cross-ite scripting payloads and what I would always do is try and get the workflow. So features can have more than one request and they often have more than one. For example, signing up might be like uh basically sending a request to an authorization domain. That authorization domain might send a request back like a single sign on feature. So there's a there's uh there's different um there's many HTTP requests that can be looked at.

And when we're looking at features, we're going to look at all of them together. So I'm just going to send this create the block thing to the uh HTTP request. And I think in this case, it's just going to be one request. Yeah, it's going to be run request. So that's basically going to be the feature that we're going to look at right now. It's just going to be creating the blog and seeing what happens. So we've included our payload.

You can see this creator ID here. So that potentially will point to an IDORM. We also want to have a look at for CSRF in this case. Uh it's a JSON response type and it doesn't seem like there's headers. So I don't think we'll be able to execute a CSRF here either. And in terms of authorization, we have a JWT token which is normally fairly secure as well. So I think the main two vulnerabilities that we want to test for in this feature is going to be to look for the door which we're going to test for in a minute and cross- site scripting.

So let's see if anything fired. And I think we managed to get a HTML injection here. Yeah. So it seemed like we were able to inject the HTML tag here. So that's good. Now, as well as that, I want to test for the IDOR. So the way I would do that is on my second account, I would come here and I would basically try and create a blog as well here. Oops, I didn't mean to do that. Okay, let's go a new blog. Let's go blog title.

And then I want to do this and we'll say something five. Submit it. And then I would just copy this it here. Can even forward that actually. So if we for example insert that here and then just call it like um ID door. So see like it went through correctly. And if we stop intercepting there we have ID door. And I think I I was doing that on this account, was I? I'm a bit lost now. What does the JWT say? So now I kind of want to properly test for this door.

So hopefully we're going to keep track of which user IDs are actually the correct ones this time. So we'll go like that. I'm just going to delete all of these and we're going to keep this on the blue profile. So we're going to keep this request on the blue profile which has this email and we're going to see if we can make an id door to have the blog created on a different email than our own. So we'll just say I door say like 1 2 3 1 2 3 submit it.

And we'll send that in again here. So that's the blue icon there. And we'll do the same thing on this side. So we'll go new blog. We'll go intercept to here and then we'll say something like test one two three one two three and then we submit it as well and then we'll just copy through uh this here and then we'll just drop it right there. Now we're going to test for this id door. We're going to see if we can create one there on a different profile.

And if we go here we see that I door has popped up. So we just cancel the request and yeah it's been created on the other profile. So we have an id door where we can uh create a blog for a different person and then we also have cross-ite scripting it seems. So that's good. So from that feature we managed to extract two vulnerabilities. You can see I've looked at this feature individually right. So I've looked at this just one HTTP request and I've considered several vulnerability types.

I'm not just looking for one vulnerability type, right? I'm not just looking for an IDOR. What I'm doing is I'm analyzing the feature and I'm considering different vulnerabilities that might arise from it. I think some people say that you should just focus on one vulnerability. I'm not really an advocate of that actually. I think you should focus on specific features that you've tested before because when you do that, you'll be able to see the patterns and see the mistakes that developers do and pick them out more frequently.

Could say the same thing for something like an IT door. But I think because websites are so different and an IDOR could literally be like anything. It could be a vulnerability in like any system. So I think looking at these features will actually develop your patterns faster than just looking for specific vulnerability types. So that's what we've done from the blog request feature, right? So creating a blog, that's the first feature that I wanted to analyze.

And the second feature, for example, let's say, is editing our profile. So same thing here, we're going to stop this here. We're going to say, example, testing whether or not we can uh change someone else's email, for example. That's something that could arise from these vulnerabilities. Um, sometimes you might be able to bypass something called email verification where you'll get like a code in your email or something like that.

You might be able to bypass um, basically having to give that code and you can basically say your email to whatever you want to, which in some websites is a very severe vulnerability. So, we're just going to have a look at what this request for this feature looks like. So, we've done here. I'm going to send it to the repeater as always. So, send it here. And what can we say about this request? Well, it's in uh URL mode.

So, it's URL encoded. Um potentially CSRF, but it does have the password here. So, I don't think we'll be able to execute a CSRF just because the password is here. Unless you can get rid of the password, it still works, which we'll test in a minute. So the cookies are as normal. Uh there's no particularly interesting headers on the other side. And it seems like this is the only request for this feature because it's just redirecting us to profile after this.

So what could we test for here? We could test for something like email validation. Maybe we can try a race condition as well. So has this actually made a change to my name? It seems like it actually has. So, wonder if we can do something like this. Maybe if we try and change the same email. Does that work? It doesn't appear to have really done anything. Maybe we can like uh not include the password in here and change the email to something else like this.

But did this work? Wonder. Okay. Did not seem to have worked either. So, I don't think we'll be able to change another user's password because um we'd have to know what their what their so we wouldn't be able to change their email because we don't really know what their password is. So, unless we were able to like um basically like use our own password and then change their email like that. But I do not think that's going to happen either.

We can give it a try though. Maybe we'll say something like this. say password is like one or something. We'll change the email to email that we know and then we'll refresh it here and go to profile and that doesn't seem to have worked. This feature seems fairly secure because it requires your password although it is being transmitted in plain text. So, it's dubious whether or not that's actually safe. But, uh, yeah, that's basically the feature there.

And it doesn't seem like there's anything and I think I've considered all the possibilities here. So, sometimes this will happen where you're going to be testing a feature and you're just going to find nothing because the feature is fairly secure. It's not like a book bounty lab. You know, not everything's going to be vulnerable. And in this case, I don't think this is vulnerable. It's not really giving me any indication of that.

But that's okay because we're going to go back to our feature ccentric methodology. So we finished testing this feature. Haven't found any vulnerabilities. That's okay. Maybe we'll just move on to another feature. Right. So we've found these features here. We've been able to create blogs. We seem that there's XSS there. There's an id there. Um what else? So we've tried creating a new blog. We went to the profile here.

Um, let's maybe have a look at trying to sign out of this or log out. What does that request look like? So, we just send a request here. And it seems like all it does is just set our cookie to nothing. Does it invalidate the cookie? I wonder like am I still able to use it here? Uh, for example, if we were to go back here and then I imagine yes, because this is a JWT token. So, normally you're able to use them even after even after they're used, but we can just check that here.

So, if we It seems like we logged back in. So, potentially sessions aren't being invalidated correctly. And this JWT usually has an expiration token. So, we'll have a look here. Yeah, it seems like it it'll expire here. Like this is Unix time. So, we could test if it actually expires or not. possibly could just wait for this time to happen and then see if it expires. That's could be another vulnerability logout feature as well.

But apart from that, I'm not seeing any um any other vulnerabilities in the logout feature. It seems like that's fairly secure. So, what's left for us now? Well, now all that's left is to test it login and registration feature. I think I'm going to leave that to you, though. I'm going might add a few more features here when you're testing it. So, I'll probably probably uh make this website a bit more advanced like comments and stuff like that so you can test on it.

But before I go, I just want to say that I actually have bulk bounty labs in the description. They're kind of like this style like what I'm showing you right now. It's where you can go in and uh basically try out to find bugs yourself. And I include solutions in the descriptions. So yeah, if you want to get more of the practical side in, then that's a really good option for you. Here I'm just talking about the theory.

Of course, you're not really actually doing anything unless you're obviously going to the website here and you're testing yourself. But if you're just watching, you're not actually getting like the practical side in. And I think my book bounty labs are actually great for that because they'll give you the skills necessary to actually find these problems yourself. All right, no PowerPoint today. We're just going to go straight into a bit of Visual Studio, the way it's supposed to be.

If you haven't watched my video on understanding HTML, then please watch it. you'll be completely confused if you don't know how to read HTML cuz JavaScript is kind of the next step up. And anyway, what the hell is client side JavaScript? Client side JavaScript when people refer to it means that it's being executed inside the browser. So here it's being executed on the user's computer and it's not being executed on the server.

Right? Nowadays there's JavaScript frameworks which work all which work on the browser as well like JavaScript works on the browser. But then you can also run it on the server like things like no NodeJS and stuff like that for example. These are different because they don't have a lot of the same restrictions as client side JavaScript does and they're not really parsed the same way. They have different functions as well and they're actually very different from each other.

So what you need to understand is client side JavaScript runs on the user's browser. Server side JavaScript when we're talking about stuff like Node.js JS will run on the actual like cloud will run on the server and it's not constrained the same way that client side JavaScript is because it's not running in a browser and it's running on like a a different environment. Right now that you know that let's have a look at this HTML form.

Whenever we're writing HTML we're always going to be using client side JavaScript and not server side JavaScript. So where is it JavaScript? Don't see it here. Well, it's actually not really practiced anymore that people will write JavaScript inside the HTML itself. They'll actually usually import it from from a different script. So, this is the way you see I have it imported as script.js. We go here. This is the JavaScript, right?

So, it's basically automatically importing it for us. It's the same as writing like a script tag in here. You know, it's the same as writing a script tag and then writing all that. But instead of doing that inside the same file just to make it look a bit cleaner, people have shifted it away to a different file. You can do the same thing with with um CSS as well. Basically just shifting it off into a different file. I think with CSS use a meta tag for or sorry use a style tag I think to import it.

And instead for JavaScript we import it with a script file. And we can set the script source here. The script source will point to the location that the JavaScript file is at. Okay, phenomenal. Let's have a look at this JavaScript file, right? How do we write JavaScript? How do we actually perform stuff on behalf on on the website? Like the way we usually do it is first of all, we need to find the elements that we want to actually modify or like listen to.

And the way we usually do that is right here is by finding its ID parameter. So, we want to like find a button or something like that. I think I spelled button wrong there. Oops. Just write that there. So we have something like this. We have button fetch and we'll just get it by the ID. The ID is something that we include from the HTML. Like see you can see this button here. So button fetch. You can see the ID and then we can just get it in JavaScript.

This just allows us to actually get a look at it. And then whenever we want to do something to it, we can just press this thing. For example, if you want to add HTML to it, we can do it like this. Or if we want to add a function to it, we can listen to an event. We can do what is it? What like? Oh, add event listen. We can do add event listen. Yeah. And then we can just add whatever event we want to. You see there's a lot of them.

Basically, there's a lot of stuff we can listen to. If someone like hovers over the button, we can do something. We can like go to a function. This could be good if you want to like make the button look nice or make some kind of animation play. You can do that with CSS obviously as well, but that's an option for you. One thing you might notice is that JavaScript doesn't have types. It's not a typed language by default.

We have either constant. So const is something that you can't change. So once I define it, it's not changeable. Or you can have like a let ones like a let is something that we can change. It's like a variable. You can also have var, which is another one. I never use that though. I just use those two. Yeah, that's the main two things. That's how we define variables. They're not typed. So it's not like you know you call like Java, Java will have like ins and strings stuff like that.

JavaScript won't. That's why they're actually two very different languages. Don't don't get them confused. Java and JavaScript two different languages. There is actually another language called TypeScript which is kind of a Microsoft patch to this because they wanted to actually add types into it. And the way TypeScript works is you like type like enter something here like next to it and instead of that you'll have types in JavaScript.

But by default it doesn't have any types. So we declare variables. They're just like this. So that was a quick overview of some of the stuff you can do with JavaScript. Now how do we hack JavaScript? What do we actually want to look for whenever we read them? Whenever we do any code review, we look for two things. We look for sources and we look for syncs. Sources are where user input will enter the code and start like flowing through it, right? and a sync is where that that code will be executed and do something.

In the case of client side JavaScript, the main vulnerability type people look for is cross-sight scripting. And that's a way to execute JavaScript code on the user's website based on some kind of user input that we control. The reason this is bad is because through JavaScript, we can do stuff like stuff like reach API endpoints with the user's cookies and credentials. That means that if we were able to do cross-ite scripting on a website, we could have the user perform an actions they did intend to.

You see here this fetch request, right? This fetch request can go up to like an API or something like that. And we're including the credentials. If the user clicks on the website and we have cross-ite scripting, which means that we can execute JavaScript on behalf of the user, then we will be able to run that API endpoint and the user will won't know. This could be like a delete account endpoint. So when the user basically gets affected by our cross-ite scripting, we can like delete their account without them even knowing, which is obviously pretty serious.

So websites want to prevent cross-ite scripting. There's a couple ways to do this. And the first way is to basically look at the sources and syncs and then make sure that user input is not being fed into a sync it's not being executed. Let's look at the first sync that I've just created here which is the sync with parameters. So this is a very common sync. It's where a parameter so a search parameter query parameter is taken from here this JS parameter and is then fed into some kind of execution later down the line.

In this case, I'm using the eval function. The eval function will take a string and evaluate it as JavaScript. That's obviously pretty good cross-ite scripting potential there. And whenever we put this JavaScript parameter, we can do some like alert. The alert will pop up. Cool. That seems like a cross-ite scripting vulnerability. Nice. How do we exploit it? What we would do is we would send a link a link to a a victim and we put our cross-ite scripting payload here.

For example, a thing that would like a fetch request that will automatically submit an API when the user clicks on it. Then when the user clicks on it, the parameter will be fed into the evaluation and then the JavaScript will be executed. That's how this vulnerability will work whenever we attack it. This is called DOM cross-ite scripting. So DOM is the stuff that here and it's different for normal cross-ite scripting because it actually runs on the client instead of on the server.

Normally cross-ite scripting is where like the server will append [snorts] like a tag onto the server when it's rendering it onto sorry the web page when it's rendering it then it'll be like cross-ite script in there right instead of that this is actually executed in the in the JavaScript here. So it's not anything server related. It only runs inside the client. That's actually very popular nowadays because most most websites use client side rendering now.

Do stuff like React and Vue.js. It's rare that you'll see like a PHP website anymore with server side rendering. So more DOMXS type stuff is actually become more and more popular. But crossite scripting isn't the only vulnerability we can find through JavaScript. There's a couple more of them. And for example, there's something like CSRF. CSRF cross request for a dream is a vulnerability I covered before. So if you don't know what it is then please go watch that video.

But in short is it basically just a way to basically do the same thing as crossite scripting. So run some kind of API endpoints on the user's behalf. Just it's a little bit different that we don't actually execute JavaScript to do it but we kind of manipulate some endpoint to do it. Right. Let's take a look at this code here. Right. Read it. Maybe take a second. See if you can spot where the vulnerability is. See how can we let's say there's an API input no API input like v1 slash delete maybe like API slash user API/ delete like say say say say say say say say say say say say this one right say this endpoint will allow us to delete an account so this is something that user press when they want to delete their account how could we exploit it so that we we can type in this ID and it'll instead go to this endpoint here.

The way we can actually go and hit this other API endpoint by manipulating this prompt is by using a path traversal. Basically, a path traversal is where we put these kind of strings here. Oops. where we can put this kind of symbol here and whenever we have like something like another path like vapi1 it'll actually go it'll actually normalize the path and go back to the previous one. So patch is just a way of basically going backward paths.

And there's another one like this which just stays in the same one. It's kind of useless to [snorts] us anyway. The most important one is this which will go back a path. And then after that we can put another endpoint like this. And once it normalizes the path we'll be oops we'll be at a different endpoint. And this is normally attacked from the server and it has been for a good couple of years. Let's say a server was fetching a file from some kind of directory and what it was using it was using like the name of the file.

So it's like file name here, file name here. If we could control that file name, what we could do is you could go back the directory. So we could set the file name to something like dot dot slash do slash and then we would go back to the root directory and read files from there. Usually we would read like etc/. We can kind of do the same thing from the client side using client side JavaScript. And this is called client side path reversal.

I made a video on as well. It's a pretty cool one. But this is we'll have a look on the JavaScript code. Now I can't actually exploit this vulnerability in my browser because I'm running this from a file and this is protected by cores and stuff like that. And if it's not HTTP, it'll kind of break a little bit. But I can just show you here. I go to fetch URL. I input do/delete like so. And I press okay. You can see it'll disallow reading the resource endpoint at at the exact end point that we wanted to.

So this was on a real website then we could execute this client side patch reversal and when the user clicks on it then that would basically happen. It's unlikely this would be like a prompt even though this is not used but this is actually not exploitable anyway because we'd have to get the user to type this in which is unlikely. What it would usually be is like for example it'll take like window.loation location and then it will get like the last one, right?

So it'll say like path name and then it'll get like the last path name basically cuz in the string what it will usually be is like when you have like an ID parameter it'll have like 1 2 3 4 5 it'll take that and then put it into a different API endpoint just the last parameter. And what we can do is you can put the dot dot slash here just in a URL encoded way instead. So like this and then this when this will be decoded hopefully by the server here it'll be placed into the string and then it'll it'll make the path reversal.

That's how you can exploit something like client side path reversal and we can get a CSR type vulnerability. So something else to look out for whenever you're actually reading your JavaScript and this is just another kind of sync. The sync in this case is the template literal. One of the other attack vectors to keep in mind when looking at client side path reversals is actually cross origin redirects with an open redirect inside an API.

Just to explain that a little bit clearer, if you have a fetch request coming from let's say www.agample.com, right? And it's an API sitting at api.agample.com, right? That's where most of the user actions will be performed. And the www domain is just like the UI mainly, right? When the www domain makes a fetch request to the API domain, it'll usually include an authorization header. Let's say that's how the website author authorizes you.

It's with the authorization header and they have like an API token in there, right? That's like the way that you're going to be able to access your API. One of the things you can do is if the API uh subdomain has an open redirect in it if the user can be manipulated with a client side patch reversal. So if you have a client side path reversal on that fetch request from www to the API and then you also find an open redirect you might be able to leak this authorization header and then basically get the user's API token which is basically the the maximal possible impact you can have from a client side vulnerability that's basically just like complete account takeover right the ideal scenario is like oneclick account takeover right the user clicks like your link with a client a patch reversal and then they get redirected to this API subdomain and then the API subdomain has an open redirect to a different subdomain that you control which then we can leak the authorization header and one thing to keep in mind is that some browsers will actually block this.

In some browsers the authorization header will not be will not carry over in cross origin redirect. Remember, an origin is basically the subdomain. So, it's it's actually even different from just a normal domain, right? So, www.agample.com is a different origin from api.agample.com. So, just keep that one in mind as well. And you can see like the biggest one I think that does this is Firefox and Safari are the two bigger ones that block this behavior.

Although, for some reason, this is still allowed in Chrome apparently. I actually didn't know that. Apparently, it doesn't even support that at all, which is interesting. I actually thought they did. Maybe I'll have to re read about that as well. Either way, this authorization header does add a little bit of protection to developers from client side patch reversals. But if Chrome doesn't doesn't support this, then I think this is still reportable even if it doesn't work on Firefox.

And [snorts] if the application is using some like X authorization header, then there's basically no no safety there for any any kind of client side patch reversals. But if you do find a client side patch reversal, then just keep in mind as well it's worth looking for the CSRF as well. But for maximal impact, leaking the author authorization header or some kind of API key would be amazing. that in mind if the client side patch reversal is going to a different domain or even on even on the same domain and then you find an open redirect there then you can maximize your impact by leaking the API token.

Next thing that I want to talk about is post message and this is another thing that I think is very underrated by most people. A post message is kind of confusing, but it's a way for a website, so the main website to talk to an I frame which is inside of the actual website. Remember in my HTML video, I talked about iframes. There you go. And it's actually a way to include or embed another website inside an already existing website.

Instead of opening a new tab with the website, we can just embed it inside our own website. In this case, the iframe is here. Why would we want to do this? It's good for stuff like widgets, for example, like notification pop-ups or something like that because instead of loading it onto our own website, we can just create it once and then load it like a load of times from different websites. And that just saves us a lot of development work first of all, and it's also quite efficient.

That's why we might want to use iframes in order to embed stuff into our own website. But these iframes, they can't just talk to each other like normally. Why can't websites just why can't an iframe just like basically be part of the website? Well, if someone went if you clicked on a malicious website and they say embedded your bank account onto their website, which they can do with an iframe. Since they've done that, the website will load with your cookies and stuff like that.

If they could just access your the website, they could read like your personal details off, right? So, we need to prevent that from happening. We need to prevent the attacker website being able to like read your personal details from an embedded website. That's where the same origin policy comes in, which also applies to iframes. So, you can't read you can't read data from inside an iframe unless you're in the same origin, which means the same like what's called um like host in here.

Basically, unless you meet that requirement, you can't read stuff from and you can't like send like requests or anything like that. You can never read cookies basically as well. That's basically the requirements that are set by the same order policy and it's to protect your details from being stolen by attackers and it's a very good thing. What if you need to do it though? Let's say you have a widget. You've loaded it in and you need to send data to it which is quite normal.

Like say you had a widget and on the side of website and it said like welcome and it's like your username. But the widget has to know your username but the username is only known by the website, right? So we need a way to pass your username into the widget. for example. And the way we do that is using something called post message. It's kind of like HTTP light just for iframes. It's very funny. We can send a message to the iframe and the iframe can choose to receive it and then process it and then it can send a response back to us.

Let's see here. When the user clicks a button like here, this is an alternative way to write the uh thing about the event listener just like this. So when the user clicks a button, we're going to get an iframe with ID child. Let's go back here. So here's the iframe and it's just loading in widget.html. It's going to get that and then it's going to send a message and it's going to send a little bit of HTML to it, right?

And then later on it's going to wait for an event from a message and then it's just going to log it into the console. So this here is how we can listen to post messages and this here is how we send post messages. Let's go to widget and here I've just written it into the script just to be a little bit safer and we have the same thing. It's listening to a post message. It's putting the notes inside inner HTML and then it's sending a response back to us.

So this is the kind of two-way communication, right? Instead of like actually doing this from the top website which we can't do, we've sent the information down to the widget which is then going to process it and then it's going to do stuff with them. That's phenomenal. There's a bit of an issue here though and there's a few security concerns that come with post messages. The anyone can open an iframe, right? So I can iframe this widget myself if I wanted to and if the widget contains some kind of sensitive data already and I send a post message to it.

If it just yeets up the sensitive information without checking if the origin above it is actually authorized to see it, it could leak your user data. And they've done a a few patches to actually prevent this from happening. I didn't really explain this little star thing. The star thing is actually is a way to specify what origin we will allow this post message to go to. All of these post message things were happening. they were vulnerabilities were happening because people weren't checking the origin.

So they added this in and this star means that any origin is allowed and it's generally it's it's generally frowned upon to use this inside production unless it's absolutely necessary to sometimes you have to use it if you have like multiple origins using it. But what we can do is we can specify different like domains inside here and this will prevent some kind of vulnerabilities. The other way we can do it is by checking the actual source of the event here.

So we can check this manually by doing like origin and we can check him and we can use that source. Source I think is a bit more secure than origin. Origin can be kind of manipulated a little bit by using sandbox iframes. So source is generally more reliable. Another thing is that if we can pass data into the post message and it handles it in securely by trusting the source that's sending it. Well then then we can basically we can actually find the sync inside the post message and then execute crosscripting there as well.

So you see this inner HTML page this inner HTML is another sync and this will just inject a string straight into the HTML and it will parse it as if it's HTML. So if you put like a script inside of it, it will parse it as a script and then the rest of it will parse a JavaScript allowing us to get a post and we get a crossite scripting vulnerability. And this is one of the bigger things actually it's in our HTML and I think it's quite it's quite insecure to use this anyway.

So you want to be make sure that the data that's being passed into this is safe. It's definitely going to be trusted. Sometimes you really need to use this for a variety of reasons. So that's what will allow us to send a post message. And the same thing applies obviously on the on the top level domain. It's also able to receive post messages. Remember that I can also I frame this domain. So it's not just like a top level domain.

I can frame this and then send a post message to this. So this is doing if it's handling this insecurity trusting its frame like this childframe. I can frame this as well if I want to and then send post messages to it. So you really have to be careful when you're actually receiving these messages. So in this case, we'll just test out what this has going to do. I'm going to click this post message button. You can see this was sent with post message, which is what I sent.

And then you can see the actual HTML here, which is reflect on the page. I have this tool called post message tracker, which shows me whenever post messages are sent. And this is the data that gets sent from the top level iframe and then the bottom level iframe sent data as well. What's cool about this tool as well is that it allows you to see where the post messages are actually being tracked. So you can see this function here is the one inside the iframe.

And this one is just is just this thing here, right? So it just allows me to see it at a glance and it allows me to see it without basically just looking through all the all the JavaScript which is nice. So how can we exploit this? This is insecure because it's passing HTML directly. It's not checking the origin. So this uh this widget here isn't verifying the origin and it's just directly yielding it into inner HTML.

There's obviously no sensitive data here on this widget, but if there was, then we could execute some kind of cross-ite scripting. So how would we execute this? Well, the the simplest way is just to make our own little HTML page here. We'll just create our own little exploit. We'll say HTML just define a few things. body and then we want to make a script background. So what we want to do is we want to I frame the widget going here.

We want to declare an I frame iframe like this I frame with the source being widget.html like that. Then we want to set an ID say set say child like this. And then in the script we want to find the widget. So document getelement by id find b finding child and then sending the post message to it. We can just go back here. We can go back to the main script here. We can go say just copy paste this stuff. Childcontext window.

We'll just copy paste it directly from the main one. And then it will say here instead of child say frame content window post message. Instead of that we're going to send a malicious post message this time which is going to allow us to get the vulnerability. We're going to say like script alert like this thing here. We get this down here as well. And then we'll say like that any origins allowed. Yeah. And hopefully this will work.

I might have to add a few things to it. And then we'll go into evil.html here. And then what's happening here? Sometimes you might need to actually wait for the iframe to open before you actually send the request. So we just go here, say unload like this, and then when it's loaded, we can just post a message. So just say here, then hopefully the frame will do that stuff. Maybe not. Okay, it's injected the script alert.

I don't know why it hasn't popped though. It should have popped. Weird. Maybe we'll try a different payload. We'll say image source x on error which is equal to alert like this which closes here. We'll save that instead. And then you can see the alert has popped. So it's popped inside this iframe. So that this this is not like an XSS cross scripting vulnerability on this website. It's actually affecting the inside the widget.

So we can use the cookies from the widget and not on the main website. That's how this cross scripting vulnerability works there. Yeah, that's kind of it for post messages. We can send a request in and then we can either get a sync or we can hope that the post message will throw up some kind of sensitive information if it hasn't. Those are the two things that we can kind of hope for when we attack post messages. One place that I've actually seen post messages implemented a lot is in third-party integrations.

Let's say a website opens like a pop-up for like some other third party service like an AI chatbot for example like the right corner and it wants to integrate it into its own website. A lot of the time the only way to communicate between that pop-up is going to be through implementing a post message handler on their side which is going to communicate with the pop-up. And this can open the door to vulnerabilities, right?

Because the company has to code in their own post message listener and then verify that it's actually coming from the pop-up, which a lot of companies are not very good at. But for example, if this event origin thing if it's getting checked wrong or if it's too lenient or if it's like a reax and a h and hacker could be able to bypass it and then masquerade as the pop-up and then depending on what information is being passed from the pop-up to the website and what impact it has on the actual on the actual top level domain, then a hacker could be able to escalate and try and achieve some like cross-ite scripting.

Let's say an example is like there's a popup on an I frame but then the iframe has to change its source to some kind of different location and then the top level domain will have to change the source of the iframe from a post message from that pop-up right it's a bit confusing you have this like you know iframe on the bottom whatever right and so it's sent the pop-up will send a post message with a URL that's going to contain do the URL of the next iframe that the top level domain will change the iframe source to.

And if the top level domain is overly lenient on trusting this pop-up or trusting the or just trusting the origin that it's coming from, then what an attacker might be able to do is send a URL with a JavaScript URI. And when the website goes to set the iframe to this JavaScript URI, then it's going to achieve cross-ite scripting. Or if it doesn't allow the JavaScript URI, then maybe we could embed an attacker control iframe in this website and then start looking to chain other vulnerabilities or just report some like fishing vulnerability or whatever.

So this can lead to vulnerabilities especially when third party integrations are involved. And again, some thirdparty integrations are not very securely coded and their JavaScript might not be great, which could allow us to basically to basically find vulnerabilities on the top level domain. Remember as well that if you can get cross-ite scripting on an iframe, then you can send post messages with any content you want to the top level domain.

So that could be a way that even if the actual top level domain correctly verifies the origin but then trust the iframe with the message if you can get cross-ite scripting on the third party iframe well then you will probably be able to get cross-ite scripting on the top level domain as well but looking at these third party implementations is a great way to attack post messages and just to end off the video I'm going to talk about some JavaScript libraries that I often see JavaScript libraries are things that other developers import into their code and that they run on the client side.

And DOM purify is one of the ones from a security perspective that is actually interesting to us. Just go back to the main one here. Dom purify what it does it is it allows us to write HTML onto the DOM but it filters out cross scripting. So it prevents us from doing stuff like adding in like script tags. It prevents the attributes that allow JavaScript inside of them and it will prevent those cross scripting vulnerabilities.

Why might someone allow to people to write JavaScript or why would they allow this? Well, say you have like a profile and you have like a profile inside web page and we want to add allow users to add a description. Makes sense to allow those allow them to use markdown on the web page to actually like underline text or like have like a text editor and stuff like that just to look a bit nicer, you know. And to do that, we have to sanitize away all the possible crossite scripting stuff so that it doesn't end up affecting the actual web page.

And to do that, a lot of people use this library called DOM purify, which you can find here on the internet. Usually, the way you include it is you just download it and then you just add a script tag. As you can see, I've added right here, it's called purify.js. And that will allow us to actually use it inside our code. You see here, we can use purify this class name here. And then we can sanitize stuff away. Let's try it out.

We'll write something like test here like that. Say okay. And you can see that we've actually injected the HTML. So that's nice. That's intended. We want to do that. Now what intended is for example if I came here and wrote like script instead of that and then I said like test next to it instead. So yes, we put it down and you can see that the script did not make it into the actual DOM. So it was sanitized away. That's the main way people use DOM purify.

It just sanitize away all the cross scripting. It's very safe. It's like gets regular updates. If people are using the latest version of Dom purify, there should be absolutely no issue. There are like regular security, you know, security problems that emerge like for example here September 16th, October 11th through 31st, 2024. Vulnerabilities do happen in this library as they do in like every other library. So you need to keep them up to date.

The main way you can find a vulnerability with someone using DOM purify is to see what version they're using. If you go here, they're using version 2.4.2, too which before that was affected by this prototype pollution. It was critical. So imagine you could just do like a crossite scripting there. You can see the latest one is 3.3.1 which will it will say it on type the the DOM purify script. So if you see this purify and you see this version is like lower than this that means that you can go read up on this commit message here you can load this diff here and you can figure out what was wrong and then you can launch the vulnerability from there.

That's the main way that you can exploit JavaScript libraries is by looking at the previous security vulnerabilities and then seeing if they're using an outdated version. One of the cool places that I've actually seen an outdated version of DOM purify deployed is in Swagger UI. Swagger UI is what visualizes the API requests for an API domain. It's often used in like book bounty labs where you have like this swagger and it's like you know the thing is like try it out yourself or whatever.

You can like click it and add your authorization header or whatever. But there's basically a DOM cross-ite scripting vulnerability between like these uh versions because this UI tool was using an outdated version of the DOM purify library. But if you're able to find this swagger UI between these versions here on a website, then you can basically get DOM XSS on it just because they were using an outdated version of DOM purify.

This is going to show you that checking whether a application is using old versions of libraries is actually a very good way to find vulnerabilities. And I think there's a tool for this. I think there's one called retirejs. This one here. Maybe let's look at the the GitHub request here. This one here, which basically will scan for outdated components, outdated JavaScript libraries as you're actually looking at a web page.

So, this could be useful as just kind of a passive scanner and maybe it'll at some point pay its debt and find you a vulnerability. And there's also a Firefox extension. So, it's really like it's really like a loweffort way to scan for these outdated libraries and maybe get some kind of vulnerability at some point just because you just got alerted to an outdated library being used. Obviously, keep in mind that the companies themselves will be running these tools as well.

So, you know, I don't know how effective that's going to be. I haven't personally found a vulnerability to this myself. However, I have heard of other people doing it. Have read ups of people that have found vulnerabilities because of it. So, it's probably worth a try. I hope you enjoyed this full guide covering the manual hacking methodology. If you managed to watch the whole video, then you probably have a 0.001% attention span, better than like 99.9% of people.

So, you'll have absolutely no issues implementing the stuff from this video and becoming a successful hacker because that kind of attention span is extremely rare nowadays. If you did enjoy the video, then please do leave a like and subscribe to the channel and leave a comment if you did enjoy the video as well. Anyways, that's it for me. Thanks for watching and happy hunting.