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:
<form method="POST" action="processPayment.do">
<input type="hidden" name="price" value="900">
$900 x Quantity: <input name="quantity" size=4><br/>
</br>
<input type="submit" value="Buy">
</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:
<form method="POST" action="processPayment.do">
<input type="hidden" name="price" value="1">
$900 x Quantity: <input name="quantity" size=4><br/>
</br>
<input type="submit" value="Buy">
</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:
-
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 Forbiddenerror message and generate an alert and/or log message. - Informative
- Low
- Medium
- High
- 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.
- Enable Server Verification to verify the TLS certificates used for the HTTPS connection between FortiWeb and the back-end server. Available only if HTTPS is selected for Protocol.
- Select the certificate for the HTTPS connection between FortiWeb and the back-end server. It should be uploaded in the CA tab in Server Objects > Certificates > CA.
- 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 post 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 post 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 post 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.
- To manually add entries to either table, do the following:
| 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 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 |
| Action |
Select which action the FortiWeb appliance will take when it detects a violation of the rule: 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 Blocked IPs. |
| Severity |
When rule violations are recorded in the attack log, each log message contains a Severity Level ( 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. |
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.
- 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.
- 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.