HTTP Brute Force Mitigation Playbook: Protecting HTML Form Based Authorization using ASM - Chapter 4
Introduction
For a long time HTML Form based authorization was - and possibly still is - the most common authorization type in use by websites on the internet; recently, of course, we have seen a move to syndicated authorization mechanisms (OAuth, OpenID etc) and "Web2.0" technologies that utilise client side JavaScript and JSON, XML or another representation layer to transport credentials. In this chapter, however, we will concentrate on HTML Form Based Authorization where the application flow will commonly consist of a series of browser requests, each resulting in either a new page being rendered in the browser or a subsequent browser request.
For example, a common login flow might look like:
GET /login.html HTTP/1.1 Host: zuul
HTTP/1.1 200 OK Content-Length: 175 Content-Type: text/html <html> <head> </head> <body> <form method="POST" action="/loginsubmit.php"> <label for="username">Username:<input name="username" type="text"></label><br> <label for="password">Password:<input name="password" type="password"></label><br> <input name="submit" type="submit"> </form> </body> </html>
POST /loginsubmit.php HTTP/1.1 Host: zuul Content-Length: 41 Content-Type: application/x-www-form-urlencoded username=test&password=xxxx
HTTP/1.1 200 OK Content-Length: 58 Content-Type: text/html; charset=UTF-8 <html> <head> </head> <body> Bad password </body> </html>
Or to visualise this in the browser, the first step is a GET request which returns the login page:
And the second step is a POST request submitting the entered credentials which returns a success/fail message:
Of course, the precise flow will differ depending on the application - most commonly there are variations in the response returned for either a valid or invalid login, and when configuring the Brute Force protections in ASM the administrator will need to understand the application flow and understand the requests and responses that are expected in both a valid and invalid login flow. Chrome's Developer Tools or an intercepting proxy such as Burp or ZAP can help you capture the login flow in a form that can be exported (e.g. a HAR file) and sent to others for analysis if necessary.
Preparing the Environment
As mentioned in the introduction, you should familiarise yourself with the application flow. Questions to ask yourself are:
- What is the entry point to the login flow?
- What request is made in order to render the login page to the user?
- What does a successful login look like?
- What is the HTTP response code returned by the server for a valid login - common examples being 200 (OK) and 302 (Moved Temporarily)
- Is there any identifiable content within the response that indicates a valid login other than the response code?
- Are there any headers specific to a valid login?
- What does an unsuccessful login look like?
- What is the HTTP response code returned by the server for an invalid login, and is it different to that of a valid login - common examples, again, being 200 (OK) and 302 (Moved Temporarily)
- Is there any identifiable content within the response that indicates an invalid login attempt other than the response code?
- Are there any headers specific to an invalid login?
It is crucial that you determine how to identify the difference between a valid and invalid login flow, as you will need that detail in order to configure the ASM.
Configuring Brute Force Protection
In this section we will run through the basic settings necessary in ASM to configure Brute Force protection to protect the login form you have examined in the earlier sections; we will not necessarily dive deeply into all of the configuration options, but these steps should provide a solid starting point and good basic protection. We will assume that you already have the following in place:
- A Virtual Server handling the application traffic
- A suitable Logging Profile associated with the Virtual Server to ensure that relevant requests are logged
- A basic ASM policy with Enforcement Mode set to Blocking is already associated with the Virtual Server
Define the Login Page
- Navigate to Security → Application Security → Sessions and Logins → Login Pages List
- Click Create
- Define the URL
- This is the place to which your application submits credentials - in the example above, that is /loginsubmit.php
- Set Authentication Type to HTML Form
- Set the HTTP parameter that contains the username - in the example above, that is 'username'
- Set the HTTP parameter that contains the password - in the example above, that is 'password'
- Using the Access Validation options, define how the ASM should detect a valid (or invalid in the case of the "NOT" options) login, e.g.
- Click Create
Define the Brute Force settings
- Navigate to Security → Application Security → Brute Force Attack Prevention
- Click Create
- Select your previously defined Login Page using the drop-down list beside "Login Page"
- Select your Source-based Brute Force Protection mitigation options
- Click Create
- Click Apply Policy
When configuring your mitigation options, it is important to understand the types of clients you expect to serve as valid clients and that you respect their capabilities when selecting mitigation mechanisms. For example, if you expect users using desktop or mobile browsers, both CAPTCHA and Client Side Integrity options will work successfully, however if you expect a mix of browser and non-browser clients (mobile applications or Microsoft Outlook, for example) then both CAPTCHA and Client Side Integrity challenges will cause failures for users using the non-browser clients due to the JavaScript they inject - in that case, consider using only mitigations that are tied to specific Source IP addresses, and non JavaScript based mitigations (such as Alarm and Drop) along with a shorter Maximum Prevention Duration so that non-browser clients who enter an incorrect password and trigger the protection mechanism are not denied access for too great a period of time.
Whitelisting
You may need to consider whitelisting specific clients or IP ranges - for example, you may have a Virtual Server servicing both internal and external clients, and/or need to whitelist IP addresses belonging to a Virtual Private Network. You can do this simply via the GUI, e.g.:
- Navigate to Security→Application Security→IP Addresses→IP Address Exceptions
- Click Create
- Enter the IP Address and Netmask you wish to Whitelist
- Check "Ignore in Brute Force Detection"
- Click Create, e.g.
- Click Apply Policy