From zero to hero in bug bounty [Pt. 5]

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:

ZAProxy:

Caido:

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: