Introduction to NetScaler Web App Firewall

The NetScaler Web App Firewall prevents security breaches, data loss, and possible unauthorized modifications to websites 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 requests 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 websites from unauthorized access, the Web App Firewall protects against vulnerabilities in legacy CGI code or scripts, web frameworks, web server software, and other underlying operating systems.

The NetScaler Web App Firewall is available as a stand-alone appliance, or as a feature on a NetScaler virtual appliance (VPX). In the Web App Firewall documentation, the term NetScaler refers to the platform on which the Web App Firewall is running, regardless of whether that platform is a dedicated firewall appliance, a NetScaler on which other features have also been configured, or a NetScaler 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 websites. The number of security configurations that you might want to create depends on the complexity of your website. Sometimes, a single configuration is sufficient. In other cases, particularly those that include interactive websites, websites 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 a 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 website 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. Websites 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 website 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 website or web server.

Certain forms of web attacks focus on obtaining private information. These attacks are often possible even against websites that are secure enough to prevent an attacker from taking full control. The information that an attacker can obtain from a website 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 serious consequences for customers whose private information is compromised. At best, these customers 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 website or the server on which it operates, or both. A hacker who gains control of a website 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 websites that are hosted on compromised web servers promote questionable or outright fraudulent businesses. For example, most phishing websites and child exploitation websites are hosted on compromised web servers.

Protecting your websites 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 websites and web services.

For more information on security check, see Overview of security checks.

Known web attacks

The first line of defense for your websites 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 websites include:

• Buffer overflow attacks. Sending a long URL, long cookie, or long information to a web server causes the system to hang, crash, or provide unauthorized 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 website directly, without navigating to the URLs with hyperlinks on the home page or other common start URLs on the website. Individual instances of forceful browsing might indicate a user who bookmarked a page on your website, but repeated attempts to access nonexistent content, or content that users must never access directly, often represent an attack on website 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 website 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 website does not expect to receive in that web form. A web form security attack can be used either to obtain unauthorized information from your website or to compromise the website 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 run 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 webpage to violate the same-origin policy, which forbids any script from obtaining properties from or modifying any content on a different website. Since scripts can obtain information and modify files on your website, allowing a script access to content on a different website 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 run 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 website traffic for specific characteristics (signatures) that always appear for a specific attack and must never appear in legitimate traffic. This approach has the advantages of requiring relatively few resources and posing relatively little risk of false positives. Therefore, it is a valuable tool in fighting attacks on websites and web services, and configuring basic signature protection.

Unknown web attacks

The greatest threat against websites 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 website or web service rather than many websites or web services (spear attacks). These attacks, like known attacks, are intended to obtain sensitive private information, compromise the website 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. Usually, they target vulnerabilities that the developers of the targeted software, website, or web service either are unaware of or have learned about. Security firms have therefore not developed defenses against these attacks, and even if they have, users have 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 websites 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 phishes, is 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 convincing. They can contain information specific to the individual that, at first look, no stranger must know or be able to obtain. The spear phisher is therefore able to convince the 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 website 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 websites, and then control how users interact with your websites, 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 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 NetScaler Web App 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. NetScaler 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 websites 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 website 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.

Note:

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

As the figure shows, when a user requests a URL on a protected website, the Web App Firewall first examines the request to ensure that it does not match a signature. If the request matches a signature, the NetScaler Web App Firewall either displays the error object (a webpage 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 website 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 NetScaler appliance (or NetScaler virtual appliance), or displays the error object. If the request passes the security checks, it is sent back to the NetScaler appliance, which completes any other processing and forwards the request to the protected web server.

When the website 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 website defacement, or other content that must not be present. If the response fails a security check, the Web App Firewall either removes the content that must not be present or blocks the response. If the response passes the security checks, it is sent back to the NetScaler appliance, which forwards it to the user.

NetScaler Web App 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 more protections.

How NetScaler Web App Firewall modifies application traffic

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

• Cookies
• HTTP Headers
• Forms/Data

NetScaler Web App Firewall session cookie

To maintain the state of the session, NetScaler Web App Firewall generates its own session cookie. This cookie is passed only between the web browser and the NetScaler Web Application Firewall and not to the web server. If a hacker tries to modify the session cookie, Web App 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 invalid. The state of the session maintains the information of the URLs and forms visited by the client.

The configurable Web App Firewall session cookie is citrix_ns_id.

Starting from NetScaler build 12.1 54 and 13.0, the cookie consistency is sessionless, and adding the session cookie citrix_ns_id generated by the appliance is not enforced. For more information on configuring cookies, see Engine settings.

NetScaler Web App Firewall cookies

Many web applications generate cookies to track user or session specific information. This information can 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 during 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 more 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 NetScaler Web App 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 following table shows the number and types of cookies generated by the Application Firewall based on the cookies generated by the web application:

NetScaler 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 HTTPs requests and HTTPs responses use headers to send information about one or more HTTPs’ 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:

Host: www.citrix.com

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 one or more HTTPs request or response to maintain the security of the application.

Request headers dropped by the NetScaler Web App Firewall

Many of the request headers related to caching is dropped 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 is inspected by the Web App 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 an 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 NetScaler Web App 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 during 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 NetScaler Web App 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 indicate that the requests are sent from the Application Firewall.

Response header dropped by the NetScaler Web App 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 a 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 webpage 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 the 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 NetScaler 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, 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.

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 by inserting the 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
+u+Svo9+NuloPhtnbkxGtNe7gB/o8GlxEcK9ZkIIVv3oIL/nIPSRWJljgpWgafzVx7wtugNwnn8/GdnhneLCJTaYU7ScnC6LexJDLisI1xsEeONWt8Zm
+vJTa3mTebDY6LVyhDpDQfBgI1XLgfLTexAUzSNWHYyloqPruGYfnRPw+DIGf6gGwn1BYLEsRHKNbjJBrKpOJo9JzhEqdtZ1g3bMzEF9PocPvM1Hpvi5T6VB
/YFunUFM4f+bD7EAVcugdhovzb71CsSQX5+qcC1B8WjQ==" />
<!--NeedCopy-->

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 and 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.

Cross-site scripting transforms action

When the transform is enabled for cross-site scripting, the Web App Firewall changes "<" into "%26lt;" and ">" into "%26gt;" in the requests. If the checkRequestHeaders setting in the Web App Firewall is enabled, then the Web App 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 is a set of default attributes and tags for cross-site scripting which the Web App Firewall allows. A default list of denied cross-site scripting patterns is also provided. These can be customized by selecting the signatures object and clicking the Manage SQL/cross-site scripting Patterns dialogue in the GUI.

Transforming SQL special characters

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

When the 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.

NetScaler Web App Firewall behavior wherein it corrupts the EXPECT header

1. Whenever NetScaler receives an HTTP request with the EXPECT header in it, NetScaler sends the EXPECT: 100 -continue response to client on behalf of the back end server.
2. This behavior is because Application Firewall protections must be run on the entire request before forwarding the request to the server, NetScaler must get the entire request from the client.
3. On receiving a 100 continue response, the 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 the EXPECT header that came in the 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.