POST

Whenever applications need to transfer files or move URL parameters, they use the POST method.

Unlike GET, which inserts user parameters in the URL, the POST method inserts parameters in the body of the HTTP request.

This has three major advantages:

→ No login required: Since POST requests can transfer larger files (file uploads), it would be inefficient for the server to log all uploaded files as part of the URL, as would happen in a GET request for an uploaded file.

→ Less need for encoding: URLs are designed to be shared, which means they need to match characters that can be converted to letters.

The POST request inserts data in the body that can accept binary data. The only characters that need to be encoded are those used to separate parameters.

→ More data can be sent: The maximum size of a URL varies depending on the browser (Chrome/Firefox/IE), web servers like IIS, Apache, NGINX, CDN (Cloudflare, Cloudfront, Fastly), and URL shorteners like bit.ly and amzn. to

Usually, the size of a URL should remain below 2,000 characters, so there is no need to deal with so much data.

Now…let’s see some examples of how POST requests work and how we can use tools like cURL or dev tools to read and send POST requests.

The activity at the end of this page is similar to the example about GET. However, when we visit the site, we can see that it uses a PHP login instead of basic HTTP authentication.

If we try to log in with admin: admin, we can access a search page similar to what we saw in the GET topic.

If we clear the Network tab in dev tools and try to log in again, we will see several requests being sent.

We can filter the requests by our server’s IP, so we will only see the requests going to the web application server (we filter out external requests).

With this, we can see the following request being sent:

We can click on the request, click on the Request tab, and click on raw to see the raw data of the request.

This way we can see that the following data is being sent by POST:

With the request data in hand, we can try to send a similar request with cURL and see if it allows us to access the page (get the login).

Here we could right-click on the request and select Copy → Copy as cURL — but we must know how to manually construct a request. So let’s try to do that!

We will use the flag -X POST to send the POST request. Then, to add the POST data we use -d and put the data right after, like this:

Looking at the HTML code returned in gray, we won’t see any login form, only the search function, which indicates that we were able to log in successfully. 🥳

Tip:

Many login forms may redirect us to a different page upon authentication (e.g., /dashboard.php). So if we want to follow this redirection with cURL, we use the -L flag.

When we are authenticated, we should receive a cookie so that our browser remains logged in and the user doesn’t have to log in every time they visit the page.

We can use the -v or -i flag to see the response, which should contain a Set-Cookie header with our cookie. 🍪

With the cookie, we can interact with the web application without having to provide credentials all the time.

Let’s test this by using the cookie with the -b flag.

As we can verify, we have been authenticated! Additionally, we can also specify the cookie as a header.

We can try the same thing in the browser.

→ First, let’s log out and return to the login page.

→ Now, let’s go to the Storage tab in our dev tools (SHIFT + F9). We click on Cookies the left panel and select our site to view the current cookie.

Sometimes we may have a cookie or not, but if we are logged out, our PHP cookie should not be authenticated, and that’s why we receive the login page and not the search page (it means we haven’t logged in and authenticated yet and our browser hasn’t saved that information).

See:

Now, let’s try to use our authentication cookie and see if we can enter without using passwords.

For that, we can replace the value of the cookie with ours. We can right-click on the cookie, select it Delete All, and click on the + icon to add a new cookie.

After that, we insert the cookie name, which is the part after the = (PHPSESSID) and the cookie value, which is the = (c1nsa6op7vtk7kdis7bcnbadf1).

Then, after everything is set, we can reload the page and see that we can authenticate without logging in.

As we can see, having a valid cookie is enough to authenticate ourselves in most web applications, which can be essential in some types of attacks, such as XSS.

Let’s see which requests are sent when we interact with the city search function.

We go to the Network tab and click on the trash icon to clear all requests. Now, we can perform any search to see which requests are sent.

As we can see, the form sends a POST request to search.php with the following data:

The data format appears to be JSON, so our request must have specified the Content-Type header as application/json.

We can confirm this by right-clicking on the request and selecting Copy>Copy Request Headers:

We do indeed have Content-Type: application/json.

Let’s try to replicate the request as we did earlier, but include both the cookie and content-type headers, and send the request to search.php:

As we can see, we were able to interact with the search function directly without logging in or interacting with the application front-end.

This can be an important skill when conducting web hacking assessments or bug bounties, as it is much faster to test applications in this way.

Now let’s try to repeat the same request using Fetch.

We right-click on the request and select Copy>Copy as Fetch, go to the Console tab, and execute the code there.

Our request returned the same data obtained with cURL.