Introduction to Citrix Web Application Firewall

The Citrix Web Web App Firewall prevents security breaches, data loss, and possible unauthorized modifications to web sites that access sensitive business or customer information. It does so by filtering both requests and responses, examining them for evidence of malicious activity, and blocking those that exhibit such activity. Your site is protected not only from common types of attacks, but also from new, as yet unknown attacks. In addition to protecting web servers and web sites from unauthorized access and misuse by hackers and malicious programs, the Web App Firewall provides protection against security vulnerabilities in legacy CGI code or scripts, other web frameworks, web server software, and the underlying operating systems.

The Citrix Web Web App Firewall is available as a stand-alone appliance, or as a feature on a Citrix ADC virtual appliance (VPX). In the Web App Firewall documentation, the term Citrix ADC refers to the platform on which the Web App Firewall is running, regardless of whether that platform is a dedicated firewall appliance, a Citrix ADC on which other features have also been configured, or a Citrix ADC VPX.

To use the Web App Firewall, you must create at least one security configuration to block connections that violate the rules that you set for your protected web sites. The number of security configurations that you might want to create depends on the complexity of your web site. In some cases, a single configuration is sufficient. In other cases, particularly those that include interactive web sites, web sites that access database servers, online stores with shopping carts, you might need several different configurations to best protect sensitive data without wasting significant effort on content that is not vulnerable to certain types of attacks. You can often leave the defaults for the global settings, which affect all security configurations, unchanged. However, you can change the global settings if they conflict with other parts of your configuration or you prefer to customize them.

Web application security

Web application security is network security for computers and programs that communicate by using the HTTP and HTTPS protocols. This is an extremely broad area in which security flaws and weaknesses abound. Operating systems on both servers and clients have security issues and are vulnerable to attack. Web server software and web site enabling technologies such as CGI, Java, JavaScript, PERL and PHP have underlying vulnerabilities. Browsers and other client applications that communicate with web-enabled applications also have vulnerabilities. Web sites that use any technology but the simplest of HTML, including any site that allows interaction with visitors, often have vulnerabilities of their own.

In the past, a breach in security was often just an annoyance, but today that is seldom the case. For example, attacks in which a hacker gained access to a web server and made unauthorized modifications to (defaced) a web site used to be common. They were usually launched by hackers who had no motivation beyond demonstrating their skills to fellow hackers or embarrassing the targeted person or company. Most current security breaches, however, are motivated by a desire for money. The majority attempt to accomplish one or both of the following goals: to obtain sensitive and potentially valuable private information, or to obtain unauthorized access to and control of a web site or web server.

Certain forms of web attacks focus on obtaining private information. These attacks are often possible even against web sites that are secure enough to prevent an attacker from taking full control. The information that an attacker can obtain from a web site can include customer names, addresses, phone numbers, social security numbers, credit card numbers, medical records, and other private information. The attacker can then use this information or sell it to others. Much of the information obtained by such attacks is protected by law, and all of it by custom and expectation. A breach of this type can have extremely serious consequences for customers whose private information is compromised. At best, these customers will have to exercise vigilance to prevent others from abusing their credit cards, opening unauthorized credit accounts in their name, or appropriating their identities outright (identity theft). At worst, the customers may face ruined credit ratings or even be blamed for criminal activities in which they had no part.

Other web attacks are aimed at obtaining control of (or compromising) a web site or the server on which it operates, or both. A hacker who gains control of a web site or server can use it to host unauthorized content, act as a proxy for content hosted on another web server, provide SMTP services to send unsolicited bulk email, or provide DNS services to support such activities on other compromised web servers. Most web sites that are hosted on compromised web servers promote questionable or outright fraudulent businesses. For example, the majority of phishing web sites and child exploitation web sites are hosted on compromised web servers.

Protecting your web sites and web services against these attacks requires a multilayered defense capable of both blocking known attacks with identifiable characteristics and protecting against unknown attacks, which can often be detected because they look different from the normal traffic to your web sites and web services.

