Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Apply ASM attack signatures to URLs?

Hi,

Is it possible to apply ASM attack signatures detection to URLs? This is the scenario I am trying to solve:

1) Assume we have a RESTFul web service that returns user details given a user ID 2) The API looks like: GET http://webservice/api/user/:id 3) Provided an ID, it returns a JSON object with the user's details

Now, if this web service is vulnerable to SQL injection, it can be easily attacked:

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

This will return a list of all users...

In our testing of the ASM, it did not detect the SQL injection attack in the URL. It did detect the usage of illegal parameters, but that is insufficient IMO.

I haven't found a way to apply attack signatures validation to a URL.. has anyone been successful in doing that?

Thanks, Dan

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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 http://webservice/api/user with a body that looks like: {"user":"' OR 1=1 --"}

This is not identified by ASM as a SQL Injection attack: GET to http://webservice/api/user/'%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...

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

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

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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 :)

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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 http://webservice/api/user/'%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 --

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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/<script>alert()</script>

This is not blocked: http://webservice/api/user/' OR 1=1 --

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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...

0