Start URL check
The Start URL check examines the URLs in incoming requests and blocks the connection attempt if the URL does not meet the specified criteria. To meet the criteria, the URL must match an entry in the Start URL list, unless the Enforce URL Closure parameter is enabled. If you enable this parameter, a user who clicks a link on your Web site is connected to the target of that link.
The primary purpose of the Start URL check is to prevent repeated attempts to access random URLs on a Web site, (forceful browsing) through bookmarks, external links, or jumping to pages by manually typing in the URLs to skip the pages required to reach that part of the website. Forceful browsing can be used to trigger a buffer overflow, find content that users were not intended to access directly, or find a back door into secure areas of your Web server. The Web App Firewall enforces a website’s given traversal or logic path by allowing access to only the URL’s that are configured as start URLs.
If you use the wizard or the GUI, in the Modify Start URL Check dialog box, on the General tab you can enable or disable Block, Log, Statistics, Learn actions, and the following parameters:
- Enforce URL Closure. Allow users to access any web page on your web site by clicking a hyperlink on any other page on your web site. Users can navigate to any page on your web site that can be reached from the home page or any designated start page by clicking hyperlinks. Note: The URL closure feature allows any query string to be appended to and sent with the action URL of a web form submitted by using the HTTP GET method. If your protected web sites use forms to access an SQL database, make sure that you have the SQL injection check enabled and properly configured.
- Sessionless URL Closure. From the client’s point of view, this type of URL closure functions in exactly the same way as standard, session-aware URL Closure, but uses a token embedded in the URL instead of a cookie to track the user’s activity, which consumes considerably fewer resources. When sessionless URL closure is enabled, the Web App Firewall appends a “as_url_id” tag to all the URL’s that are in URL closure. Note: When enabling sessionless (Sessionless URL Closure), you must also enable regular URL closure ( Enforce URL Closure) or sessionless URL closure does not work.
-
Validate Referer Header. Verify that the Referer header in a request that contains web form data from your protected web site instead of another web site. This action verifies that your web site, not an outside attacker, is the source of the web form. Doing so protects against cross-site request forgeries (CSRF) without requiring form tagging, which is more CPU-intensive than header checks. The Web App Firewall can handle the HTTP Referer header in one of the following four ways, depending on which option you select in the drop-down list:
- Off—Do not validate the Referer header.
- If-Present—Validate the Referer header if a Referer header exists. If an invalid Referer header is found, the request generates a referer-header violation. If no Referer header exists, the request does not generate a referer-header violation. This option enables the Web App Firewall to perform Referer header validation on requests that contain a Referer header, but not block requests from users whose browsers do not set the Referer header or who use web proxies or filters that remove that header.
- Always Except Start URLs—Always validate the Referer header. If there is no Referer header and the requested URL is not exempted by the startURL relaxation rule, the request generates a referer-header violation. If the Referer header is present but it is invalid, the request generates a referer-header violation.
- Always Except First Request—Always validate the referer header. If there is no referer header, only the URL that is accessed first is allowed. All other URL’s are blocked without a valid referer header. If the Referer header is present but it is invalid, the request generates a referer-header violation.
One Start URL setting, Exempt Closure URLs from Security Checks, is not configured in the Modify Start URL Check dialog box, but is configured in the Settings tab of the Profile. If enabled, this setting directs the Web App Firewall not to run further form based checks (such as Cross-Site Scripting and SQL Injection inspection) on URLs that meet the URL Closure criteria.
Note
Although the referer header check and Start URL security check share the same action settings, it is possible to violate the referer header check without violating the Start URL check. The difference is visible in the logs, which log referer header check violations separately from Start URL check violations.
The Referer header settings (OFF, if-Present, AlwaysExceptStartURLs, and AlwaysExceptFirstRequest) are arranged in order of least restrictive to most restrictive and work as follows:
OFF:
- Referer Header Not checked.
If-Present:
- Request has no referer header -> Request is allowed.
- Request has referer header and the referer URL is in URL closure -> Request is allowed.
- Request has referer header and the referer URL is not in URL closure -> Request is blocked.
AlwaysExceptStartURLs:
- Request has no referer header and the request URL is a start URL -> Request is allowed.
- Request has no referer header and the request URL is not a start URL ->Request is blocked.
- Request has referer header and the referer URL is in URL closure -> Request is allowed.
- Request has referer header and the referer URL is not in URL closure -> Request is blocked.
AlwaysExceptFirstRequest:
- Request has no referer header and is the first request URL of the session -> Request is allowed.
- Request has no referer header and is not the first request URL of the session -> Request is blocked.
- Request has referer header and is either the first request URL of the session or is in URL closure -> Request is allowed.
- Request has referer header and is neither the first request URL of the session nor is in URL closure -> Request is blocked.
If you use the command-line interface, you can enter the following commands to configure the Start URL Check:
set appfw profile <name> -startURLAction [block] [learn] [log] [stats] [none]set appfw profile <name> -startURLClosure ([ON] | [OFF])set appfw profile <name> -sessionlessURLClosure ([ON] | [OFF])set appfw profile <name> -exemptClosureURLsFromSecurityChecks ([ON] | [OFF)set appfw profile <name> -RefererHeaderCheck ([OFF] | [if-present] | [AlwaysExceptStartURLs] | [AlwaysExceptFirstRequest])
To specify relaxations for the Start URL check, you must use the GUI. On the Checks tab of the Modify Start URL Check dialog box, click Add to open the Add Start URL Check Relaxation dialog box, or select an existing relaxation and click Open to open the Modify Start URL Check Relaxation dialog box. Either dialog box provides the same options for configuring a relaxation.
Following are examples of Start URL check relaxations:
-
Allow users to access the home page at www.example.com:
^http://www[.]example[.]com$ <!--NeedCopy--> -
Allow users to access all static HTML (.htm and .html), server-parsed HTML (.htp and .shtml), PHP (.php), and Microsoft ASP (.asp) format web pages at www.example.com:
^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_.-]*[.](asp|htp|php|s?html?)$ <!--NeedCopy--> -
Allow users to access web pages with pathnames or file names that contain non-ASCII characters at www.example-español.com:
^http://www[.]example-espaxC3xB1ol[.]com/(([0-9A-Za-z]|x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|x[0-9A-Fa-f][0-9A-Fa-f])*/)* ([0-9A-Za-z]|x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|x[0-9A-Fa-f][0-9A-Fa-f])*[.](asp|htp|php|s?html?)$ <!--NeedCopy-->Note: In the above expression, each character class has been grouped with the string
x[0-9A-Fa-f][0-9A-Fa-f], which matches all properly-constructed character encoding strings but does not allow stray backslash characters that are not associated with a UTF-8 character encoding string. The double backslash () is an escaped backslash, which tells the Web App Firewall to interpret it as a literal backslash. If you included only one backslash, the Web App Firewall would instead interpret the following left square bracket ([) as a literal character instead of the opening of a character class, which would break the expression. -
Allow users to access all GIF (.gif), JPEG (.jpg and .jpeg), and PNG (.png) format graphics at
: ^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_.-]*[.](gif|jpe?g|png)$ <!--NeedCopy--> -
Allow users to access CGI (.cgi) and PERL (.pl) scripts, but only in the CGI-BIN directory:
^http://www[.]example[.]com/CGI-BIN/[0-9A-Za-z][0-9A-Za-z_.-]*[.](cgi|pl)$ <!--NeedCopy--> -
Allow users to access Microsoft Office and other document files in the docsarchive directory:
^http://www[.]example[.]com/docsarchive/[0-9A-Za-z][0-9A-Za-z_-.]*[.](doc|xls|pdf|ppt)$ <!--NeedCopy-->
Note
By default, all Web App Firewall URLs are considered to be regular expressions.
Caution: Regular expressions are powerful. Especially if you are not thoroughly familiar with PCRE-format regular expressions, double-check any regular expressions that you write. Make sure that they define exactly the URL you want to add as an exception, and nothing else. Careless use of wildcards, and especially of the dot-asterisk ( .*) metacharacter/wildcard combination, can have results you do not want, such as blocking access to web content that you did not intend to block or allowing an attack that the Start URL check would otherwise have blocked.
Tip
You can add the -and- to the allowed list of SQL keywords for URL naming scheme. For example, example https://FQDN/bread-and-butter.