Today's estimated reading time is: 13 min

Last week we saw a brief introduction to cross-site request forgery

In this post, I will show you almost all methods to exploit CSRF vulnerabilities with some common bypasses!

Today's post is brought to you by Nova Security

The cloud-based attack surface management & vulnerability detection platform that finds vulnerabilities before you do.

Waitlist is open, join today ===> https://novasec.io/

Basic CSRF Exploitation:

So we’ve seen what cross-site request forgery issues are

And although it might be still a bit vague for you, today’s post should take care of that as we are going to look more into the exploitation part

Basic CSRF exploitation involves you making a request that causes an action that modifies data on behalf of an authenticated user’s account

And a simple proof of concept may look like this:

https://example.com/messages/compose?receiver=account2%40example.com&message=test&send=1

The above PoC is a simple GET request made to the /messages/compose endpoint and it will send a message on behalf of our first test account to our second test account (account2@example.com) with the message “test”

In a real-world attack scenario, an attacker might:

1. send this as a link to the victim through social engineering

2. include this in the vulnerable web app as an iframe, image src, link, etc as long as the SameSite cookie doesn’t interfere (everyone who visits that page with the iframe/image/… or clicks on the link, will send the message)

3. or send a link to an attacker-controlled page that auto-submits an HTML form (more on this later)

CSRF Exploitation bypasses:

Method-based CSRF:

We’ve seen what a basic CSRF PoC can look like however chances of finding such simple cases are very rare

And GET requests are almost never used to perform an action so developers usually fall back to using a POST/PUT/PATCH request

The thing here is, they sometimes forget to remove other accepted HTTP methods or are just unaware of the capabilities of the technology they use (CMS, framework, library to parse requests, …)

And this can open a gap for us to still exploit CSRF by changing the request method, let’s look at an example below:

In the image above, we can see a PUT request getting sent to the API

And we can’t just send a PUT request using an HTML form (not possible) or Ajax request without triggering CORS (another browser security feature that allows you to declare what resources are allowed to be shared on other origins)

But on further inspection, you can notice that you can change the request method to GET and supply all the body parameters in the URL query

We can easily send this link and it would send the message on the victim’s behalf:

Content-Type-based CSRF:

Most REST APIs only make use of JSON data in requests

And thing is, if you try to replicate the request using an HTML form, you’ll notice that it is not possible to do so using application/json content-type

Even if you try using an AJAX request, a pre-flight request will be made and will block you because of Cross-Origin Resource Sharing (CORS)

In this scenario, you’d need to try and enumerate any other content types that the endpoint may accept

For example, changing application/json request body to application/x-www-form-urlencoded may look like this:

This would enable us to still perform the CSRF using an HTML form as no CSRF token is used (because developers initially thought that using JSON is sufficient to mitigate CSRF):

In some cases, you may notice that only a JSON object is allowed but any content type is accepted

In this case, you’d want to make use of the text/plain content-type inside an HTML form:

In the image above, we need to split up the JSON object to make it fit in an HTML form, typically, it’ll add a = between the name and value of the parameter

We fixed this by inserting it in the message field

Lack of CSRF token validation:

I’ve seen cases where a CSRF token is present (in the request header or as a parameter) but isn’t validated at all

This opens up a lot of possibilities for us, for example, we could:

• Remove the CSRF parameter or header completely and send the request

• Change it with a guessable value like “1” or “batman” or anything else

• Change it with another value as long as it is the same length as the original CSRF token

• Change it with another CSRF token (one of your second account or a previously generated CSRF token)

To provide some more context on the last case: this is usually because the CSRF token is not tied to the user’s session

Instead, developers decided to add all generated tokens (that are active) and save them in a database

And that means that any generated token can be used by any user (as long as the token is present in the database)

Cookie-based CSRF:

Another approach that some developers take to mitigate CSRF attacks is generating the token and saving it in a cookie + supplying it in the request body

And on the server side, both values get compared

If both tokens match, then the action is allowed. Otherwise, your request gets rejected

Now, this approach is generally not recommended as you can create a cookie yourself using a CR/LF injection (or some other function that allows you to set cookies) and supply the same token in the body as well, like in the image below:

To further explain what’s happening here is:

1. First of all, we make use of a CRLF Injection to inject the Set-Cookie: CSRF_TOKEN={CSRF_TOKEN} in the response body (the CSRF token can be a previously generated one or any token that has the same character length). This will set the cookie for us and we use an image src for it as a simple GET request is required

2. Next, it will submit the request using the same token as the one set in the cookie

Login/logout CSRF:

You’ll often notice that you can log yourself out by visiting an endpoint or a route, for example /account/logout

This is called “Logout CSRF”, the same as when logging in via OAuth for example (when you opt-in for your credentials to be saved), this CSRF issue is called “Login CSRF”

Login/Logout CSRF are generally not considered to be an issue in bug bounty as all that matters is the impact — which is none at the moment (unless otherwise mentioned by the program)

However, this bug is perfect for chaining it with a stored self-XSS!

I won’t go into depth here but I will link down an article that goes over this attack scenario

The lesson here is that “useless CSRFs” are not always “useless”, sometimes you’ll need to chain multiple bugs together to achieve the most impact

Referer header CSRF:

I personally haven’t encountered this before but apparently, there are developers that check if a request is valid if the referer header is matched

And the way to exploit this is by trying to match the loosely set regex pattern

For instance, you could try:

• and make sure the target’s domain is present in the URL query parameter or path: https://attacker.com/target.com/x?target.com

• or try to use the target’s domain name as the subdomain: https://target.com.attacker.com/x

Sometimes there’s no handling done at all when the referer header is not set

In that case, it is always a good idea to remove it from the request by setting the following tag in the head element of your proof of concept:

<meta name="referrer" content="no-referrer">

Resources worth reading:

• CSRF guide on exploitation + various PoCs by HackTricks

• Another CSRF exploitation guide (this one includes a cheatsheet to check if your target is vulnerable to CSRF) by Cobalt

• CSRF lab to practice exploitation by Portswigger Academy

• Some more CSRF Examples by BrightSec

• 6 CSRF Bypasses explained by Shahmeer Amir

• A chain of Self-XSS + Login/Logout CSRF to account takeover by Renwa

• A list of disclosed reports of real-world CSRF examples on Hackerone Hacktivity

• Account takeover via CSRF by sharing a cat picture by Matti Bijnens

If you're interested in levelling up your bug bounty game, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server for recon:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

m.do.co/c/7b360ceed203

• Help automate your vulnerability and recon scans with less effort using Nova Security:

Cloud-based Web & API Security Scanning. Simplified - Nova Security

Cloud-based next-gen vulnerability scanners to keep your online business safe 24/7! Start securing your website now!

novasec.io/?ref=newsletter

Thank you for reading this far!

I hope you've enjoyed & learned something new from this post!

If you have any feedback, please do not hesitate to reach out! You can reply to this email directly or send me via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Today's estimated reading time is: 7,6 min

Last few weeks we've seen Broken Access Control vulnerabilities, how to identify + exploit various cases.In the coming weeks, we're going to dive deeper into Cross-Site Request Forgery vulnerabilities!In today's post, we will mainly focus at what CSRF vulnerabilities are and how they arise, next week will all be about exploitation!

Today's post is brought to you by Nova SecurityThe attack surface management & vulnerability detection platform that finds vulnerabilities before you do.Waitlist is open, join today ===> https://novasec.io/

Cross-Site Request Forgery:

Cross-Site Request Forgery (or CSRF) are vulnerabilities that allow attackers to conduct actions on behalf of the victimNow do not confuse this with IDORs (or BAC issues in general) as CSRF happens after deceiving a victim into clicking a malicious linkLet's take a look at a simple example to understand it even betterImagine this...You've logged into your second test accountAnd you're now testing a feature that allows you to send messages to other users and whenever you click on the "Send" button, the following HTTP request gets sent:

Guess what other vulnerability type might be exploitable here ;)

In the image above, we can see a GET request with 2 query parametersNow again imagine if we change those 2 query parameters' values and open the link using our first test accountCorrect, it will perform the same action but on our first account (victim), resulting in sending messages to anyone on the first test account's behalf without the victim's knowledge.Now of course this is a simple case of a CSRF vulnerabilityAnd the impact depends on how important the messaging feature wasIn some cases, CSRF vulnerabilities can even lead to account takeovers (imagine if you could apply the same method as above but change the user's email address or password!)However, the chances of finding these kinds of CSRFs are slim as most applications have some form of CSRF protectionBut don't worry about that, next week we will go over various exploitation approachesLet's first look at how you can easily identify these + how these issues often arise

Identifying CSRF vulnerabilities:

Any (privileged) function that performs some kind of action (like modification of data) can be potentially vulnerable to CSRFHowever, there are a few conditions that must be met to make it exploitable:

1. First of all, you should find a privileged action. One that can modify, add or delete data such as changing a user's email address or sending a message or even sending/verifying transactions

2. The second thing is your session ID (the ID with which a web application can verify your account and privileges) should be a cookie (with SameSite disabled) or HTTP Basic/certificate-based authentication should be used so that the browser automatically adds the authentication data to the request.

3. The last condition is that the request should not contain any kind of value that is unpredictable (such as in a query parameter or request header)

Besides these 3 conditions, there are also some other factors that play a role in whether for example, an API endpoint is vulnerable to CSRF or notBut also the request method and content type that the API accepts (this will become more clear once we start looking at exploiting CSRF attacks)Now you may think that it's super hard to find an exploitable case because of all the requirements, but understand that:

• Even if the web application only sends a specific type of request to an endpoint, it is possible that the endpoint also accepts other request methods or content types

• The request method can sometimes be overridden using query parameters or HTTP request headers

• Not every query parameter you see in a request (even the ones that have unpredictable values) is required to be supplied

• You can automate the process of crafting a working CSRF proof of concept

But again, this will become all clear in the next post when we learn to exploit and craft our CSRF payloads

Additional Resources:

• Cross-Site Request Forgery Attacks by OWASP

• A guide + labs to learn more about CSRF vulnerabilities by Portswigger Academy

• Learn more about what SameSite cookies are by MDN

• Bypassing SameSite cookie restrictions by Portswigger Academy

Don't worry, way more resources in next week's post ;)!

If you're interested in leveling-up your bug bounty gameI can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server for recon:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

• Help automate your vulnerability and recon scans with less effort using Nova Security:

Automated Web Security Scanning Simplified - NOVA SECURITY

Actively search for vulnerabilities 24/7 using next-gen automated security tools! Start securing your website now!

https://novasec.io/?ref=newsletter

Thank you for reading this far!

I hope you've enjoyed & learned something new from this post!If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!Have a nice day and see you in the next post!You can follow me on Twitter to receive upcoming updates on this newsletter:

Today's estimated reading time is: 11,5 min

Last week we went over various different IDOR cases and how you can exploit each one of them.In this week's issue, we are going to look at more advanced (and harder-to-spot) IDOR vulnerabilities.

Today's post is brought to you by Nova SecurityThe attack surface management & vulnerability detection platform that finds vulnerabilities before you do.Waitlist is open, join today ===> https://novasec.io/

Advanced IDOR exploitation:

"Object-based" IDOR:

Most APIs that you'll come across nowadays are REST APIsThese kinds of APIs often accept data in the form of a JSON object and sometimes developers mess up with handling this dataAnd you can use this to your advantageLet's go through some examples belowYou surely have seen this kind of request before:

In the above request, we tried to update the data of our second test account (using our first test account)And as you can see, it of course returned a 401 UnauthorizedNow it is possible for us to wrap the user ID in an array and with that supply multiple IDs:

Now, depending on how to backend might handle it, it can update the data for both users just like in this caseYou can also map it into another JSON object (example of the POST body):

Or use a boolean (be careful with this):

You can try various other things such as:

• replacing the user ID with a very large digit: 123500000

• adding zeros in front of the user ID: 000001235

• replacing the user ID with a negative digit: -1 or -1235

• replacing the user ID with a decimal number: 1235.0

• passing multiple user IDs as a string value separated by a comma: "1234,1235"

• replacing the user ID with a wildcard or a percentage sign (again, be careful with this if you're testing it on features that update/delete data): "*" or "%"

These are just a few examples and I recommend trying all of these outAnd depending on your target, it can result in an IDOR vulnerability

Multi-step IDOR:

These types of IDORs can often easily be exploited as they are sort of "hidden" behind the first pageBasically, the vulnerable API endpoint is used AFTER you complete a step or a series of stepsFor example, say you got a target that has a feature that allows you to send in your details and apply for job offers:1) You fill in the first form and click next (data gets saved in the background as a draft application, but no IDOR on the auto-save endpoint)2) You submit your application (data gets saved another time, no IDOR on this new endpoint)3) In the last step, you get to review your details before submitting the final application (data gets saved but no authorization checks are set in place >>> IDOR on this last endpoint)From the example above, we had to go through a series of steps that all looked secure but the last step (reviewing and submitting final changes) did not properly check for any authorizationThese are multi-step IDORs and can easily be exploited if you understand the target you're testing well enough

Second-Order IDOR:

Second-Order IDORs are IDOR vulnerabilities but the only difference here is that the web app uses your input to indirectly reference an object or resource.Your ID gets stored first, and then used later to reference a data resource.There are a lot of different cases like these but I will only go over 1 case in this article (check the additional resources section for another case of this type)I found this special case a while ago where an API reflected my input without any validation in the path of an internal-only API request It allowed me to make HTTP requests on behalf of the backend API (SSRF) and unfortunately, there was nothing that I could chain this with except the IDORLet's first understand how this case of IDOR can arise as it will help you understand how you can identify these easily as wellMost companies today tend to separate their web project into components (or layers, it's called a "multi-tier" or an "n-tier architecture")And the thing here is, when user data is passed without any type of validation to another layer (or service), it may introduce weird (and exploitable) behaviour, just like in this caseNow one thing to mention is that I found this on 1 single API endpoint, the other endpoints seemed to URL encode my input first before forwarding it to the internal API (I recommend checking for all API endpoints)Let's take a look at a simple diagram:

When I requested my profile data, a POST request was sent to the APINext, the request got forwarded to the internal API, and afterwards, the internal API retrieved my info from the database and returned it backAnd as you might have noticed, the user ID got reflected in the path but without any validationThis gives us 2 options:

• We could either inject a new line feed character and request any other resource on behalf of the internal API

• Or we could traverse paths and retrieve another user's ID

At first, I tried exploiting the SSRF vulnerability:

And now you may ask how I came up with thisI simply tried injecting a path and it returned a 404 (you could also try passing a hash fragment, a query parameter and/or URL encode your input):

The second option is traversing paths like below:

And depending on the target, it can be vulnerable if there are no authorization checks put in place on the internal APIThis is most likely when the API does not forward the authorization header for exampleThis is just one case of a second-order IDOR why my user input was used in a second query without any validation

"ID-less" IDOR:

ID-less IDORs are just like any other IDOR vulnerabilities however, they are a bit harder to spot.Let me explainSay you have a target that you're testing out and looking at the intercepted requests, you keep seeing that all your profile data gets retrieved from the following API endpoint (this is just an example, there are many other variations):

If you haven't noticed yet, the "current" keyword is a reference to your accountBut in the response, we can also see that there's a customer ID in thereAnd you may have already guessed it, sometimes replacing the "current" keyword with your ID will return the same response:

And if it did (in your case), then it may be vulnerable to IDORNow let's be real, chances to find an IDOR on such a critical endpoint are very slimThat's why you should look furtherSo here's what I did:I found the exact same case a while ago, I replaced the current keyword with my ID (that I retrieved from my response) and got the same response (if you receive a 404 Not Found status, know that the ID is ineffective on that endpoint and try other identifiers such as your email)So I went ahead and changed the ID to my second account's ID and as you might've guessed, I faced a 401 UnauthorizedBut instead of stopping there, you should try the same technique on other API endpointsI did just like that and found that I was able to remove 2FA from my second account

Additional Resources:

• Another example of a second-order IDOR vulnerability by Ozgur Alp

• A deep dive into Broken Access Control Vulnerabilities by Inon Shkedy

• An IDOR Lab by Portswigger to test for IDORs

• A Twitter search query for IDOR bugbountytips (writeup links often get shared on Twitter, recommend taking a look there for any resource you need)

Thank you for reading this far!

I hope you've enjoyed & learned something new from this post!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

• Help you save time & earn more bounties using Nova Security:

Cloud-based Web & API Security Scanning. Simplified - Nova Security

Cloud-based next-gen vulnerability scanners to keep your online business safe 24/7! Start securing your website now!

https://novasec.io/?ref=newsletter

Today's estimated reading time is: 13 min

Last week we saw a brief introduction to broken access control issues, what they are in general and where they often are present in web applications.Today we are going to dive deeper into IDORs. IDORs are easy to spot but most people aren't finding them because they aren't looking where they should be.That's why I made these posts. By the end of these, you will be able to find way more IDORs. I highly recommend also reading all the articles I attached in the additional resources section.

Today's post is brought to you by Nova SecurityThe attack surface management & vulnerability detection platform that finds vulnerabilities before you do.Waitlist is open, join today ===> https://novasec.io/

Insecure Direct Object Reference:

IDOR vulnerabilities arise when the web app you're testing accepts & uses user input to get back or update a data entry without validating if that supplied ID is in fact yours.As a new bug bounty hunter, you'll notice that despite all the claims that this vulnerability type is easy to spot, you still can't find an IDOR vulnerability.And that's okay, to find more IDORs you should spend more time on targets that have a large code-base + should focus on newly introduced features or forgotten/less-accessible features. As these will often contain such vulnerabilities (they usually haven't been tested before).For example:• Instead, of looking for IDORs on your profile (a heavily tested functionality), look for them under your backup settings (a less exposed place).• Instead of focusing on the main feature (posting an image), look at the options it has (editing posts or images).• Instead of focussing on editing the post, look at the auto-backup feature.• Instead of testing a feature that has been tested over and over again, test that newly implemented 2FA security feature.See a trend here now? GoodNow that we've clarified where to look for IDORs, let's start with looking at some basic IDOR examples and in the next post look at some more advanced and harder-to-spot cases (this will be sent next week)!

Basic IDOR:

Basic IDOR vulnerabilities are where we can easily change a predictable identifier (ID) such as a numeric int value with another ID.Let's take a look at a small example. Our current account has the user ID of "1234".Making the following request should allow us to return the data of another user, in this case, our second test account.

It's sometimes just as easy as that, but it can get trickier.Let's go through some more cases.

UUID-based IDOR:

More and more web apps start to enforce the use of UUIDs because they aren't predictable and can not be brute-forced in any way.If you are unfamiliar with what a UUID is, no issue below is an example of one:

However, this shouldn't be seen as the only measure against IDOR vulnerabilities. As many times, these UUIDs can be retrieved or returned back in the response in another way (or form).Say we got the following API endpoint: /api/users/{UUID}

Making a GET request to that endpoint returns all data associated with that user. However, upon taking a closer look at the response returned back, we can see a second user ID. One that is predictable.What we could do now to exploit this IDOR is 1) try replacing the UUID with the numeric ID and 2) find the UUID referenced elsewhere in the web application.The first option is easy, we simply send the following GET-based request and check whether the same information is returned, and apparently, it is:

The second option involves us looking for our UUID in the responses. One way to do so is by using our proxy interceptor and searching for our UUID and afterwards looking for other users' UUIDs at the same place.Another way is to just simply to check common places where that UUID may get leaked. For example, public profiles, built-in messaging features (they have to identify the receiver in one way, right?), profile pictures, etc.You could also look for these on public sources such as the Wayback Machine (archive of the internet) or search engines such as Google, Bing, etc.Don't worry if you are unfamiliar with using public sources, here's an example.Say we are looking for more UUIDs, all we got to do in this case is use search filters and search on Google and Bing: "site:api.example.com inurl:/api/user"You could also search the internet archive for any archived UUIDs. Simply visit archive.org/web and submit the URL, afterwards look at the saved URLs as that is where you would want to look.

Method-based IDOR:

Before I tell you how to test for this type of IDOR, let's first take a look at a small code snippet. It'll help you understand why and where these types of misconfigurations often arise.

As you can see in the above image, 1 route is defined: /api/messages/{ID}However, it accepts 2 HTTP methods, one function accepts the POST method, and the other one the DELETE method (both functions are able to delete the message).And as you might have noticed, the POST method does enforce the authentication & authorization checks. Meanwhile, the DELETE method does not.This is often the case when new API endpoints are added. Developers forget about implementing the right authentication & authorization checks and it doesn't get caught until you find & report it.Getting back to the example. Sending a POST request, like below, to delete another message ID (that isn't yours, like "1235") will return a 401 Unauthorized.Meanwhile sending a DELETE request to the same endpoint, will delete the other message and return 200 OK.

I also recommend trying and changing the content type of your request body as sometimes, the same can happen here as well.

IDOR through outdated API Version:

This is also applicable to different API versions. For example, say the /api/v2/message endpoint did not allow you to delete the message using the DELETE method.Trying an older API version such as /api/v1/message might allow you to do so easily:

This is often the case when a new version of an endpoint gets introduced, but the older one is still accessible.

IDOR through parameter pollution:

Parameter pollution is basically supplying the same parameter name multiple times in a request (each with a different value).And depending on the service that is running and accepting/parsing the parameters, it may concatenate the values, only read the first value or only read the last one.This behaviour can be used to evade certain filters to still retrieve other users' data. That is why it is important to also test for parameter pollution when testing for IDOR vulnerabilities.

IDORs in GraphQL:

As in other services, GraphQL can also be misconfigured and contain IDOR vulnerabilities (and much more).Exploitation however is sometimes much harder as you need to identify the queries and mutations (sort of like methods/functions to identify what action to conduct) available + craft a valid request.Sometimes, the Introspection Query (you ask GraphQL to return all information about what queries it supports) is enabled, and with that, you should be able to list all available operations.If that is not the case, you could also make use of the built-in autocomplete feature. As with that, you'll also be able to enumerate more operation names just by supplying a few common keywords.However, if both features are disabled, I recommend going through the whole application and using each and every functionality available + reading javascript files as they also often contain operation names.With that, you should be able to enumerate all operation names and test each one of them without any issues. Sometimes it's just replacing an ID with another ID.

Additional Resources:

• Find more IDORs by @thaivd98 (some very interesting cases)

