We can type our own requests by using telnet to access port 80. So, botheration of generating or modifying forms for every type of attack is overcome by this method as it might just use raw HTTP for alteration of form data. Because of this, we can say that this method has a higher degree of complexity than others.

Forging HTTP requests is a more advanced form of automating attacks.

In the following example, we are requesting to log in to the example forum:

  POST /index.php?act=Login&CODE=01&CookieDate=1 HTTP/1.1
  Host: forums.example.com
  Connection: close
  Referrer: http://forums.example.com/
  Cookie: session_id=7819
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 44

  UserName=myname&PassWord=mypass&CookieDate=1

To use the preceding mentioned requests, you will need to change a few items, which are:

Let us assume that the following HTML form is located at http://sampledomain.com/form.php:

<form action="/example.php" method="post">
  <select name="browser">
  <option value="chrome">Chrome</option>
  <option value="firefox">Firefox</option>
  </select>
  <input type="submit">
</form>

We assume that we will be able to refer to $_POST['browser'] and it will have a value of either of the two options chrome or firefox. Now, if the user selects chrome, the request will look something similar to the following:

  POST /example.php HTTP/1.1
  Host: sampledomain.com
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 8

  browser=chrome

A user can save the form from the browser to the local machine (desktop or laptop) then open the saved HTML file and make the following changes to it:

Now our form will look similar to the following code:

<form action=http://sampledomain.com/example.php method="post">
  <textarea name="myvar"></textarea>
  <input type="submit">
</form>

The user can now submit any value of $_POST['myvar'] with these simple changes to the form. Moreover, there is no way to prevent the user who manipulated our form from submitting unexpected form variables or anything that can be achieved with an HTML form.

There are solutions available to prevent forms from spoofing. It is from a strict protocol perspective; the only thing we know is that HTTP requests and responses are going back and forth. There is no clear and concise way to determine that a form submission has not been spoofed.

Using the following two ways, we can prevent forms from spoofing as they reduce the possibility of unwanted values that are submitted by following a general architecture for handling data and forms:

Shared secrets are also referred to as one-time tokens or hashes. We create a secret that is only known by the server and the user. In this, the implementations vary widely but they share the characteristics of being transparent to the users and are difficult to exploit.

One of the implementation methods is that in the user's session, we will store the secret as shown in the following code:

  $secret = md5(uniqid(rand(), true));
  $_SESSION['secret'] = $secret;

Now, it can be used as a hidden form variable in the form like:

  <input type="hidden" name="secret" value="<? echo $secret; ?>" />

Every time we display the form, we would regenerate this secret so that the user always has a current and correct secret value. This helps in preventing CSRF (Cross-Site Request Forgery).

The page which will open can check this by comparing the secret sent by the form with the secret that was stored in the corresponding session variable.

Taking this further, we can even enhance the security of this method by restricting the timeout window rather than relying on the session timeout, which can be too large for your needs.

An application with a best architecture always assumes that: