JavaScript Enumeration for bug bounty hunters

JavaScript Enumeration is a critical skill to have if you want to level up your penetration testing or bug bounty hunting game. Yet, not everyone does it, partly because it is a boring exercise or it consumes most of your time, not to mention how intimidated you might feel reading someone else’s code. Today, we will explore this topic and understand why it matters, and how you can perform it.

Hopefully, this episode will help you overcome these hurdles and give you the tools you need to make JavaScript Enumeration less painful. We will first understand how it can lead to serious security bugs. Then, we will discover different ways to properly do it. So, stay with me until the end because you will definitely learn some hacking tricks along the way!

Why JavaScript enumeration matters?

If you don’t perform JavaScript enumeration during your hacking engagements, you are overlooking a vital portion of your target web application. In fact, JavaScript powers the client-side; meaning that all the logic that happens before hitting the back-end server is there. Think about it, you have half of the code that you can look through, and code never lies! If there is an error, the code will tell you, you just have to look through it.

Let’s first discover what you could find with JavaScript Enumeration.

JavaScript enumeration can give you easy wins

Because of bad coding practices, the developers can unintentionally introduce low hanging security bugs in the JavaScript code, ready to be exploited by entry-level hackers. Sloppy coding can include hard-coded credentials, hidden web page URLs with no authentication, or even back-end API endpoints with broken access control flaws.

For example, by simply enumerating the code for API endpoints, you can find some unprotected ones. If you want to learn a real-world example of how I found a serious account takeover flaw, make sure to read this article.

JavaScript enumeration helps you understand how the application works

While you are looking through the code for hard-coded credentials and API endpoints, you will naturally get a feel of the structure, the coding style and what the web application does. If you don’t get that, don’t worry, it comes with practice; the more you do it, the easier it becomes. We will explore shortly how you can start doing it.

JavaScript enumeration can give you deep and serious bugs

Besides the low hanging fruits which you can find using JavaScript enumeration, you can uncover hidden issues which fewer people are looking for. These are typically DOM XSS vulnerabilities that you can exploit through postMessage events or the usage of dangerous JavaScript sinks and sources. For example, a developer might use the path part of the URL to populate the DOM using the sink innerHTML. In this case, you can inject malicious JavaScript code that will be reflected in the DOM without proper encoding, leading to a DOM XSS.

If you want to learn and practice DOM XSS, you can visit Portswigger’s article.

JavaScript enumeration simplified with tools

JavaScript enumeration can be intimidating, hard or time-consuming. If that’s the case for you, maybe you are doing it the wrong way! If you jump onto random JavaScript files and look for low hanging fruits only, you might get lucky once, but you won’t find great and consistent bugs. At least you won’t cover the entire attack surface. Instead, I suggest you first extract all JavaScript files, then browse through them, and then you can focus on specific parts which seem interesting.

You can use various tools that will assist you during this exercise. These are the ones I found helpful, but if you prefer other tools, feel free to suggest others in the comments.

Step 1 in JavaScript enumeration: Extract JavaScript files

Sometimes all you have is the login page, that’s fine. Once you finish browsing all the accessible features, your web proxy should have recorded all the JavaScript files. I like to use BurpSuite Professional to extract them all at once, but you can use other alternatives, such as manually downloading all the JavaScript files from BurpSuite Community Edition (The free version of BurpSuite).

To do that, you right-click on your target root entry in the Sitemap, then choose the Find scripts option under the Engagement tools in the contextual menu.

JavaScript Enumeration using BurpSuite Find scripts feature
JavaScript Enumeration using BurpSuite Find scripts feature

From there, you click on Export scripts and choose a file to store them. I like to store them because I will be using the next tools to look for specific things, like endpoints, secrets, etc.

Saving all the scripts into one single file
Saving all the scripts into one single file

Extract JavaScript using free tools

If you have been following this blog, you know that the bug bounty community has published many awesome tools which you can combine to get the content of JavaScript files. I like to use waybackurls and the built-in bash commands xargs, curl and tee. You can find many more on this article. Here is a one-liner that will do the job:

waybackurls target.com | grep "\\.js" | xargs -n1 -I@ curl -k @ | tee -a content.txt

The above one-liner will collect all publicly available JavaScript files using waybackurls. Then, it filters only JavaScript files. From there, it grabs the content of each file using curl. Finally, it stores the result in one file.

Step 2: Beautify the JavaScript code

From my experience, most of the JavaScript files get obfuscated and packed into one single line. Therefore, it’s hard to deal with them as they are. Luckily, there are tools which help at least structure them into readable JavaScript code. The one I use is Jsbeautifier, a command-line tool that accepts a file as input and beautifies its content, unpacks it or deobfuscates it into a resulting file.

First, you install it using pip: pip install jsbeautifier. Then, you run it with js-beautify -o outfile.txt scripts.txt. This will output the file outfile.txt which you can easily browse through.

It’s time for the next step: finding the juicy data we are all looking for!

Step 3: JavaScript enumeration with Grep and the family

Now that we have a readable version of all the JavaScript code in one place, I like to start with Grep to get a feel of what I am expecting. The general command is grep --color -i term outfile.txt. You just change the word term with what you’re looking for. For example, try words like secret, admin, password or token to find hardcoded secrets. Alternatively, you can use a path prefix to look for endpoints. Say you noticed that all API endpoints start with /api/v1. In this case, you can substitute the word term in the grep command with /api/v1 to collect all the API endpoints.

Once you grab some endpoints, and hopefully some secrets, you can focus on areas of interest within the JavaScript files.

Javascript enumeration using Chrome Dev Tools

If you don’t have BurpSuite Pro or you don’t want to parse the entire JavaScript files, you can use your built-in Web Browser Developer tools. I like to use the Chrome Browser.

Look for keywords across the entire website

In Chrome, you can open the Developer Tools using the shortcut Command + option + I on Mac, and Ctrl + Shift + I on Windows. From there, choose the Sources Tab. Once inside, you will see the different files in a tree on the left. Hit Command + option + F on Mac, or Ctrl + Shift + F on Windows and a search menu will appear in the bottom. Type the keywords you found from the previous steps to locate where exactly they appear in the client-side source code.

JavaScript Enumeration using Chrome Developer Tools
JavaScript Enumeration using Chrome Developer Tools

From there, click on the one on the right of the results, which will load the JavaScript file in the main screen.

JavaScript enumeration within a file in Chrome Dev Tools

Once you choose a JavaScript file, it may appear obfuscated or minified. Don’t worry, Chrome can make it readable. You just have to click on the Prety-print button. Alternatively, there is a button named {} on the bottom of the screen, which you can click as well.

The Pretty-print feature in Chrome Developer Tools
The Pretty-print feature in Chrome Developer Tools

From there, hit Command + F on Mac or Ctrl + F on Windows and look for your keyword, such as api_key.

You can search for keywords inside the beautified JavaScript code
You can search for keywords inside the beautified JavaScript code

JavaScript Enumeration using breakpoints

Once you focus on a particular snippet within a JavaScript file which brings your attention, you might find it hard to understand what the code does. This can be due to random variable or function names, or simply because you can’t understand what the code does. In this case, you can set a break-point on one or multiple lines, then refresh the page.

Using breakpoints to pause the execution at areas of your interest
Using breakpoints to pause the execution at areas of your interest

Once the client-side code hits your break-point, you can debug it like you would do in any Code Editor using the controls you have on the menu in the right.

You can use the control buttons to debug the JavaScript code
You can use the control buttons to debug the JavaScript code

JavaScript enumeration examples

After mapping the application, collecting all JavaScript files, looking for interesting areas and debugging the JavaScript code, it really depends on your experience and creativity to find interesting bugs. However, without the prior steps, you wouldn’t be able to focus on the areas that matter. The following are examples which illustrate what hackers have found using JavaScript enumeration.

PostMessage DOM XSS vulnerabilities

In this great article, Mathias explains how he performed JavaScript Enumeration using the very steps you discovered earlier to find and exploit a DOM XSS vulnerability due to a misconfiguration in the PostMessage event handling.

Exploit a token leak to disclose your Paypal password

This blog post explains how Alex, a Security Researcher and bug bounty hunter, could exfiltrate your Paypal password through a token leak. He started with JavaScript enumeration and found an interesting endpoint that he was able to understand and exploit.

Conclusion

Hopefully, you now understand why you should perform JavaScript enumeration. But most importantly, you have a methodical approach and the tools to help during the process.

Top 10 Burp Suite extensions to use in bug bounty hunting

Hello ethical hackers and bug bounty hunters. Today, you will learn the top 10 Burp Suite extensions I found myself using over and over again. They assist me in different areas, such as pretty-printing data, actively testing for specific vulnerability classes, parsing API definitions and brute-forcing.

Wsdler is your burp extension for SOAP

During your penetration testing or bug bounty hunting, you might encounter SOAP-based APIs. They are web services that you can consume according to a file which describes the actions they expose and how to call them. This file is based on the Web Services Description Language (WSDL).

Whenever you find one, you can parse it using Wsdler. Additionally, this Burp extension constructs the HTTP requests as the API expects them.

Wsdler Burp extension showing the HTTP request to send
Wsdler Burp extension showing the HTTP request to send

JSON Beautifier

Before Burp Suite rolled its Pretty button feature, this was the first extension I needed to install after any fresh Burp Suite setup. Nowadays, the majority of web application use RESTful APIs which generally use JSON objects to transfer data between the client and the server. JSON Beautifier prettifies the inline JSON data to make your life easier.

JSON Beautifier burp extension prettifies JSON data
JSON Beautifier burp extension prettifies JSON data

This Burp extension is free and can be used in either Burp Suite Community Edition or Professional.

J2EEScan is a great burp extension for Java EE applications

In my penetration testing assignments, I usually test J2EE web applications, which are Java web applications that support enterprise-level requirements, such as scalability and availability. Therefore, I use J2EEScan to assist me in finding vulnerabilities for the most common CVEs that target J2EE technologies.

The extension adds test cases to the BurpSuite Scanner. Therefore, there no additional configuration after you install it. All you have to do is run a scan and wait for vulnerabilities in the Issue Activity panel in the Burp’s Dashboard tab.

J2EEScan showing a list of issues in Burp Suite issue tracker
J2EEScan showing a list of issues in Burp Suite issue tracker

JSON WEB Tokens, the Burp extension, not the standard

According to jwt.io, JSON Web Token is:

[…] an open standard […] that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.

JWT token parsed
JWT token parsed

When you do bug bounty hunting or web application penetration testing, it is a pain to manually copy the tokens from Burp Suite and paste them into your favourite parsing tool, such as jwt.io. This extension allows you to parse the token within Burp, the same way JSON Beautifier prettifies inline JSON objects.

SAML Raider

For those of you who don’t know what SAML, it’s a standard used in Single Sign-On (SSO) for authentication. Here is a brief definition from Wikipedia:

Security Assertion Markup Language (SAML) […] is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions.

Since SAML requests contain long base64 encoded XML data, it is impractical to manually parse them. SAML Raider automatically performs the parsing within Burp Suite. Additionally, you can use it to perform known attacks against your target web application. In fact, it comes with pre-configured exploitation techniques, such as signature wrapping, that you can easily run to test for weaknesses in SAML implementations.

SAML request parsed
SAML request parsed

AuthMatrix burp extension for broken access control

I’ve already covered this great extension in a Youtube video. It allows you to test for broken access control vulnerabilities, such as IDOR, unprotected endpoints, etc. The flow is fairly simple. Firstly, you browse your target application and send any interesting requests to this extension. Then, you create the target users, such as the attacker and the victim. Then, for each user, you configure the session cookies, and any HTTP headers containing tokens such as JWT or API keys. Lastly, you hit the run button and let AuthMatrix highlight the suspicious requests in red.

All requests are protected against broken access control
All requests are protected against broken access control

HTTP request smuggler

This is the go-to Burp extension when you want to easily detect and exploit a web application through HTTP Request Smuggling.

It detects whether you have a CL.TE or TE.CL condition and reports it directly into Burp Suite’s Dashboard tab, under the Issue Activity menu where all the issues get listed.

If you have no clue about what do CL.TE and TE.CL means, I invite you to read this article from the authors of Burp Suite.

Turbo Intruder

This extension allows you to send large numbers of HTTP requests to a target web application. If you have Burp Community, you know that you can only work with a limited version of the Intruder which does not support multiple threads. Instead, you can use Turbo Intruder.

Since this Burp extension uses a Python snippet that you can edit, I recommend you get familiar with the basics of the Python programming language. That way, you can customize Turbo Intruder to bring more flexibility when you brute force.

Upload Scanner

Whenever you encounter a file upload feature that uses the multipart mime type, I encourage you to give this Burp extension a try. In fact, you can use it to probe the upload features for many security issues.

It fuzzes all the parameters using a set of organized categories that you can choose from. If the application retrieves the uploads, you can configure Upload Scanner to fetch the files to verify cases like XSS.

There are plenty of other features in this awesome Burp extension. I encourage you to learn more about it. Additionally, I prepared this Youtube video to show you how it works.

Java Deserialization Scanner

This Burp extension checks for insecure deserialization issues in Java applications. It uses pre-built serialized java objects to probe the application for a callback. You can configure this feedback to be either a time delay or a callback. If the application sleeps for some time before responding, or if you receive a hit as a callback, the extension highlights exactly what payload has triggered it. Therefore, you can prepare your own payload using tools such as ysoserial.

If you want to learn how insecure deserialization works and how to exploit it with real examples, I invite you to read this article.

Conclusion

There are so many tools, extensions and methodologies available a few clicks away. However, I should mention that you don’t have to use them all. Take some time to discover how they work, then pick the ones that suit your taste and your needs.

Hopefully, this episode has shown you some new Burp extensions that might help you in your next assignment.

Until the next episode, stay curious, keep learning and go find some bugs!

Hacking a Google Web Toolkit application

hacking a GWT application

Hello ethical hackers and bug bounty hunters! I’ve recently conducted a successful penetration testing against a web application built using Google Web Toolkit, and I want to share with you the process I followed and the bugs I found. Hopefully, this episode will inspire you to try harder during your own bug bounty hunting and penetration testing journey.

I will briefly explain what Google Web Toolkit is and what research has already been made around it. Then, I will explain why and how I built a Burp extension to help me during the penetration testing process. Finally, I will share with you some vulnerabilities I found, especially a cool one which required further effort. So stay with me as we smash this web application into pieces!

A brief introduction of Google Web Toolkit

Throughout this episode, I will use Google Web toolkit and GWT interchangeably. It is pronounced GWiT according to the official website.

What is Google Web Toolkit?

Throughout my career, I’ve encountered GWT applications two times only. It’s a relatively old technology, but it’s still used by some companies. According to the official GWT website, Google Web Toolkit is

[…] a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.

From the official GWT website

In other words, GWT allows developers to write web applications in Java, without having to worry about client-side technologies. In fact, it cross-compiles Java code into JavaScript ready to be used cross-browsers. 

How do Google Web Toolkit requests look like?

It’s easy to tell when you are in front of a GWT application. Typically, you will mostly see POST requests in your web proxy, with a series of strings separated with pipes. It seems intimidating at first, but when you understand how the POST data is structured, it’s fairly easy to spot what it does with a bit of practice. The following is the kind of data you will encounter in a typical GWT web applications.

GWT body example
GWT body example

Understanding the Google Web Toolkit body

I’ve built my knowledge upon this awesome article which explains the previous work that has been done, the GWT body structure and how you can enumerate the endpoints in such a technology. Although it doesn’t completely apply to recent versions, I still recommend you take some time to read it. However, if you still don’t want to manually analyze the requests, it’s possible to parse the GWT requests and pinpoint exactly where the user input is located thanks to a parser available on GitHub. Using this tool, the following command takes the GWT request body and returns the user input marked with the same highlight that BurpSuite uses in the Intruder tool.

GWT parser script highlighting user input similar to Burp Intruder
GWT parser script highlighting user input similar to Burp Intruder

Even with this, it’s impractical for me to manually copy the request body from BurpSuite and run the parser for each and every request. I think it would be great if BurpSuite automatically highlights the user input whenever it encounters a GWT request.

Writing my own Burp Extension for Google Web Toolkit

I have always wanted to write a BurpSuite extension, and this was the best opportunity for me to do so. In fact, I didn’t find any publicly available extension that would successfully parse this kind of requests. For example, the GWT Insertion Points is an extension which doesn’t seem to work, at least for me. It hasn’t been updated for 3 years. Moreover, ZAProxy supports scanning GWT requests, but it doesn’t support them during manual security testing.

The birth of GWTab

With the penetration testing schedule I had, I planned for one day to write the extension. Therefore, I had to keep it simple. The goal was to show a new tab in BurpSuite containing the user input for every GWT request. That way, I can significantly increase my efficiency by focusing only on the marked strings without having to manually run the parsing command. Hence, GWTab was born.

The process of writing GWTab

Writing GWTab involved three main actions:

  • Show a new tab in Burp: I used the custom editor tab template provided by BurpSuite, which gave me a quick start and let me focus on only the GWT feature I wanted to develop. 
  • Parse the GWT body: I used the parser I mentioned earlier. As I said, it can highlight the user input with the Burp Intruder’s marker, which is useful if I want to perform some automated fuzzing later, or even active scanning based on the highlighted input.
  • Extensive reading: I had to read parts of the Burp Extender API in order to properly understand the signature of the functions, the interfaces to use and what to implement.

After a lot of trial and error, I finally got it working! I made it available for everyone on GitHub. The following screenshot shows the new GWT tab containing the user input that I can focus on.

GWT body shown in directly in a Burp tab thanks to the GWTab extension
GWT body shown in directly in a Burp tab thanks to the GWTab extension

Limitations of GWTab

Some requests containing long values make the GWT parser crash. Therefore, GWTab will sometimes show the message “Parser Failed” whenever that happens. Unfortunately, I couldn’t invest more time to fix this issue on the parser.

Now that I can spot user input in most GWT requests on the fly, I was ready to start hunting for those juicy bugs!

Low hanging fruits

I found many low hanging vulnerabilities during this assessment because developers simply didn’t bother implementing any sort of proper access control.

Security through obscurity is a flaw by design

Because the GWT body seems complex, developers assume hackers won’t be able to understand and exploit it. I guess they ignore the very definition of a hacker. If you are a developer reading this, just know that curiosity and challenge are key drivers for a hacker. Besides, be aware that security through obscurity is a fundamentally false protection. It has only pushed hackers to dig even deeper. 

This application was no different. In fact, Broken Access Control and IDOR vulnerabilities were everywhere.

IDOR everywhere

Because of the false assumption I mentioned earlier, almost all endpoints were vulnerable to IDOR vulnerabilities. To make things worse, most requests use increasing numerical identifiers. Besides, it was easy to spot such IDs without even using GWTab since there was only one identifier per request. All I needed was a trained eye, which came naturally with practice. These vulnerable endpoints allowed me to access, edit and even delete resources of other accounts.

However, I want to share details about one bug which required more effort to fully exploit. I chose this one because I want to demonstrate why impact is critical and what techniques you can use to increase it.

Beyond trivial IDOR vulnerabilities

This application is a service exchange platform which allows its clients to offer and consume services. Therefore, if an attacker can delete arbitrary offers, it means that the whole purpose of the application is compromised. Guess what! I found just how to achieve that!

Vulnerability detection

Detecting this vulnerability was easy. In fact, I followed the same approach I mentioned in the video tutorial about Broken Access Control. In a nutshell, I used two separate accounts. Using the first account, I created an offer and triggered the request to delete it. Before deleting it though, I captured the request using BurpSuite and sent it to the Repeater, then dropped the request to preserve the offer. From there, I took the JSON Web Token of the attacking user and inserted it into the vulnerable request. When I sent it to the server, the victim’s offer got deleted.

Impact analysis

Looking at the POST data revealed a huge payload containing multiple objects, IDs and string values. As a bug bounty hunter, you would quickly report this bug right? Well, the impact is still not clear. In fact, I had no idea how an attacker can realistically build such POST data. If you have listened to read the episode about writing a good report, you know that impact plays a huge role in the bug bounty game. To prove the impact, I had to dig deeper into the application.

Exploiting the vulnerability

I first assumed that the server might delete the offer whose ID is present in the request. Therefore, I tried injecting the victim’s offer ID in all the potential inputs present in the POST data. I had to do it by hand since the GWTab extension failed at parsing the POST data. However, after many tries, it became obvious that this was not the right approach because nothing was deleted.

I didn’t want to give up so quickly. I knew that the application allowed users to search for offers of other users. What if I could grab the entire offer object from the results? Unfortunately, this idea failed since both objects didn’t fully match.

It was clear that I needed two requirements if I wanted to successfully exploit this vulnerability.

  • First, I needed a request which uses the same offer object structure.
  • Second, this dream request should be accessible to the attacker.

Based on these two requirements, I started looking through the application features for all the actions a user can perform on offers published by other users. After some time, I found that the user can like and unlike an offer. Lucky for me, the unlike operation uses the exact same offer object as the one used in the offer deletion request! I couldn’t believe my eyes, I was really lucky!

From there, the attack scenario became clear:

  • An attacker browses the offers list, which is public.
  • He/she likes the victim’s offer, then unlikes it.
  • He/she captures the offer object and injects it into the vulnerable request.
  • The victim’s offer gets deleted from the database.

Writing the report

Now that the impact is clear, you can finally and safely report that bug without worrying about rejection. Besides, you might even reduce the probability of getting duplicated since your vulnerability requires more effort to exploit, and not all bug bounty hunters are willing to take the extra steps. Moreover, even if the team accepts your not-so-convincing-impact report, the reward of a clear impact will certainly be much higher.

Conclusion

In the offensive security industry, whether you are a full-time penetration tester or a seasoned bug bounty hunter, curiosity and challenge are the fuel which will push your limits. In my case, I always wanted to write a Burp extension to solve a problem, and this application presented the right opportunity for me to challenge myself. Besides, I always seek ways to achieve the highest impact not only to get higher bounties but to give a better return on investment to my clients as well.

Later I found that the developers were already aware of this issue. However, because of the complexity of the POST data, they assumed that nobody would figure out how to successfully exploit the vulnerability. Thanks to this full exploit, they’ve learnt that they should never rely on obscurity…the hard way!

I hope you found this content useful. If you did, then support me by commenting, sharing and subscribing. Until next time, stay curious, keep learning and go find some bugs.

OWASP Top 10 training for Burp Suite

Hello and welcome again in this OWASP Top 10 training series. In this blog post, you will setup Burp Suite. Then, you will configure it to capture HTTP traffic.

By the end of this blog post, you will have everything ready to start practicing all the OWASP Top ten vulnerabilities.If you would like to setup Zaproxy instead, I prepared a step-by-step guide to do it here. My suggestion is to setup both OWASP Zap and Burp Suite and get yourself comfortable in working with them. They are both the best tools to have under your ethical hacking belt.

OWASP Top 10 training setup steps for Burp Suite

Burp Suite is a web application security testing collection of tools developed by Portswigger Web Security. If this doesn’t ring a bell with you, you should add @albinowax in your Twitter account and google Postwigger Academy, you will thank me later 😉  

Burp Suite is a great piece of software which enables you to perform the same tasks as OWASP Zap does. It comes with a free, Pro and enterprise version. The Pro version includes the Burp Scanner, which is for automated(ish) testing. The enterprise version is meant for enterprise environments where you need to constantly scan your assets. 

For now, all you have to know is that the free version is more than enough for the purpose of this training.

Setup Burp Suite Community Edition

  1. As we did with Owasp Zap, go to the download page and download Burp Suite Community Edition. This is the free version.
  2. Follow the setup instructions by clicking the Next button.
  3. When the installation is done, click on the Finish button.
  4. When you open Burp Suite, you will have the only option to use a temporary project, which is fine for our case. Click Next. Then click “Start Burp”.

Configure Burp Proxy settings

  1. In the top left you can see tabs. Click on the one named “Proxy”, then the tab OptionsOWASP Top 10 training: Burp Suite proxy settings
  2. Make sure you change the port to 8087, or any other port that you’d like which doesn’t interfere with an already running service. Remember that if you have Zaproxy running from the previous episode, you obviously cannot use its port in Burp Suite.

Configure the web browser

  1. To configure Foxyproxy add-on, follow the same steps as we have done in Zaproxy and create a new proxy with the port 8087. Give it a meaningful name, like “Burp”
  2. Now we are going to import Burp CA certificate. Go to http://burp, make sure that you have chosen Burp as your proxy in FoxyProxy.
  3. Click on CA Certificate on the top right corner of the web page.
  4. Follow the same steps as we did in the Zaproxy setup part to import the downloaded certificate into Firefox.

Testing HTTP traffic with Burp Suite

  1. Go to the Proxy tab, then the Intercept tab
  2. Disable “Intercept is on”, and click on the “HTTP history” tabOWASP Top 10 training: Burp Suite HTTP history
  3. Go to any web page on your Firefox browser, you should see HTTP traffic coming through Burp Suite in the HTTP history.

Congratulations! You’ve made another step forward towards practicing OWASP Top 10 vulnerabilities! In the next episodes, we will set up and configure our vulnerable web applications.

That’s it for today! I hope you enjoyed reading this blog post. Stay tuned for the next one. If you’d like to be notified when there is news on thehackerish.com, please subscribe to the Newsletter below. Until then, stay curious, crave for learning, be ethical and share with the world!

Find the video here