The BIG-IP Application Security Manager Part 3: The Importance of File Types, Parameters, and URLs

This is the third article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first two articles in this series are:

This third article in the series will discuss the importance of File Types, Parameters, and URLs.

It's no surprise that your web app will include various files, parameters, and URLs. It's also no surprise that these same files, parameters, and URLs can be vulnerable to various attack vectors like parameter tampering and forced browsing. In this article, I'll show you how to configure your ASM to mitigate these threats by allowing or blocking file types, parameters, and URLs. Let's get this party started!!

File Types

To configure the Allowed and Disallowed file types for your application, navigate to Security >> Application Security >> File Types. The following screenshot shows a list of the allowed file types for my current security policy (protecting the online auction site).

This specific policy only allows three file types: .jpg, .php, and no_ext. The "no_ext" is listed because the web application that I'm protecting doesn't always have a file extension at the end of the URL. For example, the web app might have the following URL: www.example.com/support. Notice that "support" does not include a file extension...that's why the "no_ext" is included in the list of approved file types. You can also restrict the length of the URL, the request, the query string, and the POST data as well. In these cases, if a user attempts to access an allowed file type, but the URL is too long, the request would get blocked.

I'm kind of anxious to try this thing out...so, let's fire up the web application and see if the ASM does its job! Here's a screenshot of the auction website being protected by our security policy. Notice the end of the URL...it doesn't have a file extension, so the security policy allowed it to be accessed. I won't post screenshots of examples of all the allowed file types, but take my word for it...they all work!

Of course, now you're asking yourself if the ASM will block a file type that is not included in the Allowed File Types list. Well, here's the answer:

The ASM worked!! Notice the URL in this example. The user was trying to access the file "badfile.exe" in the web application. Because the file type ".exe" is not included in the list of allowed file types, the request was rejected. By the way, you can change the wording on the "Request Rejected" page to say whatever you want...or you can automatically redirect to another page.

The ASM is a default-deny firewall (meaning it will block everything unless explicitly told to allow it), so you may be wondering why the ASM includes a list of Allowed File Types and Disallowed File Types. After all, the ASM blocks anything that is not listed in the Allowed File Types list, right? So, why does it even need a Disallowed File Types list? Great question! The answer is found in the "Wildcard" entry. The wildcard (listed as an asterisk) essentially allows access to all file types. Let's say you only have a few file types that you want to block, but everything else should be granted access. In this case, you would include a wildcard (*) in the Allowed File Types list and then explicitly block the known-bad file types in the Disallowed File Types list.

Parameters

Parameters are a very important part of any web application, and they consist of "name=value" pairs. Web applications may include a large or small number of parameters, but regardless of how many parameters are defined in your web app, they need to be protected. Parameters are typically listed after the question mark "?" portion of the URL. For example, the following screenshot shows a parameter name of "nick" and value of "fakeuser".

One of the potential security risks for a web application is parameter tampering. This involves a user changing a parameter to a value that the web application should not accept. Using the example above, if the "nick" parameter value was changed from "fakeuser" the wildcard value * then what do you suppose would happen? Maybe a malicious user would try this in order to view sensitive information about other users on this auction site. Check out the following screenshot to see what happens when this change is made...

Not good, right? When this subtle change is made to the parameter value, an entire list of user information suddenly populates the screen. Well, we need to protect the application from this behavior. So, we configure the "nick" parameter in the ASM to protect against dynamic parameter changes . Notice in the screenshot below that several parameters are listed in the ASM security policy, so each parameter can be updated with whatever configuration you want. Also, notice that each parameter is a "Global" level parameter, meaning that they are not associated with any specific URL or application flow. You can define URL or Flow parameters...these parameters are only allowed during specific application behavior and are more restrictive than Global parameters.

In order to protect the "nick" parameter, I updated the value type to "Dynamic content value" and defined extractions for the file type .php and the URL /index.php. These configurations lock down the changes that can be made on the "nick" parameter given a .php file type and a URL of /index.php. So, in the case of the ULR listed above (https://auction.f5demo.com/user_menu.php?nick=*), the "nick" parameter value was changed from "fakeuser" to the wildcard, so the ASM should now reject this request.

There's one more important setting to configure...be sure your Blocking Settings are updated for "Illegal dynamic parameter value". You can update these settings by navigating to Application Security >> Blocking >> Settings.

Let's see what happens when we apply these changes to the policy...

The ASM worked again! Just like in the File Types blocking page, the "Request Rejected" page can be modified to say whatever you want...or, you can simply redirect the user to another URL without ever showing a "Request Rejected" page at all.

URLs

The concept for allowing and blocking URLs is very similar to that of File Types. The ASM gives the option of allowing or disallowing URLs. In the security policy for our auction site, I added the wildcard URL to the "Allowed URLs" list and then added the /sell.php URL in the "Disallowed URLs" list. You can see these lists in the screenshots below.

Allowed URLs

Disallowed URLs

There's no real reason I added the /sell.php URL other than for purposes of demonstrating the ASM capabilities for the URLs. This configuration blocks anyone from selling an item on the auction site. In this example, I have decided that all URLs should be allowed except for one...that's why I included the wildcard URL in the Allowed list and then explicitly listed the URLs I wanted to block in the Disallowed list.

Now that the security policy is updated with the Allowed and Disallowed URLs, there's one more important step to take before the ASM will start blocking (I mentioned this in the Parameter section, but here's a screenshot for you). You have to set up the Blocking Settings for the URL violation. In fact, you have to configure the Blocking Settings for every violation you want the ASM to block on...not just URL stuff. But in this example, we will key in on the "Illegal URL" violation...check it all out in the screenshot below.

As you can see in the settings above, the enforcement mode must be set to "Blocking" and the Violation must be checked for "Block" as well. If both of these are not set, the ASM will not block the request. Keep in mind that you can set the Violation to "Learn" and "Alarm" as well. Last thing...don't ever forget to hit the "Apply Policy" button whenever you make any changes.

So, now that everything is set, let's see if the ASM does what it says it will do!

Not surprising, the ASM rocked our world! I chose to manipulate the Response Page a little bit just so you could see that it's possible to make it say whatever you want. You can really get crazy with these response pages, but I'll let your creative side take over on that one.

So that's it for File Types, Parameters, and URLs. Let me know if you have any questions about all this. There's a lot more out there to discuss, but I hope this article primed the pump for you to get excited about all the ASM can do for you. Until next time, keep it safe, keep it real, and keep the ASM turned on!

Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list.