[Task 4] Overview of Features

[Task 5] Engage Dark Mode

Working on a project late at night? Fear no more! In this task we'll cover how to enable dark mode in Burp Suite!








This task is optional! You can simply click 'Complete' on all of the questions if you'd like to skip it. This section is purely for 'quality of life' improvements while using Burp Suite throughout this room. You can see what dark mode looks like in question three of task eight.



#1 With Burp Suite launched, let's first navigate to the 'User options' tab.
















#2 Next, click on the 'Display' sub-tab.







#3 Now, click on the 'Look and feel' drop-down menu. Select 'Darcula'.












#4 Finally, close and relaunch Burp Suite to have dark theme (or whichever theme you picked) take effect.

[Task 6] Proxy

Generally speaking, proxy servers by definition allow us to relay our traffic through an alternative route to the internet. This can be done for a variety of reasons ranging from educational filtering (common in schools where restricted content must be blocked) to accessing content that may be otherwise unavailable due to region locking or a ban. Using a proxy, however, for web application testing allows us to view and modify traffic inline at a granular level. Throughout this task, we'll explore the major components of the Burp proxy including interception, request history, and the various configuration options we have access to.









Basic diagram of how communications are relayed through a proxy - Wikipedia - Proxy Servers


In task three, Gettin' [CA] Certified, we configured our web traffic to route through our instance of Burp Suite. By default, Burp will be set to 'intercept' our traffic. This means a few things:


1. Requests will by default require our authorization to be sent.


2. We can modify our requests in-line similar to what you might see in a man-in-the-middle attack and then send them on.


3. We can also drop requests we don't want to be sent. This can be useful to see the request attempt after clicking a button or performing another action on the website.


4. And last but not least, we can send these requests to other tools such as Repeater and Intruder for modification and manipulation to induce vulnerabilities.



Burp Suite reference documentation for Proxy: Link


#1 Deploy the VM attached to this task!

