The Policy define a list of allowed requests and parameters to a given web system to which access is filtered by Web Security Manager.
The policy is defined by a collection of proxy global policies and application specific policies. This mix provides the ability to specify short yet fine grained access control policies:
- Global policy
-
These are general rules which specify criteria for allowing requests on a proxy global basis. Rules are specified by extension and by specifying a grammar (using regular expressions) for valid URLs and parameters.
Global patterns include Static content policies, Global URL policies and Global parameters policies.
- Web applications
-
In access policy terms a web application is defined as an URL path which takes one or more parameters as input.
The web application policy list consists of one or more URL paths each with a specific policy, a web application policy entry.
The web application policy entry is defined by its URL path and valid input for one or more of the URLs parameters are defined using either a list of allowed values, grammar (a regular expression) or a class which is a predefined regular expression.
Web application policy entries always take precedence over global rules. It is perfectly possible though to utilize a mix of global and specific rules - even for a single application.
Incoming requests are validated in the following order:
-
Static content policy
If the extension and path of the requested filename matches the policy defined in Static content policy and the request has no parameters, the request is allowed.
-
Global URL path policy
If the request has no parameters and one of the global URL policy patterns matches it it is allowed unless the URI matches one of the
Denied pathspolicy rules in which case the request is denied. -
Web applications policy
If the request (including possible parameters) matches an entry in the detailed web application policy it is allowed.
-
Web applications policy + global parameters policy:
If a request matches an entry in the web applications policy but one or more parameters are offending, these parameters are checked against the global parameters policy.
If there is a combined match the request is allowed.
-
Global URL policy + global parameters policy:
If a requested URL with parameters matches a global URL policy pattern and all supplied parameters match global parameter patterns the request is allowed.
-
No match:
The request is denied.
Operating modes are sets of configurations defining what violations to block and what violations to just log. Two configurable and one non-configurable presets are available.
- Protect
-
The Protect mode preset by default blocks and logs all violations according to the access policy.
- Detect
-
In the default Detect mode preset only logging occurs and no blocking protection is activated. Blocking protection that would occur in Protect is logged and available for review in the deny log. Operating in the default Detect preset is comparable to an intrusion detection system - it detects and logs activities but does not protect or prevent policy violations.'
- Pass
-
In Pass mode all requests are passed through the website proxy. No requests are blocked and no logging is performed. As no filters are active in Pass mode this mode is not configurable.
For each violation Web Security Manager can be configured to either block and log or just log.
| Path unknown | No policy rules allow the path segment of the URL, either because it does not match a positive policy rule or because it matches a negative policy rule - a signature. |
| Path denied | The path is explicitly denied by an URL blocking policy rule. |
| Query unknown | No positive policy rules match the name of the request parameter. |
| Query illegal | No policy rules allow the value of the request parameter, either because it does not match a positive policy rule or because it matches a negative policy rule - a signature. |
| Session validation failed | The request session ID is not valid, either because the session token has been tampered with or hijacked. |
| Form validation failed | The form submitted cannot be verified as having been issued by the web application in a response to a request from the current user session. This is an indication of a CSRF attack. |
| Session expired | The request session has exceeded the idle expiration threshold configured in Web Security Manager for the web application. |
| Malformed XML | Submitted XML request is malformed and hence cannot be parsed and validated. |
| Multiple or %u encoded request | The request contains elements that are encoded more than twice or it contains elements that are encoded using %u-encoding. |
| Authorization failed | User is not authorized to access requested resource. |
| Header unknown | Request header not RFC 2616 compliant. |
| Header illegal | Header value failed strict validation. |
| Header validation failed | Header value failed pragmatic validation. |
| Output illegal | Server response contains illegal string. |
| Generic protocol violation | Protocol violations like missing content length or content type headers for POST requests. |
| HTTP Protocol version | HTTP protocol version not allowed. |
| Method illegal | HTTP method not allowed. |
| Missing hostname | Request does not specify host name. |
| Invalid hostname | Not website proxy is configured for the requested host name. |
| Request line maximum length | Entire request line (URI?query) exceeds allowed maximum length. |
| Request path maximum length | Request path exceeds allowed maximum length. |
| Query string maximum length | Request query exceeds allowed maximum length. |
| Content type not enabled | Request content type is supported but not enabled. |
| Header name length | Header name exceeds allowed maximum length. |
| Header value length | Header value exceeds allowed maximum length. |
| Maximum number of headers | Header number exceeds allowed maximum. |
| Upload attempt | Upload attempted but upload not allowed. |
| Payload length exceeded | POST payload exceeds allowed maximum size. |
| Maximum number of upload files | Number of files to upload in a request exceeds allowed maximum. |
| Total upload size | Total size of upload files in request exceeds allowed maximum. |
| Maximum file size | Size of a single upload file exceeds allowed maximum. |
| Cookie version not allowed | Request cookie version not allowed. |
| Maximum number of cookies | Number of cookies in request exceeds allowed maximum. |
| Cookie name length | Name of a cookie exceeds allowed maximum length. |
| Cookie value length | Value of a cookie exceeds allowed maximum length. |
| Maximum number of GET parameters | GET parameter number exceeds allowed maximum. |
| GET parameter name length | GET parameter name exceeds allowed maximum length. |
| GET parameter value length | GET parameter value exceeds allowed maximum length. |
| GET parameter combined length | Combined length of GET parameter name and value exceeds allowed maximum length. |
| Maximum number of POST parameters | POST parameter number exceeds allowed maximum. |
| POST parameter name length | POST parameter name exceeds allowed maximum length. |
| POST parameter value length | POST parameter value exceeds allowed maximum length. |
| POST parameter combined length | Combined length of POST parameter name and value exceeds allowed maximum length. |
| General request violation | Other generic violations. |
In order for Web Security Manager to parse requests as close to the way the target application/web server technology does it is important to configure web application behaviour.
According to the official RFC, query part of a URL is delimited by ? and parameter part by &. Some web applications don't honor this and use different delimiters. Possible delimiters are: ";?:@&+$,". Several delimiters are separated by a space.
Re-use of delimiter characters across the three delimiter categories is not allowed.
| Query delimiter(s)
Input field |
Characters used for delimiting query part of the URL.
|
| Parameter delimiter(s)
Input field |
Characters used for delimiting parameters in the URL.
|
| URL session id delimiter(s)
Input field |
Characters used for delimiting URL based session identfiiers from the rest of the query.
|
![[Note]](images/note.png) |
Note |
|---|---|
|
Don't change these delimiters unless you are absolutely certain that you know the consequences. |
When output rewriting or CSRF protection is enabled it is necessary for Web Security Manager to know the character set for the pages served by the web application/server in order to rewrite pages correctly. Web Security Manager will try to read the character set in use from the Content-Type header in the web server response. However, if the header does not specify a character set Web Security Manager will default to the configured charset.
| Response charset default Input field |
Default character set used for encoding served pages if none specified by backend server.
|
These options are all related to parsing and validation of POST requests.
| Guess Content-Type
Check box |
Inspect payload of POST requests to guess content type if Content-Type header not present. Default: |
| Validate multipart/form-data request format
Check box |
When parsing multipart form data require that the payload is formatted correctly. If enabled requests that does not validate correctly will be denied. Default: |
| Block on multipart/form-data request parsing errors
Check box |
When parsing multipart form data block on recoverable request parsing errors like missing data caused by content-length being too small. If enabled requests that that does not parse correctly are blocked. It is highly recommended that this setting is enabled as disabling it introduces the risk of attacks bypassing the WAF filter. Default: |
Some web systems match requests case sensitive and some do not. When web systems are not case sensitive it is not uncommon that samples of requests are presented in different case combinations.
To avoid requests to resources with different case being learned as different requests, case sensitivity can be disabled.
| Enable case sensitivity
Check box |
Enable / disable case sensitivity matching. Some web systems match requests case sensitive and some do not. When web systems are not case sensitive it is not uncommon that samples of requests are presented in different case combinations. If enabled, Web Security Manager will match case sensitive. Default: |
Web Security Manager allows for re-writing arbitrary request header values using regular expressions for matching the value to re-write.
| Enable header re-writing |
Check or uncheck the checkbox Enable request header re-writing to enable this feature. |
| Rewriting rules |
In the input area enter one or more rules for header re-writiting.
|
For each attack class in the list define the criticality level.
| Attack class
Drop down lists (SQL injection, XPath injection, SSI injection, OS commanding, XSS, Path traversal, Enumeration, Format string, Buffer overflow, DoS attempt, Worm probe, etc.) |
Select a criticality level for the attack class.
|
Source IP tracking and blocking adds IP sources exceeding a certain risk level to summary database. This allows for tracking attacker activity across the websites configured in Web Security Manager. The Dashboard Deny Log Interactive List and the global Attack Source Auto Blocking are both based on the information collected when this feature is enabled.
| Enable IP source tracking
Check box |
Enable / disable IP source tracking. Default: |
| Risk level
Drop down list |
Sets the risk level above which the source IP is tracked and added to the global database.
|
When a request is denied at the application level, instead of just stopping the request the source IP can be blacklisted forcing the attacker to change IP address or to find another target.
| Enable IP source immediate blocking
Check box |
Enable / disable IP source immediate blocking. Default: |
| Risk level
Drop down list |
Sets the risk level above which the source IP is immediately blocked. When the IP is blocked the attacker will not be able to access the website from that source IP for a duration configured in Attack source auto blocking.
|
Enable sending of alerts to syslog server. Only alerts with priority above or equal to the configured threshold are sent.
Alerts are sent to Local3 facility.
To have attack alerts sent to an external syslog server configure threshold level and server address in System-> Section 2.3, “Syslog - logging to external host”.
| Enable alerts to syslog
Check box + Drop down list |
Enable or disable sending of alerts to syslog server. When enabled the drop down menu Syslog criticality threshold specifies the lowest informational level (priority) for which alerts will be sent to the syslog server.
|
Enable sending of alerts by email. Only alerts with priority above or equal to the configured threshold are sent.
| Enable email alerts
Check box + Drop down list |
Enable or disable sending of email alerts. When enabled the drop down menu Instant email criticality threshold specifies the lowest informational level (priority) for which alerts will be sent.
The email address is the contact email specified in Section 2.6, “Admin contact”. |
For each criticality level set the corresponding log priority (informational level).
| Criticality level
Drop down lists (Critical, High, Medium, Low, None) |
Select a log priority level for each criticality level.
|
Enable/disabled support for logging of blocked requests.
When a request fails the defined access policy for a given proxy, Web Security Manager will block the request.
| Enable logging for normal/filtered requests
Check box |
Enable / disable logging for normal/filtered requests. If enabled, Web Security Manager will log blocked requests for normal/filtered end-user traffic. Default: |
| Enable logging for pass-through requests (IP whitelisted)
Check box |
Enable / disable logging for pass-through requests (Pass through mode) If enabled, Web Security Manager will log blocked requests from client matching the pass-through white-list. Default: |
| Do not log bypassed requests from trusted clients
Check box |
Disable logging of bypassed requests (that would have been blocked) from trusted clients. If checked, Web Security Manager will not log requests that are violating the policy but are bypassed because because the source IP is in the trusted clients list of the website proxy and HTTP blocking bypass is enabled for trusted clients. Default: |
| Do not log blocked requests from trusted clients
Check box |
Disable logging of blocked requests from trusted clients. If checked, Web Security Manager will not log requests that get blocked if the source IP is in the trusted clients list of the website proxy. It is not recommended to disable logging of blocked requests unless there is a good reason for it. If for example some kind of monitoring software is used to regularly verify that specific requests are being blocked it could be desirable not to have these requests logged in order to prevent the log from being filled with these (known) requests. Default: |
Enable/disable logging of broken requests.
Broken requests are either requests resulting from broken internal or external links. Broken bot requests are requests originating from bots not adhering to standards.
| Enable logging of broken links
Check box |
Enable / disable logging of referred requests (requests with a referrer header) allowed by the policy but resulting in a Default: |
| Enable logging of webserver 404 not found
Check box |
Enable / disable logging of requests allowed by the policy but resulting in a Default: |
| Enable logging of broken bot requests
Check box |
Enable / disable logging of requests classified as broken bot requests. Default: |
In order to avoid compromising confidential data like for instance payment card numbers (along with other payment card data like control code and expiration date) ending up in the deny log it is possible to configure log data masking policies based on regular expressions.
| Enable rewriting of logged querys |
Check or uncheck the checkbox Enable rewriting of logged querys to enable this feature. |
|||
| Name |
This is an informal field allowing for assigning a human readable name to the rewrite policy rule.
|
|||
| Search for |
A regular expression matching the string to replace.
Notice the use of backslash ("\") in the examples above to escape the metacharacter ".". Without escaping the "." it will be interpreted as a metacharacter matching any character resulting in the regular expression also matching strings like xxxyhost2xxx4tld and xxxhost_xxx_tld (a.o.). The regular expressions matches case insensitive in a repetitive fashion meaning that if more than one instance of the search pattern is present in the string they will all be replaced. |
|||
| Replace with |
A string to replace with
|
When access logging is enabled all requests to the website is logged.
The access log is generated on a per day basis and closed logs are made available for download.
| Enable access logging
Check box |
Enable / disable access logging. If enabled, Web Security Manager will log all proxied requests to the web site. Default: |
| Access log format
Drop down list |
Select the format for the access log.
When the |
| Custom fortmat
Input field |
Define a custom log format.
|
| Add roundtrip time and cache info to access log format
Check box |
Enable / disable additional proxy specific log fields. If enabled, Web Security Manager will add roundtrip time and "served from cache flag" to the selected log format. Default: |
When log files are available for download the filename is an active link. To download an access log file click on the filename.
When remote backup is enabled, the latest access log file made available for download will be compressed (using gzip) and copied to the remote backup destination along with the backup of the system configuration.
Web Security Manager supports a number of standard access log formats suitable for importing into log-analysis tools. For plain access logging the Web Security Manager format is the most condensed.
The Web Security Manager Common log format is a condensed version of the Common log format (below). It contains only basic HTTP access information and the time field is kept in Unix epoch format to save time and space.
| Source IP | The client source IP address. |
| Time | Time the request was received (UNIX timestamp) |
| Request | First line of request |
| Server response code | Web server server response code - i.e. 200 |
| Response size | Size of response in bytes, excluding HTTP headers |
| Response time | The time taken to serve the request, in microseconds |
| Cached response | Is response served from cache or not (1=yes, 0=no) |
The Common log format contains only basic HTTP access information.
| Source IP | The client source IP address. |
| Remote logname | N/A - will contain a dash, included for compatibility. |
| Remote user | N/A - will contain a dash, included for compatibility. |
| Time | Time the request was received (standard english format) |
| Request | First line of request |
| Server response code | Web server server response code - i.e. 200 |
| Response size | Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent. |
The Common log format contains only basic HTTP access information with the addition of canonical name of the Virtual Host serving the request.
| Virtual Host | The canonical ServerName of the server serving the request. |
| Source IP | The client source IP address. |
| Remote logname | N/A - will contain a dash, included for compatibility. |
| Remote user | N/A - will contain a dash, included for compatibility. |
| Time | Time the request was received (standard english format) |
| Request | First line of request |
| Server response code | Web server server response code - i.e. 200 |
| Response size | Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent. |
The NCSA extended/combined format contains the same information as the Common log format plus two additional fields: the referral field and the user_agent field. This log format is also called Apache Combined log format.
| Source IP | The client source IP address. |
| Remote logname | N/A - will contain a dash, included for compatibility. |
| Remote user | N/A - will contain a dash, included for compatibility. |
| Time | Time the request was received (standard english format) |
| Request | First line of request |
| Server response code | Web server server response code - i.e. 200 |
| Response size | Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent. |
| Referrer | The content of the request header "Referer". |
| User-Agent | The content of the request header "User-Agent". |
The custom log format allows for specifying custom log formats by entering log format field names separated by space. The field names below are available.
| Source IP | remote_addr | The client source IP address. |
| Remote logname | remote_logname | N/A - will contain a dash, included for compatibility. |
| Remote user | remote_user | N/A - will contain a dash, included for compatibility. |
| Time | time_local | Time the request was received (standard english format) |
| Request | request | First line of request |
| Server response code | status | Web server server response code - i.e. 200 |
| Response size | body_bytes_sent | Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent. |
| Referrer | referer | The content of the request header "Referer". |
| User-Agent | user_agent | The content of the request header "User-Agent". |
| Cookie | cookie | The content of the request header "Cookie". |
| Response time | roundtrip | The time taken to serve the request, in microseconds. |
| UNIX timestamp | timestamp | Time the request was received (UNIX timestamp). |
| Cached response | cache | Is response served from cache or not (1=yes, 0=no). |
This feature allows for configuring the proxy to dynamically mirror the policy of another website proxy.
To mirror a proxy select it in the drop down list and enable the Mirror proxy policy from master module.
When mirroring is enabled it will be indicated in the top of the page with the text (MIRROR OF PROXY xx). Also in the websites overview the information in the Virtual Web server column will contain the text (M:X) where X is the website proxy ID.
Note that the selected mode is not mirrored so if the mirrored proxy (the master) is running in Protect mode and the mirror (the proxy for which mirroring is enabled) is running in Detect mode it will log/block according to the Detect mode preset while the mirrored proxy will use the Protect mode preset.
Restrict which HTTP protocol versions are allowed.
Corresponding violation: HTTP Protocol version
| HTTP 1.0 Check box |
Allow / disallow HTTP 1.0 requests . Default: |
| HTTP 1.1 Check box |
Allow / disallow HTTP 1.1 requests . Default: |
Restrict which HTTP methods are allowed.
Corresponding violation: Method illegal
| HEAD Check box |
Allow / disallow HTTP method HEAD. Default: |
| GET Check box |
Allow / disallow HTTP method GET. Default: |
| POST Check box |
Allow / disallow HTTP method POST. Default: |
| OPTIONS Check box |
Allow / disallow HTTP method OPTIONS. Default: |
Web Security Manager supports inspection of XML and JSON based web services requests, including SOAP and XML RPC.
XML based requests are learned like other queries and positive and negative policies and combinations thereof can be enforced.
Corresponding violation: Content type not enabled
| Enable XML web services support
Check box |
Enable / disable support for XML web services support . If enabled, Web Security Manager will parse requests with Content-Type = text/xml and treat the XML as a query. Default: |
| Enable JSON web services support
Check box |
Enable / disable support for JSON web services support. If enabled, Web Security Manager will parse requests with Content-Type = application/json, text/x-json or text/json and treat the JSON request payload as a query. Default: |
| Parse text/plain content type requests
Check box |
Enable / disable support for POST requests with Content Type text/plain. If enabled, Web Security Manager will accept requests with the text/plain Content Type and parse the payload of the request. As there is no standard for how the payload is composed the parser is configurable. The default configuration parses the payload as a carriage return / newline separated list of parameter name / value pairs in the form name=value. This is the format used by the Direct Web request (or DWR) Java library. To change the way the payload is parsed click the button. This will display the regular expression that extracts the name / value pairs. If you want to change it you may want to contact Alert Logic support to get help doing it. It not complicated if you are comfortable with regular expressions though.
The values are captured in the two parentheses. The first parenthesis The The last parenthesis ([^\n\r]*) the value but is optional as set by the asterisk (*) after the bracketed list. When changing the regular expression it is a requirement that there is at least one pair of parentheses matching something. The simplest allowed regular expression would be (.+) which will match the entire payload. When composing regular expressions note that the expression is run with the /gsi options meaning that the expression is iterated over until there are no more matches (/g), the payload is treated as one string (including \r and \n) (/s) which redefines the meaning of the meaning of the "anything" meta character (.) to include \r and \n and finally that matching is case insensitive (\i). Default: |
Web Security Manager allows for encapsulating other protocols in the HTTP protocol, so called HTTP tunneling.
Corresponding violation: Content type not enabled
| Allow HTTP tunneling Check box |
Enable / disable HTTP tunneling (Content-Type = application/octet-stream). When HTTP tunneling is enabled requests with content type application/octet-stream are passed through without parsing the payload. Default: |
| Bypass Flash Remoting Check box |
Enable / disable Flash Remoting (Content-Type = application/x-amf). When Flash Remoting is enabled requests with content type application/octet-stream are passed through without parsing the payload. Default: |
| Bypass ActiveSync WBXML (binary XML) and message/rfc822 Check box |
Enable / disable WBXML (binary xml) and message/rfc822 content types. When enabled binary XML and content type message/rfc822 will be bypassed. This is necessary for Activesync synchronization with mobile devices and outlook web access to work. Default: |
Restrict length and number for HTTP request headers.
If a header fails this check, the entire request is blocked and handled accordingly.
| Header name maximum length
Input field |
Maximum length for each inbound HTTP header name. Corresponding violation:
|
| Header value maximum length
Input field |
Maximum length for each inbound HTTP header value. Corresponding violation:
|
| Maximum number of headers
Input field |
Maximum number of HTTP headers in request. Corresponding violation:
|
Restrict type, length, number and type for HTTP request cookies.
If a cookie fails this check, the entire request is blocked and handled accordingly.
| Accept Version0 Check box |
Allow / disallow version 0 cookies. Version 0 is most widely used on the internet today. Corresponding violation: Default: |
| Accept Version1 Check box |
Allow / disallow version 1 cookies. Corresponding violation: Default: |
| Cookie name maximum length
Input field |
Maximum length for each cookie name. Corresponding violation:
|
| Cookie value maximum length
Input field |
Maximum length for each cookie value. Corresponding violation:
|
| Maximum number of cookies
Input field |
Maximum number of cookies in request. Corresponding violation:
|
Restrict length and number for HTTP request in general.
If the request fails this check, the entire request is blocked and handled accordingly.
| Request line maximum length
Input field |
Maximum allowed length of the request line. When the request is displayed in the browser address bar the request line is everything following the protocol://domain.name.tld part of the request. The request line is the emphasized part of http://domain.name.tld/path/to/resource?query=1&string=1 Corresponding violation:
|
| Request path maximum length
Input field |
Maximum allowed length of the path part of the request line. The path part is the emphasized part of http://domain.name.tld/path/to/resource?query=1&string=1 Corresponding violation:
|
| Query string maximum length
Input field |
Maximum allowed length of the query part of the request line. The query part is the emphasized part of http://domain.name.tld/path/to/resource?query=1&string=1 Corresponding violation:
|
| POST form payload limit
Input field |
Defines the maximum allowed POST content length. If a given POST request length fails the check, the entire request is blocked and handled accordingly. Corresponding violation:
|
| Maximum number of files
Input field |
Maximum number of allowed files to upload in request. Corresponding violation:
|
| Individual file size
Input field |
Maximum allowed size for each individual file in upload request. Corresponding violation:
|
| POST upload payload limit
Input field |
Maximum allowed size for entire upload request, i.e. total size of all files in upload request. Corresponding violation:
|
| GET Parameter name maximum length
Input field |
Maximum length for each GET parameter name. Corresponding violation:
|
| GET Parameter value maximum length
Input field |
Maximum length for each GET parameter value. Corresponding violation:
|
| GET Parameter combined length
Input field |
Maximum length for each GET parameter name + value pair. Corresponding violation:
|
| GET Maximum number of parameters
Input field |
Maximum number of GET parameters in request. Corresponding violation:
|
| POST Parameter name maximum length
Input field |
Maximum length for each POST parameter name. Corresponding violation:
|
| POST Parameter value maximum length
Input field |
Maximum length for each POST parameter value. Corresponding violation:
|
| POST Parameter combined length
Input field |
Maximum length for each POST parameter name + value pair. Corresponding violation:
|
| POST Maximum number of parameters
Input field |
Maximum number of POST parameters in request. Corresponding violation:
|
The Static content policy allows requests without parameters based on file extension (i.e. .gif) and allowed path characters.
To define a static content policy enter or edit file extensions and allowed path characters.
- File extension
-
The file extension is defined as a list of comma separated values.
- Allowed path characters
-
Allowed path characters are defined by selecting them on a list.
The letter A denotes all international alphanumeric characters and other characters are represented by their glyph, their UTF-8 number and a description.
As static content is not supposed to have any parameters (hence the denotation "static") only requests without parameters
and with the method GET are validated against this rule.
It is possible to allow static requests in general.
| Allow all static requests Radio button |
If selected, requests without parameters like requests for graphic elements, stylesheets, javascript, etc. are allowed in general. Allowing all static requests is faster but less secure as only input to web applications will be inspected when this option is enabled. |
| Validate static requests path and extension Radio button |
If selected, requests without parameters like requests for graphic elements, stylesheets, javascript, etc. are validated using allowed path extension and allowed path characters. Default: |
| Allowed static file extensions Input field |
The file extension is defined as a list of comma separated values.
|
| Allowed path characters List of check boxes |
Allowed path characters are defined by selecting them on a the list which appears when activating the button . In the list the letter A denotes all international alphanumeric characters and other characters are represented by their glyph, their UTF-8 number and a description.
|
| Validate cookies for static requests Check box |
Enable / disable validation of cookies for requests for static content. Default: |
The URL regular expressions filter matches URLs without parameters on a proxy global basis. If a request matches any of the defined regular expressions, it will be marked as valid by Web Security Manager and forwarded to the back-end server.
For examples of global URL regular expressions, please refer to Table 5.6, “Examples of global URL regular expressions”
|
Note |
|---|---|
|
Full match is implied for each regular expression, meaning that each will match from the start to the end of the request (a caret ^ and dollar $ will be appended if not already present). |
| Negative validation Check box |
Check or uncheck to enable validation of the path element of the URL against negative signatures. Paths not matching attack signatures will be allowed. |
| Positive validation Check box |
Check or uncheck to to enable positive validation of the path element of the request URL. Paths matching one of the regular expressions in the list will be allowed. |
| Allowed path |
In the list enter one or more regular expressions defining the global path policy.
|
The URL regular expressions block filter matches URLs without parameters on a proxy global basis. If a request matches any of the defined regular expressions it will instantly be blocked.
Suppose for instance that a global paths policy rule allows all URL paths's with the extension ".php" but that you want to block access to all resources in the /admin directory - including subdirectories. To do that simply add the policy rule "/admin/".
|
Note |
|---|---|
|
The expressions are matching from left to right. Full match is not implied but matching always start at start of line. This implies that for instance the expression /admin will match any URI starting with /admin. |
| Denied path Input fields |
In the list enter one or more regular expressions defining the global denied path policy.
|
Depending on the web server and web application technology and design of the web applications on the back end web server cookie names and values may in some cases be parsed as part of a general request object with the risk that client request cookies may be used to bypass validation controls. It is therefore recommended that cookies are parsed and validated as an integral part of the client query. That is as request parameters.
Web Security Manager parses cookies and when learning is enabled the Learner maps cookie values as global parameters.
| Cookie validation enabled Check box |
If enabled client request cookies will be parsed and validated as request parameters. Default: |
In the global parameters section, parameters which all or many URLs have in common can be added. For instance in many CMS systems an URL can be viewed in a printer friendly version by adding a specific parameter to the URL.
When adding parameters to the list the name of the parameter is interpreted by Web Security Manager as regular expressions. Like with the global URL-regular expressions full match from start to end is implied. The value can either be a regular expression or a predefined input validation class.
| Enable global parameter signature based negative matching Check box |
Check or uncheck the checkbox Enable global parameter signature based negative matching to enable signature bases matching of parameter names and corresponding values. When learning is enabled for the website this option should be enabled as it ensures that parameters not being validated by positive policy rules are validated negatively and thus not rejected by default. |
| Enable global parameter regexp matching |
Check or uncheck the checkbox Enable global parameter regexp matching to enable global parameter regexp matching. |
| Name Input fields |
In the list enter a regular expression matching the parameter name or names you want to match.
|
| Type
Drop down list |
Input validation type.
|
| Update Drop down list |
Controls how the Learner handles the parameter. When update is set to |
| Value
Depends on |
Value for input validation.
When type is |
For examples of specifying global parameters using regular expressions please refer to Table 5.8, “Examples of global parameters regular expressions”.
For more general examples using regular expressions for input validation please refer to Table 5.7, “Examples of regular expressions for input validation”.
|
Note |
|---|---|
|
Full match is implied for each regular expression, meaning that each will match from the start to the end of the request (a caret ^ and dollar $ will be appended if not already present). |
| Enforce strict HTTP/1.0 and HTTP/1.1 compliant headers
Check box |
Enable / disable enforcement of strict HTTP/1.0 and HTTP/1.1 compliant headers. If enabled, Web Security Manager will enforce strict HTTP 1/0 and HTTP/1.1 header compliance according the RFC standards and deny any custom HTTP header is sent in the request. If a given header fails the check, the entire request is blocked and handled accordingly. Default: |
| Pragmatic HTTP headers checking
Check box |
Enable / disable pragmatic HTTP headers checking. If enabled, inbound HTTP headers are checked according to a more loose definition. Custom HTTP headers are allowed. Default: |
Requests can be blocked/logged based on the value of a header.
| Enable headers blocking Check box |
Check or uncheck to enable blocking of requests based on header content. Requests with headers matching the blocking rules will denied. |
| Header Input fields |
Enter name of header to match.
|
| Allowed path Input fields |
Regular expression to match header value. Note that full match is not implied so the regex
|
The use of attack signatures can be enabled or disabled for each request method supported.
The checkboxes in the negative filtering column enable or disable the use of attack signatures for validating input. The settings only applies to requests or or request parts for which negative filtering is enabled.
| Attack Class |
The name of the signature attack class |
| HEAD
Check box |
Check or uncheck to enable signature for method Default: Signature dependent. |
| GET
Check box |
Check or uncheck to enable signature for method Default: Signature dependent. |
| POST
Check box |
Check or uncheck to enable signature for method Default: Signature dependent. |
| OPTIONS
Check box |
Check or uncheck to enable signature for method Default: Signature dependent. |
The checkboxes in the classification column enable or disable the use of attack signatures for classifying log records and learning samples. If for instance the website takes HTML as in input like some CMS'es and bulletin board systems does this is likely to trick the Cross Site Scripting (XSS) signature. If it is not possible to white-list the IP address(es) from which the input originates or to only allow access to the CMS via VPN it might be neccessary to disable the XSS signature in order to ensure that the Learner gets the data samples.
| Attack Class |
The name of the signature attack class |
| HEAD
Check box |
Check or uncheck to enable signature for method Default: Signature dependent. |
| GET
Check box |
Check or uncheck to enable signature for method Default: Signature dependent. |
| POST
Check box |
Check or uncheck to enable signature for method Default: Signature dependent. |
| OPTIONS
Check box |
Check or uncheck to enable signature for method Default: Signature dependent. |
Web Security Manager has the ability to protect against session hijacking and CSRF (Cross Site Request Forgery) by:
-
Binding client IPs to session cookies by issuing a validation cookie containing a cryptographic token (a checksum) which validates session id + client IP + a secret for each client request.
-
By binding forms to sessions and verifying the origin of the form through insertion of a form validation parameter containing a cryptographic token which proves that the action formulator (the system issuing the page containing a form with an action) knows a session specific secret.
-
Additionally idle sessions are timed out in order to prevent users from staying logged in making them vulnerable to CSRF attacks.
When the web system issues a session cookie Web Security Manager detects it and issues a corresponding session validation cookie. In order to be able to identify the session cookie it is necessary to enter the name of the cookie containing the session id - i.e. PHPSESSID, JSESSIONID, ASPSESSIONID, SID.
An easy way to identify the session cookie name for the site you are configuring protection is to establish a session with the site (logging in, visiting the site or whatever actions are necessary to make the site issue a session cookie) and then view the cookies issued for that specific site in your browser.
- Finding session cookie name in Firefox
-
When a session is established view the cookie in ->+->->
Enter the domain name of the site in the search field.
| Session ID name
Input field |
The name of the cookie containing the session identifier. This field value is required to enable session and form (CSRF) protection.
|
| Secret for signing checksums
Input field |
A hard to guess string used to generate session cookie validation tokens.
|
| Idle session timeout
Input field |
Idle session timeout specifies the maximum duration of an idle session before it is dropped resulting in the user being logged out from the web site.
|
| Add Secure flag to session cookie
Check box |
Add secure flag to session cookie to instruct users browser to only send the cookie over an SSL connection. Default: |
| Make session cookie HttpOnly
Check box |
Add HttpOnly flag to session cookie to instruct users browser to make the cookie inaccessible to client side script. Default: |
| Enable session protection
Check box |
Enable / disable validation of session identifiers. If enabled, Web Security Manager will issue a validation cookie containing a cryptographic token (a checksum) which validates session id + client IP + secret for signing checksums (above) for each client request. The validation cookie is named __PFV__ and is issued whenever Web Security Manager detects a set_cookie with a cookie name matching the value configured (above) from the web site to protect. Default: |
| Session violation action
Check box |
What Web Security Manager should do when an invalid session id is detected. Session violation actions
Default: |
| Generate request form validation tokens (CSRF protection)
Check box |
Enable / disable generation of request form validation tokens (CSRF protection) If enabled, Web Security Manager will parse web system responses of type text/* searching for form tags. When forms tags are detected a session specific checksum validating the form action is inserted as a hidden parameter (named ___pffv___) to the form. Default: Now go to -> to enable request validation for specific applications (see Section 1.4.1, “Web application settings”). If configured the Learner will learn and configure CSRF protection for applications. |
| Form violation action
Check box |
What Web Security Manager should do when an invalid request is detected. Form violation actions
Default: |
| Enable request authorization
Check box |
Enable / disable request authorization for configured web applications. If enabled, Web Security Manager will authorize access to resources based on session validity. Request authorization is only enforced for resources for which this feature is enabled. Default: Now go to -> to enable request authorization for specific applications and other resources incl. static files (see Section 1.4.1, “Web application settings”). |
List if IP addresses which are trusted / whitelisted. The in- and output filters can be configured to be bypassed for the whitelisted addresses.
| Whitelist
Input field |
Per default, requests originating from any IP address (0.0.0.0/0) is affected when Pass Through Mode is enabled. The white list allows for the definition of specific IP address(es) or networks for which Pass Through Mode is enabled.
|
IP pass through allows for configuring overriding of filter actions based on the source of the request.
| Enable HTTP request blocking bypass for trusted clients
Check box |
Enable / disable HTTP pass through With Pass Through for trusted clients enabled, all requests will be forwarded to the real server, but will be otherwise handled the usual way (ie. Web Security Manager will learn about the site and log any would be blocked requests not matching the applied access control list). Default: |
| Enable IP network blocking bypass for trusted clients
Check box |
Enable / disable network blocking pass through When enabled, IP addresses listed as trusted clients will be included in the global list of IP addresses that are allowed to bypass network blocking and DoS mitigation controls. Note that the address will not be bypassed unless network blocking bypass is allowed in -> Default: |
The trusted domains is a whitelist of domains which is composed of 1) the domain of the website proxy virtual host and the domains of the host names in Virtual host aliases and 2) a list of other trusted domains which can be entered manually.
The effective list of trusted domains is used in Remote File Inclusion signatures to leave out URLs targeting hosts within the list and when validating redirects to allow redirects to hosts within the list.
| Effective trusted domains |
This is the effective list of trusted domains, i.e. the automatically generated list of the domain of the website proxy virtual host, the domains of the host names in Virtual host aliases and the manually entered domains (if any). |
| Other trusted domains |
Enter additional domains to the list of trusted domains. Domains are separated by newline. |
| Include other trusted domains in domains list | When enabled the manually entered domains will be added to the effective trusted domains list. |
IP pass through allows for configuring overriding of filter actions based on the source of the request.
| Enable HTTP request blocking bypass for trusted clients
Check box |
Enable / disable HTTP pass through With Pass Through for trusted clients enabled, all requests will be forwarded to the real server, but will be otherwise handled the usual way (ie. Web Security Manager will learn about the site and log any would be blocked requests not matching the applied access control list). Default: |
| Enable IP network blocking bypass for trusted clients
Check box |
Enable / disable network blocking pass through When enabled, IP addresses listed as trusted clients will be included in the global list of IP addresses that are allowed to bypass network blocking and DoS mitigation controls. Note that the address will not be bypassed unless network blocking bypass is allowed in -> Default: |
| Block multiple and %u encoded requests
Check box |
Enable / disable blocking of multiple (or %u) encoded requests. In an attempt to evade detection attackers often try to encode requests multiple times. If enabled, Web Security Manager will block requests which after being decoded still contains encoded characters. Default: |
If duplicate parameter names are allowed, wrongly configured web application behaviour may result in Web Security Manager not learning the web site correctly and may also lead to WAF bypassing vulnerabilities depending on the target application/web server technology.
An attacker may submit a request to the web application with several parameters with the same name depending on the technology the web application may react in one of the following ways:
-
It may only take the data from the first or the last occurrence of the duplicate parameter
-
It may take the data from all the occurrences and concatenate them in a list or put them in an array
In the case of concatenation it will allow an attacker to distribute the payload of for instance an SQL injection attack across several duplicate parameters.
As an example ASP.NET concatenates duplicate parameters using ',' so /index.aspx?page=22&page=42 would result in the backend web application parsing the value of the 'page' parameter as page=22,42 while Web Security Manager
may see it as two parameters with values 22 and 42.
This behaviour allows the attacker to distribute an SQL injection attack across the three parameters.
/index.aspx?page='select data&page=1 from table would result in the backend web application parsing the value of the 'page' parameter as 'select data, 1 from table while
Web Security Manager may see it as two parameters with values 'select data and 1 from table.
By default when Web Security Manager validates parameters negatively it automatically concatenates the payload of duplicate parameters. It is mostly in the case where a positive application or global rule allows a specific parameter with an input validation rule that makes room for attacks like the above the parameter duplication problem exists. In the page example above the attack would be stopped because the page parameter would be learned as numeric input (an integer). This would not allow text input like in the example above. Nevertheless it is important to configure Web Security Manager to mimic the target web applications parsing of requests as closely as possible.
| Block duplicate parameter names
Check box |
Enable / disable blocking of duplicate parameter names. If enabled, Web Security Manager blocks requests containing duplicate parameter names. Default: |
| Join duplicate parameter names
Check box |
Enable / disable concatenation duplicate parameters. If enabled, Web Security Manager will concatenate the values of the duplicate parameters using the configured join separator (below). Default: |
| Join separator
Input field |
Character(s) used for separating concatenated parameter values.
|
The best option is to disallow duplicate parameter names. It may not be practical though as the use of duplicate parameters
may be intended in some applications - the most prominent example being PHP which parses parameter names suffixed with [] as an array - like par1[]=22&par1[]=42 becoming array(22,42). If this feature is not in use block it.
If the application technology is ASP/IIS or ASP.NET/IIS and it is not possible to disallow duplicate parameters the recommended setting is to join duplicate parameters using ',' as in the join separator example above.
Access to a website can be restricted on a time basis.
For each weekday enter opening hours.
| Opens
Input field |
Time the website opens on the weekday.
|
| Closes
Input field |
Time the website closes on the weekday.
|
To specify dates where the website is closed enter a list of dates in the format mm/dd separated by whitespace, comma or semicolon.
Characters classes are useful when you want to use a predeclared set of criteria used by Web Security Manager for input request validation. Eg. if you have lots of HTML forms that use an input field "email", you can define a class and a regular expression which defines what a valid e-mail address is. This class can then be used throughout the entire policy.
When a class is changed, all affected policy elements are automatically updated to reflect the change.
| Rank
Read only |
The class rank when used by the Learner. To change the rank, place the cursor in one of the classes input fields. The rank number will be indented. Use the buttons and in the lower button panel to change the class' rank. |
| Name
Input field |
The class' name.
|
| Value
Input field |
The class regular expression.
|
| X
Button |
Mark class for deletion. When classes are saved the marked classes will be deleted. When deleting classes that are in use in the policy you will be prompted to accept replacement of the deleted classes with existing classes. Learner data samples using deleted classes will be deleted. |
For more information about classes and their corresponding regular expressions refer to Section 1.7, “Regular expressions”.
Some user input is so complex and unpredictable that, to avoid false positives, positive validation of input ends up being very general and loose. An example of this is free text input fields which often get mapped to the input validation class "printable" which basically allows all printable characters. It is often better validate such input negatively - which Web Security Manager does by default.
Web Security Manager determines if an input should be validated negatively based on the input validation class rank. By default
the threshold is the class Printable. If a parameters input is learned/configured to be the class configured as threshold the signatures policy will be used instead
of the class regular expression.
| Move up |
Change the rank of the selected class. To move the class upwards. Select the class by clicking anywhere in the class row. When selected the class rank number is highlighted and indented. Click Move up to move the class one step upwards. |
| Move down |
Change the rank of the selected class. Works as described above. |
| Add new | Add new class. When clicked an empty row will appear at the bottom of the class list. Fill out the blanks and place the class in the class hierarchy with the move buttons. |
| Use negative checking above and including class rank
Drop down |
The class rank above and including which input will be validated negatively.
To disable negative class checking select |
The Web applications section allows for defining policy rules with a scope that is limited to specific web applications.
Web applications are either added manually or they are automatically created created by the Learner.
| Requests
Drop down list |
Configure URL request status. When set to deny all requests for the web application will be denied.
|
| Update
Drop down list |
Configure URL update setting.
|
| Violation action
Drop down list |
Action to take when a request for the web application is denied. When set to block or detect this setting will override the global setting for the violation at hand.
|
Restrict which HTTP methods are allowed.
Corresponding violation: Method illegal
| HEAD Check box |
Allow / disallow HTTP method HEAD. Default: |
| GET Check box |
Allow / disallow HTTP method GET. Default: |
| POST Check box |
Allow / disallow HTTP method POST. Default: |
| OPTIONS Check box |
Allow / disallow HTTP method OPTIONS. Default: |
| Require a valid session to access this resource
Check box |
Enable / disable authorization of access to this resource based on session validity. If enabled, whenever this resource is requested, Web Security Manager will only allow the request if it originates from a valid user session. Note that session protection and request authorization have to be enabled for resource request authorization to be effective - see Section 1.3.7, “Session and CSRF protection” Default: |
| Enable request origin validation for this application
Check box |
Enable / disable validation of requests resulting from forms with this application as action. If enabled, whenever a request for this application contains a specific parameter (see below) it is verified that the request origins from a form on a web page / application belonging to the web system and that the form has been issued on a page belonging to the current users session. Note that for the validation token to be generated Generate request form validation tokens (CSRF protection) has to be enabled - see Section 1.3.7, “Session and CSRF protection” Default: |
| Validate parameter name
Input field |
String specifying the name of a specific parameter to be present for Web Security Manager to perform request origin validation.
|
This section contains a list of current defined parameters with corresponding input validation type and value and other settings.
To update a parameter simply change the values and click on the button.
| Select parameter
Check box |
Check or uncheck to mark for deletion. Default: <unchecked> To mark an entry for deletion, check the box. When the parameter list is saved the parameter will be deleted. |
|||
| Name
Input field |
String specifying the parameters name.
|
|||
| Type
Drop down list |
Input validation type.
|
|||
| Value(s)
Depends on |
Value for input validation.
|
|||
| Negative Check
Drop down |
Use negative checking if validation class is above configured threshold. If set to Auto the policy configured in classes negative signatures policy will be applied when validating input.
|
|||
| Update
Drop down |
Configure how the parameter should be handled by the Learner. If set to When set to
|
The Output filter section allows for configuring policies for rewriting headers and body of server responses sent to the client.
A typical web server gives out a lot of information about it's version, installed software, operating system, etc.
This information is completely irrelevant for normal HTTP/HTTPS communication between clients and web server. However, attackers and worms can misuse this information to craft more targeted attacks on a vulnerable web application or server.
| Server ID
Input field |
The server name string that is sent in respones to clients in the Server header. When the website proxy is created the value is extracted from the backend server response in a short form. Leave the field empty to omit the Server header from responses.
|
| Enable Web server cloaking mode
Check box |
Enable / disable Web server cloaking mode. If enabled, Web Security Manager removes web server information from the response sent back from the back-end server before forwarding it to the client thus protecting the web application and server from leaking potentially sensitive information. This includes stripping of all HTTP headers that start with "X-". Eg. header "X-Powered-By: PHP/4.4.0" will be removed. Default: |
| Intercept backend error pages
Check box |
Intercept error pages with error code 400 or higher sent by the backend web server and replace with a general error page. Configure error pages in Section 2.2, “Error messages” Default: <checked> When enabled the original error code can be replaced with a general one (ie. 405 > 404) or the original error can be sent to the client.
|
| Exclude status codes
Input field |
Exclude specific error codes from error interception (if enabled).
|
Redirects validation protects against attacks that redirect victims to phishing or malware sites through target applications that use untrusted data to determine the destination pages.
| Block redirects to non trusted domains |
When enabled Web Security Manager will validate redirects from the protected web applications and only allow redirects to domains in the trusted domains whitelist. |
| Whitelist |
The whitelist is the effective list of trusted domains. Redirects are allowed to hosts in the domains in this list. The list can be edited in Trusted domains (Section 1.3.9, “Trusted domains”) in the global policy section. |
Web Security Manager allows for re-writing arbitrary response header values using regular expressions for matching the value to re-write.
| Enable response header re-writing |
Check or uncheck the checkbox Enable response header re-writing to enable this feature. |
| Header |
In the list enter a the name of the header to match.
|
| Search for |
A regular expression matching the string to replace.
Notice the use of backslash ("\") in the examples above to escape the metacharacter ".". Without escaping the "." it will be interpreted as a metacharacter matching any character resulting in the regular expression also matching strings like xxxyhost2xxx4tld and xxxhost_xxx_tld (a.o.). The regular expressions matches case insensitive in a repetitive fashion meaning that if more than one instance of the search pattern is present in the string they will all be replaced. |
| Replace with |
A string to replace with
|
Web Security Manager allows for parsing and rewriting the body of server responses. This is useful for screening (and replacing) output for confidential data like credit card numbers. Note however that rewriting server responses involves parsing the complete document and therefore will introduce added latency.
It is important that the correct response content type is configured in Web application behaviour.
| Search for |
A regular expression matching the string to replace.
As with the response header rewrite function the the regular expressions matches case insensitive in a repetitive fashion meaning that if more than one instance of the search pattern is present in the string they will all be replaced. Also meta characters should be escaped if they are to be interpreted literally. |
| Action
Drop down |
Action to take if there is a search match. Replace: replace matched string with replace string. Block: block the rest of the response and log the violation.
|
| Replace with |
A string to replace with
|
Web Security Manager can be configured to not rewrite the response body if the request is originating from trusted clients or if the requested path matches a regular expression.
| Do not re-write from whitelisted IP's (trusted clients) |
Check or uncheck the checkbox to exclude requests from trusted clients / whitelisted IP from being rewritten. The list of trusted clients is edited in the global policy section |
| Do not re-write from URIs matching regex |
Enter a regular expressions matching the path part of the requests to be excluded. Only responses with content types text/
|
| Verify Client
Drop down list |
This directive enables the verification of the client identity. When set to deny all requests for the web application will be denied.
|
| Verify Depth
Input field |
Sets how deep Web Security Manager should go in the client provided certificate chain in order to verify the client identity.
|
One or more Certificate Authority certificates are required for authenticating clients.
To upload an authority certificate click the button. This will expand an area in which you paste the certificate authority certificates. Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.
To view detailed certificate information click the + in the left column.
The entire client certificate or specific certificate information can be forwarded to the backend web server in HTTP request headers.
The information selected will be forwarded in HTTP headers with the name of the selected info, ie. SSL_CLIENT_CERT will be forwarded in the header SSL_CLIENT_CERT.
Web Security Manager uses Certificate Revocation Lists (CRL) to support certificate revocation.
To use CRL configure a location where Web Security Manager can retrieve CRLs. When configured CRLs are downloaded and compiled at regular intervals to make sure that CRL updates are included.
Downloaded CRL files are displayed in the table below the CRL location rules.
| Enable
Check box |
Check to enable CRL checking for certificate. Default: <unchecked> |
| CA Certificate
Drop down list |
Select the CA certificate to enable CRL checking for. |
| Location URL
Input field |
A URL that points to the directory the where the CRL files are served from or directly to a CRL-file if CRLs for the CA are served as one (big) file.
|
| Type
Drop down list |
The type of the Location URL - index or file.
|
| Wildcard
Input field |
If the URL Location type is Index it is necessary to specify a wildcard that matches the CRL files in the location.
|
| Test
Button |
Before saving the CRL rule click the Test button. This will display all CRL files in the location matching the CRL location rule. |
In addition to generally restricting access to the website based on validity of client certificate it is possible to specify requirements which has to be fulfilled in order to allow access to website resources defined as paths.
Suppose you have an organisation, Snake Oil, that have a website to which they only want employees with valid client certificates issued by Snake Oil to be able to access in general. In the website there is an area, /management/, that they only want management to be able to access.
The first requirement can be achieved by requiring a valid Snake Oil certificate to access the website.
The second requirement can be met by creating an authorization rule that matches the Organisational Unit of the Subject DN, like: Location=/management, SSL_CLIENT_S_DN regex match OU=management.
| Location |
In the list enter one or more regular expressions defining locations. Note that the expressions are matching left to right so the expression can be a simple path like
|
| Requirements |
One or more requirements to be met for the client to be allowed access to the specified location. Using the operators AND and OR complex requirements can be specified. The AND operator precedes the OR operator so O=Snake Oil AND OU=management OR O=Rattle Snake Oil AND OU=admin will be evaluated as (O=Snake Oil AND OU=management) OR (O=Rattle Snake Oil AND OU=admin).
|
Web Security Manager has full support for standard PCRE (Perl Compatible Regular Expressions).
Following below is a brief regular expression "survival guide". For a more thorough explanation of the subject some links and books are recommended at the end of the section.
A regular expression is a formula for matching strings that follow some pattern.
Regular expressions are made up of normal characters and special characters. Normal characters include upper and lower case letters and digits. The characters with special meanings and are described in detail below.
In the simplest case, a regular expression looks like a standard text string. For example, the regular expression "john" contains no special characters. It will match "john" and "john doe" but it will not match "John".
In an input validation context we always want the expression to match the whole string. The expression above would now be expressed as ^john$, where the characters ^ and $ means starting of line and end of line. Now john will only match "john" but not "john doe". To obtain match of "john doe" as well as "john smith" etc. we employ a few more simple special characters. In its simplest form "john lastname" could be expressed as "^john.*$" meaning: A string starting with the characters "john" followed by zero or more (the "*") occurrences of any character (the "."). For those familiar with the simple wild-card character "*" in (a.o.) DOS and Unix, ".*" equals "*" - that is: anything.
Specifying anything is not very useful in an input validation context. With regular expressions much more fine grained input validation masks can be defined with the rich set of meta characters, character classes, repetition quantifiers, etc.
A brief explanation with some examples follows below.
^ |
Beginning of string (implied in Web Security Manager) |
$ |
End of string (implied in Web Security Manager) |
. |
Any character except newline |
* |
Match 0 or more times |
+ |
Match 1 or more times |
? |
Match 0 or 1 times; or: shortest match quantifier (i.e. *?) |
| |
Alternative (like logical OR) |
() |
Grouping |
[] |
Set of characters (a list of characters) |
{} |
Repetition modifier |
\ |
Quote or special |
Table 5.1. Metacharacters in regular expressions
To present a metacharacter as a data character standing for itself, precede it with \ (e.g. \. matches the full stop character "." only).
|
Note |
|---|---|
|
In Web Security Manager all regular expressions are forced to match the entire string (URL path or parameter value) by automatically prefixing an expression with "^" and suffixing it with "$". |
a* |
Zero or more a's |
a+ |
One or more a's |
a? |
Zero or one a's (i.e., optional a) |
a{m} |
Exactly m a's |
a{m,} |
At least m a's |
a{m,n} |
At least m but at most n a's |
repetition? |
Same as repetition but the shortest match is taken |
Table 5.2. Repetition in regular expressions
Read "a's" as "occurrences of strings, each of which matches the pattern a".
Read repetition as any of the repetition expressions listed above it.
Shortest match means that the shortest string matching the pattern is taken. The default is "greedy matching", which finds the longest match.
\t |
tab |
\n |
newline |
\r |
return (CR) |
\xhh |
character with hex. code hh |
\b |
"word" boundary (zero space assertion) |
\B |
not a "word" boundary |
\w |
matches any single international character classified as a "word" character (alphanumeric or _). Examples: A, z, 1, 9, Æ, â |
\W |
matches any non-"word" character |
\s |
matches any whitespace character (space, tab, newline) |
\S |
matches any non-whitespace character |
\d |
matches any digit character, equiv. to [0-9] |
\D |
matches any non-digit character |
\pN |
Matches any UNICODE character classified as numeric |
Table 5.3. Notations with \ in Web Security Manager regular expressions
A character set is denoted by [...]. Different meanings apply inside a character set ("character class") so that, instead of the normal rules given here, the following apply:
[characters] |
matches any of the characters in the list (c,h,a,r,a,c,t,e,r,s) |
[x-y] |
matches any of the characters from x to y (inclusively) in the ASCII code |
[\-] |
matches the hyphen character - |
[\n] |
matches the newline; other single character denotations with \ apply normally, too |
[^something] |
Negation. Matches any character except those that [something] denotes; that is, immediately after the leading [ the circumflex ^ means "not" applied to all of the rest |
Table 5.4. Character sets in regular expressions
The lookaround construct allows for the creation of regular expressions matching something but only when it is followed/preceded or not followed/preceded by something else. Note that the lookaround construct is a zero-width assertion. It is testing for a match of something else but it will not actually match it - that is why it is called an assertion. The lookaround constructs allows for the creation of otherwise impossible or too complex expressions.
In an input validation context look ahead could be used for specifying an expression allowing angle brackets <> but only when they are not closed.
| a(?!expression) | Negative lookahead. Matches "a" when not followed by expression, where expression is any regular expression. |
| a(?=expression) | Positive lookahead. Matches "a", when followed by expression. |
| (?<!fixed-expression)a | Negative lookbehind. Matches "a" when not preceded by fixed-expression, where fixed-expression is any regular expression specifying a fixed number of characters. That is "aaa" wil work but a+ will not work. |
| (?<=fixed-expression)a | Positive lookbehind. Matches "a" when preceded by fixed-expression. |
Table 5.5. Lookaround in regular expressions
The URL regular expressions filter matches URLs without parameters on a proxy global basis. If a request matches any of the defined regular expressions, it will be marked as valid by Web Security Manager and forwarded to the back-end server.
| Expression | Matches |
|---|---|
(/[\w\-]+)+\.html |
URL with the extension html containing any international word characters, digits, _ and -. (\w matches upper and lower case alphanumeric characters plus _). |
/abc(?:/[\w\-]+)*\.html |
Same URL starting with /abc, including the URL /abc.html.
|
(/[\w\-]+)+\.html? |
Same URL matching extensions html and htm |
(/[\w\-]+)+\.(html|pdf) |
Same URL matching extensions html and pdf.
|
(/[abcdefgh]+)+\.html |
URL with the extension html containing any of the lower case letters abcdefgh.
|
/index\.html |
Exact match of /index.html |
(/[\w\-]+)+/? |
"Natural" URL containing international alphanumeric characters, digits, _ and -.
|
/sw[0-9]{0,12}\.asp |
URL with the extension asp starting with /sw followed by 0-12 digits.
|
/(login|logout) |
Only URLs /login or /logout |
(/[\w\-]+)+\.(htm|html|shtml|pdf) |
Any international characters URL with one of the extensions htm, html shtml or pdf. |
Table 5.6. Examples of global URL regular expressions
| regular expression | matches |
|---|---|
^[\w \.@()\-]+$ |
International alphanumeric characters, underscore, a space, dot, @, parentheses and a dash. |
^[0-9a-za-z. ]+$ |
digits, ASCII characters a-z, a dot and a space. |
^[0-9]+$ |
only digits. [0-9] can also be expressed as \d |
^[\d]{1,5}$ |
one to five digits. |
^[a-z]+$ |
only lower case ASCII characters from a-z. |
^[a-z]{0,32}$ |
matches only lower case ASCII characters from a-z and limits the total length to maximum 32 characters. |
Table 5.7. Examples of regular expressions for input validation
When specifying global parameters both the name and the value are defined using regular expressions.
| Name | Value | Matches |
|---|---|---|
usepf |
true |
The specific parameter usepf with the static value true |
parm\d{3} |
[a-zA-Z\d]{3,32} |
All parameters with name starting with parm followed by three digits with the value any combination of letters a-Z (upper and lowercase) or digits with a minimum length of 3 and a maximum length of 32 characters.
|
\w{1,25} |
[\w\s_,/:()@$*\.\-]* |
Any parameter with name consisting of international word characters and with values containing zero or more"friendly characters". |
Table 5.8. Examples of global parameters regular expressions
The following classes are predefined in Web Security Manager. The classes are presented in the order the Automatic Policy Generator evaluates them when automatically mapping classes to input parameters.
| Class | Regular expression | Description |
|---|---|---|
| empty | No values allowed | |
| num | \d{1,32} |
Digits - a maximum of 32 digits |
| payment_card | (?:\d{4}[\-\x20]?){2}\d{4,5}[\-\x20]?(?:\d{2,4})? |
Payment card numbers, allows for spaces and hyphens between number groups. |
| ms_ident | {?[A-Za-z0-9]{8}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{12}}? |
Microsoft identifier with optional preceding and trailing curly brackets. |
| alphanum | \w{1,256} |
International alphanumeric characters. No spaces. max. 256 chars. |
| text | (?!.*(\.\.|//).*)[\w\x20+.,\-:@=/]+ |
Simple international text. |
| url | (?:https?://)?(?!.*(\.\.|//).*)[\w\x20@,.(){}/\-=?&]+ |
Simple international URL match. With parameters. Consecutive "/" or "." not allowed (negative look ahead) |
| standard | [\w\s@,.(){}/\-=?&_:]+ |
Text input, international, several special characters allowed including newline. |
| printable | [^\x00-\x08\x0b\x0c\x0e-\x1f\x7f]+ |
Any number of printable characters. Defined by negating character class containing non-printable characters. |
| anything | .+ |
Anything but newline. |
| Anything_multiline | (?:.|\n)* |
Anything including newline. |
Table 5.9. Predefined standard classes in Web Security Manager
A number of web sites and books are describing regular expressions in more detail.
- Wikipedia
-
A general description
- The 30 Minute Regex Tutorial
-
The code project
.NET specific tutorial, includes a software tool for testing.
- Regular-Expressions.info
-
Excellent web site dealing extensively with the subject.
There are many good books covering regular expressions. Here we mention a few.
- Regular Expression Pocket Reference
-
Introduction and quick reference from O'Reilly.
- Regular Expression Pocket Reference
-
Introduction and quick reference from O'Reilly.
- Mastering Regular Expressions, Second Edition
-
Learning to use regular expressions efficiently. Does not pretend to be introductory in any way. Also from O'Reilly.
- Sams Teach Yourself Regular Expressions in 10 Minutes
-
Sounds appealing. If you are new to regular expressions this is probably a good place to start. From Sams Publishing.