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.
Custom attack signatures are those that your organization creates and adds to the attack signature pool. Custom attack signatures must adhere to a specific rule syntax. They are never updated by F5 Networks. All user-defined signatures are carried forward as-is when the system is updated to a new software version.
You can develop custom attack signatures, if needed, for specific purposes in your environment. The signatures that you define are stored in the attack signatures pool along with the system-supplied signatures. You can also export and import custom signatures to and from other Application Security Manager™ systems.
This example describes an attack signature that blocks attempts to access the management interface, which is located at http://example.com/manage/. The web server is IIS, and the signature ignores URL case, treating manage the same as MaNAGE.
The following example attack signature examines the URL part (without the query string) and is not case-sensitive. The signature does not need to use a regular expression, because it needs to match only one pattern (manage):
uricontent:"/manage/"; nocase; objonly;
This signature can detect URLs that contain /manage/ (the nocase modifier causes it to be not case-sensitive so that it also catches /mAnage/, for example). The signature catches, for example: http://example.com/portal/manage/panel/index.php.
This signature also catches a request that contains:
It does not catch:
In the example, %2f is URL-encoded in place of / because the query string part cannot include an explicit forward slash.
This example describes an attack signature that blocks a cross-site scripting attempt that use HTML events such as onmousemove, onmousedown, onmouseup and other similar events within a parameter.
HTML is not case-sensitive, so the signature should be as well. Thus the browser treats the onMousemOve event the same as onmousemove).
This example signature is not case-sensitive and looks inside a parameter. The signature also uses a regular expression for these reasons:
The signature has two parts:
valuecontent:"onmouse"; nocase; norm; re2:"/\bonmouse(?:move|down|up|out|over|enter|leave|wheel) \\W*=/Vsi"; norm;
http://example.com/index.php?a=onmousedown%3D%22alert(document.cookie)%22After parameter a is URL-decoded, you can see onmousedown="alert(document.cookie)". The same signature would also catch requests where this expression is located in the request body, for instance:
POST /index.php HTTP/1.1 Host: example.com a=onmousedown%3D%22alert(document.cookie)%22
http://example.com/onmousedown%3d/since it is located in the URI part of the request, and not in the query string part.
After the import, the system puts updated signatures into staging for the Enforcement Readiness Period (specified in Policy properties). Custom signatures are put into staging for all policies that have this signature in their assigned signature sets. It is a good idea to make sure that the new signature was added to the appropriate security policies.
The XML file format is the only accepted import format for attack signatures. Following is an example of the XML format used when saving user-defined attack signatures for import onto another system.
<?xml version="1.0" encoding="utf-8"?> <signatures export_version="11.X.X"> <sig id="300000000"> <rev num="1"> <sig_name>Unique signature name</sig_name> <rule>msg:"Signature Name"; content:"foo";</rule> <last_update>2011-04-15 13:37:17</last_update> <apply_to>Request</apply_to> <risk>3</risk> <accuracy>2</accuracy> <doc>Any additional descriptive text</doc> <attack_type>Cross Site Scripting (XSS)</attack_type> <systems> <system_name>IIS</system_name> <system_name>Microsoft Windows</system_name> </systems> </rev> </sig> </signatures>