Preventing tampering with hidden inputs

Unlike visible inputs, hidden field rules are for hidden parameters only, from <input type="hidden"> HTML tags. For information on constraining visible inputs, see Validating parameters (“input rules”).

Hidden form inputs are often written into an HTML page by the web server when it serves that page to the client, and are not visible on the rendered web page. Because HTTP is essentially stateless, like cookies, hidden form inputs are one way that web applications can use to remember session data from one page request to the next (called “persistence”).

For example, to remember the price of a TV accessed from a secret sale URL previously requested that session, this form remembers the sale price, and will provide it again to the shopping cart application when the client submits the payment page:

$900 x Quantity: <input name="quantity" size=4><br/>

</br>

</form>

Since they are not rendered visible, hidden inputs are sometimes erroneously perceived as safe. But similar to session cookies, hidden form inputs store the software’s state information client-side, instead of server-side. This makes it vulnerable.

Hidden fields are accessible through the JavaScript document object model (DOM). Additionally, forms often use the HTTP POST method and send input to a URL (such as /checkPayment.do) that legitimate clients never see, since the server replies with an HTTP 302 status code and the next URL in the Location: header, which the client then fetches using the GET method and displays. Unless there is code to prevent it, however, attackers often can easily send altered hidden inputs to this POST URL simply by altering a local copy of the page, using a browser plug-in tool such as Tamper Data, or in some cases simply typing different URL parameters into the browser’s location bar.

Like any other input from clients, it can be tampered with and should not be trusted. Tampered hidden inputs can be used as a vector for state-based attacks.

To follow the above example, an attacker could alter the sale price so that he or she can buy the item much more cheaply:

$900 x Quantity: <input name="quantity" size=4><br/>

</br>

</form>

When this form is submitted, the attacker orders TVs at a price reduced from $900 to $1. The request looks like this:

POST /processPayment.do HTTP/1.1

Host: www.example.com

Referer: HTTP://www.example.com/checkout.do

Cookie: JSESSIONID=12345667890

Content-Type: application/x-www-form-urlencoded

POSTDATA quantity=9999&price=1

Unless the web application is smart enough to test for unauthorized prices, /processPayment.do accepts the request, processes the order, and returns a normal reply like this:

HTTP/1.1 302 Moved

Set-Cookie: JSESSIONID=12345667890;HttpOnly

Location: HTTP://www.example.com/thankYou.do

Content-Length: 0

Connection: close

Content-Type: text/plain; charset=UTF-8

The client then loads the final “thank you” shopping cart page indicated in the reply’s Location: header.

Hidden field rules prevent tampering by caching the values of a session’s hidden inputs as they pass from the server to the client, and verifying that they remain unchanged when the client submits the form to its POST URL.

To configure a hidden field rule

Before you configure a hidden field rule, if you want to apply it only to HTTP/HTTPS requests for a specific real or virtual host, you must first define the web host in a protected host names group. For details, see Defining your protected/allowed HTTP “Host:” header names.
Go to Web Protection > Input Validation > Hidden Fields and select the Hidden Fields Rule tab.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
Click Create New.
Configure these settings:

Name	Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
Host Status	Enable if you want the hidden field rule to apply only to HTTP/HTTPS requests for a specific web host. Also configure Host.
Host	Select the name of a protected host that the `Host:` field of an HTTP request must be in to match the hidden field rule. This option is available only if Host Status is enabled.
Request URL	Type the exact URL that contains the hidden input for which you want to create a hidden field rule. This is usually a form that is visible to the person’s web browser, not the CGI script or page that processes submitted forms. The URL must begin with a slash ( / ). Do not include the web host name, such as `www.example.com`. It is configured separately in the Host drop-down list.
Action	Select which action the FortiWeb appliance will take when it detects a violation of the rule: Alert—Accept the connection and generate an alert email and/or log message. Alert & Deny—Block the request (reset the connection) and generate an alert and/or log message. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Deny (no log)—Block the request (or reset the connection). Period Block—Block subsequent requests from the client for a number of seconds. Also configure Block Period. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP. Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type. For details, see Defining your proxies, clients, & X-headers. Redirect—Redirect the request to the URL that you specify in the protection profile and generate an alert and/or log message. Also configure Redirect URL and Redirect URL With Reason. Send 403 Forbidden—Reply with an HTTP `403 Access Forbidden` error message and generate an alert and/or log message. The default value is Alert. Note: This setting will be ignored if Monitor Mode is enabled. Note: Logging and/or alert email will occur only if enabled and configured. For details, see Logging and Alert email. Note: Because the new active appliance does not know previous session history, after an HA failover, for existing sessions, FortiWeb will not be able to apply this feature. For details, see Sessions & FortiWeb HA.
Block Period	Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule. This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 (1 hour). The default value is 1. See also Monitoring currently blocked IPs.
Severity	When rule violations are recorded in the attack log, each log message contains a Severity Level (`severity_level`) field. Select which severity level the FortiWeb appliance will use when it logs a violation of the rule: Informative Low Medium High The default value is High.
Trigger Policy	Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Viewing log messages.

Click OK.
Click Fetch URL.
In the Pserver drop-down list, select the IP address of a physical server.
In Port, type the TCP port number on which the physical server listens for HTTP/HTTPS connections. The valid range is from 0 to 65,535. Typically HTTP is port 80; HTTPS is port 443.
In Protocol, select whether to connect to the back-end web server using either HTTP or HTTPS.
Click the OK button on the dialog.
FortiWeb retrieves the web page you specified in Request URL on the Hidden Fields Rule dialog, and analyzes it. A new dialog appears displaying a list of hidden inputs that FortiWeb found, and URLs where those hidden inputs will be posted when a client submits the form.
Entries in the list are color-coded by the recommended course of action:
- Blue—The URL/hidden field exists in the requested URL, but you have not yet configured it in the hidden field rule. Add it to the hidden field rule.
- Red—The URL/hidden field does not exist in the requested URL, yet it is currently configured in the hidden field rule. Remove it from the hidden field rule.
- Black—The URL/hidden field exists in both the requested URL and your hidden field rule.
For each entry that you want included in the hidden field rule, in the Status column, mark its check box.
Also mark the check boxes of any previously configured items that you want to keep in the hidden field rule. If you do not, they will be deleted.
Click OK to save the entries in the dialog.

FortiWeb adds the entries to the Post URL Table and Hidden Fields Table on the Hidden Fields Rule dialog. It also removes any that did not match the fetched URL.

To manually add entries to either table, do the following:

Click Create New under the applicable table.
A dialog appears prompting for either a new URL or hidden field.
Enter the name of the post URL or hidden field.

Click OK.

Repeat the previous steps for each post URL or hidden field that you want to manually add to the hidden field rule.

On the Hidden Fields Rule dialog, click OK.

Go to Web Protection > Input Validation > Hidden Fields and select the Hidden Fields Policy tab.

Click Create New.

In Name, type a unique name that can be referenced by other parts of the configuration. The maximum length is 63 characters.

Click OK.

Click Create New to include a rule in the set.

From the Hidden Fields Rule drop-down list, select the name of an existing hidden field rule that you want to add to the set.

Click OK.

Repeat the previous steps for each individual rule that you want to add to the hidden fields policy.

To apply a hidden field policy:

Select it in an inline protection profile. For details, see Configuring a protection profile for inline topologies.
Enable Configuring a protection profile for inline topologies.