Burpsuite is known to be one of the powerful penetration testing tools, that was created by Portswigger a high-profile web security organization, and is commonly used by penetration testers, and bug bounty hunters alike.
In this article, we will be describing a few Headers information’s intercepted using this tool. The aim is to expose the basics or foundational information of these headers, every aspiring web application security tester should know, and also how they can manipulate this header information’s to discover vulnerabilities.
1. REQUEST METHOD:
This when intercepted proxying through Burpsuite, demonstrates and explains the type of request made to fetch the information from the tested target.
Depending on what endpoint you are hitting or targeting, this can be manipulated with other methods, to get sensitive information about the webserver. From the image figure (Fig-1) shown below, you can see that, when trying to make a request to the target, the method used here is “GET”, assuming we are testing an API endpoint, we could change that to another method such as “POST” etc. to insert or modify data on the target server side of the endpoint.
There are various methods by which a request can be made to a target. These methods are: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, TRACE, and TRACK. Understanding these various methods in depth, and with your skills as a penetration tester (Red Teamer), gives you leverage to manipulate the method, and repeat the request, to obtain the sensitive information. Also, this is not limited to just testing API endpoints.
2. HTTP VERSION:
This contains information about what type of version was used in making the request. From the image Fig-1 above, the request made indicates that the web browser made such request, using HTTP/2, which the target or host whose resources we are requesting, supports.
3. HOST (KNOWN AS THE ENDPOINT):
This is information about the intercept of the request made. Usually, it contains information about the target or endpoint that was proxied through Burpsuite. For example, assuming we are trying to proxy the login credentials of a target which we desire to test for SQL-Injection, this can be modified, by setting positions in the respective data value, and adding a payload to match the respective position. Then, then we can further conduct an attack using the desired form of attack supported by Burpsuite e.g. Cluster Bomb etc. To test which SQL-payload is injectable by the endpoint we are testing, in this case the login form.
Modifying the “HOST(ENDPOINT)” is not limited to just SQL-injection. As an experienced pentester, depending on the information obtained when proxied through Burpsuite, or the endpoint you are targeting, you could do other forms of manipulation on the Host and combining it with the “REQUEST METHOD” modified e.g. (changing GET to POST), you as a penetration tester, could obtain sensitive information as well to exploit.
4. SEC-CH-UA (KNOWN AS USER AGENT CLIENT):
The Sec-Ch-Ua, also known as the User-Agent Client Hints header, contains information of what user agent was utilized in intercepting the request made to the host, endpoint, or target. From the image (Fig-1) we could see the information “Chromium”; v=”125”, “Not.A/Brand”; v= “24”.
Breaking down the information, we could see that the request was proxied using the Burpsuite chromium browser, and the version is 125, the Not.A/Brand indicates, that we are not using a specific brand or version of the browser. As an experienced pentester, assuming there are some security features you desire to test for, you can install a lesser version or custom brand of chromium, then configure the proxy on Burpsuite (e.g. localhost:8080 or 8081, if the port 8080 is used by another instance) and also, set the configuration settings, on the version browser installed, to have its request to be proxied through the configuration made on the Burpsuite proxy application. This implies that you must make a new proxy request if you are using a custom browser, to intercept the request with Burpsuite, and not rely on the information gotten before using the default Burpsuite Chrome browser, as shown in the image (Fig-1) above.
5. SEC-CH-UA-MOBILE (KNOWN AS USER AGENT MOBILE):
The SEC-CH-UA Mobile describes the information which indicates if the request made by the client (Browser), is running on a mobile device or not. Looking at the image screenshot, we have the information Sec-Ch-Ua-Mobile: ?0. In binary numbers or bitwise numbers, we know the number “1” indicates “True”, and the number “0” indicates “False”. Assuming, the request was made using a mobile browser (usually for mobile Pentesters), the value would be “1” indicating that the request was made using a mobile browser.
6. SEC-CH-UA-PLATFORM:
This header information indicates the platform which the client (browser) that is responsible for the request is running on. In this case, we are running our Burpsuite tool (which has the Burpsuite chrome browser), on a windows platform. Therefore, the reason we have Sec-Ch-Ua-Platform: “Windows.”
6.1. UPGRADE INSECURE REQUESTS:
On the server side of the target, websecurity experts are mandated to configure the webserver, to upgrade any insecure request (e.g. HTTP), made to the target. This security measure when implemented, is to prevent MITM (Man-In-The-Middle-Attack). If you are familiar with the hacking tool called “BEEF” in Kali-Linux, you could understand that a request can be downgraded, and sent as a phishing link to a legitimate user. When the legitimate user tries their credentials on the downgraded phishing link (less secure version of HTTPS i.e. to HTTP), the attacker would be able to sniff credentials e.g. logins, bank credentials, cookies and so on using Wireshark, while on the same network as the user, or through ARP or DNS Spoofing if they are not on the same network as the targeted user. The server-side configuration of HTTP request upgrade is usually done in the content security policy header using the “Strict-Transport-Security (HSTS).” With this, any form of request made to the target or endpoint would be automatically upgraded, even when the user clicks on the downgraded phishing link of the legitimate server, the request will automatically be upgraded.
Referencing back to the image (Fig-1), we could see that the “Upgrade-Insecure-Request:1” which is true. Depending on the target even when the information obtained, says true to upgrade insecure request, do not stop there as the target might not have included “HSTS”, which implies the target may still be vulnerable to downgrading HTTPS request. To detect if the target has HSTS implemented, you can manually install the web-browser plugin wapplyzer and request the domain manually. Then check the technology stack information, if the information did not indicate that the target uses HSTS in its security, it then means that the request can still be manipulated and downgraded. As an experienced pentester, you can decide on what form of attack to conduct.
7. USER-AGENT:
This contains generic information in a string-like manner which is identified by the server of the endpoint we are targeting. In the image (Fig-1), we could see generic information such as Mozilla/5.0, indicating the browser making such request is compatible with Mozilla browser versions from 5.0 upwards. Additional information includes (Windows NT 10.0; Win64; x64) AppleWebKit/573.36 (KHTML, like Gecko) Chrome 125.0.6422.112 Safari 573.36.
The information above is generic platform information, indicated by the server of the request platform origin, and its compatibility. For example, looking at the request from the image, we could notice that the request was made from chromium version 125.0.6422.112.
8. ACCEPT:
The “ACCEPT” information contained in the header indicates what type of content the target accepts based on the information understood by the client (browser). As an experienced penetration tester, when the endpoint targeted is a file upload endpoint, this would give information of the file types accepted by the target and enable you to build your payload for your reverse shell, based on that information.
9. SEC-FETCH-SITE:
The “SEC-FETCH-SITE” is an information that discloses where the request originates from. In the image, we could see that the output is “none.” This implies that the request was manually entered in the address bar. It is also the same when a bookmarked endpoint is accessed or dragging a saved webpage to the client (browser), making this request.
If the request originates from another site to the target, then the information which would be indicated in the request would be “cross-site.” These requests are known as “DIRECTIVES”. There are other forms of “DIRECTIVES” e.g. “SAME-SITE”, “SAME-ORIGIN” etc.
10. SEC-FETCH-MODE:
This contains information on how the request was made. In this case from the image (Fig-1), we have the “navigate.” Other forms of modes, which the endpoint information, can be requested includes: cors, no-cors, same-origin, WebSocket.
11. SEC-FETCH-USER:
Information contained here indicates the request was fetched by the user. This value is always “1” which indicates true, except the request is triggered by something else, then this information is omitted by the browser.
12. SEC-FETCH-DEST:
This header is about the information type requested from the target. If the request is intended to be repeated to the target, as an experienced pentester, you can modify the type, and repeat the request. There are lots of “SEC-FETCH-DEST” types e.g. audio, audioworklet, embed, frame, iframe, report, object, style etc. If the server supports such request type, or if the request dest value, is of the data type being requested, upon repeating the request, information would be relayed back to the Burpsuite tool (Response Window).
Understanding this “SEC-FETCH-DEST” is important and can be manipulated during a penetration testing. Manipulating this as well will give you insight, on paths that the target resources are being fetched from, from the response gotten from the repeater.
To read more about different types of *SEC-*Headers, visit Mozilla Developer.
13. ACCEPT LANGUAGE:
This contains information about the preferable language of the client (browser). This is served to the Burpsuite proxied request by the server using content negotiation. As an experienced hacker, you should be able to find a way to manipulate this and get a bug out of it. Additionally, you can also manipulate this, when testing an API payload.
To read more information about manipulating this, check out this Hackerone report.
14. PRIORITY:
This header information ensures that the right bytes of data are loaded at the right time, before they are presented as a page or media type to the user (in this case the response view of our Burpsuite proxy) to achieve optimum result. As an experienced hacker, when testing API endpoints, if a value number appears as shown below,
“Priority: u=0, i”
You could try altering this value “0” to “1” and repeating this request. Check the response information thrown back at you, there are possibilities that API keys and configuration files would be revealed.
15. ACCEPT ENCODING:
This information from the intercepted request indicates the media encoding type accepted by the server for that endpoint requested. When testing a particular endpoint, lookout for this information, to understand what type of media is acceptable to the server, then build your payload based on that information.
It comes handy for RCE’s (Remote-Code-Executions), especially when you discover an endpoint that accept file upload, and you are trying to build your payload (e.g. php, or java), when trying to upload the file and it keeps rejecting the file, reload the page of the error rejected file, and intercept the request via burp-proxy. This information will indicate the file type that the endpoint accepts (Server). Encoding the payload to masquerade on a file extension type acceptable by the target would successfully upload your file, if the target doesn’t implement a proper input sanitization.
To read more about Accept Encoding visit the W3 org website.
16. CONNECTION:
The “Connection: Keep-alive”, indicates how long the connection should be open. It is also important to always lookout for this information to debug a payload that throws errors. If the server is configured to timeout the connection, repeating the request using the repeater after encoding a payload might throw error in the response gotten.
This might give you a false negative of the payload. Therefore, if your payload is not working due to time-out, look at the “Connection: Keep-alive” to see if the connection is set to a particular time duration, and not “Keep-alive”.
17. 301 PERMANENTLY MOVED:
This is the “Status-Code.” Of the repeated request. When the request is repeated, checking the response status code, gives us an indication that our payload was successfully received by the target, in this case we should be getting “200-ok”, otherwise debugging the status code, gives us an insight of what next to try on the target e.g. “403” is an indication that such request is forbidden. As an experienced penetration tester, we can then modify these payloads (encoding our characters) and replay the request to see what the output will become. In addition, there are other status codes that could be gotten in a response. Get yourself familiar with these status codes, to see what other mechanisms you could try, to obtain additional information.
18. DATE:
Is an indication of the date and time the response was served by the server.
19. CONTENT TYPE:
This header contains information of the resources requested before the request was encoded and repeated. For example, in the image (Fig-1), the requested information is of HTML document type, hence our “Content-Type” header, contains the information related to “html document”.
20. LOCATION:
This header information indicates the URL, to redirect the page to. When testing for CSRF, looking at this information, sure does help. As an experienced pentester, when you repeat a request, and check the “Response”, whatever information disclosed here, would give you an insight if your attack was successful or not. For example, using a CSRF token, with valid credentials, when repeated, check the response, and lookout for what page was redirected back to you.
Additional information that also assists you in uncovering the “Location” redirect page, is the status code. Status code such as 3xx, are very important. 301,302,303,307, & 308.
21. SERVER:
The server header contains information about the content origin server software or type. This response is very crucial to be read, as security misconfiguration by the web expert could reveal sensitive information, that could further be used to probe and exploit the target. Example of server information includes Nginx 1.xx, apache2.xx, awselb/2.0 these are common information that could give the hacker insight of vulnerabilities with POC’s (Prove of Concept), to search in other to exploit the webserver.
Furthermore, this is also not limited to just the webserver information, as you can see from the image (Fig-1) above, the webserver is proxied through a public server provided by a CDN (Content Delivery Network) Service, known as Cloudflare. If the web security expert doesn’t implement a good code sanitization on the webserver, non-ethical hackers could find possible ways to bypass the CDN and exploit vulnerabilities (e.g. SQL, CSRF, XSS etc.), pertinent to the endpoint they are exploiting. This method of Bypassing the CDN is known as WAF (Web Application Firewall) Bypass.
These various concepts explained, is part of the foundational or introductory knowledge a Red-Teamer, Offensive Security Expert, Bug Bounty Hunter, and Penetration Tester, should know, in order to understand strategies on how to manipulate requests pertinent to the endpoint they are trying to Hack.
Put your comments below in the comment section on your thoughts about this.