Known web attacks

The first line of defense for your web sites is protection against the large number of attacks that are known to exist and have been observed and analyzed by web security experts. Common types of attacks against HTML-based web sites include:

  • Buffer overflow attacks. Sending an extremely long URL, extremely long cookie, or other extremely long bit of information to a web server in hopes of causing it or the underlying operating system to hang, crash, or provide the attacker with access to the underlying operating system. A buffer overflow attack can be used to gain access to unauthorized information, to compromise a web server, or both.
  • Cookie security attacks. Sending a modified cookie to a web server, usually in hopes of obtaining access to unauthorized content by using falsified credentials.
  • Forceful browsing. Accessing URLs on a web site directly, without navigating to the URLs by means of hyperlinks on the home page or other common start URLs on the web site. Individual instances of forceful browsing may simply indicate a user who bookmarked a page on your web site, but repeated attempts to access nonexistent content, or content that users should never access directly, often represent an attack on web site security. Forceful browsing is normally used to gain access to unauthorized information, but can also be combined with a buffer overflow attack in an attempt to compromise your server.
  • Web form security attacks. Sending inappropriate content to your web site in a web form. Inappropriate content can include modified hidden fields, HTML or code in a field intended for alphanumeric data only, an overly long string in a field that accepts only a short string, an alphanumeric string in a field that accepts only an integer, and a wide variety of other data that your web site does not expect to receive in that web form. A web form security attack can be used either to obtain unauthorized information from your web site or to compromise the web site outright, usually when combined with a buffer overflow attack.

Two specialized types of attacks on web form security deserve special mention:

  • SQL injection attacks. Sending an active SQL command or commands in a web form or as part of a URL, with the goal of causing an SQL database to execute the command or commands. SQL injection attacks are normally used to obtain unauthorized information.
  • Cross-site scripting attacks. Using a URL or a script on a web page to violate the same-origin policy, which forbids any script from obtaining properties from or modifying any content on a different web site. Since scripts can obtain information and modify files on your web site, allowing a script access to content on a different web site can provide an attacker the means to obtain unauthorized information, to compromise a web server, or both.

Attacks against XML-based web services normally fall into at least one of the following two categories: attempts to send inappropriate content to a web service, or attempts to breach security on a web service. Common types of attacks against XML-based web services include:

  • Malicious code or objects. XML requests that contain code or objects that can either directly obtain sensitive information or can give an attacker control of the web service or underlying server.
  • Badly-formed XML requests. XML requests that do not conform to the W3C XML specification, and that can therefore breach security on an insecure web service
  • Denial of service (DoS) attacks. XML requests that are sent repeatedly and in high volume, with the intent of overwhelming the targeted web service and denying legitimate users access to the web service.

In addition to standard XML-based attacks, XML web services and Web 2.0 sites are also vulnerable to SQL injection and cross-site scripting attacks, as described below:

  • SQL injection attacks. Sending an active SQL command or commands in an XML-based request, with the goal of causing an SQL database to execute that command or commands. As with HTML SQL injection attacks, XML SQL injection attacks are normally used to obtain unauthorized information.
  • Cross-site scripting attacks. Using a script included in an XML based application to violate the same-origin policy, which does not allow any script to obtain properties from or modify any content on a different application. Since scripts can obtain information and modify files by using your XML application, allowing a script access to content belonging to a different application can give an attacker the means to obtain unauthorized information, to compromise the application, or both

Known web attacks can usually be stopped by filtering web site traffic for specific characteristics (signatures) that always appear for a specific attack and should never appear in legitimate traffic. This approach has the advantages of requiring relatively few resources and posing relatively little risk of false positives. It is therefore a valuable tool in fighting attacks on web sites and web services, and configuring basic signature protections that intercept most known web attacks is easy to do.

Unknown web attacks

The greatest threat against web sites and applications does not come from known attacks, but from unknown attacks. Most unknown attacks fall into one of two categories: newly-launched attacks for which security firms have not yet developed an effective defense (zero-day attacks), and carefully-targeted attacks on a specific web site or web service rather than many web sites or web services (spear attacks). These attacks, like known attacks, are usually intended to obtain sensitive private information, compromise the web site or web service and allow it to be used for further attacks, or both of those goals.

Zero-day attacks are a major threat to all users. These attacks are usually of the same types as known attacks; zero-day attacks often involve injected SQL, a cross-site script, a cross-site request forgery, or another type of attack similar to known attacks. In most cases, they target vulnerabilities that the developers of the targeted software, web site, or web service either are unaware of or have just learned about. Security firms have therefore usually not developed defenses against these attacks, and even if they have, users have usually not obtained and installed the patches or performed the workarounds necessary to protect against these attacks. The time between discovery of a zero-day attack and availability of a defense (the vulnerability window) is shrinking, but perpetrators can still count on hours or even days in which many web sites and web services lack any specific protection against the attack.

Spear attacks are a major threat, but to a more select group of users. A common type of spear attack, a spear phish, is usually targeted at customers of a specific bank or financial institution, or (less commonly) at employees of a specific company or organization. Unlike other phishes, which are often crudely written forgeries that a user with any familiarity with the actual communications of that bank or financial institution can recognize, spear phishes are letter perfect and extremely convincing. They can contain information specific to the individual that, at first look, no stranger should know or be able to obtain. The spear phisher is therefore able to convince his or her target to provide the requested information, which the phisher can then use to loot accounts, to process illegitimately obtained money from other sources, or to gain access to other, even more sensitive information.

Both of these types of attack have certain characteristics that can usually be detected, although not by using static patterns that look for specific characteristics, as do standard signatures. Detecting these types of attacks requires more sophisticated and more resource-intensive approaches, such as heuristic filtering and positive security model systems. Heuristic filtering looks, not for specific patterns, but for patterns of behaviors. Positive security model systems model the normal behavior of the web site or web service that they are protecting, and then block connections that do not fit within that model of normal use. URL based and web-form based security checks profile normal use of your web sites, and then control how users interact with your web sites, using both heuristics and positive security to block anomalous or unexpected traffic. Both heuristic and positive security, properly designed and deployed, can catch most attacks that signatures miss. However, they require considerably more resources than do signatures, and you must spend some time configuring them properly to avoid false positives. They are therefore usually used, not as the primary line of defense, but as backups to signatures or other less resource-intensive approaches.

By configuring these advanced protections in addition to signatures, you create a hybrid security model, which enables the Web App Firewall to provide comprehensive protection against both known and unknown attacks.

How Citrix Web Application Firewall works

When you install the Web App Firewall, you create an initial security configuration, which consists of a policy, a profile, and a signatures object. The policy is a rule that identifies the traffic to be filtered, and the profile identifies the patterns and types of behavior to allow or block when the traffic is filtered. The simplest patterns, which are called signatures, are not specified within the profile, but in a signatures object that is associated with the profile.

A signature is a string or pattern that matches a known type of attack. The Web App Firewall contains over a thousand signatures in seven categories, each directed at attacks on specific types of web servers and web content. Citrix updates the list with new signatures as new threats are identified. During configuration, you specify the signature categories that are appropriate for the web servers and content that you need to protect. Signatures provide good basic protection with low processing overhead. If your applications have special vulnerabilities or you detect an attack against them for which no signature exists, you can add your own signatures.

The more advanced protections are called security checks. A security check is a more rigorous, algorithmic inspection of a request for specific patterns or types of behavior that might indicate an attack or constitute a threat to your protected web sites and web services. It can, for example, identify a request that attempts to perform a certain type of operation that might breach security, or a response that includes sensitive private information such as a social security number or credit card number. During configuration, you specify the security checks that are appropriate for the web servers and content that you need to protect. The security checks are restrictive. Many of them can block legitimate requests and responses if you do not add the appropriate exceptions (relaxations) when configuring them. Identifying the needed exceptions is not difficult if you use the adaptive learning feature, which observes normal use of your web site and creates recommended exceptions.

The Web App Firewall can be installed as either a Layer 3 network device or a Layer 2 network bridge between your servers and your users, usually behind your company’s router or firewall. It must be installed in a location where it can intercept traffic between the web servers that you want to protect and the hub or switch through which users access those web servers. You then configure the network to send requests to the Web App Firewall instead of directly to your web servers, and responses to the Web App Firewall instead of directly to your users. The Web App Firewall filters that traffic before forwarding it to its final destination, using both its internal rule set and your additions and modifications. It blocks or renders harmless any activity that it detects as harmful, and then forwards the remaining traffic to the web server. The following figure provides an overview of the filtering process.


The figure omits the application of a policy to incoming traffic. It illustrates a security configuration in which the policy is to process all requests. Also, in this configuration, a signatures object has been configured and associated with the profile, and security checks have been configured in the profile.

Figure 1. A Flowchart of Web App Firewall Filtering

Web App Firewall Flowchart

As the figure shows, when a user requests a URL on a protected web site, the Web App Firewall first examines the request to ensure that it does not match a signature. If the request matches a signature, the Citrix Web Application Firewall either displays the error object (a web page that is located on the Web App Firewall appliance and which you can configure by using the imports feature) or forwards the request to the designated error URL (the error page). Signatures do not require as many resources as do security checks, so detecting and stopping attacks that are detected by a signature before running any of the security checks reduces the load on the server.

If a request passes signature inspection, the Web App Firewall applies the request security checks that have been enabled. The request security checks verify that the request is appropriate for your web site or web service and does not contain material that might pose a threat. For example, security checks examine the request for signs indicating that it might be of an unexpected type, request unexpected content, or contain unexpected and possibly malicious web form data, SQL commands, or scripts. If the request fails a security check, the Web App Firewall either sanitizes the request and then sends it back to the Citrix ADC appliance (or Citrix ADC virtual appliance), or displays the error object. If the request passes the security checks, it is sent back to the Citrix ADC appliance, which completes any other processing and forwards the request to the protected web server.

When the web site or web service sends a response to the user, the Web App Firewall applies the response security checks that have been enabled. The response security checks examine the response for leaks of sensitive private information, signs of web site defacement, or other content that should not be present. If the response fails a security check, the Web App Firewall either removes the content that should not be present or blocks the response. If the response passes the security checks, it is sent back to the Citrix ADC appliance, which forwards it to the user.

Citrix Web Application Firewall features

The basic Web App Firewall features are policies, profiles, and signatures, which provide a hybrid security model as described in Known Web Attacks, Unknown Web Attacks, and How the Web App Firewall Works. Of special note is the learning feature, which observes traffic to your protected applications and recommends appropriate configuration settings for certain security checks.

The imports feature manages files that you upload to the Web App Firewall. These files are then used by the Web App Firewall in various security checks, or when responding to a connection that matches a security check.

You can use the logs, statistics, and reports features to evaluate the performance of the Web App Firewall and identify possible needs for additional protections.

How Citrix Web Application Firewall modifies application traffic

The Citrix Web Application Firewall affects the behavior of a web application it protects by modifying the following:

  • Cookies
  • HTTP Headers
  • Forms/Data

To maintain the state of the session, Citrix ADC Web App Firewall generates its own session cookie. This cookie is passed only between the web browser and the Citrix ADC Web Application Firewall and not to the web server. If any hacker tries to modify the session cookie, the Application Firewall drops the cookie before forwarding the request to the server and treats the request as a new user session. The session cookie is present as long as the web browser is open. When the web browser is closed, the Application Firewall session cookie becomes longer valid.

The configurable Web App Firewall session cookie is citrix_ns_id.