To complete this task you need to connect to the TryHackMe network through OpenVPN. If you're using the in-browser machine this isn't needed (but make sure you're accessing the machine and using Burp inside the in-browser machine).





#2 By default, the Burp Suite proxy listens on only one interface. What is it? Use the format of IP:PORT


ANs :- 127.0.01:8080



#3 In Burp Suite, navigate to the Intercept sub-tab of the Proxy section. Enable Intercept






#4 Return to your web browser and navigate to the web application hosted on the VM we deployed just a bit ago. Note that the page appears to be continuously loading. Change back to Burp Suite, we now have a request that's waiting in our intercept tab. Take a look at the actions, which shortcut allows us to forward the request to Repeater?

Ans :- Ctrl-R



#5 How about if we wanted to forward our request to Intruder?


Ans :- Ctrl-I



#6 Burp Suite saves the history of requests sent through the proxy along with their varying details. This can be especially useful when we need to have proof of our actions throughout a penetration test or we want to modify and resend a request we sent a while back. What is the name of the first section wherein general web requests (GET/POST) are saved?


Ans :- HTTP history



#7 Defined in RFC 6455 as a low-latency communication protocol that doesn't require HTTP encapsulation, what is the name of the second section of our saved history in Burp Suite? These are commonly used in collaborate application which require real-time updates (Google Docs is an excellent example here).


Ans :- WebSockets history



#8 Before we move onto exploring our target definition, let's take a look at some of the advanced customization we can utilize in the Burp proxy. Move over to the Options section of the Proxy tab and scroll down to Intercept Client Requests. Here we can apply further fine-grained rules to define which requests we would like to intercept. Perhaps the most useful out of the default rules is our only AND rule. What is it's match type?


Ans :- URL


#9 How about it's 'Relationship'? In this situation, enabling this match rule can be incredibly useful following target definition as we can effectively leave intercept on permanently (unless we need to navigate without intercept) as it won't disturb sites which are outside of our scope - something which is particularly nice if we need to Google something in the same browser.


Ans :- Is in target scope

[Task 7] Target Definition

Perhaps the most important feature in Burp Suite, we'll now be turning our focus to the Target tab!
















The Target tab in Burp allows us to perform arguably some of the most important parts of a web application penetration test: defining our scope, viewing a site map, and specifying our issue definitions (although this is more useful within report generation and scanning).


When starting a web application test you'll very likely be provided a few things:


- The application URL (hopefully for dev/test and not prod)
- A list of the different user roles within the application
- Various test accounts and associated credentials for those accounts
- A list of pieces/forms in the application which are out-of-scope for testing and should be avoided



From this information, we can now start to build our scope within Burp, something which is incredibly important in the case we are planning on performing any automated testing. Typically this is done in a tiered approach wherein we work our way up from the lowest privileged account (this includes unauthenticated access), browsing the site as a normal user would. Browsing like this to discover the full extent of the site is commonly referenced as the 'happy path'. Following the creation of a site map via browsing the happy path, we can go through and start removing various items from the scope. These items typically fit one of these criteria:


- The item (page, form, etc) has been designated as out of scope in the provided documentation from the client
- Automated exploitation of the item (especially in a credentialed manner) would cause a huge mess (like sending hundreds of password reset emails - If you've done a web app professionally you've probably done this at one point)
- Automated exploitation of the item (especially in a credentialed manner) would lead to damaging and potentially crashing the web app


Once we've removed any restricted or otherwise potentially dangerous items from our scope, we can move onto other areas of testing with the various tools within Burp Suite.



Burp Suite reference documentation for Target: Link



#1 Before leaving the Proxy tab, switch Intercept to disabled. We'll still see the pages we navigate to in our history and the target tab, just having Intercept constantly stopping our requests for this next bit will get old fast.





#2 Navigate to the Target tab in Burp. In our last task, Proxy, we browsed to the website on our target machine (in this case OWASP Juice Shop). Find our target site in this list and right-click on it. Select 'Add to scope'.





#3 Clicking 'Add to scope' will trigger a pop-up. This will stop Burp from sending out-of-scope items to our site map.





#4 Select 'Yes' to close the popup.




#5 Browse around the rest of the application to build out our page structure in the target tab. Once you've visited most of the pages of the site return to Burp Suite and expand the various levels of the application directory. What do we call this representation of the collective web application?

Ans :- site map




#6 What is the term for browsing the application as a normal user prior to examining it further?

Ans :- happy path




#7 One last thing before moving on. Within the target tab, you may have noticed a sub-tab for issue definitions. Click into that now.




#8 The issue definitions found here are how Burp Suite defines issues within reporting. While getting started, these issue definitions can be particularly helpful for understanding and categorizing various findings we might have. Which poisoning issue arises when an application behind a cache process input that is not included in the cache key?


Ans :- web cache poisoning

[Task 8] Puttin' it on Repeat[er]

As the name suggests, Repeater allows us to repeat requests we've already made. These requests can either be reissued as-is or with modifications. In contrast to Intruder, Repeater is typically used for the purposes of experimentation or more fine-tuned exploitation wherein automation may not be desired. We'll be checking out Repeater with the goal of finding a proof of concept demonstrating that Juice Shop is vulnerable to SQL injection.







Burp Suite reference documentation for Repeater: Link




#1 To start, click 'Account' (this might be 'Login' depending on the version of Juice Shop) in the top right corner of Juice Shop in order to navigate to the login page.










#2 Try logging in with invalid credentials. What error is generated when login fails?














#3 But wait, didn't we want to send that request to Repeater? Even though we didn't send it to Repeater initially via intercept, we can still find the request in our history. Switch over to the HTTP sub-tab of Proxy. Look through these requests until you find our failed login attempt. Right-click on this request and send it to Repeater and then send it to Intruder, too!























#4 Now that we've sent the request to Repeater, let's try adjusting the request such that we are sending a single quote (') as both the email and password. What error is generated from this request?










#5 Now that we've leveraged Repeater to gain proof of concept that Juice Shop's login is vulnerable to SQLi, let's try something a little more mischievous and attempt to leave a devastating zero-star review. First, click on the drawer button in the top-left of the application. If this isn't present for you, just skip to the next question.












#6 Next, click on 'Customer Feedback' (depending on the version of Juice Shop this also might be along the top of the page next to 'Login' under 'Contact Us')


#7 With the Burp proxy on submit feedback. Once this is done, find the POST request in your HTTP History in Burp and send it to Repeater.


#8 What field do we have to modify in order to submit a zero-star review?


#9 Submit a zero-star review and complete this challenge in Juice Shop!

[Task 9] Help! There's an Intruder!

Arguably the most powerful tool in Burp Suite, Intruder can be used for many things ranging from fuzzing to brute-forcing. At its core, Intruder serves one purpose: automation.




Download File :-  Click Here



While Repeater best handles experimentation or one-off testing, Intruder is meant for repeat testing once a proof of concept has been established. Per the Burp Suite documentation, some common uses are as follows:



- Enumerating identifiers such as usernames, cycling through predictable session/password recovery tokens, and attempting simple password guessing
- Harvesting useful data from user profiles or other pages of interest via grepping our responses
- Fuzzing for vulnerabilities such as SQL injection, cross-site scripting (XSS), and file path traversal











To accomplish these various use cases, Intruder has four different attack types:


1. Sniper - The most popular attack type, this cycles through our selected positions, putting the next available payload (item from our wordlist) in each position in turn. This uses only one set of payloads (one wordlist).


2. Battering Ram - Similar to Sniper, Battering Ram uses only one set of payloads. Unlike Sniper, Battering Ram puts every payload into every selected position. Think about how a battering ram makes contact across a large surface with a single surface, hence the name battering ram for this attack type.




3. Pitchfork - The Pitchfork attack type allows us to use multiple payload sets (one per position selected) and iterate through both payload sets simultaneously. For example, if we selected two positions (say a username field and a password field), we can provide a username and password payload list. Intruder will then cycle through the combinations of usernames and passwords, resulting in a total number of combinations equalling the smallest payload set provided.


4. Cluster Bomb - The Cluster Bomb attack type allows us to use multiple payload sets (one per position selected) and iterate through all combinations of the payload lists we provide. For example, if we selected two positions (say a username field and a password field), we can provide a username and password payload list. Intruder will then cycle through the combinations of usernames and passwords, resulting in a total number of combinations equalling usernames x passwords. Do note, this can get pretty lengthy if you are using the community edition of Burp.










Intruder Attack Type Selection


For our purposes, we'll be returning to the SQL injection vulnerability we previously discovered through using Repeater.




Burp Suite reference documentation for Intruder: Link


#1 Which attack type allows us to select multiple payload sets (one per position) and iterate through them simultaneously?




#2 How about the attack type which allows us to use one payload set in every single position we've selected simultaneously?





#3 Which attack type allows us to select multiple payload sets (one per position) and iterate through all possible combinations?




#4 Perhaps the most commonly used, which attack type allows us to cycle through our payload set, putting the next available payload in each position in turn?




#5 Download the wordlist attached to this room, this is a shortened version of the fuzzdb SQLi platform detection list.




#6 Return to the Intruder in Burp. In our previous task, we passed our failed login attempt to both Repeater and Intruder for further examination. Open up the Positions sub-tab in the Intruder tab with this request now and verify that 'Sniper' is selected as our attack type.














#7 Burp attempts to automatically highlight possible fields of interest for Intruder, however, it doesn't have it quite right for what we'll be looking at in this instance. Hit 'Clear' on the right-hand side to clear all selected fields.






#8 Next, let's highlight the email field between the double quotes ("). This will be whatever you entered in the email field for our previous failed login attempt.
















#9 Now click 'Add' to select our email field as a position for our payloads.











#10 Next, let's switch to the payloads sub-tab of Intruder. Once there, hit 'Load' and select the wordlist you previously downloaded in question five that is attached to this task.










#11 Almost there! Scroll down and uncheck 'URL-encode these characters'. We don't want to have the characters sent in our payloads to be encoded as they otherwise won't be recognized by SQL.








#12 Finally, click 'Start attack'. What is the first payload that returns a 200 status code, showing that we have successfully bypassed authentication?


Ans :- a ` or 1=1--

[Task 10] As it turns out the machines are better at math than us

While not as commonly used in a practice environment, Sequencer represents a core tool in a proper web application pentest. Burp's Sequencer, per the Burp documentation, is a tool for analyzing the quality of randomness in an application's sessions tokens and other important data items that are otherwise intended to be unpredictable. Some commonly analyzed items include:



- Session tokens
- Anti-CSRF (Cross-Site Request Forgery) tokens
- Password reset tokens (sent with password resets that in theory uniquely tie users with their password reset requests)


We'll take a quick peek at how we can use Sequencer to examine the session cookies which Juice Shop issues.



SEO Friendly Progressive Web Applications withThe Overcoat by Chill Desk on Dribbble Angular Universal by Maxime Bourgeois on Dribbble













Burp Suite reference documentation for Sequencer: Link



#1 Switch over to the HTTP history sub-tab of Proxy.



#2 We're going to dig for a response which issues a cookie. Parse through the various responses we've received from Juice Shop until you find one that includes a 'Set-Cookie' header.



#3 Once you've found a request response that issues a cookie, right-click on the request and select 'Send to Sequencer'.


#4 Change over Sequencer and select 'Start live capture'



#5 Let Sequencer run and collect ~10,000 requests. Once it hits roughly that amount hit 'Pause' and then 'Analyze now'



#6 Parse through the results. What is the effective estimated entropy measured in?


Ans :- bits



#7 In order to find the usable bits of entropy we often have to make some adjustmens to have a normalized dataset. What item is converted in this process?

Ans :- token

[Task 11] Decoder and Comparer

Decoder and Comparer, while lesser tools within Burp Suite, are still essential to understand and leverage as part of being a proficient web app tester.






As the name suggests, Decoder is a tool that allows us to perform various transforms on pieces of data. These transforms vary from decoding/encoding to various bases or URL encoding. We chain these transforms together and Decoder will automatically spawn an additional tier each time we select a decoder, encoder, or hash. This tool ultimately functions very similarly to CyberChef, albeit slightly less powerful.





Similarly, Comparer, as you might have guessed is a tool we can use to compare different responses or other pieces of data such as site maps or proxy histories (awesome for access control issue testing). This is very similar to the Linux tool diff.


Per the Burp documentation, some common uses for Comparer are as follows:


- When looking for username enumeration conditions, you can compare responses to failed logins using valid and invalid usernames, looking for subtle differences in responses. This is also sometimes useful for when enumerating password recovery forms or another similar recovery/account access mechanism.


- When an Intruder attack has resulted in some very large responses with different lengths than the base response, you can compare these to quickly see where the differences lie.


- When comparing the site maps or Proxy history entries generated by different types of users, you can compare pairs of similar requests to see where the differences lie that give rise to different application behavior. This may reveal possible access control issues in the application wherein lower privileged users can access pages they really shouldn't be able to.


- When testing for blind SQL injection bugs using Boolean condition injection and other similar tests, you can compare two responses to see whether injecting different conditions has resulted in a relevant difference in responses.


*These examples are taken nearly in their entirety from the Burp docs simply to provide a broader set of examples to consider when using Comparer.



JavaScript Arrays in Depth by Maxime Bourgeois on Dribbble


Burp Suite reference documentation for Decoder and Comparer



#1 Let's first take a look at decoder by revisiting an old friend. Previously we discovered the scoreboard within the site JavaScript. Return to our target tab and find the API endpoint highlighted in the following request:







#2 Copy the first line of that request and paste it into Decoder. Next, select 'Decode as ...' URL





#3 What character does the %20 in the request we copied into Decoder decode as?


Ans :- space




#4 Similar to CyberChef, Decoder also has a 'Magic' mode where it will automatically attempt to decode the input it is provided. What is this mode called?


Ans :- Smart Decode



#5 What can we load into Comparer to see differences in what various user roles can access? This is very useful to check for access control issues.





Ans :- site maps




#6 Comparer can perform a diff against two different metrics, which one allows us to examine the data loaded in as-is rather than breaking it down into bytes?


Ans :- words

[Task 12] Installing some Mods [Extender]

Similar to adding mods to a game like Minecraft, Extender allows us to add components such as tool integrations, additional scan definitions, and more! Here are some of the most popular extensions I suggest checking out (not all of these are free but I suggest looking into them all the same):



 Logger++ - Adds enhanced logging to all requests and responses from all Burp Suite tools, enable this one before you need it ;)

Request Smuggler - A relatively new extension, this allows you to attempt to smuggle requests to backend servers. See this talk by James Kettle for more details: Link

Autorize - Useful for authentication testing in web app tests. These tests typically revolve around navigating to restricted pages or issuing restricted GET requests with the session cookies of low-privileged users

Burp Teams Server - Allows for collaboration on a Burp project amongst team members. Project details are shared in a chatroom-like format

Retire.js - Adds scanner checks for outdated JavaScript libraries that contain vulnerabilities, this is a premium extension

J2EEScan - Adds scanner test coverage for J2EE (java platform for web development) applications, this is a premium extension

Request Timer - Captures response times for requests made by all Burp tools, useful for discovering timing attack vectors










A prerequisite for many of the extensions offered for Burp, we'll walk through the installation of Jython, the Java implementation of Python.


Burp Suite reference documentation for Extender: Link


Article on some of the top extensions for Burp Suite: Link



#1 To start, let's go ahead and switch over to the Options sub-tab of the Extender tab.



#2 Scroll down until you reach the 'Python Environment' section. Note, Burp requires the standalone edition of Jython.



#3 Download the standalone version of Jython from here: Link - I suggest saving this or moving it to your Documents folder



#4 Return back to Burp and hit 'Select file' under the Python Environment subsection for Jython standalone. Navigate to where you just downloaded this file and select it.



#5 Burp is now set to go for installing extensions. Switch to the BApp Store sub-tab of Extender and look through the various extensions offered.



#6 Which extension allows us too bookmark various requests?


Ans :- Bookmarks

[Task 13] But wait, there's more!

Before we conclude, let's take a quick look into the features that Burp Suite Professional offers: The Burp Suite Scanner and Collaborator Client!





File Download :- Click Here 










Arguably the most powerful feature in Burp Suite, the Burp Suite Scanner allows us to passively and actively scan and spider the website we are testing for vulnerabilities. In Burp 2.0's task-based model, we can launch these scans (Scanner and Spider) from the dashboard and let them run in the background while we continue to examine the web app. In this case, I've run an unauthenticated scan against Juice Shop and have attached it to this task. These reports can provide a starting place for further enumeration and exploitation via the other tools in Burp Suite.









A Preview of the Report Attached to this Task Created with Burp Professional


Commonly used in manual tests, Burp Collaborator Client allows us to gain insight into issues that may otherwise seem to produce no output. Often during testing, we may come across items which, either due to timing/slowness of the web app or a lack of any reaction, are likely vulnerable but don't produce any sure-fire indicators. With Burp Collaborator, however, we can produce out-of-band alerts via generating payloads that reach back to Burp Suite's servers for us.