Securing Web Applications with an Application Firewall

I have been working with Application Firewalls for quite a few years - many times to protect web applications published in languages and character sets that I didn't understand. Frequently, I have seen these Application Firewall deployment projects get bogged down in pursuit of the perfect policy set.

I have also seen many situations in which this process and application changes actually break these applications.

The NetScaler Application Firewall deployment can also be subject to these issues since the appliance provides extensive application firewall features. Even with the learning capabilities, creating the ideal set of security policies for any application can be a trial and error process that can take significant time.

In this blog, I would like to share an implementation methodology that shortens the deployment, and helps avoid breaking the applications to be protected. Experience has shown that approaching the configuration of the Application Firewall in stages is the key to timely success. This methodology is effective for all types of applications and their needs.

To alleviate the time and risk of varying degrees of policy complexity, break the task into stages. That is, separate the policy configuration into groups of ascending risk.  While some may raise the point that a simplified protection policy set is not complete, it must be remembered that protection stages will build upon each other, and will be better than allowing unfiltered access while all policies are in learning or logging/warning mode.

The benefit of staging is that a basic set of policies are made operational.  Then, the following stages will consist of conducting a repeatable process of "policy tightening" procedures as required by the application.

Stage I

When configuring the NetScaler Application firewall policies, start with some of the basic protections.  Activating the simple, generic policies almost never produce false positives.  These typically include:

• Protect against Cross Site Scripting (XSS) attacks
• Protect against SQL Injection attacks
• Protect against Buffer Overflow attacks
• Prevent Credit Card Leakage
• Prevent access to system files
• Alter the contents of the server headers

Activating these policies will typically not break applications.  As such, a small user community - with etc/hosts overrides - can be used to validate the configuration over a fairly brief validation period.

More importantly, this is a great start. These policies create security effectiveness that can typically be rated as a level seven on scale of zero though nine (you can never get to a perfect "10" in security).

Stage II

The next stage will include applying policies that require more application validation to determine the application specific relaxation adjustments ("policy overrides").

But first, don't forget to ask yourself if this application actually requires tightened policies.

If so, Stage II protections should be sequenced - Cookie Tampering prevention should be blocked first. Then, move on to blocking tampering with the values of parameter and/or hidden form fields.

Start with cookie poisoning prevention ("Cookie Consistency"). It will be likely require the least number of relaxations. This will build on the Stage I successes most rapidly.

To do this, use the learning process to identify the cookies that are legitimately altered between the response and request process. Minimally, relaxations will be required for cookies that are set and modified by third party monitoring services. Again, because of the staging, this learning can happen while the basic policies are in place and actively applying their protection mechanisms.

If further tightening is required, focus on creating policies that prevent users from tampering with the values of parameter and hidden form fields. This is achieved by activating "Field Consistency" learning in the NetScaler application firewall. Depending on the architecture of the application or a frequent use of client side scripting, these policies carry a higher risk of blocking legitimate requests. These policies thus require a more extensive learning period and associated relaxation overrides.

It should also be noted that these Stage II policies and their relaxations do have a tendency to be susceptible to producing false positives as applications change, and should be re-evaluated in conjunction with major application changes.

Stage III and Beyond

If the application is contains super sensitive information, and undergoes frequent changes, further security configuration may be required.

Stage III typically involves enforcing field formats and enforcing user navigation paths. Adding restrictions to field input types, such as date formats, and more, will require further time for learning these application attributes. Be aware that these policies will also be more likely to be sensitive to application changes.

Enabling the "Start URL" facility allows users to access only the specifically stated URL types. Due to the flexibility inherent in application architectures, however, these restrictions may require modification to include additional request types present in a particular application.

Lastly, carefully consider activating "URL Closure" to control the flow of access by users. Enforcement of this policy set disallows users from navigating to locations not previously offered by an application response. These policies may require significant application validation if client side scripts modify URLs, or if FLASH objects contain links.

The above policies tend to bend the needle towards the nine level and will be more likely to cause false positives during policy refinement or when the application changes. Leaving these to Stage III, however, allows continued protection afforded by the policies of Level I and Level II during the refinement, however.

Summary

Personally, when I plan my application firewall deployments, I always attack the assignment in the phases outlined above. I focus on the quick return policies first. Then I take time to consider if the sensitivities of the specific application even warrant the extra effort of going all the way to Stage III. This last question can produce some interesting answers that pit my application security ideals against the practicalities driven by the depth of my current to-do list.

And then, of course, this staged approach may be completely ignored in situations in which a specific application just suffered from an attack through a specific Level III vulnerability. Such situations may warrant overriding the staged approach and focusing on addressing the impacted vulnerability immediately.

Also, don't forget to sign on to MyCitrix and download the Application Hacking Kit and actually try some of the most common application attacks on the BadStore application!

The #1 Web Filter by St.Bernard is now Citrix Ready. The Highest Performance Web Application Solution from Citrix Systems can now be deployed with the the #1 Web Filter by St. Berdard. IDC ranked them #1, SC Magazine gives them high ratings, and you will agree when you plug this thing in. The Citrix Web Application Firewall protects inbound traffic destined to Web and Application Servers without degrading throughput or response time. Now, with St.Bernard's iPrism h-Series high performance appliances, you can also do outbound Web filtering, IM/P2P filtering, and antivirus detection. The iPrism Web Filter is optimized for the datacenter infrastructure and sits behind the firewall while it monitors traffic. St. Bernard's platforms are hybrid so that Web filtering, antivirus and IM/P2P filtering are all contained within one box - unlike other point solutions.

St.Bernard's iPrism Web Filter is easy to use and easy to manage. If fact, it's so easy, we had the device up and running in Proxy mode and then in Bridge mode in a matter of seconds. The management software auto-discovers the box, so you don't have to plug in a console cable - very nice!

It is far better than a transparent proxy because St.Bernard has engineered their filtering technology at the kernel level, so their bridge mode really is a bridge between interfaces, and not just a transparent proxy like other solutions in the market.

We deployed the iPrism Web Filter behind our NetScaler, and had the NetScaler perform NAT (Reverse NAT) for outbound connections to the Internet. The iPrism Web Filter adds another level of security that IT organizations sometimes look for to complement their existing base of high-performance Citrix Gear.


Citrix & St.Bernard Deployment Guide!

You can try this product for free.


The product demo is awesome.


As a hybrid unit, this is a steal.












NetScaler Developer Network!