In addition to URL Encryption, it is possible to sign, and therefore protect, all form information of an application. To activate Form Protection within Airlock, it is necessary to activate URL Encryption (PBE or session-based) first.
This feature activates the innovative (patent pending) Smart Form Protection technology which dynamically protects HTML forms. With this feature enabled, Airlock will only accept user input parameters matching the meta constraints contained in the original HTML form. Using this technology greatly improves the protection against forceful browsing attacks. A user can only send those form parameters back to the server which were originally requested by the server. An attacker can not add other parameters to manipulate the back-end application.
In addition to the Form Protection settings mentioned above, this option also protects form parameter values where applicable. With this option enabled, an attacker can no longer modify hidden fields, send illegal option values or send oversized input. Only parameter values that were offered by the application server will be accepted. Also, meta constraints given by the HTML form source code, such as the maxlength attribute for input fields, are enforced.
Airlock's URL Encryption & Form Protection technology provides complete protection from forceful browsing attacks.Example:
If an application provides an HTML form where a user can enter the amount and select the currency to create an electronic payment, he will not be able to send any other parameters or send a currency that is not in the offered option list. All constraints are strictly enforced by Airlock. The back-end application will only get requests and user input data which it actually requested, and which it can safely deal with.
If form fields are changed or added by client-side JavaScript, the form submission will be blocked because Airlock suspects malicious intention. To enable such client-side changes, define one or more name patterns matching the form fields.
A form field matching one of these patterns will then no longer be protected. For an example, see the following screenshot:
Since the exeption pattern is a normal regular expression, it is also possible to use logical operators like "|" (for OR) .
Example:
^(exception_field1|exception_field2)$
^(exception_field[12]{1}|exception3|onemore_exception)$