Apply ASM attack signatures to URLs?

Depends on how your policy is configured. The out-of-the-box General Signature List includes SQL Injection signatures, so I would verify if they are enabled. Go to your policy, then go to Security ›› Application Security : Attack Signatures : Attack Signatures List. Plug in 1=1 in the Containing String field and select SQL-Injection in the Attack Type field then hit Go. From the results, ensure the applicable signatures are Enabled and not in Staging mode.

Hi Tim,

The SQL Injection signatures are in fact enabled, and successfully block SQL injections if these come in the request body.

This is identified by ASM as a SQL Injection attack: POST to with a body that looks like: {"user":"' OR 1=1 --"}

This is not identified by ASM as a SQL Injection attack: GET to '%20OR%201=1%20--

Instead, ASM detects that the request has illegal characters in the URL - which is fine, but it means it is not applying attack signature validation to the URL itself...

Do you have a type listed here (i.e. wildcard) that isn't enforced yet?

Security ›› Application Security : File Types : Allowed File Types

Yes, I do. It is the default type that gets created along with the policy (I assume). When I enforced it, it started blocking literally everything, so I'm not sure if that's what I need :)

Ok, so I think I was able to replicate what you're seeing.

My guess is the ASM engine does not see a GET request for '%20OR%201=1%20-- as illegal because the SQL Injection-like character set is not contained after a question mark signifying the query string portion of a URI. I can get the SQL Injection signature block by doing something like this:

https://f5testdmzqa.rjf.com/?' OR 1=1 --

...as well as including a query string key/value pair like:

https://f5testdmzqa.rjf.com/?user=me' OR 1=1 --

Thanks Tim, I think you are right - when using a question mark to denote the query part, ASM recognizes it and blocks it. Still, seems like this is a major gap as more and more RESTful web services are using this convention.. Any idea if there is some workaround that I can use to "help" ASM detect this?

It seems that some attack signatures (like XSS) are being successfully detected in the URL, while others (like SQL) are not.

This is blocked:

http://webservice/api/user/

This is not blocked:

http://webservice/api/user/' OR 1=1 --

Probably need to ping F5 support for more specific info. My take is that SQL Injection attack types are parameter-based and specific to user input, hence why it doesn't apply in this case. Granted, you could certainly argue mucking up the URL is a type of user input, but it still doesn't satisfy the parameter-based aspect. Regardless, there are other means to validate URL content, such as allowed/disallowed meta characters.

The thing about meta characters is that none of the characters used in the SQL Injection attack are actually invalid. They are all legitimate characters that can be found in URLs, especially in APIs that support ODATA filters - theoretically, for such APIs we can rely on ASM detecting the actual SQL Injection (since they do look like ?$filter='whatever'), but this is a level of micro-management of the policy that I am not very reluctant to get into just yet...