Attack signatures are rules or patterns that identify attacks on a web application. When Application Security Manager™ (ASM) receives a client request (or a server response), the system compares the request or response against the attack signatures associated with your security policy. If a matching pattern is detected, ASM™ triggers an Attack signature detected violation, and either alarms or blocks based on the enforcement mode of your security policy.
For example, the SQL injection attack signature looks for certain expressions like ' or 1=1, and if a user enters that string into a field (such as the username field) on your web application, ASM can block the request based on the SQL injection attempt.
An ideal security policy includes only the attack signatures needed to defend your application. If too many are included, you waste resources on keeping up with signatures that you do not need. Likewise, if you do not include enough, you might let an attack compromise your application without knowing it. If you are in doubt about a certain signature set, it is a good idea to include it in the policy rather than omitting it.
ASM provides over 2,500 attack signatures that are designed to guard against many different types of attacks and protect networking elements such as operating systems, web servers, databases, frameworks, and applications. Updates are provided periodically.
You can also create custom signatures, if needed, to secure your application. Additionally, you can create signatures to protect specific alphanumeric user-input parameters.
All of the attack signatures are organized into sets and are stored in the attack signature pool on ASM. If you know what systems your application is built on (Windows, SQL, IIS, UNIX/Linux, Apache, and so on), you can allow the system to choose the appropriate attack signatures to include in the security policy.
When you first activate a security policy, the system puts the attack signatures into staging (if staging is enabled for the security policy). Staging means that the system applies the attack signatures to the web application traffic, but does not apply the blocking policy action to requests that trigger those attack signatures. The default staging period is seven days.
Whenever you add or change signatures in assigned sets, those are also put into staging. You also have the option of putting updated signatures in staging.
Placing new and updated attack signatures in staging helps to reduce the number of violations triggered by false-positive matches. When signatures match attack patterns during the staging period, the system generates learning suggestions. From Manual Traffic Learning, if you see that an attack signature violation has occurred, you can view these attack signatures from the Attack Signature Detected screen.
Upon evaluation, if the signature is a false-positive, you can disable the signature, and the system no longer applies that signature to traffic for the corresponding web application. Alternately, if the detected signature match is legitimate, you can enable the corresponding attack signature. Note that enabling the signature removes it from staging, and puts the blocking policy into effect.
Attack signatures in a security policy are compared with requests or responses to attempt to identify classes of attacks, for example, SQL injection, command injection, cross-site scripting, and directory traversal. The following table describes the types of attacks that attack signatures can detect. You can filter lists of attack signatures by these attack types.
|Abuse of Functionality||Uses a web site's own features and functionality to consume, defraud, or circumvent the application’s access control mechanisms.|
|Authentication/Authorization Attacks||Targets a web site's method of validating the identity of a user, service or application. Authorization attacks target a web site's method of determining if a user, service, or application has the necessary permissions to perform a requested action.|
|Buffer Overflow||Alters the flow on an application by overwriting parts of memory. An attacker could trigger a buffer overflow by sending a large amount of unexpected data to a vulnerable component of the web server.|
|Command Execution||Occurs when an attacker manipulates the data in a user-input field, by submitting commands that could alter the web page content or web application by running a shell command on a remote server to reveal sensitive data-for example, a list of users on a server.|
|Cross-site Scripting (XSS)||Forces a web site to echo attacker-supplied executable code, which loads in a user's browser.|
|Denial of Service||Overwhelms system resources to prevent a web site from serving normal user activity.|
|Detection Evasion||Attempts to disguise or hide an attack to avoid detection by an attack signature.|
|Directory Indexing||Involves a web server function that lists all of the files within a requested directory if the normal base file is not present.|
|HTTP Response Splitting||Pertains to an attempt to deliver a malicious response payload to an application user.|
|Information Leakage||Occurs when a web site reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system.|
|LDAP Injection||Concerns an attempt to exploit web sites that construct LDAP statements from user-supplied input.|
|Non-browser Client||Relates to an attempt by automated client access to obtain sensitive information. HTML comments, error messages, source code, or accessible files may contain sensitive information.|
|Other Application Attacks||Represents attacks that do not fit into the more explicit attack classifications, including email injection, HTTP header injection, attempts to access local files, potential worm attacks, CDATA injection, and session fixation.|
|Path Traversal||Forces access to files, directories, and commands that potentially reside outside the web document root directory.|
|Predictable Resource Location||Attempts to uncover hidden web site content and functionality.|
|Remote File Include||Occurs as a result of unclassified application attacks such as when applications use parameters to pass URLs between pages.|
|Server Side Code Injection||Attempts to exploit the server and allow an attacker to send code to a web application, which the web server runs locally.|
|SQL-Injection||Attempts to exploit web sites that construct SQL statements from user-supplied input.|
|Trojan/Backdoor/Spyware||Tries to circumvent a web server’s or web application’s built-in security by masking the attack within a legitimate communication. For example, an attacker may include an attack in an email or Microsoft® Word document, and when a user opens the email or document, the attack starts.|
|Vulnerability Scan||Uses an automated security program to probe a web application for software vulnerabilities.|
|XPath Injection||Occurs when an attempt is made to inject XPath queries into the vulnerable web application.|
The following table describes the attack signature properties, listed on the Attack Signature Properties screen, that you can view for more information about the signatures in the pool.
|Name||Displays the signature name.|
|ID||Specifies the signature number automatically provided by the system.|
|Signature Type||Specifies whether the signatures are for all traffic, for requests only, or for responses only.|
|Apply To||Indicates whether the rule inspects the client’s request (Request) or the server’s response (Response).|
|Attack Type||Forces a web site to echo attacker-supplied executable code, which loads in a user's browser.|
|Systems||Displays which systems (for example, web applications, web server databases, or application frameworks) the signature or set protects.|
|Accuracy||Indicates the ability of the attack signature to identify the attack including
susceptibility to false-positive alarms:
|Risk||Indicates the level of potential damage this attack might cause if it is
|User-defined||Indicates whether this signature is a system supplied rule (No) or was defined by a user (Yes).|
|Revision||Indicates the version of the attack signature.|
|Last Updated||Indicates the date when the attack signature was most recently updated.|
|Documentation||Indicates whether the system provides documentation explaining this attack signature (View) or not (N/A). Click the View link to display the available documentation.|
|References||Displays a clickable link to an external web site explaining this attack signature, or displays (N/A) if no link is available.|
You can create attack signature sets in two ways: by using a filter or by manually selecting the signatures to include.
Filter-based signature sets are based solely on criteria you define in the signatures filter. The advantage to filter-based signature sets is that you can focus on the criteria that define the attack signatures you are interested in, rather than trying to manage a specific list of attack signatures. Another advantage to filter-based sets is that when you update the attack signatures database, the system also updates any signature sets affected by the update.
When manually creating a signature set, you must select each of the signatures to include from the signature pool. To simplify using this method, you can still filter the signatures first, then select the individual signatures from the filtered list.
Once you create the attack signature sets that you need, you can assign them to security policies.
An attack signature set is a group of attack signatures. Rather than applying individual attack signatures to a security policy, you can apply one or more attack signature sets. The Application Security Manager™ ships with several system-supplied signature sets.
Each security policy has its own attack signature set assignments. By default, a generic signature set is assigned to new security policies. You can assign additional signature sets to the security policy. Certain sets are more applicable to certain types of applications or types of attack. The sets are named logically so you can tell which ones to choose. Additionally, you can create your own attack signature sets.
The following table lists the attack signature sets included with Application Security Manager™.
|Signature Set||Contains These Signatures|
|All Response Signatures||All signatures in the attack signature pool that can review responses.|
|All Signatures||All attack signatures in the attack signature pool.|
|Generic Detection Signatures||Signatures that target well-known or common web and application attacks.|
|High Accuracy Signatures||Signatures with a high level of accuracy that produce few false positives when identifying attacks.|
|Low Accuracy Signatures||Signatures that may result in more false positives when identifying attacks.|
|Medium Accuracy Signatures||Signatures with a medium level of accuracy when identifying attacks.|
|OWA Signatures||Signatures that target attacks against the Microsoft Outlook Web Access (OWA) application.|
|WebSphere Signatures||Signatures that target attacks on many computing platforms that are integrated using WebSphere including general database, Microsoft Windows, IIS, Microsoft SQL Server, Apache, Oracle, Unix/Linux, IBM DB2, PostgreSQL, and XML.|
|Command Execution Signatures||Signatures involving attacks perpetrated by executing commands.|
|Cross Site Scripting Signatures||Signatures that target attacks caused by cross-site scripting techniques which force a user to execute unwanted actions in a web application where the user is currently authenticated.|
|HTTP Response Splitting Signatures||Signatures targeting attacks that take advantage of responses for which input values have not been sanitized|
|OS Command Injection Signatures||Signatures targeting attacks that attempt to run system level commands through a vulnerable application.|
|Path Traversal Signatures||Signatures targeting attacks that attempt to access files and directories that are stored outside the web root folder.|
|SQL Injection Signatures||Signatures targeting attacks that attempt to insert (inject) a SQL query using the input data from a client to an application.|
|Server Side Code Injection Signatures||Signatures that target code injection attacks on the server side.|
|XPath Injection Signatures||Signatures targeting attacks that attempt to gain access to data structures or bypass permissions or access when a web site uses user-supplied information to construct XPath queries for XML data.|
|Filter-based||To create a signature set by using a filter only.|
|Manual||To create a signature set by selecting signatures from the signature pool, and optionally a filter as well.|
|Filter Option||What It Does|
|Signature ID||Manual only. Leave blank unless you want to include a signature with a specific ID number in the signature set.|
|Signature Type||Select to include signatures that apply to all traffic, requests only, or responses only.|
|Apply To||Manual only. Select whether to include in the set all signatures or only signatures that apply to alpha-numeric user-input parameters defined in the security policy, XML documents, or JSON data.|
|Attack Type||Select the threat classifications for which to include signatures in the set.|
|Systems||Select the systems (for example web applications, web server databases, and application frameworks) that you want protected by the set.|
|Accuracy||Select the level of accuracy you want for the signatures in the set. Higher accuracy results in fewer false positives.|
|Risk||Select the level of potential damage for attacks protected by the signatures in the set.|
|User-defined||Specify whether to include signatures based on who created them (the user, system, or both).|
|Update Date||Specify whether to include signatures in the set based on the date the signature was changed.|
When signature staging is enabled, the system places new or updated signatures in staging for the number of days specified in the enforcement readiness period. The system does not enforce signatures that are in staging, even if it detects a violation. Instead, the system records the request information.
If staging is disabled, attack signatures are not put into staging before they are enforced, regardless of the staging configuration for each individual signature. The system enforces the Learn, Alarm, and Block settings for each signature immediately. New signatures are always placed in staging even if the signature settings are disabled.
If staging is disabled for a specific signature or group of signatures, those signatures are also enforced according to the blocking settings. (If traffic causes an attack signature violation, it is blocked only if the security policy’s enforcement mode is Blocking.)