Today I would like to discuss HTML parameters and how you can leverage the BIG-IP ASM module to help secure a web site by doing what I call parameter scanning. For this little exercise I will focus on only two parameters, TARGET and user, but the principals I am covering here can be applied to all kinds of parameters.

For those of you who do not have a lot of experience with HTML parameters you probably have heard to them referred to as fields in your web application. For example, many web applications have username and password fields and these are essentially parameter fields. There are sometimes hidden parameters and dynamic parameters that are not associated with a field on the page, but today I want to discuss the basic ones. I have chosen the TARGET parameter because it is deprecated and it can be used in phishing attacks as a form of “Open Redirect” attack on your web sites. The user parameter was chosen because it is a pretty common parameter/field name and it just seemed to make sense to include it in the discussion.

An open redirect type of attack will often consist of an attacker creating a URL that will redirect a victim to a site that they control. This URL is then used in a phishing attack where a user is presented with a valid link in an email and companywebsite.com redirects the user to companywebsite-justgotowned.com… which is the site the attacker controls! That’s just one type of open redirect attack though, another type focus’s on using the TARGET parameter to redirect a user behind the scenes to a malicious web site.

Needless to say, that’s not good. What is good though is that protecting against the malicious use of parameters is very EASY to do with BIG-IP ASM. The first thing that you will want to do, provided you already have an application security policy in place, is to create a Parameter. Navigate to Application Security, Parameter, Parameters List, select the application policy that you want to modify and click the GO button.

Then click Create. Give your parameter an explicit name (I used TARGET in my example), select Global Parameter, Data Type should be Alpha-Numeric and check the “Regular Expression” box. Now you will need to come up with a regular expression that fits your environment. In my example I am going to define two things. First I will use the hostname of the web site that is valid and then after the pipe I will define a value for a URL that is still being called in our own code via the TARGET method. Since it is a relative URL I have to include it because the regex for just the hostname will not cover it. Below is a screenshot for reference:

The regex looks like this:

.*mycompany.com.*|.*myurlpath.*

Something very important to remember when creating these regular expressions is that whenever you create a parameter value and check the Regular Expression box it is automatically setup as a POSITIVE regular expression. Therefore whatever is in this box defines what is legal for this parameter/field. In the example above if a TARGET value is submitted to the web application it must contain “mycompany.com” or “myurlpath” or it will be shot down by the ASM. This will prevent someone from setting a target of somewhere other than your web site. This will stop a blatant open redirect attack but certainly not all. Then click the create button.

Now you will need to tell your web application policy to be on the lookout for violations of this type. Navigate to Application Security, Policy, Blocking, Settings. Then scroll down the list until you see “Parameter value does not comply with regular expression”, check the Learn, Alarm and Block check boxes. Save and then Apply the policy. That’s it!

When ever a violation happens you will now see this in the manual traffic learning section:

Now to tackle the “user” parameter. I am going to take a different angle on this one because like I mentioned before, once you understand the principal behind it you will see it can be used in a million different ways to protect your web application.

After looking over a few security logs you might notice that some hackers attempt to utilize the “user” parameter/field in your web application and they will try to throw all kinds of things in there. One common element I have seen is that they will try to inject a [email protected] into the field. Since that is not a valid character for the application I am looking to protect, I am going to block this kind of attack configuring the ASM to block based off of an invalid metacharacter value being placed in the parameter value.

Following the instructions above for creating a new Parameter, except this time instead of using a regular expression, click the Value Meta Characters tab. Select “@ (0x40)” from the list on the right hand side of the page and then set the value to be disallowed using the drop down box under the set state heading. Put a check mark in the check characters on this parameter value check box. Now to configure your web application policy to listen, alarm and block on these kinds of attacks. Navigate to Application Security, Policy, Blocking, Settings. Then scroll down the list until you see “Illegal meta character in parameter value”. Check the appropriate boxes, save and then apply.

Now whenever a would be hacker attempts to inject an invalid character into that field (the @ character in this case, but like I said you can use countless others) they will be smacked down by the ASM.

It’s a piece of cake really once you do it a time or two. If you get hung up on the regular expression part have no fear! The kind folks over at F5 Networks have thought ahead and have included a regular expression validator inside of the ASM module. Just navigate to Application Security, Options, Tools and RegExp Validator. You can use that tool to compile your regular expression if need be.

Remember when thinking about security related things it is best to take the defense in-depth approach. Little things added here and there to your web application security policy that do no harm but can mitigate attacks can be very effective.