Citrix Web App Firewall cookies

Many web applications generate cookies to track user or session specific information. This information could be user preferences or shopping cart items. A web application cookie can be one of the following two types:

  • Persistent Cookies - These cookies are stored locally on the computer and used again the next time you visit the site. This type of cookie usually contains information about the user, such as, logon, password, or preferences.
  • Session or Transient Cookies - These cookies are used only for the duration of the session and are destroyed after the session is terminated. This type of cookie contains application state information, such as, shopping cart items or session credentials.

Hackers can attempt to modify or steal application cookies to hijack a user session or masquerade as a user. The Application Firewall prevents such attempts by hashing the application cookies and then adding additional cookies with the digital signatures. By tracking the cookies, the Application Firewall ensures that the cookies are not modified or compromised between the client browser and the Application Firewall. The Application Firewall does not modify the application cookies.

The Citrix Web Application Firewall generates the following default cookies to track the application cookies:

  • Persistent Cookies: citrix_ns_id_wlf. Note: wlf stands for will live forever.
  • Session or Transient Cookies: citrix_ns_id_wat. Note: wat stands for will act transiently. To track the application cookies, the Application Firewall groups the persistent or session application cookies together and then hash and sign all the cookies together. Thus, the Application Firewall generates one wlf cookie to track all persistent application cookies and one wat cookie to track all application session cookies.

The Web App Firewall always generate an Application Firewall session cookie regardless of whether the web application generates any cookie.

The following table shows the number and types of cookies generated by the Application Firewall based on the cookies generated by the web application:

Before Citrix ADC Web App Firewall To
No cookies Session cookie: citrix_ns_id
One persistent cookie Session cookie: citrix_ns_id
Two persistent cookies Two original persistent cookie from the application.Session cookie: citrix_ns_id, Persistent cookie: citrix_ns_id_wlf
One persistent cookie, One transient cookie One original persistent cookie from the application. One original session cookie from the application. Session cookie: citrix_ns_id, Persistent cookie: citrix_ns_id_wlf, Transient cookie: citix_ns_id_wat

Citrix Web App Firewall allows encrypting the application cookie. Application Firewall also provides an option to proxy the session cookie sent by the application, by storing it with the rest of the Application Firewall session data and not sending it to the client. When a client sends a request to the application that includes an Application Firewall session cookie, Application Firewall inserts the application sent cookie back into the request before sending the request on to the origin application. Application Firewall also allows adding the HTTPOnly and/or Secure flags to cookies.

How the application firewall affects HTTP headers

Both HTTP(s) requests and HTTP(s) responses use headers to send information about the HTTP(s) message. A header is a series of lines with each line containing a name followed by a colon and a space, and a value. For example, the Host header has the following format:


Some header fields are used in both request and response headers, while others are appropriate only for either a request or a response. The Application Firewall might add, modify, or delete some headers in the HTTP(s) request or response to maintain the security of the application.

Request headers dropped by the Citrix Web Application Firewall

Many of the request headers related to caching might be dropped by Application Firewall in order to view every request within the context of a session. Similarly, if the request includes an encoding header to allow the web server to send compressed responses, the Application Firewall deletes this header so the contents in the uncompressed server response can be inspected by Application Firewall to prevent any leakage of sensitive data to the client.

The Application Firewall drops the following request headers:

  • Range – Used to recover from a failed or partial file transfers.
  • If-Range – Allows a client to retrieve a partial object when it contains a part of that object in its cache already (conditional GET).
  • If-Modified-Since – If the requested object is not modified since the time specified in this field, an entity is not returned from the server. You get a HTTP 304 not modified error.
  • If-None-Match – Allows efficient updates of cached information with a minimum amount of overhead.
  • Accept-Encoding – What encoding methods are allowed for a particular object, such as gzip.

Request header modified by the Citrix Web Application Firewall

