BURP_SUITE : REPEATER

The repeater tool in burp suite is used for manipulating and resending captured HTTP requests.

Captures browser requests while using the Burp proxy. You can then replay these requests with tweaks, like changing headers, parameters, or the body. This lets you test different scenarios and explore potential vulnerabilities.

Automate sending requests with varied inputs, a technique called fuzzing, to identify weaknesses in how the application handles user data. The Repeater also allows you to compare responses from different requests, helping you understand the application's behaviour and potential vulnerabilities based on response variations.

Sections of the repeater tab

Request List: See all captured requests here. You can manage multiple requests and navigate their history.

Request Controls: Send, cancel, or navigate through requests using these buttons.

Request & Response View: Edit and send requests in the top section. The bottom section displays the corresponding response.

Layout Options: Choose how you want to see the request and response (side-by-side, vertical, or separate tabs).

Inspector: Analyze and modify requests visually for easier editing.

Target: Shows the destination of your requests (automatically filled when sending from other Burp tools)

Once a request has been captured in the Proxy module, we can send it to Repeater by either right-clicking on the request and selecting sent to the repeater.

Furthermore, we can utilise the history buttons situated to the right of the Send button to navigate through our modification history, allowing us to move forward or backwards as needed.

MESSAGE ANALYSIS TOOLBAR:

Provides us the response and request presentation options

1. Pretty: This is the default option, which takes the raw response and applies slight formatting enhancements to improve readability.

2. Raw: This option displays the unmodified response directly received from the server without any additional formatting.

3. Hex: By selecting this view, we can examine the response in a byte-level representation, which is particularly useful when dealing with binary files.

4. Render: The render option allows us to visualize the page as it would appear in a web browser. While not commonly utilised in Repeater, as our focus is usually on the source code, it still offers a valuable feature. For most scenarios, the Pretty option is generally sufficient. However, it is beneficial to be acquainted with the usage of the other three options.

INSPECTOR:

Breakdown of requests and responses, as well as for experimenting to see how changes made using the higher-level Inspector affect the equivalent raw versions

1. Request Query Parameters: These refer to data sent to the server via the URL. For example, in a GET request likehttps://admin.tryhackme.com/?redirect=false, the query parameter redirect has a value of "false".

2. Request Body Parameters: Similar to query parameters, but specific to POST requests. Any data sent as part of a POST request will be displayed in this section, allowing us to modify the parameters before resending.

3. Request Cookies: This section contains a modifiable list of cookies sent with each request.

4. Request Headers: It enables us to view, access, and modify (including adding or removing) any headers sent with our requests. Editing these headers can be valuable when examining how a web server responds to unexpected headers.

5. Response Headers: This section displays the headers returned by the server in response to our request. It cannot be modified, as we have no control over the headers returned by the server. Note that this section becomes visible only after sending a request and receiving a response.