• A Notion DB to find more IDORs (you don't need Notion to view it)

• Find more IDORs by @vickieli7

• Tips and Tricks for finding more IDORs by AON.com

• Top 220 IDORs found by @_nyan (highly recommend going through all disclosed Hackerone reports)

• Top 25 IDOR reports (again, read all 35 disclosed reports, it will help you understand IDORs!)

• More info about HTTP Parameter Polution by OWASP (learn more about HPP vulnerabilities)

• An official introduction to GraphQL by GraphQL (recommended if you want to get really into GraphQL hacking)

• A detailed blog post all about exploiting GraphQL by @Yeswehack (has the introspection query)

• A Twitter search query for IDOR bugbountytips (writeup links often get shared on Twitter, recommend to take a look there for any resource you need)

Thank you for reading this far!

I hope you've enjoyed this post! In next week's issue, I will go through advanced IDOR exploitation techniques! Stay tuned!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

• Help you save time & earn more bounties using Nova Security:

Automated Web Security Scanning Simplified - NOVA SECURITY

Actively search for vulnerabilities 24/7 using next-gen automated security tools! Start securing your website now!

https://novasec.io/?ref=newsletter

Today's estimated reading time is: 12 min

We've seen XSS vulnerabilities first as they are easy most of the time easy to spot.In the coming weeks, we're going to dive deeper into Broken Access Control vulnerabilities!They are generally also very easy to spot, as long as if you know what you're looking for, and are by nature, often high-severity vulnerabilities!Simply put, BAC or Broken Access Control vulnerabilities allow you to access and/or make changes to (sensitive) data, and functionalities or pages without being authorized to do so.A simple example would be you having access to order details of (all other/) another client on an online e-commerce webshop without their knowledge.

Today's post is brought to you by Nova SecurityThe attack surface management & vulnerability detection platform that saves you time, and earns you more bounties.Waitlist is open, join today ===> https://novasec.io/

Broken Access Controls:

Access controls are present within an application to prevent unauthorized users from accessing certain pages of functions.However, sometimes it is quite possible that during the implementation of a new feature, these access controls get forgotten about.That's why you should always aim at looking for vulnerabilities in new features as a beginner.

Now that we covered what access control issues are and where they usually originate from, let's take a closer look at what kind of shapes and forms they can all come in.In next week's post, I will continue with this topic by explaining more in detail where you can find them and what payloads you can use.

Vertical Access Control issues:

Vertical access control issues are very easy to understand as the name says it all.You elevate your privileges vertically.So what does that mean? Let's take a look at a small example.Say you found a vulnerability that allowed you to take over any user account. Taking over an admin or staff account would elevate your privileges vertically as those types of accounts often have way more access than standard user accounts do.

Insecure Direct Object Reference (IDOR) issues:

Insecure Direct Object Reference or IDOR vulnerabilities are a form of horizontal access control issues.IDORs are usually found in APIs and websites. Exploitation often includes changing an account identifier to someone else's.Don't worry if you didn't fully get it, let's take a look at a quick example below:

In the image above, we can see the front end making a request to the API to fetch our user data.However, if we examine the request more carefully, we can see that a user ID is supplied as a request parameter.Removing the query parameter returns a 400 Bad Request, which tells us that the parameter is used by the backend to fetch our data!Supplying another user ID of our second test account confirms that this particular API endpoint is vulnerable to IDOR as it returns the user data associated with the second account.This is a major issue as anyone can view the private data of other users without being authorized.Besides reading data, IDORs can also allow us to modify, create or even delete someone else's data without being authorized to do so.Another thing to note is that user identifiers or user IDs can come in multiple forms and shapes. IDs can sometimes be email addresses, UUIDs, hashes or even signatures.It is always recommended to look at a request very carefully for any IDs.Do remember that IDORs usually lead to vertical access control issues.

File-based access control issues:

To view certain (sensitive) files, you must have the right privileges in order to view them.At least, that's what should happen. However, this is not always the case.Sometimes, developers deploy code to their hosting platform (such as Amazon S3 or Google GCP, etc.) or place sensitive configuration files in the same folder where the website is hosted.When this is the case, and no single server rule is set to block anyone from reading the file contents, it'll give you access to sensitive web config files or sometimes even backup files.This is sometimes the case for web config, GIT config data & htaccess/htpasswd files for example. These files often contain sensitive server configuration data and are not meant to be public.The same case for backup files (which often contain full source code of the backend for example).Very recently, I found a JAR file referenced in one of the javascript files which was obtained via a very unique approach (I will tell you more about it in a few weeks or so).It turned out that each new version of the compiled JAR file gets uploaded with the Java application.I was able to download and decompile it locally. It gave me access to the entire source code of the app (pentesting a web application when you have the source code is way easier and often allows you to find vulnerabilities that are very hard to find).File-based access control issues do not stop here, it is sometimes possible to get access to an unprivileged part of the web application through forced browsing.This attack often revolves around navigating to the path or file directly and with that bypassing any set restrictions.No issue if you didn't fully get it. Let me explain to you with a simple illustration:

As we can see in the image above, requesting the /admin route will redirect us back to /admin/login (watch the Location response header).Now say we did our homework today and found through content discovery another route called /admin/dashboard. Navigating it resulted in a 200 status code with a huge response body (meaning that we most likely successfully bypassed the login interface and got unauthorized access to the admin dashboard).This technique can be used in many examples, such as for example bypassing 2-factor authentication pages, email verification, etc.

Access control issues via controllable request parts:

Say, for example, a developer added for development purposes a query parameter that when supplied, would bypass an authentication form or display more and expose you to more functions or data than normal.For example, navigating to /dashboard would return you to your dashboard as usual, however, passing the ?debug=1 query parameter & navigating to /dashboard?debug=1 suddenly returns a lot of sensitive configs & debug data.Sometimes, web apps may allow you to view certain pages based on a request header such as the Referer header. Portswigger Labs has a perfect example of it.I've personally never encountered this with the Referer header before except with some custom headers that gave me access to other endpoints. You often find them referenced in JavaScript files.

Location-based access control issues:

This is a more uncommon or less detectable access control issue as your device's location matters.Basically, if your public IP matches a certain whitelist that the organization or company has set up, then you may get access to additional features that are only available in a specific country or region.You can test these by using different VPNs.I personally encountered this type of access control issue only once and I realized it was location-based after the triager couldn't reproduce my previously found vulnerabilities.It turned out that they whitelisted a public IP space and mine was included in it (I couldn't access the vulnerable staging website with a VPN for example).

Additional Resources:

• A more in-depth article with some more examples of access control vulnerabilities from Portswigger (including labs)

• OWASP's Broken Access control post with some common examples

• Broken Access Control examples by Snyck

Next week, I will add much more resources and writeups to start finding way more IDORs!

Thank you for reading this far!

I hope you've enjoyed this post! In next week's issue, I will continue to go through Broken Access Control issues! Stay tuned!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

• Help you save time & earn more bounties using Nova Security:

Automated Web Security Scanning Simplified - NOVA SECURITY

Actively search for vulnerabilities 24/7 using next-gen automated security tools! Start securing your website now!

https://novasec.io/?ref=newsletter

Today's estimated reading time is: 12 min

Imagine thisYou found an injection point, spent 2 hours finding a bypass that works and FINALLY got that alert box popupAnd now you've got to escalate the XSS to an account takeoverYou look at the cookies, all sensitive ones are HTTPOnly :/You check whether you can change the password, and you notice that the previous password is really requiredYou checked whether you can turn off 2FA, and you see that the current 2FA code is also required...You tried so many ways and conclude that you can't escalate it any further...In today's post, I will help you go over plenty of ways how you can escalate XSS vulnerabilities to account takeovers through leaked session cookies, access tokens, and sometimes even to RCE!I will also share some unique findings I found a while back, let's get into it!Just a small reminder, all the proof of concept code that I share here is just to give you an idea of how you can achieve different tasks. Please adjust the PoC code according to your target for it in order to work.Also, to keep the post length reasonable, it is not possible to include all possible ways to achieve account takeover (as there are plenty of ways to do so). I've included the ones that are generally not very known or shared.

Today's post is brought to you by Nova SecurityThe attack surface management & vulnerability detection platform that saves you time, and earns you more bounties.Waitlist is open, join today ===> https://novasec.io/

Sensitive cookie leak:

Sometimes, even when cookies are set to HTTPOnly, they can be reflected elsewhere in the application.This is usually due to developers reflecting it in the response body by error or because they need it to be retrieved later (while also enforcing the cookie security).A few ways to look for this are:

• Looking in your proxy interceptor's sitemap for your session cookie's value (or cookie name). If you do not have Burpsuite Pro, you can also crawl the entire site as an authenticated user and grep for the token in the response body.

• Checking the response body of the API that returns your profile data (example: /api/v1/me, /api/v1/profile, ...)

• Checking for any CRLF injections on pages that return your cookie in the Set-Cookie response header (important thing is to make sure your injection point is ABOVE the Set-Cookie header as you need to transform the remaining headers in the response body).

Now, if you've found your session cookie being reflected inside the response body, all you've got to do is to make an HTTP request to that page. Extract the value using a regex pattern and send it back to your end.Here's a simple proof of concept code (you may copy this, but do adjust the details first according to your needs):

Access Tokens and JWTs:

Most modern web applications today are built with front-end JavaScript libraries and frameworks such as React, NextJS, VueJS, Angular, etc.And to keep track of users, they usually don't make use of cookies but instead, use JSON Web Tokens or access tokens.These are often stored in your web browser's local or session storage and can be easily accessed via the LocalStorageAPI or SessionStorageAPI.Sometimes, these can even be stored in your IndexedDB or Web SQL Database (although that may be much rarer to find).I recommend mapping out all possible ways that the web application may have been used to store your access token.One last note: web applications built using front-end javascript libraries and frameworks are not vulnerable to reflected XSS as they are built differently. By default, they encode all user input before reflecting it. However, this does not protect it from being vulnerable to DOM-based XSS vulnerabilities! If the web application passes your raw input into a DOM source, you may be able to execute javascript.

If you did find the access token in your local or session storage, all you've got to do is use the API to retrieve the token, and send it back to your end:

Access Tokens and JWTs in PWAs:

One thing I've encountered in the past was a web application that was built using the NextJS framework.It was vulnerable to DOM-based XSS, but I couldn't identify any kind of sensitive tokens in the local storage or session storage.However, if you're familiar with how Progressive Web Applications (PWAs) work, you'd understand that these save user data in the response body as a JSON object (to be retrieved later).

You can usually identify a PWA using Wappalyzer or by just looking for the "__PWS_DATA__" id in one of the script tags.

All I had to do to obtain all user data (including PII such as the address, full name, phone number etc. + access token to invoke the API), was to read the data from the window property (or make a request to any page). Extract the script tag's value, and parse its contents using the JSON parse method to retrieve the access token for example. And send it back to my end.

In my case, the company was using Apollo GraphQL and had all that data stored inside the JSON object.

WordPress XSS to RCE:

Twitter

Ever heard of XSS to RCE? Now you do.Next time when you find an XSS vulnerability in a CMS like WordPress, escalate it further via CSRF to remote code execution!I can't explain it any better than @brutelogic himself, but instead of going for an alert box, you basically trick the admin into visiting your XSS PoC link. And create a plugin on behalf of the admin!Easy, impactful yet most forget about this!

Compromising CMSes with XSS - Brute XSS

CMSes (Content Management Systems) are a perfect target for XSS attacks: with their module installation features and the possibility to know all the requests done by a legit administrator of the system previously, it’s pretty easy to mount a CSRF (Cross-Site Request Forgery) attack against him/her. By taking the anti-CSRF token/nonce and doing the subsequent … Continue reading Compromising CMSes with XSS

https://brutelogic.com.br/blog/compromising-cmses-xss/

Additional Resources:

• Cookie attributes by Mozilla Web Docs (explains cookie security flags in detail)

• Use cookieStore() in case WAF blocked you by @PortSwiggerRes (basically, if session cookies are not HTTPOnly but document.cookie is blocked, you could still subscribe to the cookieStore interface and retrieve all cookies)

• Account takeover through Session Data in IndexedDB by @SMHTahsin33 (this post walks you through on how you can extract data from IndexedDB)

• XSS to RCE in Content Management Systems by @brutelogic

• Weaponised XSS Payloads by @hakluke (drop him a follow as well)! This GitHub repo contains a set of payloads for upgrading your XSS to a P1 (RCE) for different CMSs (helped me get my very first account takeover through XSS a few years ago)!

Thank you for reading this far!

I hope you've enjoyed this post! In next week's issue, I will go through Broken Access Control issues! Stay tuned!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

• Help you save time & earn more bounties using Nova Security:

Automated Web Security Scanning Simplified - NOVA SECURITY

Actively search for vulnerabilities 24/7 using next-gen automated security tools! Start securing your website now!

https://novasec.io/?ref=newsletter

Today's estimated reading time is: 10 min (hope you like the new theme colors!)

Today, you'll learn how to craft your own payloads to bypass filters and web application firewall rules!Let's get into it!This post assumes you've identified a valid injection point that allows you to render HTML tags. If this is not the case (yet), read the following post: [#1] Cross-Site Scripting (XSS)

Table of Contents:

• Reflected & Stored XSS

• DOM-based XSS

• Resources

Reflected & Stored XSS:

In order to craft a payload, you first need to be aware of a few things.First of all, your context. Is your injection point inside a script tag? Is it inside a value of an HTML attribute? Or between a specific HTML tag (for example style tags)?You should always determine your injection point before crafting any payload. Your script alert(1) payload won't work everywhere.

If your input got reflected inside the style tag (or any other tag that doesn't directly allow you to render tags that can execute javascript code, such as the textarea), then it is recommended to first close the preceding tag before opening the new one (your payload):

Another example. In case your unencoded input got reflected inside the script tags (as a value of a variable for example), then you should close the value and add a function.In the code snippet below, assume that the "lang" query parameter's value gets reflected inside the javascript variable:

Another example. If your input was reflected inside an href attribute of an a-tag for example, you could inject a payload that uses the javascript protocol (assuming that the opening & closing tags are encoded or escaped):

Remember that you should always go for a payload that executes with no additional user input needed possible:

Now that we got the basics, we should start crafting our payload using various bypassing techniques. To make things easier, let's first get into the developer's mind:I'm a full-stack developer myself, and whenever I see developers recommending security measures to each other on public forums (Stack Overflow for example).I see that they are most of the time aware of any security vulnerabilities that may be present but have a quite vague understanding of any existing bypasses.And XSS is one of them. Some think that XSS vulnerabilities are all about tags, and try to solve this by encoding input based on a loose regex pattern.Can you tell me what's wrong with the following pattern? It seems to do the job, no?

No worries if you couldn't figure it out yet, after all, you're reading this post to learn more about crafting payloads & bypassing rules!First of all, it only matches input when it is delivered with an opening AND a closing tag. The second thing, it's a global pattern and not a multi-line pattern. This means it will only check for matches of the pattern on the first line.This can easily be bypassed in multiple ways:

• This regex won't be helpful if your injection point is inside the value of an HTML attribute or the href attribute of an a-tag for example.

• This regex can easily be bypassed using CRLF characters as it only checks for it on 1 line.

• This regex only checks for an opening AND a closing tag (and everything in between). However, we can omit the closing tag in some common cases.

• This regex won't be helpful if any input is passed to a DOM sink (depending on the sink, you can in some cases also pass escaped Unicode characters.

Let's take a closer look by using the pattern to match against different variations of our payload on https://regexr.com/ :

Wondering how a payload without a closing tag works? Here's an example:

You can apply the same bypasses if the keyword or the pattern /javascript/g is used (this is how I found so many XSS vulnerabilities).There are so many ways to bypass rules.Here's an example of how I used the techniques above to craft payloads that bypass (custom) WAF rules for example:

Twitter

In the example above, I used the SVG tag (it was one of the tags that were allowed) in combination with the "onload" event handler. I used a double URL encoded Carriage Return character and made use of hostname (instead of document domain as "document" was blocked)You could also concatenate code as it is much harder to detect:

Now that we've covered most of the bypasses, there's another type of stored XSS that is quite common when no (basic) validation is done in file upload features.As I stated in my previous post, it is possible to execute javascript in script-based contexts. This means that SVG and XML files for example are also capable of executing javascript.Here's one for an SVG file for example:

It is always recommended to try and upload SVG files when there's a file upload on your target.

DOM-based XSS:

For DOM-based XSS, a payload really depends on the sink to which it'll end. For example, a script tag won't work in the example below:

However, the javascript protocol will. I've encountered a lot of times where "javascript" is blacklisted or just some parts (such as "java" or "script" is blacklisted).I was almost always able to bypass it using URL-encoded CRLF characters (remember multi-line??).I also encountered cases where everything is whitelisted as long as it matches the following pattern (the app wanted to support HTTP as well as mobile app links):

The developer might've thought that this was safe, right? Or is it?

Twitter

It isn't, using a URL-encoded line separator character (U+2028) we can easily circumvent the regex pattern and still inject our malicious code.

Now what if your input got in the "innerHTML" sink AND opening and closing tags are filtered?

Use Unicode! Supplying the following payload would render an image tag with the "onerror" event handler. I recommend using tools like CyberChef and Burpsuite's decoder or Hackvector to encode/decode text easily:

There are countless amount of bypasses like these, as every target is different, I keep trying different ways until I find one that works.

Resources:

• Here is another detailed blog post from YesWeHack on bypassing web application firewalls

• A detailed post of achieving XSS using SVG files from Ghostlulz

• A WAF bypass cheatsheet from Hacken.io

• Another resource on bypassing filters in different contexts from Brutelogic

• Want to test out a payload? Portswigger has a playground where you can test new tags

I also recommend keeping an eye on Twitter's bug bounty community as most of the time, new WAF bypasses get shared there.

Thank you for reading this far!

I hope you've enjoyed this post! In the next newsletter issue, I will go through a topic I still need to figure out (suggest me some)! Stay tuned!By the way, congratulations on making it this far! You are one of the few who have come this far and you make much more chance to complete this guide and become a bug bounty hunter!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

Today's estimated reading time is: 19,7 min

Hi mate! Glad to see you back again reading my newsletter! By the end of this post, you'll have a better understanding of what Cross-Site Scripting (XSS) vulnerabilities are and in what forms they often are or can be found!This week will be all about understanding XSS, next week I will show you how you can identify and exploit them using custom-crafted payloads! Throughout this post, I may give additional information about where & how I found some of the most unique XSS vulnerabilities, don't miss out on this and take notes ;)!

Table of Contents:

• Cross-Site Scripting (XSS) introduction

• Types of XSS vulnerabilities

  • Reflected Cross-Site Scripting

  • Stored Cross-Site Scripting

  • DOM-based Cross-Site Scripting

• Testing Methodology

  • Reflected & Stored XSS

  • DOM-based XSS

• Additional Resources

Cross-Site Scripting introduction:

Cross-Site Scripting (or XSS in short) is an injection vulnerability that can be present on the client side as well as on the server side.Simply put, XSS vulnerabilities allow attackers to execute client-side javascript code on behalf of their victim (usually, without their knowledge). Or on the server side (think of HTML to PDF generators, or just some code that renders your HTML and JS code on the server side, etc.)And as they can execute javascript in the victim's web browser, they basically can redress the whole UI, perform unwanted actions or in severe cases, get a hold of the victim's session cookies (more on this when we approach the exploitation part).XSS vulnerabilities exist due to bad user input validation. Developers often underestimate what parameters attackers can control. However, sometimes, they just forget about it. This is often the case for example when the application is super complex and has a very large code base (take notes...).Modern web browsers can't fully mitigate this vulnerability as it is hard to determine whether the script that is loaded or code that gets executed comes from a trusted source or not (think of a third-party script that gets injected after the DOM has loaded).However, over the past few years, new browser security headers and features (such as Content Security Policy) started to get introduced and can (partially) mitigate this.The only most reliable mitigation is to validate user input and always encode it wherever possible.One small note:Most make this mistake, but understand that XSS vulnerabilities can not be exploited in a server's redirect (whenever the Location response header is set and a 3XX status code is returned).Say we have the following PHP code:

Then even if we try to inject an XSS payload using a payload, which will give us the following response

The browser will just redirect you to the destination host.

And, as we've seen in the previous post, the response content type also plays a major role in how your browser will handle the server's response. XSS vulnerabilities can only be executed in script-based contexts. Even if your payload got reflected in the response without any encoding, it won't execute in responses with a content type of for example "text/plain", "application/json", "text/javascript", etc. (unless you managed to find a CRLF injection and forced the server to respond with your specified content type, crazy stuff I know, I'll explain this vulnerability type later).It will for example execute in responses with a MIME type of "text/html", "image/svg+xml", "text/xml", etc.

Types of XSS vulnerabilities:

XSS vulnerabilities can be present in various contexts and to further classify them, we further separate them into 3 classes: Reflected XSS, Stored XSS and DOM-based XSS.

Reflected Cross-Site Scripting:

Reflected, Reflective, Non-Persistent or Type-I XSS are XSS vulnerabilities that get executed because invalidated or unencoded user input gets reflected in the server's response whenever the payload is specified.The victim must click on a malicious link that is provided by the attacker before it executes on the victim's browser.It only executes once whenever the malicious link is visited.Sometimes, it is possible to elevate a reflected cross-site scripting vulnerability to a (temporarily) stored cross-site scripting vulnerability through for example getting the server's response get cached.You often find reflected XSS vulnerabilities in search functions (that return the query) or in other input fields that reflect the value in the server response.You should also test hidden input fields and try to use javascript variable names as a query parameter.Do remember that parameters often get re-used by the developer on other routes or endpoints (if you found a reflected XSS on the login page using the "redirectURL" parameter, try to also check for XSS on the register or forgot password page).It is also pretty common that developers read the parameter from the response body and/or URL query (depending on where the parameter got supplied). So make sure to test it for both POST-based as well as normal GET-based XSS.Test everything that accepts user input and reflects it somewhere else.There's also POST-based XSS, where an injection point only reflects POST parameters. It's the same as a reflected XSS except for how you send the payload. Instead of a link with a payload, you send a link to your site with a simple HTML POST form.Auto-submitting the HTML form (when the link is visited) will decrease the attack complexity.One last form the reflected XSS can come in is in the URL path. Simply put, everything in the URL path may get reflected in the page, I've encountered a few times where whenever you request a resource that doesn't exist, it returns a 404 status code along with the path unencoded. This allowed me several times to execute javascript code just make sure your payload is in the right format.

Stored Cross-Site Scripting:

Stored, Persistent or Type II XSS is another type of XSS, it's quite similar to reflected XSS.The only main difference is that it is stored (i.e. saved in a database or somewhere else) and later retrieved again (everything, even the payload).This means that any user who visits a particular page gets the malicious javascript payload executed in his/her browser (without the need of specifying the payload every single time)!By nature, stored XSSs are a high-severity vulnerability as they can cause severe damage to each user who visits the page.And as you might have guessed, stored XSS can be anywhere where data is stored and later retrieved and reflected in the response body!You can think of comment sections, review forms, contact forms, user details (when signing up for example), file uploads (when uploading an HTML or SVG file for example, I'll share the payloads in the next post), chats, (login) logs, online viewable emails, notification system (that is built in to the site, don't confuse this with the Notifications browser API), etc.

DOM-based Cross-Site Scripting:

DOM-based XSS is different from reflective and stored XSS as your input does not get reflected in the source code.DOM-based XSS vulnerabilities arise when unsafe data (user input from a query parameter for example) gets processed in javascript and gets passed without proper validation.There are a few ways where user data can originate from, such as "window.location" object property. Every property that reads user-supplied input is called a DOM source.While each function that processes data in an unsafe manner is called a DOM sink.When user input gets passed from a DOM source to a DOM sink, DOM-based (XSS) vulnerabilities may arise.This may still be a bit vague, I know, but don't worry! Lets take a look at the following code snippet that is vulnerable to a DOM-based XSS vulnerability:

User input is read from the "redirect_url" query parameter (from the "location.search" DOM source) and is later passed on to the "location.href" DOM sink. If you send a request to that document with the "redirect_url" query parameter with a payload, you may execute javascript on the user's behalf!There are a lot of sinks that can lead to DOM-based XSS, I recommend going over them one by one in this article from Portswigger Academy.

Be aware that Blind XSS also exists. Blind XSS is hard to detect as you can't see the injection point (as it is often on a higher privileged or internal web dashboard, think of an admin's moderation dashboard where all data of a user gets reflected in the response) and can be any type of XSS. It often is stored XSS but this can also be a blind reflected or blind DOM-based (although these are much much harder to find).That is why it is also advisable to put your payload in other parts of your request such as your User-Agent, Cookie header, X-Forwarded-For (depending on how and what request headers the application processes), or in the request body (as a parameter) etc. Your request will eventually get logged and displayed on the admin's dashboard.Another trick you can use is to cause an error and have the request contain a blind XSS payload as errors often get logged separately to get resolved.