If a web browser uses the HTTP/1.0 or earlier protocols, the browser continually opens and closes the TCP socket connection after receiving each response. This adds overhead to the web server and prevents maintaining session state. The HTTP/1.1 protocol allows the connection to remain open for the duration of the session. The Application Firewall modifies the following request header to use HTTP/1.1 between the Application Firewall and the web server regardless of the protocol used by the web browser: Connection: keep-alive

Request headers added by the Citrix Web Application Firewall

The Application Firewall acts as a reverse proxy and replaces the original source IP address of the session with the IP address of the Application Firewall. Therefore, all requests logged in the web server log indicates that the requests are sent from the Application Firewall.

Response header dropped by the Citrix Web Application Firewall

The Application Firewall might block or modify content such as removing credit card numbers or stripping comments, and this might result in a mismatch in size. To prevent such scenario, the Application Firewall drops the following header:

Content-Length – Indicates the size of the message sent to the recipient. Response Headers Modified by the Application Firewall

Many of the response headers modified by the Application Firewall are related to caching. Caching headers in HTTP(S) responses must be modified to force the web browser to always send a request to the web server for the latest data and not use the local cache. However, some ASP applications use separate plug-ins to display dynamic contents and might require the ability to cache the data temporarily in the browser. To allow temporary caching of data when Advanced Security protections such as FFC, URL closure, or CSRF checks are enabled, Application Firewall adds or modifies the cache-control headers in the server response using the following logic:

  • If Server sends Pragma:no-cache, then the Application Firewall does not do any modification.
  • If Client Request is HTTP 1.0, then Application Firewall inserts Pragma:no-cache.
  • If Client Request is HTTP 1.1 and has Cache-control: no-store, then Application Firewall does not make any modification.
  • If Client Request is HTTP 1.1 and Server Response has Cache-Control header with no store or no cache directive, then Application Firewall does not make any modification.

  • If Client Request is HTTP 1.1 and Server Response has either No Cache-control Header or Cache-Control header does not have no store or no-cache directive, the Application Firewall completes the following tasks:
  1. Inserts Cache-control: max-age=3, must-revalidate,private.
  2. Inserts X-Cache-Control-orig = Original value of Cache-Control Header.
  3. Deletes Last-Modified header.
  4. Replaces Etag.
  5. Inserts X-Expires-Orig=Original value of the Expire Header sent by the server.
  6. Modifies the Expires Header and sets the expiration date of the web page to the past, so it is always picked up again.
  7. Modifies Accept-Ranges and sets it to none.

To replace temporarily cached data in client browser when Application Firewall changes the response such as, for StripComments, X-out/Remove SafeObject, xout or remove Credit Card or URL Transform, Application Firewall takes the following actions:

  1. Deletes Last-Modified from server before forwarding to client.
  2. Replaces Etag with a value determined by Application Firewall.

Response headers added by the Citrix Web App Firewall

  • Transfer-Encoding: Chunked. This header streams information back to a client without having to know the total length of the response before sending the response. This header is required because the content-length header is removed.
  • Set-Cookie: The cookies added by the Application Firewall.
  • Xet-Cookie: If the session is valid and if the response is not expired in cache, then you can serve from cache and do not have to send a new cookie because the session is still valid. In such a scenario, the Set-Cookie is changed to Xet-Cookie. For the web browser, Xet-Cookie is similar to any other custom header.

How form data is affected

The Application Firewall protects against attacks that attempt to modify the content of the original form sent by the server. It can also protect against Cross-site Request forgery attacks. The Application Firewall accomplishes this by inserting hidden form tag as_fid in the page.

Example: <input type="hidden" name="as_fid" value="VRgWq0I196Jmg/+LOY7C" />

The hidden field as_fid is used for field consistency. This field is used by Application Firewall to track all fields of the form including the hidden field name/value pairs and to ensure that none of the fields of the form sent by the server are changed on the client side. The CSRF check also uses this unique form tag as_fid to ensure that the forms submitted by the user were served to the user in this session and no hacker is attempting to hijack the user session.

