SQL attack signatures, are they enough to prevent an attack?

Wasfi, where Attack Signature protections end, by adding positive security you can make up any shortfalls. In your example, if you configure the Last Name parameter in the policy you can then restrict metacharacters, for example the single quote ', so ASM would block your second example with "illegal metacharacter in parameter value" and not require an Attack Signature.

Hope this helps,

N

There is a signature which is looking at the presence of the word " OR " (surrounded by white space) and other SQL reserved words like "drop table". Due to normalization ASM will even understand an evasion technique like this: DR/*junk comment*/OP TAB/** blah blah **/LE

There is a good white paper (from 2007) on how ASM's Evasion Detection Engine handles such cases here: https://f5.com/resources/white-papers/sql-injection-evasion-detection

Having siad that, you need to understand that ASM signatures will mostly only stop the "low hanging fruit" attacks from automated scanners & botnets. Essentually the signatures are just a bunch of Regular Expressions and can be bypassed. You will need defence-in-depth and should really add positive security checks on parameters to stop more determined attackers.

No LastName should contain numbers '=' '><%' characters - this is how you can make the policy tighter (Irish last names can have a ' character e.g. O'Henry, O'Brien!!!).

More precise SQL injection protection can be provided by a Database Firewall product such as IBM Guardium, these products actually understand the SQL language and the INTENT of the query. F5 ASM and IBM Guardium can be integrated, there is an article about it if you are interested in learning about this solution: https://devcentral.f5.com/articles/f5-and-ibm-announce-asm-and-infosphere-guardium-database-security-integration