It is possible that a web application has two or more login forms. Each of those login forms might authenticate for a different section of the web site (when the application has e-commerce and admin sections, for example) or just be different depending on the user profile.
For now, the WAS scanning engine tries to authenticate on the first login form it encounters. If for any reason the provided credentials are intended for the second or subsequent login form, the WAS scanning engine does not authenticate.
You can deduce whether the correct login form was identified by first looking at QID 150008. Inside the QID details, you will find the URI where the WAS scanning engine attempted to login. The URI should match the same one that you expect for the login form. However, sometimes the page name might differ from what you see from your browser, so make sure it is the actual page.
One way to verify this is by looking at the action from the FORM HTML tag. To find out this information follow these steps:
1 Go to the login form page.
2 Right click as close as possible to the login inputs form (generally the username and password fields).
3 A contextual menu will appear. Click "View Source" to view the page source.
4 When the HTML source appears, search for the keyword "<form"
5 You might see more than one result. In this case, identify the correct result. To do this, see if <input type="password" is close by or between the opening <form and closing </form> tags that you found. Of course, the action name might be clear enough to know it’s the right result.
6 In that form look for the action keyword. A typical form would look like this:
<form action="/merchant/login.php" method="POST">
7 Check the URI the WAS scanning engine POSTed to (/merchant/login.php in our example) matches the URI you see in the QID 150007. If it’s the wrong one then you've found your problem. If it's empty or no action property exists, then it means that the WAS scanning engine will crawl the page you see in your browser URL bar.
You simply need to change your starting URI in the web application settings to point directly to the page. In our example our starting URI would be /merchant/login.php. Since this is the first login form the crawling module will encounter your problem will be settled.
Another workaround is to blacklist the culprit login form URI. The downside is that you might not find vulnerabilities that could be present on that form/page or find new links associated to that web page.