Sessionless form check

Application Firewall also offers an option to protect form data using sessionless field consistency. This is useful for applications where the forms might have large number of dynamic hidden fields that lead to high memory allocation per session by the Application Firewall. The sessionless field consistency check is accomplished by inserting another hidden field as_ffc_field for only POST requests or for both GET and POST requests based on the configured setting. The Application Firewall changes the method GET to POST when it forwards the form to the client. The appliance then reverts the method to GET when submitting it back to the server. The as_ffc_field value can be large because it contains the encrypted digest of the form being served. The following is an example of the sessionless form check:

<input type="hidden" name="as_ffc_field" value="CwAAAAVIGLD/luRRi1Wu1rbYrFYargEDcO5xVAxsEnMP1megXuQfiDTGbwk0fpgndMHqfMbzfAFdjwR+TOm1oT
/YFunUFM4f+bD7EAVcugdhovzb71CsSQX5+qcC1B8WjQ==" />

HTML comment stripping

The Application Firewall also offers an option to strip all HTML comments in the responses before sending them to the client. This affects not only forms, but all response pages. The Application Firewall locates and removes any text embedded between “<!-“ and “->” comment tags. The tags remain to indicate that a comment existed in that location of the HTML source code. Any text embedded within any other HTML or JavaScript tags is ignored. Some applications might not work correctly if they have JavaScript incorrectly embedded within comment tags. A comparison of the page source code before and after the comments were stripped by Application Firewall can help in identifying if any of the stripped comments had the required JavaScript embedded in them.

Credit card protection

The Application Firewall offers an option to inspect the headers as well as body of the response and either removes or x-outs the Credit Card numbers before forwarding the response to the client. Currently Application Firewall offers protection for the following major credit cards: American Express, Diners Club, Discover, JCB, MasterCard, and Visa. The x-out action works independent of the Block action.

Safe object protection

Similar to Credit Card numbers, leakage of other sensitive data can also be prevented by using Application Firewall Safe Object security check to either remove or x-out the sensitive content in the response.

XSS transform action

When the transform is enabled for XSS, Application Firewall changes "<" into "%26lt;" and ">" into "%26gt;" in the requests. If the checkRequestHeaders setting in Application Firewall is enabled, then the Application Firewall inspects the Request Headers and transforms these characters in Header and cookies also. The transform action does not block or transform values that were originally sent by the server. There are a set of default attributes and tags for XSS which are allowed by Application Firewall. A default list of denied XSS patterns is also provided. These can be customized by selecting the signatures object and clicking on the Manage SQL/XSS Patterns dialogue in Graphical User Interface.

Transforming SQL special characters

Application Firewall has the following default transformation rules for SQL special characters:

From To Transformation
’ (single quote that is, %27) Another single quote
\ (backslash that is %5C) |Another backslash added  
; (semicolon that is %3B)   Dropped

When transformation of special characters is enabled and the checkRequestHeaders is set to ON, then the transformation of special characters happens in Headers and cookies also. Note: Some request headers such as User-Agent, Accept-Encoding usually contain semicolons and might be impacted by SQL transformation.

Cirix Web Application Firewall behavior wherein it corrupts EXPECT header

  1. Whenever NetScaler receives HTTP request with EXPECT header in it, NetScaler sends EXPECT: 100 -continue response to client on behalf of the back end server.
  2. This behavior is because Application Firewall protections need to be run on entire request before forwarding the request to the server, NetScaler needs to get the entire request from client.
  3. On reception of 100 -continue response, client sends the remaining portion of request that completes the request.
  4. NetScaler then runs all the protections and then forwards the request to the server.
  5. Now as NetScaler is forwarding the complete request EXPECT header that came in initial request becomes obsolete as a result NetScaler corrupts this header and sends it to the server.
  6. Server on receiving the request ignores any header which is corrupted.