Signatures

The Web App Firewall signatures function provides specific, configurable rules to simplify the task of protecting your web sites against known attacks. A signature represents a pattern that is a component of a known attack on an operating system, web server, website, XML-based web service, or other resource.  A rich set of preconfigured Web App Firewall built-in or Native rules offers an easy to use security solution, leveraging the power of pattern matching to detect attacks and protect against application vulnerabilities.  

You can create your own signatures or use the signatures in the built-in templates. The Web App Firewall has two built-in templates:

• Default Signatures: This template contains a preconfigured list of over 1,300 signatures, in addition to a complete list of SQL injection keywords, SQL special strings, SQL transform rules, and SQL wildchar characters. It also contains denied patterns for cross-site scripting, and allowed attributes and tags for cross-site scripting. This is a read-only template. You can view the contents, but you cannot add, edit, or delete anything in this template. To use it, you must make a copy. In your own copy, you can enable the signature rules that you want to apply to your traffic, and specify the actions to be taken when the signature rules match the traffic.

The Web App Firewall signatures are derived from the rules published by Snort, which is an open source intrusion prevention system capable of performing real-time traffic analysis to detect a variety of attacks and probes.

• *Xpath Injection Patterns: This template contains a preconfigured set of literal and PCRE keywords and special strings that are used to detect XPath (XML Path Language) injection attacks.

Blank Signatures: In addition to making a copy of the built-in *Default Signatures template, you can use a blank signatures template to create a new signature object. The signature object that you create with the blank signatures option does not have any native signature rules, but, just like the *Default template, it has all the SQL/XSS built-in entities.

External-Format Signatures: The Web App Firewall also supports the use of external format signatures. You can import the scan files of the third party scan tools by using the XSLT files that are supported by the Citrix Web App Firewall. A set of built-in XSLT files are available for the following scan tools to translate these external format files to the Native format:

• Cenzic
• Deep Security for Web Apps
• IBM AppScan Enterprise
• IBM AppScan Standard.
• Qualys
• Whitehat
• Hewlett Packard Enterprise WebInspect

Protection options for your application

Tighter security increases processing overhead. Signatures provide the following deployment options to help you to optimize the protection of your applications:

• Negative Security Model: With the negative security model, you use a rich set of preconfigured signature rules to leverage the power of pattern matching to detect attacks and protect against application vulnerabilities. You block only what you don’t want and allow the rest.[DR1]   You can add your own signature rules, based on the specific security needs of your applications, to design your own customized security solutions.

• Hybrid security Model: In addition to using signatures, you can use positive security checks to create a configuration ideally suited for your applications. Use signatures to block what you don’t want, and use positive security checks to enforce what is allowed.

To protect your application by using signatures, you must configure one or more profiles to use your signatures object. In a hybrid security configuration, the SQL injection and Cross-Site scripting patterns, and the SQL transformation rules, in your signatures object are used not only by the signature rules, but also by the positive security checks configured in the Web App Firewall profile that is using the signatures object.

The Web App Firewall examines the traffic to your protected web sites and web services to detect traffic that matches a signature. A match is triggered only when every pattern in the rule matches the traffic. When a match occurs, the specified actions for the rule are invoked. You can display an error page or error object when a request is blocked. Log messages can help you to identify attacks being launched against your application. If you enable statistics, the Web App Firewall maintains data about requests that match an Web App Firewall signature or security check.

If the traffic matches both a signature and a positive security check, the more restrictive of the two actions is enforced. For example, if a request matches a signature rule for which the block action is disabled, but the request also matches an SQL Injection positive security check for which the action is block, the request is blocked. In this case, the signature violation might be logged as <not blocked>, although the request is blocked by the SQL injection check.

Customization: If necessary, you can add your own rules to a signatures object. You can also customize the SQL/XSS patterns. The option to add your own signature rules, based on the specific security needs of your applications, gives you the flexibility to design your own customized security solutions. You block only what you don’t want and allow the rest. A specific fast-match pattern in a specified location can significantly reduce processing overhead to optimize performance. You can add, modify, or remove SQL injection and cross-site scripting patterns. Built-in RegEx and expression editors help you configure your patterns and verify their accuracy.

Auto-update: You can manually update the signature object to get the latest signature rules, or you can leverage the auto-update feature so that the Web App Firewall can automatically update the signatures from the cloud-based Web App Firewall updates service.

Note

If new signature rules are added during auto-update, they are disabled by default. You should periodically review the updated signatures and enable the newly added rules that are pertinent for protecting your applications.

You must configure CORS to host signatures on IIS servers.

Getting started

Using Citrix signatures to protect your application is quite easy and can be accomplished in a few simple steps:

1. Add a signature object.

• You can use the Wizard that prompts you to create the entire Web App Firewall configuration, including adding the profile and policy, selecting and enabling signatures, and specifying actions for signatures and positive security checks.  The signatures object is created automatically.
• You can create a copy of the signatures object from the *Default Signatures template, use a blank template to create a new signature with your own customized rules, or add an external format signature. Enable the rules and configure the actions that you want to apply.

2. Configure the target Web App Firewall profile to use this signatures object.

3. Send traffic to validate the functionality

Highlights

• The *Default signatures object is a template. It cannot be edited or deleted. To use it, you must create a copy. In your own copy, you can enable the rules and the desired action for each rule as required for your application. To protect the application, you must configure the target profile to use this signature.
• Processing signature patterns has overhead. Try to enable only those signatures that are applicable for protecting your application, rather than enabling all signature rules.  
• Every pattern in the rule must match to trigger a signature match.
• You can add your own customized rules to inspect incoming requests to detect various types of attacks, such as SQL injection or cross-site scripting attacks. You can also add rules to inspect the responses to detect and block leakage of sensitive information such as credit card numbers.
• You can make a copy of an existing signatures object and tweak it, by adding or editing rules and SQL/XSS patterns, to protect another application.
• You can use auto-update to download the latest version of the Web App Firewall default rules without need for ongoing monitoring to check for the availability of the new update.
• A signature object can be used by more than one profile. Even after you have configured one or more profile(s) to use a signature object, you can still enable or disable signatures or change the action settings. You can manually create and modify your own custom signature rules. The changes will apply to all the profiles that are currently configured to use this signature object.
• You can configure signatures to detect violations in various types of payloads, such as HTML, XML, JSON, and GWT.
• You can export a configured signatures object  and import it to another Citrix ADC appliance for easy replication of your customized signature rules.

Signatures are patterns that are associated with a known vulnerability. You can use signature protection to identify the traffic that attempts to exploit these vulnerabilities, and take specific actions.

Signatures are organized into categories. You can optimize the performance and reduce the processing overhead by enabling only the rules in the categories that are appropriate for protecting your application.