You might also come across self-XSS in program scopes. Self-XSS can also come in the form of the preceding 3 different types. To put it simply, self-XSS means just what you might think it means, only you can get exploited and affected by it.It often can not be used to harm other users. This is why it is almost always out of scope for most programs out there.You can come across it in various components of a web application such as your private profile or settings, an input field (with no query parameters) where the whole payload needs to be typed first (think of an auto-complete feature or similar features), etc.To save yourself and the company time, do not report self-XSS vulnerabilities. Instead, try to seek impact by chaining multiple vulnerabilities. This may not always be possible, however, the end results are always rewarding (you either learn something new or earn a bounty).

Testing methodology:

If you want to properly test XSS, I recommend going through the following steps. These have worked for me and allowed me to determine whether a specific field is vulnerable or not and have helped me find a lot of XSS vulnerabilities (all types).I usually first try a simple XSS payload just to save myself time but if that does not work, I fall back to these steps.This is how I always find XSS:

Let me explain

Reflected & Stored XSS:

1. Inject a simple non-malicious HTML tag followed by a unique string or int value (depending on what the website is expecting). The HTML tag can be a u-tag, s-tag or i-tag. In this step, you mainly only want to identify injection points without getting blocked by a web application firewall. If you found a reflection point where your HTML tag got rendered, proceed to the following step.

2. This step involves you (manually) checking what tags are allowed. To do so, you can open the XSS cheat sheet provided by Portswigger Academy and copy all the HTML tags. Going over them manually can be a tedious task, I recommend using a fuzzer such as your Burpsuite Intruder or any other tool that does the job. Take note of each single allowed tag, this will help you a lot in the following step.

3. Now it's time to identify any allowed event handler (if the script tag is one of the allowed tags, skip this step, you already got XSS ;)). Usually, what you want to do now instead of directly injecting an event handler is to first determine if the keyword "on" is allowed or not. If it is, add an "x" after the "on" keyword. Keep on adding an "x" character until you reach the length of one of the event handlers. All you do know is to start checking what event handlers of the same length are allowed. You are mainly looking for event handlers that execute code without requiring any additional user input (such as "onload", "onerror", etc.). Note down each allowed event handler.

4. This step is the final step, this is where you check what payload gets accepted and craft the final payload (including the code that is going to be executed). The code is often an alert popup including the document's domain as 1) it proves code execution and 2) it indicates on what domain it got executed.

If you still couldn't find a payload, I recommend bruteforcing payloads (I never had to reach this step as I always found it after finishing the 4th step).

DOM-based XSS:

For DOM-based XSS the methodology differs as your payload does not get reflected. That's why I recommend reading and analyzing javascript files for DOM sinks and sources and injecting your payload accordingly.

Additional Resources:

• OWASP has great resources on XSS for if you want to read more about it.

• Learn more about DOM-based XSS (Portswigger Academy has awesome labs too)!

• XSS Cheat Sheet by Portswigger Academy

• If you're a developer yourself, you may want to look at how you can prevent this issue in your web apps. OWASP provides a Prevention Cheat Sheet that you can follow.

Thank you for reading this far!

I hope you've enjoyed this post! In the next part, I will go through how you can craft your own custom XSS payloads while avoiding most web app firewalls! Stay tuned!By the way, congratulations on making it this far! You are one of the few who have come this far and you make much more chance to complete this guide and become a bug bounty hunter!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

Today's estimated read time is: 3,5 min

Hi mate! Congrats! You've made it this far! You now got the technical basics just to get started in learning web security! If you keep following along, you'll soon be ready to hit real bug bounty targets and start earning those bounties!

What's next?

From now on, I'll be covering all vulnerability types that often are present in websites!Just to give you an idea, each vulnerability type will be divided into 2 (or 3) parts, sent out each week.This is to keep the post lengths reasonable.The first part will be all about understanding the vulnerability type.In the second week, I will cover the practical stuff such as common payloads and bypasses, and where to look for them!And as a lot of you requested, we'll be covering Cross-Site Scripting (XSS) vulnerabilities in next week's issue!But before I close off this post, I wanted to ask for your feedback!Please reply to this email (or send me via Twitter DMs) anything that you want to be added or changed in this newsletter.Would you prefer to have shorter posts (and send each week 2 emails), or would rather prefer longer posts that may take 10min+ to read?One important last note, I noticed that a lot of emails stay unread whenever I post any technical content (e.g. payloads, bypasses, etc).Please whitelist my domain or add this sender as a contact if you want it to bypass the SPAM filter and keep receiving my emails.And as always, you can read all my previous posts on my blog:

Weekly Bug Bounty Content

Subscribe for Weekly Bug Bounty & Web Application Security related content in your inbox!

https://weekly-bugbounty-content.beehiiv.com/

Thank you for reading this far!

I hope you've enjoyed this post! In the next part, I will go through cross-site scripting (XSS) vulnerabilities! Stay tuned!By the way, congratulations on making it this far mate! You are one of the few who have come this far and you make much more chance to complete this guide and become a bug bounty hunter!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

Recap:

Hi mate! Glad to see you back on this post! I also want to welcome our 100+ new readers who are joining us today! Thank you all for your support!

