NetScaler Application Firewall 9.2 has added a comprehensive new feature to defend against Cross Site Request Forgery (CSRF) attacks. In addition to basic filtering of Referrer HTTP headers, NetScaler also can add a random token to html forms per user request and validate these on subsequent form submissions in that session. Configuring the NetScaler to defend against CSRF attacks is simple. If you know all about CSRF, just skip to the configuration steps below. The Application Firewall is a core component of the NetScaler Platinum edition load balancer (ADC) and is also available as a separate appliance.
What is CSRF?
CSRF is widely prevalent (listed in OWASP Top 10 2010), but it has not attracted as much attention as other web application vulnerabilities like Cross Site Scripting (XSS) or Injection attacks. These attacks have more immediate and visible consequences and must be defended against first (A stored XSS vulnerability makes CSRF defenses very difficult). But CSRF is important to consider as well. Let us look at how this attack is performed (multiple variations of this are possible, but the simplest case is listed here):
CSRF (also known as Session Riding, XSRF, Hostile linking, One-click) vulnerabilities occur when the web application relies on session / user authentication mechanisms that are automatically submitted by the browser. A web application could, for example, add a cookie to store the userid after login and use this information (on each subsequent request) to check whether to allow or deny this request. A very common scenario for users today is to have multiple tabs open pointing to various different sites. If a user is logged into the victim site as well as the attacker site (in a different tab/window), script on the attacker page could make requests to the victim site. The user’s browser automatically submits stored cookies (userid in our example) along with the request. The victim web application cannot normally between requests actually made by the user or this fraudulent request and so performs the operation specified.
The OWASP page on CSRF has a good description of the attack and suggested remedial measures. The most robust defense against CSRF involves adding a random token to each form sent to the user and validating this token on subsequent form submission. The NetScaler Application Firewall does exactly this. A random token is added to every form as it streams through the firewall and is validated on the requests. This builds on the unique strengths of the Application Firewall to do in-line parsing of html to store all the links and forms sent to the client in that session. The firewall can thus validate all form fields against a stored signature to ensure no fields are added or tampered with (we call this form field consistency).
As a defense in depth measure, the firewall can also validate the referrer header to ensure that it comes from a permitted whitelist of URLs (as specified in the Start URL check). Earlier versions of the NetScaler could defend against some forms of CSRF attacks by a combination of strict session URL whitelisting and referrer filtering but the new feature provides a simpler and more secure option.
This assumes you have the application firewall already configured and running. If not, take a look at the Basic App Firewall configuration to get started.
Enable the CSRF form tagging protection
In the profile settings, the CSRF form tagging check needs to be enabled. Options include Block, Log and Stats. Forms that should not have a tag added can be exempted by adding a relaxation for the URL of the page and the form.
What does this protection do?
For every HTML form that streams through in responses, the firewall will add a hidden field with a randomly generated token value. When this request is submitted, the token is validated. If the token is invalid or not present, this is treated as an error. Depending on the firewall settings, appropriate action (Block, Log etc) are taken. This token is unique per request per user.
Enable Referer header validation
This check is in the profile settings, under the Start URL check.The options in the drop down include:
- Off: Referer header is not validated.
- If-Present: Referer header is validated only if present.
- Always: If Referer header is not present in request, treat as failure condition.
What does Referer validation do?
The Application Firewall Start URL check defines a set of URL (specified as regular expressions) that are allowed to access the application. The Referer header validation enforces this white-list on the Referer header also. The Start URL check has to be enabled for this protection.
Some personal firewall/anti-virus solutions might strip Referer headers when forwarding requests. So a setting of If-Present is recommended.