Skip to main content

Improper Input Validation

Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from triggering the malfunction of various downstream components.

Overview

Input validation should happen as early as possible in the data flow, preferably as soon as the data is received from the external party. Data from all potentially untrusted sources should be subject to input validation, including not only Internet-facing web clients but also backend feeds over extranets, from suppliers, partners, vendors or regulators, each of which may be compromised on their own and start sending malformed data. Input Validation should not be used as the primary method of preventing XSS, SQL Injection and other attacks but can significantly contribute to reducing their impact if implemented properly.

Rule Options

The rule options for Input Validation can be broken up into 3 general types:

  1. Request URL - .Net only - Input validation will be based on the contents of the request URLs
  2. Cookies, Parameters, and Headers - Input validation will be based on the contents of cookies, headers, or parameters
  3. Method - Input validation will be based on the selected method types

Basic Options: All types​

The following fields are common among all option types:

HTTP Endpoint (Relative URI)​

Here you can enter in a list of relative URIs to be protected, monitored, or whitelisted.  A relative URI only includes the path portion of the URL, and not the domain.  For example if the website address was http://www.victim.com/home/test.html, then /home/test.html is the relative URI or HTTP Endpoint.

The path within the relative URI must be absolute and begin with a leading /. In the above example /home/test.html is valid, and home/text.html is not. In addition relative paths may not contain .. or other similar characters denoting path shortcuts. For example, /home/test/user/test.html is valid, but ../test/user/test.html is not.

Enter in a value in the field, and upon clicking the Add button, entering in a comma, or hitting enter, the value will be stored and shown as a chip below the input field.  Copying and pasting of lists separated by commas or carriage returns are supported.

Validation Subject: Request URL​

URLs containing​

This is a basic black list.  You must enter a character sequence to be matched within the URL of the request.  If the request URL has a character sequence matching the one in the rule, then the request is dropped.

Enter in a value in the field, and upon clicking the Add button, entering in a comma, or hitting enter, the value will be stored and shown as a chip below the input field.  Copying and pasting of lists separated by commas or carriage returns are supported.

Validation Subject: Cookies/Headers/Parameters/Method​

Parameter/Cookie/Header Validation Type​

  • Cookies - The subject(s) of the validation are cookies.
  • Headers - The subject(s) of the validation are the headers.
  • Parameters - The subject(s) of the validation are the configured parameters.

The options (below) are exactly the same for all 3 subject types

Cookie/Header/Parameter Value Type​

The Value Type tells us the input constraints that you wish to place on the named [Cookies/Headers/Parameters].  This is the criteria that validation will be matching on.  More than one Value Type may be selected.

Note that value types and value names maintain a many-to-many relationship.  In other words, if both Value Types of alphanumeric and HTML text are chosen here, and the Value Names Name1 and Name2 are defined, then both Name1 and Name2 will be validated as both alphanumeric and HTML text.  All Validation Types are applied to all Names , and vice-versa.

  • Alphanumeric - constrain input to letters and numbers
  • Integer - constrain input to whole numbers only
  • Integer Positive - constrain input to whole positive value numbers only
  • Integer Unsigned - constrain input to whole numbers whose value will be considered positive even if they are negative
  • SQL No Single Quotes - constrain input such that no single-quote characters are allowed to be used in SQL
  • SQL No Double Quotes - constrain input such that no double-quote characters are allowed to be used in SQL
  • HTML No Single Quotes - constrain input such that no single-quote characters are allowed to be used in HTML
  • HTML No Double Quotes - constrain input such that no double-quote characters are allowed to be used in HTML
  • HTML Text - constrain input such that HTML content that is not text, i.e., opening of tags < is not allowed
  • HTML Attribute Unquoted - constrain input such that only HTML attributes values that are unquoted are allowed
  • RegEx - use Regular Expressions as validation criteria for matching either instead of, or in addition to, the Value Types above

Cookie/Header/Parameter Names​

Enter in a value in the field, and upon clicking the Add button, entering in a comma, or hitting enter, the value will be stored and shown as a chip below the input field.  Copying and pasting of lists separated by commas or carriage returns are supported.

Example: If you wish to ensure that the username field in a web login screen served up by a Waratek-protected application is comprised of only letters and numbers, and not special characters or escape characters like one might use in a SQL injection type attack the rule would be set up like so:

Validation Subject: Parameters Parameter Name: username Parameter Value Type: alphanumeric Action: Protect

This will drop the username input of any form where the parameter username is a non-alphanumeric character.

Validation Subject: Method​

Method Types​

These method types select the methods upon which validation will occur. Available options are:

  • GET
  • POST
  • HEAD
  • PUT
  • DELETE
  • CONNECT
  • OPTIONS
  • TRACE
  • PATCH

Action​

  • Detect - The Agent will detect the matching of the entered URLs Containing field and log the event. The event will be viewable on the Security Events pages, but the Agent will take no further action.
  • Protect - In addition to Detect, the Waratek Agent will drop the incoming request.
  • Allow - The Allow action will supersede the Protect action by whitelisting the Request URLs to be excluded from Protect actions and allowing them to be accepted.

The Allow action is only available for the Method validation type for Rules that are ARMR 2.4 and above

Log Messaging​

The logs provide a message field, which can be customized.  Text entered here is the message that will be seen on the log file’s when the rule has been triggered, regardless or the Action.  If the field is left blank, then the default logging message will be displayed in the message portion of the event log.

Severity​

The log files allow you to select a custom severity level for the event: Low, Medium, High or Critical.  A severity is required, and there is no default selection.

Advanced Options​

Disable Logging - By checking this option, no logging will be performed when a rule is triggered. Subsequently the Portal will not see these events, and they will not appear anywhere in the Portal, nor will they be searchable in Event Storage.

This option will be greyed out if the rule action is set to Detect.

Enable Stack Trace - By checking this option, when a rule is triggered, the stack trace will be included in the event log, and will be available for viewing in the Portal UI for each triggering security event.