Forum Discussion
Dan_Bowman
Cirrus
CirrusASM Brute Force when app success/fail isn't the first response?
Hi guys,
I've been looking at configuring ASM Brute Force protection for a couple of web apps. The challenge I'm hitting is that the app doesn't instantly respond with a success/fail criterion in the initial response to a POST.
For one example you might enter your username/pass, hit post, then a 'checking your details' screen appears, waits a while then redirects you to either the success/fail pages.
In another instance, username is on the initial screen, you hit post, the server then responds with a partial (generic) response before 302ing to the next screen where password chars are entered. That in turn follows the same pattern of partial response after a post, then a 302 to the eventual success page.
Is there any way out of the box to use ASM Brute Force to protect apps of this type? Basically I seem to need to be able to protect based on subsequent responses rather than the immediate response to the initial post.
Do the initial login pages defined in brute force have to be the pages with the login info form on? Or could I perhaps track the intermediate pages where the user hasn't physically typed anything in, but the subsequent response is where they'd finally be taken to the success/fail pages? I'd considered an iRule but again if login pages need to be the initial form, then the responses I'd need to trap in the iRule wouldn't be available until later in the session.
TL;DR - Does ASM Brute Force have to be defined against the page with a form on it, or can I target deeper into the app's login process..?
Thoughts and comments appreciated!
Dan
Dan_BowmanJust to revisit this - I've been looking again at the app that has username on screen 1 and then password on screen 2. Is it possible to persist the username entered on screen 1 and then pass via an iRule to Brute Force so that it can be matched against the password as a pair?
As it stands I've configured screen 1 and screen 2 as separate login pages, but not having username available on screen 2 is proving troublesome for accurate BF detection.
samstepCirrocumulus
No form parameters is a potential problem - you need at least username for brute force detection to work as ASM needs to associate the session with a user in order to count the number of failed login attempts for that username from the same IP address or within the same HTTP Session.
You might need a bespoke iRule if you can't have a reliable way to associate a username with a failed login response.
- samstep
Hi Dan,
The login pages configured in ASM do not have to be the exact login form pages to track brute force. They can be those intermediate pages you are describing. For example when you talk about the first page in the process being a page asking the username and the second page is asking for some random characters from the password you can configure the second page to be the login URL page. I presume that the username will be preserved on the second page as a hidden form parameter.
In summary the login page URL in ASM has to be the URL on which something in the response will change depending on successful or failed authentication (that "something" can be HTTP status/some text/some header/cookie or parameter). Note that the absence of some text can be a sign of a successful login.
For example a lot of systems I deal with will respond with a text "Invalid username or password" while a successful login will just return the page the user was trying to access and it is impossible to predict what text will be on the successful page as it can be anything. This is where the "A string that should NOT appear in the response" setting on login page URL is very useful!
Hope this helps,
Sam