Many of us have lived with this assumption, and many still do, that we have no control over the requests that our browser make behind the veil. However, we have full control over the contents of the requests that our browser makes. We can intercept these requests, tweak them, and forward them to the server. The server then will return the response of the newly created request and send it back to the browser. The browser tries to make sense of the returned response and render it to you.
Capturing your HTTP requests isn’t a hack in itself but this is where you find most of the vulnerabilities. To give you an example, consider capturing a request of a shopping web page where a developer decides price logic by embedding value in the HTML source. If there is no server-side validation, then you can change the price parameter to a 0 value and buy a $x item free. Life isn’t as easy always, but things like this still exist and to be able to understand the program properly, looking at these requests and observing the different outcomes of changed parameters and values is a must.
Tweaking with HTTP requests?
There are dozens of ways to intercept and play with the HTTP requests and dozens of tools that will help you with that; Burp Suite is one among them.
BurpSuite comes pre-installed on Linux. If you are a Windows user, you can download it from here. Make sure you have a compatible JDK running to be able to run JAR files.
You can also use Inspect Element Feature on browsers to see all these requests passing by to the server while you surf the Internet. (In Chrome, it is CTRL+SHIFT+I)
How does a HTTP request look like?
HTTP request consist of headers and body. Any HTTP request always includes headers and can have body (depending if the request method is POST).
A general HTTP request will look like this:
GET /endpoint-of-a-url HTTP/1.1 Host: huntingreads.com Cookies: _Session=user; User-Agent: Your Browser Origin: https://domain-from-where-request-was-generated Referer: https://link-of-previous-site
Since, you are reading this article, you as well made a GET request which would have looked like this:
GET /working-with-http-requests HTTP/1.1 Host: huntingreads.com Cookies: something=something; User-Agent: Your Browser
The verb type, the endpoint mentioned with it and the HTTP protocol (first line) and the Host value (second line) are the important parts of a request. The host is the name of a domain.
The response of any valid HTTP request will also include headers and body but these headers are going to be little different from the request headers. They could look like this:
HTTP/1.1 200 OK Date: Mon, 1 Feb 2021 12:28:13 GMT Server: running-on-server-abc Content-Length: Length-of-the-content-in-response (it's interger) Content-Type: text/html Connection: Closed
The response can also have body which usually include the raw code (HTML and JS) like:
<html> <body> <h1>Hunting Reads</h1> </body> </html>
When this raw code is passed back to the browser, your browser renders it to you and thus you see what’s in front of your face.
The “HTTP/1.1 200 OK” in the response means that the content was returned properly without any errors. Other than 200 OK, a header can also contain different values like 404 (means content which you requested was not found) or 400 (indicates Bad Request/Invalid Request) etc.
Feel free to ask below!