ASM 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