Transcription
I'm about to take you on a wild ride, spilling the secrets of the cyber underworld that will completely shatter the illusions of digital security. When we're done lifting the digital veil, you'll have complete mastery in the art of URL hacking, data leaks, digital negotiation, making data bend to your every whim, finding hidden requests that flit like phantoms on the web, and wielding the weapons of the cyber elite.
Look, you don't need a fancy degree or years of experience to get in on this action. I already did that for you—17 years total. What you need is adventure, pure and simple. You got to be willing to take risks, push limits, and break the rules with your newfound hacking skills. I'll teach you exactly how to do this without getting thrown in jail. Hopefully. I'm not a lawyer, so no promises.
So here's the deal: I'm going to teach you how to hack like a pro—not some timid little dork who just got hold of the script—all without knowing anything about coding in no time flat. When we're done, your status will skyrocket to become the master of your digital domain, effortlessly navigating the cyber shadows and outmaneuvering anyone who poses a threat.
Oh, and I forgot to mention, this is now completely for free. All I ask is that you give this video a like and subscribe to my channel. If you really want to donate, I'll have a link in the description. So what do you say? You ready to join me on this ride to the top of the cyber food chain? Then let's have some fun and get started.
Welcome to the no-code hacking course! I'm going to show you the most powerful way to hack a website without knowing anything about coding. Hold on—everything I teach is for educational purposes only, not illegal activity. So promise, no pinky promise, you're going to be good.
All right, let's go. Every time you visit a website, there's a URL. All right, everybody knows this. Nothing earth-shattering here. But as a hacker, a URL is often the key to understanding exactly how developers organize their website, so you can then use that to your advantage.
Think about it like this: when I was a little boy, I'd always play the original old-school Zelda game for NES. I'd be exploring a dungeon and acquire a map, only to find there are hidden rooms right next to me on the map. But there's one big problem—there aren't any doorways leading inside. It's completely blocked off. So I just do what any little kid would do in the same situation: pick up a bomb and blast a hole right through that wall, making my own way in.
This is exactly what you can do with URLs. Let me take you back to one of my very first hacks. But instead of just listening about it, let's actually do this hack together. You can click the link below if you want to follow along.
Here on OnlyFans, you get to see the watermarked thumbnails of images unless you become a member for $99 a month. Or you could just hack it. Like I said earlier, the URL is a map for how the developers organize the website, so we just need to find the hidden room, so to speak, by looking at the URLs of the thumbnails to see what we can learn.
To do this, simply right-click and select "Open image in new tab." Now let's break down this URL. At first glance, this doesn't look all that helpful, but it actually has everything we need to hack this website and steal all the photos without making a single purchase.
The first part is "/photo sets." It makes sense; we're looking at a photo set. Then there are some random numbers, and this is just the ID of the photo set we're looking at. Finally, the file name of the thumbnail itself: "56789-th.PNG."
Now let me ask you something: what do you think the "th" stands for? Thumbnail. If this is the URL for the thumbnail, what do you think the URL for the full-sized image looks like? How about we just take off the "th"? We just hacked our way into getting the full-size image without paying a penny for a membership.
Now think about how we're going to steal the remaining photos in the photo set. There might be an easier way, and by "might be," I mean there is. If this file name is just an example of one photo, we just need a new file name. Since there's a number involved, we can just add one or subtract one.
So let's try this out on another one of the photo sets. Let's look at "Orca Love" this time and open the image in a new tab. What we're going to do is change the file name here so we can get the full-size image. Remove the "th," and there's the full-size image. Now we're going to add one to this "66" and finally subtract one from the original "65," so it's going to be "64."
There you go! You can do the exact same thing with the other one as well. This time with "Beta Beauty," open the image in a new tab, and we're doing the exact same thing: remove the "th," hit enter, and there's the full-sized original. We're going to add one to "88" and subtract one from the original "86," and there you go!
Now, websites manage a ton of resources like private information, and a lot of the time, the only thing protecting it is just the assumption that you're not going to change the URL. This means the key to this hack is to find the resource IDs in the URLs and change them.
For instance, websites can use usernames, email addresses, numbers, and so on, and the data returned can expose sensitive private information or locked features you're not supposed to see.
Wait a sec! This obviously has the potential to expose a lot of private information. Because I'm not expertly qualified to give legal advice and guarantee you won't be raided by the feds, here is just some friendly advice: only use this against your own accounts rather than trying to expose actual private user information. Just a friendly tip.
We're going to cover more advanced attacks and later recipes in the no-code hacking course, but what's important to know is that this vulnerability is actually likely to be the most common problem on the web—maybe even more common than XSS, which we do a deep dive into in the ultimate XSS training course.
The difference here is that security scanners don't easily find these vulnerabilities, so they often go unnoticed and unpatched. After all, most scanners don't know the difference between normal data and sensitive data or what permissions a user is supposed to have.
For developers, it gets worse. As we saw, it doesn't require complex coding skills or social engineering trickery to exploit it. So really, anybody can find these vulnerabilities pretty easily just by doing a little exploration.
This is the perfect test score challenge: every student in the hardest class is getting perfect test scores. The school thinks this is too good to be true, so you've been hired to evaluate the security of the school's website and find out if students are hacking in to steal the test answers.
The goal is to go to this link for the final exam and find the answers to the final exam and submit it below. So let's look at that link, and this is the final exam from Professor X in the Mind Reading 101 course.
So the question is: there's only one question—what is the random number I'm thinking? All right, there's no other information on this page. So what we can do is, like I said before in the recipe, look at the URL because the URL is a map of how the developers organize the website.
What we see here is we have "SL Pages" then "SLF Final D Exam." So our goal again is to find the answers for this final exam. Knowing that the resource ID here for the pages resource is called "Final Das Exam," and we want the answers, let's just try to add "answers" at the end and see what happens.
All right, there it is! So here's the answer. I'm going to copy it and then paste it in here, click submit, and there we go! The challenge was solved. You passed this challenge by discovering how students can hack the website to find the answers to the exam.
Now, for being honest, I've actually done this before in real life for homework assignments where you could just change the URL and then find answers—not that I needed it; it was just to double-check my work, which I got everything right, of course.
Let's go on to the next challenge. This is "Inbox Invasion." Sensitive pictures and private conversations are being leaked and used to blackmail the CEO. Your task this time is to find out how emails are being hacked and stolen by attackers.
The goal here is to go to the inbox and then find the name of the group responsible for the attacks and submit it below. So I'm opening that link. This is the inbox right here, and so I'm going to click on this message. This is from the CEO. The subject is "Please Help," sent today.
The message says, "I'm about to lose everything. I don't have a clue how these hackers got into my emails, but now they're threatening to leak everything if I don't pay them money. Please find out who's doing this."
So I'm going to go back to the inbox, check out the other email. This is from the system admin, says "Welcome," sent one day ago. This is an autogenerated email. Your inbox is ready to receive messages.
So the CIS admin set up an email account for us to help out, and then the CEO emailed us directly. What information do we have? Well, let's check out the URL. We're at "/Pages/SL Inbox/SLTH Message ID." All right, and the message ID here is "1123."
So let's go back to the inbox, and this message ID is "1122," so it's one less than the CEO's email. Knowing that the CEO had some information that was sensitive and private in his email from the past, we know that we can just decrease this number to check out the past emails.
So we're going to minus one, so it's "1121." This message has been deleted, so let's just keep going. Put it at "20." We've uncovered something now. This is a message from the CIS admin, says, "All your info are belong to us," sent three days ago.
"Dear CEO, we have taken all your emails—everything from your pictures to your secrets—we have it all. Do not contact the police; we own the police. Time to pay up for thinking you can challenge us. Send $500,000 to account number 162923 by next week or the leaks will begin."
So that doesn't give us who actually did it just because this email was sent by the CIS admin. So they hacked the CIS admin's account too. What we want to do is keep going back in time. Change it to "19," and the message has been deleted.
Let's try the next one: "18." And then here we go! From a deleted user: "Next steps, dear Biofarm Mafia. I have taken the emails like you asked. When will I get paid? Please call me. I don't trust the email system, and I need to go into hiding."
All right, so we have the information right here. It is Biofarm Mafia that is behind this hack. So we're going to copy that, paste it in here for the answer, and then click submit. And that is correct!
So let's move on to the next recipe, and then we can solve the challenges there. In this recipe, I'm giving you x-ray vision superpowers so you can see through to places you're not allowed.
ACC main program: "Ah, you didn't say the magic word." We're now going to expose and steal sensitive data in a very sneaky and subtle way using just the minimalist skills we've covered so far—typing in a URL.
The difference here is that we're going to be using what's called a side channel. This means we're not going to steal the sensitive data directly, but instead, it will be leaked and stolen indirectly. Think about it like x-ray vision in that even though we can't access a URL, we're still going to reveal private information inside just by looking at how the website tells us that we're blocked.
Let's explore this further in the example for this recipe below. So first thing is we're going to click on "My Secret Project," and you're going to see you are the owner of this project. We see the URL is set to "/Pages/SLM/My-Sec-Project," and since it's our own project, naturally, we have access.
But what if we wanted to find out other secret projects that aren't ours? Here's where a little exploration can help. First, let's start off by just replacing the project ID "My-Sec-Project" with something random just to see what happens when you pass an invalid ID.
So I'm just going to type in some random letters, hit enter, and we see that there is a 404 saying the page wasn't found. Makes sense. But I have a suspicion that there's another secret project we need to expose, but we don't have any proof it exists yet. That project is called "Operation Steel Cookies."
So let's type that into the URL: "Operation D Steel Das Cookies." This time, unfortunately, we're blocked. We received a 403 Forbidden message, so no luck. Hold on! We actually just got something extremely important. Were you paying attention?
We just uncovered a side channel leak that "Operation Steel Cookies" is in fact a real secret project. Why? Because it didn't return a 404. Let's retrace our steps. When we visited a random project that didn't exist, we got a 404 since it couldn't be found.
However, when visiting the "Operation Steel Cookies" project, we got a different response saying that we don't have access, thereby revealing that it does in fact exist. Let's try another scenario. Say you had no user account at all, but you're looking to leak some kind of sensitive information.
First, let's copy the original URL for "My Secret Project." All right, it's copied. Then open a private browser window so you're not signed into your account. Finally, paste in the URL and hit enter. Since you're not logged in, you see it redirected to the login page, which is pretty much what you'd expect.
You can't access your project if you're not logged in. We still don't know anything at this point. Nothing's been leaked unless, like earlier, it behaves differently for resources that don't exist. Let's change the project to something random again to see what happens when we're not logged in.
I'm going to paste it in and then replace "My Secret Project" with random letters, hit enter, and again we found a second leak exposing secret projects because the behavior changes between valid and invalid resources.
This time when logged out, valid resources redirected to a login page, whereas invalid resources responded with a 404. That's our side channel! What we've just seen can also happen with other server responses like 500 errors, but the pattern remains exactly the same.
Here it is again: if a response behaves differently between valid and invalid resources, there's a side channel leak of information. Normally, this doesn't matter for many resources. Nobody really cares if it's nothing important, unless of course you're actually exposing sensitive information. Then it's a big deal.
Generally speaking, credit cards, personal identities, health information are all sensitive and protected because if exposed, they could result in legal trouble for companies or be used by criminal groups for identity theft and other types of fraud, which is why developers really need to lock this information down securely.
It also needs to be said that when you search for these vulnerabilities in the wild, like in a bug bounty program, it's very, very important that you only access your own personal data so you don't expose someone else's private information. Even if that means creating multiple accounts on the same website, this will help protect you from getting into legal troubles of your own.
Now, I am not a lawyer, and this is not professional legal advice, but I'm going to guess that "Oh, I'm sorry, my x-ray vision made me do it" probably isn't a valid legal defense that will hold up in court.
Hold on! Put the skills you just learned to use and solve the challenges for this recipe. This is the health record leaks challenge. Massive health record leaks are spreading all across the internet, causing billions of dollars in damages in legal fees. Find out how disease information is being leaked from the website.
So here's the goal: check out the link to your health dashboard and then list all diseases that user "barely alive" has and submit them below, separating each with a comma. So let's check this out. Here's my health dashboard.
So you can see from the URL this is a health dashboard, and it's for me. So what positive results do I have? Here's one: extreme coolness. There is no cure. Let's check out the URL because we want to get as much information as we can before we proceed.
Like we already mentioned before, this is a health dashboard for me, and then "SL Diseases," and then we have "Extreme Das Coolness." So you can see the map of how the website is designed. We have basically the user ID right here—this one's me—and then we have diseases and then the extreme coolness.
This will determine whether or not we have a disease. So let's take an example for negative results. We see "Atlantis Complex." We're going to copy that one and paste that in, and let's see what happens. Okay, it's a 404. So as expected, whenever we don't have the disease, then what's going to happen is it's going to 404.
So let's go back to the challenge page. We want to uncover what diseases that the user "barely alive" has. So let's check that out to see if it's locked down or not. So I'm going to paste the username "barely alive" in the URL for the health dashboard and let's check out this same disease, "Extreme Coolness," and see if barely alive has been diagnosed with extreme coolness.
All right, no! Barely alive has not been diagnosed with extreme coolness. So actually, let's go back there. So let's check out the other diseases that we can see if barely alive has been diagnosed with them. All right, check out "Atlantis Complex." Nope! Barely alive does not have Atlantis Complex.
Or this website is protected, so it may not just give information for that user because it's not us. But let's check it out. Let's be certain and go through this disease list and find out. Next one is "Bloodfire." All right, paste that in. Bloodfire is also 404.
All right, cooties! Does barely alive have cooties? Let's find out. Replace bloodfire with cooties. 401 Unauthorized. Okay, this is a different response. Remember, this gives us some information. This is a side channel leak because whenever we saw the page 404, that means the user doesn't have the disease.
But here we've got a 401 saying we're unauthorized. We're not barely alive; we can't access the information. But we know through the side channel that the user has in fact been diagnosed with cooties. So let's check out the next one.
Actually, before we do that, let's paste cooties in here, put a comma, and let's check out the remaining diseases that we have. "Hawaiian Cat Flu" is the next one. Paste it in. 404. Okay, next one is "Love Sickness." Does barely alive have love sickness? The answer is yes! Barely alive has love sickness in addition to cooties.
So I'm going to paste that in there, add a comma, and go on to the next one. "Lycanthropy" is the next one. Paste that in. 404. "Stand Virus" is next. Paste that in. 401. All right, so barely alive also has the stand virus.
Now let's check the final one: "TS19." Let's see, barely alive, do you have TS19? Yes! Barely alive also has TS19. I can see why the user is called barely alive. All right, paste that in, click submit. These are all the diseases barely alive has been diagnosed with, and we uncovered that side channel leak exposing the private health records even though, again, we do not have access.
We are unauthorized to view that page. So let's go on to the next recipe. What if you could get anything you want in life? I'm going to teach you how to negotiate on the web like an expert to get everything you could possibly desire.
Some say we're in the business of hacking, but I'd say we're more than that. We are digital negotiators. Developers of websites write code for you to behave a certain way, but you don't always have to do what they want.
You see, here's what most people don't tell you and what developers don't want you to know: anytime you're dealing with data—viewing, creating, updating, or deleting resources—you actually have a choice to do it your own way rather than exactly how the developers programmed it.
Whatever! I'll do what I want. For example, you see forms every day on web pages, but just like a physical form, as hackers, we are digital negotiators. We can essentially edit or just rip up the form and replace it with the details that we want.
We just first have to understand the basics of how forms work. Every time you click a submit button on a form, it takes all the inputs, some of which are hidden, and sends their values to a URL set by the form. When you normally type in the URL into your browser and hit enter, this is a GET request because you're getting data and displaying it on the web page.
Forms, on the other hand, can use GET but often use a POST request instead because they're posting the values to a URL in order to create new data. We're not going to go over the simplest way attackers can control form data and modify it. Then in later recipes, we'll cover more advanced ways of doing this using more sophisticated tools.
Go to the first example for this recipe below. This example allows us to digitally negotiate the terms of a contract, which means there's a form posting all of this information from the inputs to a URL. So as expected, you see inputs for the contract details.
But if we look closer, we can see there's actually more to this form than what is visible. Right-click and inspect one of the inputs so we can look at the complete data this form uses for the contract. Now this is the no-code hacking course, so you don't need to understand everything that's going on, and you're not going to be writing any code here, so don't worry.
Right now, we're just looking at the inputs used by the form. What we see right now highlighted is "first name," and to continue, we're going to click the arrow next to this other one, and we see there's a "last name" input. Let's expand this.
We see there's a "bonus," and under that, it's "I agree," and that's the button. If you look at the very top, you can see that there's a hidden input that stores the salary amount. So now's our chance to do a little digital negotiation and change this value for an instant raise.
All you got to do is click the value and change it to anything you want. So I'm going to put "900,000," and there you go! When you submit the form, now the contract will be processed according to your own terms.
So I'm going to put my name, and I can't change this, so I'm just going to click agree, and I see that the salary is now $900,000 and the bonus is 3%. Now if we go back, we can also do a little more negotiation because remember we couldn't edit this 3%.
So if we do the exact same way and change the value of the bonus from 3% to let's say 5%, and then change the contract value to $900,000 again, then I'm going to click agree, and we see that the contract was processed with a salary of $900,000 and a bonus of 5%. Pretty successful negotiation, right?
Now, not all websites will be this simple to hack. This is just the very basics, but the concept we just learned is incredibly powerful—big power! This is an entirely new paradigm that we can work with because we can combine this with what we already know, namely rewriting URLs.
Forms on the web often include resource IDs as part of the form URL where the inputs are sent. This means in addition to modifying the inputs, we can also modify the URLs of forms. This takes us to other form methods besides POST.
We already know GET retrieves data and POST creates data, but there are other HTTP methods commonly used as well. PUT and PATCH are used to update existing resources, such as when you update your user profile, and DELETE, as you can guess, deletes resources, which can come in very, very handy for digital negotiators like us.
And you're going to see more of this later. So that's all for this recipe. Next time, we're going to—hold on! Now is your chance. Put the skills you just learned to use and solve the challenges for this recipe.
This is the "Find the Admin" challenge. The first and most important step in finding critical vulnerabilities is getting information. Admin accounts are being taken over and deleted. Your task is to discover how hackers are doing this.
This first step requires you to uncover if any private admin information is being leaked by the website. So as in the previous examples, this is a link to your user account in the API. I'm going to open that up, and the goal here is to find the email of the admin account and submit it below.
So we're trying to find the admin's email. What information do we have here? All right, so the information we have here is the ID is 5. This is me, my name, my email address. I have no image and I have no access token.
All right, so since we have the user 5, what we want to do is find the admin. Like before, decrement the user ID from 5 to 4 and go like this. This is Toodles Galore, and there's an image there. Let's check out what Toodles Galore looks like.
I'm just curious. Hey, look at that! Toodles Galore. All right, but Toodles Galore is not the one we are looking for. We're looking for the admin. So like I said before, we can keep going down with the ID.
Next name is Jerry Mouse, and let's take a look at Jerry Mouse. There is Jerry, a good pal Jerry, and two is Tom Cat. Let's take a look at Tom Cat just for fun. There he is! All right, and then we can go to one, and this is admin.
But look right here, there is an ID of one. The name is admin, user image is null, but there's no email address. So how are we supposed to uncover the admin's email? Admin here, who we want, doesn't have an email address visible.
So the only email address that we can see on here is ours right here. So that's because the API does have some security built in. So how do we bypass this? The API is protecting email addresses from being leaked when your user is trying to access somebody else's data.
However, if we're not trying to access a specific user's data and instead take off the resource ID, then we'll access the full data. So instead of accessing a specific user, now we're just trying to access all users.
And here is where the API fails because now it reveals the email addresses of all users. We have Tom, Jerry, Toodles, me, there's Spike Bulldog, there's Spike, and last one is T.I. There he is! But the one we want, the one we care about, is the admin user.
Here's the admin's email address. I'm going to copy the email address, paste it for the answer. We found the admin email and click submit. Congratulations! You passed this challenge by finding the admin's email address.
So let's move on to the next challenge. This is the "Become the Admin" challenge. After gathering information, turning a low or medium severity vulnerability into a high severity vulnerability can be as simple as linking the information together.
Admin accounts are being taken over and deleted. Your task is to discover how hackers are doing this. The second step requires you to prove how hackers can take over an admin account. We're given a link to edit our user account using the API, so we open that up and then use the admin's email and ID from the previous challenge to take over their account with a new access token.
So the answer is not solved right now, and we'll refresh the page when we're ready to check again. So in the link that we're given, we have our name, we have an image URL, and access token. Our goal is to find out how we can take over an admin account.
So we see here that access tokens can be used to give access to the account from other apps, which means this is the approach that we're going to use to take over the admin's account. So to test this out, what we want to do is set an access token for ourselves.
Let's say ASDF, click update, and we see we're taken to our user data page from the API. So we have the ID, the name, the email, the image, and now we have an access token set to ASDF. So let's go back. We know we want to change this to the admin.
So let's right-click and inspect this form to see what data is available for us to modify. First off, we have the form action, which is set to our user ID to the API. So if we change that by double-clicking it, remember we want to take over the admin account.
So let's change that to one because that's the admin's ID. All right, let's look at what we actually care about. There's a lot of information in here. There's a lot of different inputs, but we only care about what we can modify to take over the admin account.
So we've already taken over the action, changed the ID to the admin's ID. Next, there's a hidden email, and that has our email address in there, so that is something we want to change. So paste in the admin's email from before.
Admin. And then next inputs are the name. You can change that or leave it as you want. I'll change it to admin. The next one is the image URL. Leave that blank. Access token—this is where we set the access token that we want to use.
And just to show that we can put anything else instead of ASDF, I'll put FDAS. So the plan here is once we click update and submit this form, it's going to update the admin's account to have the FDAS access token because we changed the form action to the admin's ID, and we changed this hidden email to the admin's email address instead of our own.
And then we set the access token to the access token that we want to set. I'll click update, and here we go! We're automatically redirected. We passed this challenge by taking over the admin account. The answer has been solved.
Let's go back and check the API, and so we see that we have already solved the challenge. But let's check out the data. I'm going to go to the site users index again, so "/Pages/Site/Users," hit enter. I'll print this, and we see now that the admin's access token has indeed been updated to FDAS, indicating that the challenge was successful.
So let's move on to the next challenge. This is the "Delete the Admin" challenge. Sometimes attackers choose a different path, and rather than stealing or controlling data, they choose to destroy it. Admin accounts are being taken over and deleted. Your task is to discover how hackers are doing this.
This third step requires you to prove how hackers can delete an admin account. The goal is to get a link again to delete our own user account using the API, and the goal is to delete the admin account. Right now, the answer is not solved, and we can refresh to check again when we are ready.
So this says delete your account. Click delete to confirm, and there's a big delete button there. Now just like last time, we know we're going to have to modify something in this form, so let's just right-click and inspect it first without trying it out.
And we see, as expected, just like last time, we have a user ID in the form action. So we want to delete the admin. In order to do that, we'll change the user ID from our own user ID of 5 to the admin's user ID of 1.
Let's check out what other inputs might be relevant. These we can ignore, and let's see what's down here. There's just the button for delete, and there's no other inputs. There's no other checks that need to be performed like last time.
So we'll just click the delete button to confirm, and let's see if this deletes the admin. All right! Congratulations! You passed the challenge by deleting the admin account. The answer was solved.
All right, so let's move on to the next recipe. In this recipe, we're going behind the scenes of web applications so you can exponentially increase your chances of doing bad things. We've seen many different ways to attack applications and URLs, but what about what we haven't seen or can't normally see?
When you're on a web page, there's often a whole lot more going on than you realize. This is because developers can make several hidden background requests to APIs—getting, posting, putting, patching, and deleting resources—which makes web pages a lot more exciting and overall less boring.
Without this, every time the web page needs new data, you'd have to wait for the page to reload every single time. But with background requests, there can be several requests for new data going on all at the same time, and you never have to leave or refresh the web page.
It works like this: web pages use JavaScript code to make requests to an API server. You never see. All this server does is send and receive data, and as mentioned earlier, accessing this API opens up greater interactivity, but also so many more possibilities for sensitive data exposure or a little bit of digital negotiation to take place.
Let's take a look at an example now. Click the link below. We're not going to be stealing private user information. All right, so let's start off going to our own user profile page. That is going to show all of your information.
So click on "My Profile." You see an image, you see your title, and if it's private or public. And on the bottom, you have your personal info. So since it's your profile, you should expect to see this.
So for me, my email address, my address, and my IP address—three addresses! How about that? So all my addresses are here. You see you have a friend, Rocky. Click on his name, and so this is Rocky's profile. He looks very similar.
He looks very similar to this guy right here. Hey, it's you! My friend got anything to say? Rocky's profile has his name. It says his little tagline: "Take naps, scratch furniture, live in the meow," and this account is private, and there is no information down here—no private sensitive information.
So since there's nothing to see here, we're just going to give up. Hold on! Remember I told you earlier there can be hidden background requests that we haven't seen yet? To check these out, right-click anywhere on the page, select "Inspect," and go to the network tab.
Now we're going to clear all of this out by clicking this button up here and then refreshing the page. We see there is a request that has Rocky's name in there. So let's click that to check it out. Click on "Preview," and we can see right here this is all the information returned from the API.
It has his address, 101 Salmon Parkway, his bio, his email address, his IP address, his name, his profile picture, and just the privacy setting right there. But we can see that we do have his three addresses, namely his IP address, his email address, and his physical address.
And so this reveals the extra sensitive data we couldn't see in the web page. Now we could even take this URL. So if I were to copy the link address and paste it in the URL, this is exactly what's going on in the background.
Because remember, the APIs—you never really interact with them directly. It's always done in the background with some code that the developers write. You're free to use these APIs in your browser just like this.
And right here, changing the username from Rocky to me to see the different data that gets returned. So what's going on is on the web page, the code running makes the request for the user information in the background and then decides to show all of it if it's our profile or only some of it if the profile belongs to someone else, like Rocky.
Now that we've unlocked background requests, this is going to exponentially increase your chances of finding leaks in websites. But it also comes at a price—namely, there are a ton of background requests on some websites, so you may have to do lots and lots of digging through lots and lots of data.
But in the end, if you do find a vulnerability leaking sensitive information or a new opportunity for a little digital negotiation, it could certainly be well worth your efforts.
Hold on! Now is your chance. Put the skills you just learned to use and solve the challenges for this recipe. This is the "Unlimited Gift Cards" challenge. Background requests can often reveal a lot more information than intended.
A survey company gives out gift cards for completing surveys, but lately, they're losing unbelievable amounts of money buying gift cards without receiving enough survey data to sell. The company is about to go bankrupt, so you need to help understand how gift cards are being hacked and obtained without completing surveys.
So we're given a link to the survey website. The goal is to find three valid gift card codes and submit them below, separating each with a comma. So here's a survey: "Take the survey, win a free gift card! Awesome Apple, Windows, or Penguins."
I'm going to choose the penguin. Forest, mountain, ocean. I'm going to choose the mountain. Cookie, cake, pie. I'll choose cookie. All right, but before we submit, I'm going to right-click and inspect, choose the network tab because we want to capture the background request to see what goes on to create the gift card.
And this is a very important step. Also, make sure you click "Preserve Log" because when you click the submit button, there's actually going to be two requests that happen. So make sure you preserve log, have this checked, and then click the submit button.
Okay, so we have one gift card code right here. I'm going to copy that, paste it in here, add a comma. Now go back to this page. Here are all the requests that were made. The first one looks interesting; it's to a gift cards page.
And then there's another GET request to the surveys page. So it makes sense that when you do a GET request to the gift cards page, we can retrieve more gift cards. I am going to copy this link because I think this is what is getting us our gift card.
So I'm going to open a new tab, paste in that link to gift cards, hit enter, and here we go! We just generated a brand new gift card. So I'm going to copy that card, I will paste it in here, add a comma, and we need one more.
So I'm just going to simply make another request, hit enter, and there we go! A new code was generated. I'll copy here, and now we have unlimited gift cards. This is how hackers were breaking in and making the company go bankrupt by distributing too many gift card codes.
So paste that in, click submit, and congratulations! You passed the challenge by discovering how gift cards are being hacked. So let's move on to the next challenge. This is the "Exposed Hidden Information" challenge.
Data seem harmless at first, but carefully analyzing it can reveal secrets that were added by accident. Scammers have managed to steal $200,000 in wire transfers from employees of a company by making phone calls from the CEO's secret phone number.
Find out how the phone number is being leaked to avoid further losses. So here we're given a link to the CEO's post to investors: "We take security very seriously. As such, we've invested $200,000 to identify security weaknesses in our operations. We're moving forward to strengthen the resilience of the company to provide world-class services to our clients that will help us grow into a billion-dollar company. We will seek an additional $200,000 to help us change the world."
CEO. All right, and there's a discussion. There's some comments on the bottom. So the goal again is to find the CEO's phone number and submit it below. This is just a blog page. Now there's no other information about the CEO's phone number not visible anywhere.
But since we just learned about hidden requests, let's see what might be going on in the background. Right-click and inspect the page, select the network tab. We have preserved log checked. It's just a good idea to have that enabled if you're trying to capture network activity.
And then I'm going to refresh the page to see what may be going on in the background. So the first request is just the blog post, and you can see the discussion normally has just a loading message. And so all the comments, the discussion, get loaded separately, and that is something that could possibly help us.
So let's explore this comments request down here. I'll click on that and then expand these to see what information we can retrieve from it. All right, so these are the comments. This is from Investor A, the comment that was written. Profile information is null.
And then the reply from the CEO. We'll expand that replies, expand this object, and this is a CEO author comment created, downvoted profile. So profile—that's interesting. So let's expand that, and we see right here this is the information that we want.
It not only has the CEO's phone number but also has the email address. So since we want the phone number, let's copy that phone number and then go back to the answer, paste it in, and click submit. Congratulations! You passed this challenge by discovering how the CEO's phone number was being leaked.
It was being leaked through the API that was retrieving the comments because the CEO's profile information was contained in its entirety within the comments from the API request.
So let's move on to the next recipe. Today we're learning a very popular and very powerful tool used by cybersecurity experts around the world. Today we're learning the art of interception using the free version of Burp Suite.
Burp Suite is a tool that can help you in many, many ways when looking for vulnerabilities in websites. In fact, it's probably the number one tool used by cybersecurity experts and bug bounty hunters around the world, and they're not even paying me to say this, but they should.
Anyway, there's a very good reason why it's so popular. An absolutely essential skill in finding vulnerabilities requires you to intercept and modify requests before they get sent to the server. This is because websites restrict what you can and can't do. Developers write code to lock down your behavior in the web in order to prevent bugs and stop hackers and digital negotiators from causing problems.
Hold on! This is your browser on your computer, not the developers', which means you can control absolutely everything that happens next. In my house, we do stuff like this all the time. My house, my house, my house!
Let me tell you something, Tommy: this isn't my house; it's my house! And when you're in my house, sometimes you got to do things my way. The way around these protections is to simply pretend you're playing by the rules, and then after developers run their JavaScript checks, your browser will send the request to the server.
And this is where Burp Suite comes in because it can intercept the requests in between your browser and the server. Let's walk through this with the first example below. We're now going to be installing Burp Suite.
So in this example, we're just going to go over the very basics of intercepting, and in the challenges, you're going to actually get to use it and put it to good work. So let's start off by clicking this link to install Burp Suite Community Edition—that's the free version.
And here we go! Burp Suite Community Edition download. I'm going to download it. All right, let's start it up, click open, and step two for starting Burp, we want to select a temporary project. So let's go with that temporary project, click next, then select "Use Burp Defaults." It's already selected, then click "Start Burp."
We're just going to focus on one specific thing right now. There's a lot going on here, but what we care about is the proxy to set up intercepting. For step three, select the proxy tab from the top menu and then click the "Open Browser" button.
What we want to do for step four is intercept a request. This is our very first interception, so type in "HTTPS example.com" and hit enter. Now is your chance to do some bad things! Burp Suite sits in between the browser and the server, so as it intercepts the request, you're going to be able to modify all the values that are being sent over.
So here, there isn't a whole lot we can do, but let's just change some things. You know, who knows what'll happen? Just say ASDF there, why not? And just type some gibberish on the bottom. Yeah, all right.
And after that is done, go ahead and click "Forward" to forward the request. And hey, we got something! We got a bad request. So you're being bad, weren't you? This is again the kind of the whole point of hacking: to explore, experiment, and try new things out and just see what happens.
Here I am editing this video and realizing you're not quite ready to whip out your mask and hoodie, so I made one more example using Burp Suite. Step one: create an HTTP endpoint using the free request inspector service.
So let's click this link right here and then change the URL to be something that you can easily type in. I'm going to do "Chef Secure" and click "Let's Start." So this now is the URL that we're going to be using to stand in as an API server where we're going to see our requests being sent.
So to start off, copy this link and then paste it in this input box right here. And step two: open the Burp proxy browser. So copy this link and then open the browser. I turn intercept off because we don't want to intercept anything right now. This is just to open up the example.
Paste it in and hit enter. All right, step three: intercept and modify a GET request with Burp. In this step, we're going to do pretty much what we did in the last example, but we're going to change some query parameters that pass extra data to the URL.
And they look like this: there's a question mark, there's the name of the parameter, an equal sign, and then the value. And then you can have multiple parameters with an ampersand separating each of them. So we have "name1=value1" and "name2=value2."
So let's click "Send GET Request," but before we do that, hold on! We got to turn intercept back on because remember we want to intercept this and modify it. So intercept is on. Send GET request. I'm going to click this button right here, and you can see right here back in Burp, it intercepted the request.
So we see the resource is called "Change Me," and "account" is equal to "locked." So this is exactly what we want to change those URL parameters, and this is essentially again how you send data in a GET request.
So to change the resource, I'm just going to change it to my name, Jesse, and then the account I want it to be unlocked. All right, and then what we're going to do is hit forward. Now we have the request inspector open in this tab over here, so let's check it out.
Right here, you see that what was received on the API server was our changes that we made as expected. We have the resource equal to Jesse and account is equal to unlocked. Remember, you can also add parameters as needed too.
So if we were to do that, let's do it again, hit "Send GET Request." This time, let's add a new parameter. Let's just say "new=true." Then we're going to forward the request, and we see it popped up over here.
And we have the resource "Change Me," account locked, and "new=true." So this is what you're going to be using whenever you want to modify anything related to GET requests using Burp.
We're on to step five: send and modify a POST request. So you want to intercept and modify the POST request that gets sent when you click the button below. Change the input value using Burp because you see right here it's not easy to be changed.
We can't just type it in. We could right-click and inspect, but that's just for amateurs. All right, we're using a professional tool that's free. So let's click "Send POST Request." We see right here instead of the data being sent with the URL itself, instead, it's sent at the bottom of the request, and this is called the request body.
So we can change it in exactly the same way, though, and you can see it's separated with a plus sign. So "Change Plus Me," you just use a plus instead of a space. It's just for encoding it properly for the data to be sent over.
But here instead of "Change Me," I'm going to say "Let's First Base, Let's Hack." All right, forward the request, and we're going to see it pop up over here in the request inspector. And you see right here the data that was sent over. You have "input" equal to "Let's Hack."
All right, perfect! The response was received as an okay status. That's just the POST request. You can ignore that and close this tab for now. Step number six: send and modify your request again using repeater within Burp.
There's a really cool tool called Repeater. So in order to get to that, you want to go to HTTP history in this tab right here, select the last request that you sent, that POST request, which is right here, and you want to right-click it and then click "Send to Repeater."
So this highlights the Repeater tab up here. So I'm going to click it, and you can see that this is the request that we just made. The input is "Let's Hack," and I'm just going to change it again. Let's just say "Hello," and then click "Send."
If we look back at our request inspector, we see that the input was sent with "Hello." And we can do it one more time with "Goodbye." Send again, and you see input was sent with the value of "Goodbye."
And this is a very, very easy way to make multiple requests quickly without having to go through the UI and click the button every single time you want to create the POST request. So if something doesn't work out quite how you want, but you have an idea of, "Hey, there's maybe this other way that I can do it," this is the way using Repeater.
And the last step, number eight: intercept and modify a JSON POST request. So we're going to go back to proxy and go back to intercept. And here, JSON—it's just JavaScript Object Notation. It's often used by website developers to send and receive data, and it looks just like this.
In this format, you have a key that is quoted, you have a colon, and you have its value right after that, and the whole object is surrounded by curly brackets. And that's how JavaScript denotes whether or not it's an object.
So click the link below to intercept and modify the POST request containing JSON data. Here we go! We have this data again, and you can see just like the other POST requests, it's sent on the bottom in the request body.
This is typically what you're going to see in background requests. Remember when we worked with those? When you're on a web page, there's often a whole lot more going on than you realize. This is because developers can make several hidden background requests to APIs—getting, posting, putting, patching, and deleting resources.
So here we have "superpow" equals "none," and the reward is zero. We want to change that to be whatever you desire. What's your superpower? I'm just going to say "hacking," and reward—let's give it 500. Forward the request, and you see it in request.
And this is the "Infinite Discount Challenge." One of the biggest security mistakes web developers make is trusting all data that comes in a request—data that can easily be modified by attackers. Instead, they rely on JavaScript code to check values before sending the request.
Products are being stolen from the website. Find out how attackers are doing this. So here's a link to check out a product, and the goal is to use your skills to steal the product by purchasing it for $0.
Bter is not solved yet, and we will be able to refresh this page when we're ready. Now we need to do this in Burp Suite. So the first thing I'm going to do is copy this URL for the challenge, and then I'm going to open Burp Suite.
So now go to the proxy tab within Burp, select "Open Browser." Now that the browser is open, I'm going to go to ChefSecure.com, and then I'm going to log in. So I'll put in my login details and then go to the challenge.
Okay, so now we're back on the challenge page within the Burp proxy browser. So the first thing I'm going to do is check out that link to the product and figure out how we're going to steal it for $0.
So right now, this is a 50g gold bar. You can feel just like a leprechaun when you hold on to this. It's not just bits in a computer, and it's so shiny. The total is $3,456, and there's one item left in stock, so you got to hurry before it's gone.
So I'll check this one-click checkout just to see what happens. So there's an error right here. It says "Not enough funds," and the account balance is $0. So we don't have money, so we have no other option than to get this gold bar for $0.
If you right-click and inspect the page, you're going to see an input that sets the total right here. So this is the value that gets sent within the form. So if you replace that value with zero, we can potentially steal this product for $0 without having to intercept the request.
So let's click the checkout button and see what happens. All right, we got an alert saying, "Nice try, hacker! Try again." So that wasn't successful. There are some extra JavaScript checks that make sure that you don't try to tamper with the data.
Close this out and refresh the page to reset the value. So now we have to intercept the request so we can bypass these JavaScript protections. So just like in the example, what I want to do is turn intercept on for the browser.
Okay, now that intercept is on, I'm going to click the one-click checkout again and then check out the request so that maybe I can modify any of the values. So I'll click checkout. All right, intercept has taken over the request, and let's see what's being sent.
Since this is a POST request, all the data that's being sent in the request is at the bottom. So we have a couple parameters here that we can't do anything with, so we're going to ignore. But if you look at the very end, there is a total parameter that actually sets the value of the product we're purchasing.
So instead of 3,456, let's delete that, modify it, and replace it with the value zero. Then we want to forward the request and let the remaining requests go through. So I'll just forward them and then turn intercept off so that the rest of the requests go through without us having to look at it.
Now I'm going to open the browser back up, and you can see that the challenge was passed successfully by stealing the product for a price of $0. Since that was a success, let's move on to the next challenge.
This is the "Content Creeper Challenge." Sometimes you typing in a URL in your browser won't return anything from an API because the server requires extra data sent with the request. This data is sent in something called request headers.
So there's some extra information about what can be sent, such as content type and authorization containing a secret token. And so what's going on is someone is stealing private content and selling it. The developers say the issue has been fixed, but you know better than to trust developers, right?
They have placed a bounty for anyone who can get their secret. So here's a link to your content dashboard, and the goal is to find the developer password and enter it below. So here is the content dashboard, and we can see this is my content dashboard right now.
And public content, there's nothing to display. Private content, there is this. So on the bottom, we have a developer's note. It says, "We've added extra security to protect your private content. It is now impossible to steal. Don't believe us? Here's a link to my private content containing my password. It's unhackable."
So let's check that out. I'm going to open that link, and 401 Unauthorized. Okay, so the URL right here is "/Pages/Content/Dev/Private1." So there are some protections. I can see my private content, but when I try to view the developer's private content, it's unauthorized.
So let's see how this is working in the background. In order to steal the developer password, I'm going to turn intercept on and then refresh this page. All right, so the first request right here is just to get the content dashboard.
So we can forward this request; it's just to get the first page. There's a next request that goes to get our own private content. So the GET request is to "SL Pages/Content/SL Me-Private1."
So this is the URL for our private content. As the challenge specified earlier, there's extra data that's being sent over. It's not just the GET request right here. So there's also the other headers that are being sent. A lot of these are just standard information, like the cookie, just tells us that we're logged in and who we are, and we can't modify this because it's protected.
So one other thing that looks like it could be helpful for us is the authorization token right here, which uses a token for us to access our private content. Now I'm going to forward this request just to show that it loads the page.
And remember, the goal is to steal the developer's private content, which contains the password. So one thing that looked interesting was when we sent the request to our own private content. So now the plan here is, since we can intercept the request to our own private content, we can just replace the URL from our private content to the developer's private content.
So we can simply do that by copying the URL for the developer private content, "Dev Private1," and then I'm going to keep intercept on and refresh the page again. And whenever it gets time to load our own private content, I'm going to replace the URL with the developer's.
So I'll click forward for the main page, and now this is the request that we want. So the request is being sent to "Me-Private D1," and so now I'm going to delete that and then paste in the developer URL for "Dev Private1."
And then click forward, and now you can see the developer's private content has been leaked, which contains the password, which is "secret b00m." So I'm going to type that into the password over here: "secret b00m," and then click submit.
And since we still have intercept on, I'm just going to take that off, and congratulations! You passed this challenge by discovering the developer's password. Now to go back, the reason why we couldn't access it directly is because we needed to also send that authorization header because the API required us to have a valid authorization token when accessing private content.
And that's the end of the no-code hacking course. I hope you enjoyed the course, learned a lot, and I hope you had a lot of fun doing it. Let me know in the comments what you thought of it. Thank you for joining me. I'll see you next time!