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.
As mentioned in the introduction, you should familiarise yourself with the application flow. Questions to ask yourself are:
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.
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:
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.: