Invalid URL Handler
Purpose
The Invalid URL Handler analyzes the URL given in a request (without the attributes after the “?”). A URL is only valid if it matches at least one of the regular expressions given under valid url pattern and valid full url pattern, and at the same time does not match any of the regular expressions given under invalid url pattern and invalid full url pattern.
Requests with an invalid URL are denied by vWAF with a configurable HTTP error code.
For more information regarding adding and editing Handlers, see Editing Handlers.
Severity
Events triggered by this handler are given the severity: high. (For details on severity levels, see Severity of Events Triggered by Handlers).
Recommendations for use
You can use this handler to force or forbid specific file extensions for example, or to block specific directories.
Although it might at first glance appear easier to collect possible attacks in a blacklist (invalid-pattern), creating a specific whitelist (valid-pattern) is much more advisable from a security perspective (see also Guide: Recommended Work Sequence).
Examples:
As an example, the URL of a “normal” web application always consists of:
- a path specification in which the directory name consists of letters only
- a filename, which also only consists of letters plus optionally a known extension (usually.html)
The following valid-pattern would be appropriate in this case (for syntax, see: Regular Regular Expressions):
^/(\w*/)*\w+(\.html)?$The user could then only access files with the extension .html or directories that aren’t running PHP or CGI scripts directly.
A good selection of entries for invalid-pattern are offered by filenames or extensions that usually originate from the development environment or an old version and that shouldn’t actually be available any more. For example, the pattern \.(old|bak|conf|cfg)$ prevents access to all files with the extensions .old, .bak, .conf and .cfg.
Attributes
Attribute | Meaning |
|---|---|
match on raw url | Usually, vWAF attempts to interpret all data in the same way as your web application. This means that it decodes data before it checks it. If, for any reason, you want to exercise the rules of the Invalid Args Handler on the raw URL (non URL decoded), activate this option. |
invalid url pattern | Blacklist of regular expressions describing the pattern of invalid URLs. For details on priority and internal processing, see How Blacklists, Whitelists, and Graylists Are Processed. Each entry consists of two fields:
Examples: // denies the character string // /\.\./ denies the character string /../ /xmlrpc\.php$ denies xmlrpc.php being called (For details on the syntax, see Regular Expressions.) You can toggle the display of the pattern fields by clicking the green arrow symbols next to the description fields. |
valid url pattern | Whitelist of regular expressions describing the pattern of valid URLs. For details on priority and internal processing, see How Blacklists, Whitelists, and Graylists Are Processed. Example: The entry ^/.*$ accepts all URLs. (For details on the syntax, see Regular Expressions.) |
invalid full url pattern | Similar to invalid url pattern with the difference that the complete URL must match the pattern, not just a part of the URL. |
valid full url pattern | Similar to valid url pattern with the difference that the complete URL must match the pattern, not just a part of the URL. |
error code | HTTP error code that vWAF returns when the URL in the request matches one of the regular expressions given under invalid url pattern / invalid full url pattern or doesn't match any of the regular expressions given under valid url pattern / invalid url pattern. (For an overview of possible error codes, see HTTP Error Codes.) |
usertext | Optional: Here you can specify some text that vWAF adds to the log file entries created by this handler. You can use this, for example, to document why you've added the handler to your configuration, and how the handler is intended to behave. |
enable logging | Disable this option if you do not want vWAF to create a log file entry when the handler is executed. This can be useful to keep log files smaller in case the handler creates a large number of entries but you don't need these entries. When in detection mode, disabling logging de facto makes the handler ineffective. Disabling logging also prevents the actions of the handler from being taken into account for the Top-10 lists in Attack Analysis, and from being listed in Reports. To decrease the size of the log files, also consider to enable reduced logging, which excludes all non-handler-related information from the log files (see Editing Applications). |
For details regarding entries added to the log file by this handler, see the relevant section in Entries in Application-Specific Log Files.