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:

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

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:

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:

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.

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.

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.

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.

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.

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.