ASM Brute Force when app success/fail isn't the first response?

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