Last week, we went over the HTTP protocol and covered requests and responses as well as the components that form a valid request or response (such as HTTP methods, response status codes, request/response headers, request/response body, etc). If you missed that post, it's always available on my blog!In today's issue, we will see what your web browser is all capable of in terms of testing web applications (lots of bug bounty hunters just don't know or use this!!). I will also go over the different proxy interceptors + the most used built-in capabilities and how they can be used to test web applications effectively!

Table of Contents:

• Recap

• Web browser

  • Regex Search

  • Source Maps

  • Network Interceptor

  • User-Agent spoofer

  • Content Security Policy checker

  • Hidden endpoints through the memory tab

• Proxy Interceptor

  • Burpsuite

  • ZAProxy

  • Caido

  • Proxy

  • Repeater

  • Intruder

  • Sitemap

Web browser:

Whichever web browser you use, Firefox or Edge or a Chrome-based browser (such as Google Chrome, Brave Browser or Chromium) your browser has developer tools built in it. These developer tools are meant for developers to debug and track any kind of issues on their site. However, we can use it to our advantage to find all types of vulnerabilities! A few examples: we can use the memory tab + regex search to uncover (hidden) endpoints in for example SPAs (single page applications), but we could also replicate the whole project folder using the sources tab by unpacking source map files! Let's not waste any more time and get straight to it!Throughout this post, I will be using Brave browser. Other browsers such as Firefox also have the same tools built in, however, they may not be located in the same place.

Regex Search:

Your developer tools provide you with a basic search along with a regex search to search for common patterns easily! All you have to do is open any file in your "Sources" tab, whether it's a javascript file or just an HTML file or your "Elements" tab and press Ctrl+Shift+F (keep focussing on your web console), you can now easily go through these files, and search for well-hidden endpoints and other hard-coded values or patterns (such as a custom request header or cookie you've found elsewhere) in the web application!

Source Maps:

You probably already have seen that javascript source map files can be easier to help you spot more vulnerabilities as you got access to the code. However, one thing a lot of bug bounty hunters do not know is, that you can unpack + replicate the whole project directory in your web console! Previously, most people downloaded the source map file, installed a source map unpacker, and had to replicate the whole project discovery on their own machine. This is of course doable for 1 or 2 source map files, but what if you've got a lot of them?That's where you should use the "Sources" tab! You now got access to the entire front-end code in a structured and easy-to-read format! This allows you to directly search for where user input is collected + processed (I've found lots of dom-based cross-site scripting issues using this technique + one even lead to an account takeover through a special case). You could also look for hardcoded values and trace back where they're used (to try and replicate the credentials) but this can also be used for basic content discovery by looking for endpoints.You're most of the time going to find source map files of web applications that were built using Webpack or similar site builders and only if source maps are enabled. You commonly come across these on Vuejs & React applications.

Network Interceptor:

Yes, your web console is also capable of intercepting and saving requests and responses! Opening the "Network" tab will present you with all the connections that you've made or are making at the moment. These become helpful if you want to use your web browser as an interceptor (highly impractical) but you get the idea. You can inspect the responses to requests but most importantly, you can also replicate them by copying the request as a command. One of the lesser-known features of the web console (it really does save a lot of time if you need to reconstruct a whole cURL command or fetch function).

User-Agent Spoofer:

Correct, you can spoof your user-agent header using your web console! You might ask yourself why you even want to spoof your user agent. As we've seen in the last post, from your user agent header, a web application can derive the browser, device and much more from where you're requesting a certain resource. And it is pretty common that you see a response differ based on your user-agent (useful for content discovery). Under the "Network conditions" tab, you can set a custom user agent (with an XSS or SQLi payload) or select a user agent from the menu:

Content Security Policy Checker:

A good content security policy is one, or should at least be, one of the last defences against cross-site scripting vulnerabilities (and clickjacking attacks). However, sometimes, XSS issues are available, and basic CSP misconfigurations may leave the vulnerability exposed to attackers. But you first need to find a misconfiguration in CSP itself. It is possible to do so using your web console through the "Lighthouse". Previously, you had to go to the CSP evaluator and check if CSP is set in place correctlyTo check for CSP misconfiguration, open your web console, open the "Lighthouse" tab and select "Best practices" and click on "Analyse page load". Let the scan finish. Once finished, check under "Trust & Safety" for any misconfigurations:

In this case, no browser mitigations were set to prevent XSS from executing.

Hidden endpoints through the memory tab

The memory tab gives developers the ability to track down memory leaks inside their web applications. However, we can also use this feature, but instead of tracking down memory leaks. We can search for endpoints or other hardcoded values as all these heap snapshots contain nodes and objects which are linked to the DOM!To use this feature, open your "Memory" tab, next click on "Take snapshot" and wait for it. Once the snapshot has finished, look for strings such as a custom request header, a cookie, an API endpoint, etc using the regex search!

Proxy Interceptor:

There are a few proxy interceptors that do the job. You've even got a browser-based proxy interceptor (very useful if you want to have your proxy interceptor on your VPS for example)! Below are a few proxy interceptors, I will be mainly using Burpsuite Proxy interceptor as my main proxy interceptor in this post as well as feature posts but keep in mind that any proxy interceptor is okay as long as it does the job!Below, I will go over various tools that every proxy interceptor provides through a basic Server Side Request Forgery vulnerability. I will cover this vulnerability type in a later post, but all you have to know at the moment is that SSRF vulnerabilities arise when user input gets into a function that requests external resources. This means that you can request any resource on behalf of the server, this can be severe if for example non-protected sensitive content is located on the server-side's network (localhost, AWS or Google GCP metadata, etc).

Burpsuite:

Burp Suite - Application Security Testing Software

Get Burp Suite. The class-leading vulnerability scanning, penetration testing, and web app security platform. Try for free today.

https://portswigger.net/burp?utm_source=newsletter&utm_medium=email&utm_campaign=from_zero_to_hero_in_bug_bounty_pt5

ZAProxy:

The ZAP Homepage

Welcome to ZAP!

https://www.zaproxy.org/?utm_source=newsletter&utm_medium=email&utm_campaign=from_zero_to_hero_in_bug_bounty_pt5

Caido:

Caido - Lightweight Web Security Auditing Toolkit

Caido - A lightweight web security auditing toolkit for professionals and enthusiasts.

https://caido.io/?utm_source=newsletter&utm_medium=email&utm_campaign=from_zero_to_hero_in_bug_bounty_pt5

Target:

The Target tab displays the sitemap for each previously intercepted site. It allows you to define which targets are in scope for your current project, and also allows you to conduct various other actions by selecting a site or request individually:

Say we are only authorized to test http://localhost.me. We can set up our scope accordingly to exclude any other hosts except the in-scope host:

Setting the sitemap to only show in-scope items will just show us every request made on http://localhost.me/:

Proxy:

The Proxy tab acts as an interceptor between your web browser and the server. When you set a proxy to redirect all traffic to Burpsuite's proxy, you'll notice that you can only intercept HTTP requests. For HTTPS requests, you'll have to install Burpsuite's generated certificate, I won't explain it here as there are a lot of tutorials already, but do know that you need to set up your proxy interceptor in order to intercept any request between your browser and server.Also, you'll notice that you can't intercept requests made to localhost. You'll have to manually edit your etc hosts file on UNIX-like systems and point 127.0.0.1 to any hostname of your choice (that's one way to go around this).The proxy interceptor allows you to examine, and edit requests and responses between your browser and the server. This is extremely helpful to evade client-side validation (when submitting your payloads). It also makes testing APIs more convenient.

Let's request the following resource: http://localhost.me/

Make sure your interceptor is turned on. Next, right-click it and select "Send to Repeater" or simply hit "Ctrl+R".

Repeater:

The Repeater tool allows you to edit and send an interesting HTTP or WebSocket message repeatedly. This tool is extremely helpful if we are looking for a payload that evades WAF for example. Let's take a look at the previously intercepted request.

From the source code and memory heap snapshot, we already know the potentially vulnerable query parameter. We now only need an appropriate SSRF payload. Thanks to the Repeater tab, we can repeatedly send a new variation of our initial payload over and over again (until we find one that works):

And as you can see, we found that our payload allowed us to request a page on behalf of the server and even read local files!

Intruder:

The Intruder tool allows you to conduct automated customized attacks against web applications and APIs. It can be used to automate all sorts of tasks. From content discovery to brute-forcing various payloads. Let's take a look at an example from before, in the Repeater tab, just hit "Ctrl + i":

Select or load a wordlist and click "Start attack" (small side note: on Burpsuite's community edition, your requests will be throttled and gradually slow down. I recommend using another solution if you want to save time.)

The SSRF from before was an extremely easy case that is less common nowadays. But suppose you did find a potential SSRF but you just can't get a payload that evades the web application firewall or filter. What you can do is send the request to Intruder, define the insertion points, select a wordlist with payloads and start the intruder scan. From the end results, we can achieve the same: we can check the status codes or content length of each response.

In this post, I've only covered the basics just to get you started. However, if you want to learn more, you can read the available documentation, watch some videos or even take a course on learning your preferred proxy interceptor in-depth!

Thank you for reading this far!

I hope you've enjoyed this post! In the next part, I will go through what is next in this newsletter! Stay tuned! By the way, congratulations on making it this far mate! You are one of the few who have come this far and you make much more chance to complete this guide and become a bug bounty hunter!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

Recap:

Welcome back, buddy! You're progressing a lot in this guide! Only a few have managed to come this far (especially since networking isn't something anyone wants to learn about)! Be proud of your progress!!Last 2 weeks, we've covered networking basics (see part 2 and part 3) that were needed for starting out in bug bounty, we also talked about protocols, and one of them that we will be diving into is the Hypertext Transfer Protocol (or HTTP for short). It's the language that you (as the client) use to communicate with other servers on the internet! And since we carry most of our attacks on websites, we'd need to master this and know everything about it to understand what is going on! It's going to help us tremendously later on!

Table of Contents:

• Recap

• HTTP Introduction

• Request

  • Request Methods

  • Request Headers

• Response

  • Response Status Codes

  • Response Headers

• URL Encoding

HTTP Introduction:

As we've seen earlier, the Hypertext Transfer Protocol (or HTTP) is located in the application layer of the OSI Model. HTTP is the protocol that allows us to communicate with servers on the internet. You've probably seen a raw HTTP request before, but take a look at the request below:

In the example above, the client (we) request a document on another server on the internet. In this case, we are making a GET request (more on this later) to example.com to retrieve the home or index page. The server receives the incoming request, and returns the index document, just like we requested. (Depending on what technologies or server's configuration, the index file may vary. If the web application's backend is written in PHP, then the server is most likely to return index.php. For (static) HTML files, it'll return index.html., for websites that use the .NET framework, it'll return Default.aspx, etc.).HTTP can be used to request and return a variety of documents and media files such as images, videos, text files, XML files, etc. as long as the Content-Type header is defined, so that you (the client) as well as the server, can understand what type of file is being sent or received. This helps your web browser to render for example a PDF or HTML file instead of displaying it in plain text.You'll also come across HTTP versions, and at the time, the latest version is HTTP/3. Each new version introduces several changes, so far, HTTP/3 has abandoned TCP and is now relying on the QUIC protocol (on UDP, it's much faster for web applications). I'm not going to get into detail here, but I do recommend you to read more about it.

Request:

As we've seen above, a typical valid HTTP request consists of a request line (an HTTP method, path and HTTP version), request headers, and, depending on the request method, a request body all followed by a newline consisting of CR/LF (Carriage Return: \r and Line Feed: \n) characters. Let's take a look at a typical GET request and go over the components of a valid HTTP request:

Request Methods:

There are a lot of HTTP methods, however, only some of them are documented (the others are custom but are also important in identifying weird exploitable behaviour). You can think of an HTTP method as an instruction to what the server should do. Should it retrieve a document for you? Then you're probably sending a GET request. Are you updating an existing value (for instance, updating your profile data) or perhaps requesting to create a new entry (for example registering your account)? In that case, you're most likely sending a PUT or a POST request. There are a lot of HTTP methods that are used to communicate with servers at the moment. I've lined up below some of the most commonly used HTTP methods that you'll encounter.

Please, do keep in mind that developers are not always respecting RFCs. This may introduce security vulnerabilities.

Request Headers:

HTTP request headers are necessary to provide additional information about the request or response. They are needed for example to tell which host or application you're trying to reach (it is pretty common to come across a website that shares the same IP/machine), or what type of file (that you're uploading) is in the request body, etc. Below is a list of commonly seen request headers with their corresponding description:

We've covered valid HTTP requests and the reason why I keep repeating valid is that sending invalid HTTP requests may introduce weird behaviour and in some cases open up attack surfaces. Think about making HTTP requests on behalf of the server (Server-Side Request Forgery) after messing up with the host header or path or even the HTTP version. I will definitely come back at this when we're covering SSRF vulnerabilities!

Response:

A non-malformed (yes, you can cause the server to respond with a weird reply and introduce security vulnerabilities) HTTP response is similar to an HTTP request. It also consists of 3 main components, a status line (consisting of the HTTP version, the HTTP status code, and the status message), 0 or more response headers (each followed by CR/LF characters), and often a response body (this can be absent if, for instance, you sent a HEAD request).

Response Status Codes:

HTTP status codes are codes separated into 5 different categories that range from 100 to 599 and provide us with details of how our HTTP request went. If our request was successful, then the server is most likely responding with 200 OK. If it couldn't find a resource on the server, then it's probably responding with 404 Not Found. I've created a small table with the most common status codes that you'll come across along with their corresponding description to give you an idea of what it actually means:

Mozilla Web Docs provides a full list of HTTP status codes, you may want to explore and read through the list to familiarize yourself with the other status codes.Again, please keep in mind that developers are not always respecting RFCs, and sometimes use the wrong status code for a particular response. Or even think that it be used as a security measure (you read that right, sometimes developers think that redirecting the user is a sufficient measure to avoid them accessing unauthorized resources, say a component of an admin dashboard, as the response is invisible in a web browser. However, making an HTTP request using a tool like cURL can help us view the complete response).

Response Headers:

Response headers help provide more information about the response that we receive from the server, below are some commonly found response headers:

Of course, I couldn't add each and every header in this post (there are thousands of documented and undocumented headers) but if you'd like to learn more about them and browse through other headers, I'd highly recommend you take a look at Mozilla Web Docs!

URL Encoding:

here are a lot of characters in several languages (Arabic, Chinese, Russian, ...) around the globe. However, to support these in HTTP requests, they need to use the ASCII character set (ASCII stands for American Standard Code for Information Interchange and is based on the English alphabet). This is not always the case as there are plenty of characters that fall outside of that character set and that is why it is important to URL encode these characters. Each URL-encoded character is prepended with a % and the character's hexadecimal value. Here are some of the most used URL-encoded characters that you'll often need:

If you're looking for a full list of these, you can find plenty of websites like ascii-code.com 

Thank you for reading this far!

I hope you've enjoyed this post! In the next part, I will go through some tools that are commonly used to test web applications for security vulnerabilities! By the way, congratulations on making it this far mate! You are one of the few who have come this far and you make much more chance to complete this guide and become a bug bounty hunter!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

Recap:

Hi mate! Thanks for joining me on another part of this zero-to-hero bug bounty guide! You're doing an awesome job! Keep going!In part 2 of this guide, I went over common networking terminologies, explained the OSI-Model, briefly introduced you, with simple examples, to what a network was, and much more. If you haven't read it yet, no issue at all, you can access part 2 on my blog. If you did read it, I highly recommend rereading the post again to freshen up your networking knowledge!

In today's issue, I will explain network ports & DNS. I should've added it to the previous part but it got a little lengthy. Long posts can be a bit challenging to follow and I tend to keep this guide simple & easy ;)! Without further ado, let's get started!

Table of Contents:

• Network Ports

• Domain Name System (DNS)

Network Ports:

In the last post, we've seen that a destination IP address is required in order to communicate with another device in the same network. However, to make the connection complete, we need to assign a service port to the IP address as well. Let's take a look at the following example:

As you can see in the illustration above, we had to connect to the host on port 80 (where the HTTP service is actually listening for any incoming connections). And our web browser is listening for a response from the server on the source PORT.Each IP address or device has 65535 network ports. And each one of them can be registered by a running service or program. ICANN has divided this port range into 3 different classes, you do not necessarily need to remember these, but I do recommend you memorize the following common network port numbers and their associated service:

Short summary:The IP address locates the host in the network, while the network port locates the requested service on the host that is connected to the network.

DNS:

Domain Name System (or DNS for short) is responsible for making sure you connect to the correct host whenever you request a domain. You can think of it as a telephone book that converts each number to its associated contact name. Whenever you request a website, the DNS will try to resolve the domain name and get the IP. This means that you do not have to remember IP addresses, but instead, just connect to a domain name. Let's take a look at the following image below:

On your web browser, you request example.com. However, on the backend of this process, the DNS transforms that domain into an IP address to locate the host over the network and successfully make an HTTP connection.This is how DNS works, I do recommend learning more about DNS records (A records, CNAME records, MX records, TXT records, ...) as they will be valuable, especially in the reconnaissance phase!

Thanks for making it this far!

I hope you've enjoyed this post! In the next part, I will explain the HTTP protocol in-depth and move on from there to commonly used tools! Congratulations on making it this far mate! You are one of the few who have done this and you make much more chance to complete this guide and become a bug bounty hunter!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

Introduction:

Welcome back to my complete bug bounty guide! I, first of all, want to thank everyone for your support and welcome all our new subscribers!Last week, we left the guide on requirements in bug bounty, this week, I'll introduce you to networking in bug bounty.

Networking is significantly important in bug bounty as we are almost always dealing with network attacks and it also plays a huge role in reconnaissance. Knowing how everything works under the hood is essential and cannot be skipped (if you still proceed, you might find it challenging later on).

Table of contents:

• What is a Network

• Protocols

• The OSI Model

• The Internet Protocol

• Subnet mask

• CIDR Notation

• Networking terminologies

What is a Network?

Your home probably has several devices, let's say, you have a personal computer, a printer, a smartphone and probably also a desktop. When these devices are connected they form a network. A network makes it possible for them to transfer data from one device to the other. Let's take a look at an example below.

Computer A tries to send data to the printer to print for example a document. To do so, computer A must first be in the same network as the printer. They should be connected to each other somehow in order to share data. To do so, you need a switch to connect them through a wire. The connection could also be established wirelessly by using an access point (basically, a switch without cables), this type of network is also called Wireless Fidelity, or Wi-Fi for short.And secondly, it should transmit the data in a way that is understandable for both devices (the sender, in this case: computer A, and the receiver: the printer). The structure in which data gets sent is called a protocol.

Protocols:

You can think of a protocol as a language. They help both devices understand the data that is being sent. One protocol that we are going to use a lot and talk more about in-depth is the Hyper Text Transfer Protocol, also commonly known as HTTP. This is a protocol that is used to surf the web. Don't worry for now as we will cover this protocol in a separate part.HTTP is one of the common protocols that we will use, but there are several others (I, unfortunately, won't cover these as they are beyond the scope of this guide). SMTP (Simple Mail Transfer Protocol) is used for sending electronic mails (or emails in short), Ethernet is used to transfer data in wired networks, etc.

To achieve tasks such as surfing the web & sending emails with attachments, we will need to make use of several protocols. The OSI Model allows us to reference each protocol and understand what is actually going on when we for example request a resource online. Let me explain what the OSI Model is, and shortly go over the layers and explain them briefly. Please, bear in mind that nowadays, not every protocol fits in the OSI Model, it is just a reference that we can use to make our lives a bit easier :)! Also, there are other models as well (such as the TCP/IP model) but are again outside the scope of this guide.

The OSI Model:

The OSI Model helps us to understand our network by breaking it down into separate layers. It basically consists of 7 layers: Physical, Data Link, Network, Transport, Session, Presentation and Application. The Application layer (where the File Transfer Protocol and web services are located) forms the top of the model, meanwhile, the Physical layer is located at the bottom of the OSI Model.There are a few rather funny mnemonics that can help us memorize the 7 layers, you can choose which one to remember:

• A_Penguin Said That Nobody Drinks Pepsi

• Please Do Not Throw Sausage Pizza Away

• Please Do Not Tell Salespeople Anything

Let's take a closer look at the different layers and see what role each one has (from top to bottom).- Layer 7: ApplicationThe application layer is where protocols form applications are. Think of HTTP, HTTPS, FTP, SMTP, SSH, Telnet, ...- Layer 6: PresentationThis layer is responsible for making sure that the data that is received is presented in a format that the device can fully understand.- Layer 5: SessionLayer 5 manages the connections or sessions between the two devices.- Layer 4: TransportThe Transport layer or layer 4 breaks the data into segments (small chunks of data, if it's large enough). This is also where the lower-level protocols such as TCP and UDP live.- Layer 3: NetworkWe now have everything to send data but there's no way to know where to. This is where Layer 3 or the Network layer comes into play. The Network layer will make sure to route the data to the correct destination by adding the correct address. From now on, we call our data chunk a "packet".The Network layer is also where the Internet Protocol (or IPv4 and IPv6) lives.- Layer 2: Data LinkThis layer is responsible to transfer data from one device to another device.- Layer 1: PhysicalLayer 1 or the Physical layer provides the physical connection with the device (like enabling sound, sending electrical signals, or electromagnetic waves for wireless networks, etc).This was a short introduction to the OSI Model if you want to get more in-depth, you can take a look at the following resources:

• OSI-Model - OSI-model.com

• The Transport Layer of OSI Model - TutorialSpoint

Now that we broke down how data gets transferred between 2 machines, let's move on to the next chapter where I cover the IP.

The Internet Protocol:

The Internet Protocol (or IP for short) forms the fundamental protocols and allows the internet to work. IP address act as a physical address. They allow devices to address each other across a network. They are unique, and there are 2 types of IPs: IPv4 and IPv6. The most common IP you'll see is IPv4. IPv4 is older but is more commonly used. Whereas IPv6 is much newer and only used in certain cases. They do look a lot different from each other:

Let's break down an IPv4 as we are most of the time only going to work with it. Each IP address consists of 4 digits separated by a dot. And each of the numbers is called an octet as it has an 8-bit value. And as 8-bit values start at 0 and end at 255, this means that an IP address also starts at 0.0.0.0 and ends at 255.255.255.255. This is called an IP space or a range.No worries if you haven't fully gotten this, you may want to look up how binary works to fully understand how and why an IP address starts with 0 and ends with 255.

Subnet mask:

We can further break an IP address down into 2 parts. Each IP address has actually 2 addresses. When the first organizations in the world started making use of IPs, the first 2 numbers formed the network address and the last 2 numbers represented the host address. However, this has changed over time as more and more devices started connecting to the internet. Nowadays, you can only tell what the host and network address are by looking at the subnet mask (I won't go into detail here but all 0 bits form the host address meanwhile all the 1 bits represent the network address).

CIDR:

If you have looked at some subnet masks, you may have realized that they aren't easy to write down. This is where CIDR notations help us. CIDR stands for Classless Inter-Domain Routing and is used to note down IP blocks. Take the following CIDR notation: 255.255.255.255/31. It looks like an IP address followed by a forward slash with a digit. The digit is used for identifying the hosts in that particular range. I recommend you read more about this subject as you will often come across these in bug bounty program scopes.

Networking terminologies:

TCP: TCP stands for Transmission Control Protocol and it basically ensures that data chunks, now called "packets" get sent to their destination reliably. It does so by opening a three-way handshake connection prior to sending the data packets and by also checking for errors. Since the data is divided into smaller packets, only 1 single packet has to be resent if it did contain an error (instead of terminating the whole connection and resending everything again). After the data has been transferred to the other device, it will terminate the connection using a similar four-way handshake.As we covered earlier, TCP is located in the Network layer of the OSI Model.UDP: UDP stands for User Datagram Protocol and is quite similar to TCP. The only big difference between the two is that UDP does not verify the receiving end and does not establish any kind of connection with it. Meaning, every data packet that gets sent (even if it contains errors), will not be checked for errors and resent. This makes UDP extremely unreliable compared to TCP, however, it is still used in certain conditions where delays cannot be part of a process as UDP is much faster than TCP.UDP is also located in the Network layer of the OSI Model.If you are going to rent a VPS or a Virtual Private Server (basically a computer located somewhere in the cloud), then you're going to hear about SSH a lot.SSH: SSH or Secure SHell helps you to establish an encrypted connection with another host (in this case, your VPS) and communicate with it securely (probably execute commands and perform some tasks that may or may not break some websites).SSH and many other similar protocols are located in the Application layer of the OSI Model.

And this is where I will wrap this up for this part.

Thank you for making it this far!

In the next part of Networking basics, I will go over what ports are, and explain DNS (and look at the process behind requesting a domain online) before moving on to HTTP. If you've made it this far! Congratulations! You are one of the few who have done this + you make much more chance to complete this guide and become a bug bounty hunter!I hope you've enjoyed this, if you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

Get $200 in Digital Ocean credits to set up your Virtual Private Server:

DigitalOcean | The Cloud for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

https://m.do.co/c/7b360ceed203

Introduction:

Hi there! So you want to learn to find security vulnerabilities in web applications and report them lawfully in exchange for awesome (often monetary) rewards/bounties? If so, you've found the right place!Welcome to my zero-to-hero bug bounty guide! At the end of this series, you'll be able to understand how the web works, learn to work with the most used tools such as your browser and proxy interceptor and learn how to find and fully test common (OWASP Top 10) security vulnerabilities! This is a weekly newsletter, I will send out each part every week (hopefully at the same time and day)!Below is a small summary of what this series will cover:

Table of contents:

1. A quick introduction to bug bounty, basic requirements and what to expect more (Part 1)

2. How the web works (the HTTP protocol, common request/response headers, etc)

3. Networking basics (explain basic networking concepts that you will be dealing with a lot, like what is an IP)

4. Introduce you to common web app pentesting tools such as your web browser's console and a proxy interceptor

5. Go through OWASP's top 10 vulnerabilities. These are common vulnerabilities that are found in websites. I'm also going to tell you where and how to find them (based on my real findings, you really do not want to miss out on this)

6. Once we got the basics on web app security vulnerabilities, I will teach you how to find suitable programs to start working on them (and get your first bounties in ;).

7. After that, we will go ahead and start automating a lot of repetitive work (again, you do not want to miss out on this as well, I'll be revealing some work that I do for @novasecio).

8. I will cover some advanced bypasses as well (another thing that you don't want to miss out on)

I might add more to this table depending on your feedback ;)!And if you are excited as I am, Go ahead and Tweet about it! Before we move on to the requirements and who I am. Let me first help you understand the concept of "Bug Bounty" and also let me clear up some misconceptions first to avoid any kind of disappointment.

What is Bug Bounty?

Bug bounty or bug bounty hunting is a type of activity where an ethical hacker or web application penetration tester is looking for impactful security vulnerabilities inside a pre-defined scope and under an agreement with the company. If the "bug bounty hunter" succeeds in finding a security vulnerability, he/she can report it to the company in exchange for a (monetary) reward, also commonly referred to as a "bounty".Anything outside of the pre-defined scope is usually mentioned as "out-of-scope" or "OOS" for short. These vulnerabilities are often not rewarded as you did not adhere to the program rules.It can also occur that 2 independent bug bounty hunters report the exact same vulnerability. Usually, the first submission gets accepted, and any other submission following it will be rejected as a "duplicate" and is also in most cases not eligible for a (monetary) reward.You will usually report security vulnerabilities through bug bounty platforms as they provide extra coverage and guidelines that both parties, you and the company, should adhere to.

Bug bounty Misconceptions:

• First of all, bug bounty is not a get-rich-quick game. It requires you to work hard, stay consistent but most importantly, keep learning new things! (Also, just to save you some time on further research, there are no (legal) get-rich-quick jobs anywhere.)

• Bug bounty is not about finding a vulnerability, it's about finding impact. You only get paid if you find something that can impact other users or cause direct harm to the company. If you are looking to get paid for every worked hour, web application penetration testing might be a good fit for you. Also, bear in mind that companies still have the last say in what and how much they reward you.

To not completely demotivate you or push you away from bug bounties, I've included some upsides as well!

Bug bounty Upsides:

• One of the big upsides is of course the rewards, you could go a few weeks long without finding a single vulnerability until that one moment when you find a critical security issue and earn your entire monthly (or even yearly salary) in just a few hours/days of actual work (this is of course backed by your years of experience and knowledge).

• Second upside? If you take bug bounty seriously and stay consistent every day, you can easily gain a lot of knowledge and experience to apply for a job as a web application penetration tester! I've done it and there are a lot like me that got there too! With or without certification!

Now that I covered what bug bounty is all about, let me quickly introduce myself.

WHOAMI:

I am @0xblackbird, an 18-year-old bug bounty hunter with 3 years of experience in web application penetration testing and a deep background in computer programming!I wrote my first line of code when I was 11 (almost 12) years old and was into game development shortly after that, I made a couple of switches (game dev, 3D animating, ...) until I discovered web application penetration testing! I liked the fact that you can get paid (serious cash) for breaking websites and I stuck with it!At the moment, I'm a full-time bug bounty hunter, I do some pentesting work on the side as well, and I'm also building @novasecio, a Pentesting as a Service-based platform (I can't reveal more, it's private only at the moment but you're gonna love it)!I usually hunt on Intigriti (I rank in the top 200 at the moment), but last few months, I've been hunting on a few platforms as my favourite programs are not all on the same platform. I will link the most popular bug bounty platforms in the next posts when I teach you which program to look for.Let's not waste any more time and let's move on to the requirements!

Requirements:

You are most likely going to need a machine that you're quite familiar with. Windows, Mac or any Linux distro will do it. Just be comfortable with it.I know some people are hacking from their phones but it's extremely unreliable, as first of all, it's a very small screen, and secondly, you're going to waste a lot of your time on small simple tasks. I recommend you get yourself a PC or desktop (it's an investment in yourself, you can fully control your return on your investment by staying consistent).The following requirement is optional but I hardly recommend at least holding a grip on basic web development as you'll be dealing with a lot of client-side stuff. It's only going to help you understand things better and help you find more bugs (more on this later).

Here are a few Youtube videos on front-end web development:- 2 Hours course on HTML for beginners- Full Javascript course, learn it in 3.5h- Full CSS course in 6hYou are also probably going to start to automate your stuff later. Having the ability to program will help a lot in automating repetitive tasks! Any language is okay as long as you are comfortable with it, and it does the job.Python3 is the easiest to learn (syntax is easy to understand) and gets recommended a lot as a first programming language. However, you can also learn Ruby. If you want speed Rust, C/C++ or Golang are the way to go.If you're working on a Linux distro, bash is a must-have. Here's a 3h course on bash.Some Youtube videos to get you started:- Learn Python3 (6h course) or go for Python3 (4.5h course)- Ruby 4h course- Rust 1.5h course- Learn C++ (31h course) 😂- Learn Golang (6.65h course)Again, this is optional but highly recommended. You can also skip this part until later.

One final note

I do not intend to make these parts long, I want to keep my newsletter posts short and easy to follow! Any feedback is highly appreciated! You can jump into my DM's or reply to this email if you're reading this from your mailbox!If you do not have Twitter (yet), I would highly recommend you create an account as Twitter is where the biggest infosec community is.You can follow me & direct message me anytime: @0xblackbird

A last task of today:I recommend you to go through my following list on Twitter and follow every account that I follow that is related to infosec (skip the aviation stuff) to get your Twitter feed filled with bug bounty content.That's the best way to keep up with the latest news on bug bounty, you get writeups, payloads, and news about latest CVEs (more on this later).This is where I end part 1 of this zero-to-hero bug bounty course. See you in the next part where I will start explaining the concept of HTTP and how the web works!