Account lockout and session management behavior

[Aaron Bryson]

Here is the app background. I am experiencing a problem with ZAP and need help determining the appropriate/expected behavior of ZAP for this situation.

1. The app allows concurrent sessions to be established (i.e. from different browsers or devices). 
2. The app has a built-in account lockout threshold of 6 failed attempts at 30 minutes.
3. If an account lockout occurs, it will NOT affect any already existing sessions that have been established for that user. So if that user is already logged on inside another browser it will remain authenticated.
4. The app I am testing is vulnerable to session fixation, meaning the session does not change through use of the application for a given user and the cookie has a really high max-age setting so it persists for a long time.
5. ZAP's HTTP Sessions tab only defines one active session/cookie for this user.
6. I defined the authentication type as "Form-based" and even provided a single user and password.
7. I set "Forced User" to the only user available.

The problem I am facing:

The application user account I am testing with repeatedly gets locked out while running the ZAP Active Scan. The session in ZAP was initially established via Mozilla Firefox proxied through ZAP, so ZAP has one active and fixed session. Once I begin the Active Scan, this user account gets locked out almost immediately. I verify this lockout by trying to authenticate in a separate browser (i.e. Chrome or IE).

What I do not understand if ZAP is purposefully brute forcing the authentication page to cause this lockout. Furthermore, if the account is locked out...are all of the tests that are still running under Active Scan being performed authenticated with the fixed session initially established through Firefox and also available under the HTTP Sessions tab?

Or are these tests hitting the account lockout page and preventing the tests from properly being carried out?

How can I tell which is occuring? 

Is ZAP expected to re-use and re-try the hardcoded user name and password added in the Users setting during its Active Scan? Or is ZAP going to perform all Active Scan tests using the only available session token?

Goals for this post:

• I want to understand ZAP behavior in such a scenario so I can know if I have to re-run all of the Active Scan tests because the account lockout may have fudged the results.
  
• I want to know if the session token under the HTTP Session tab OR the credentials under the User tab take precedent during an Active Scan.
  
• I want to know how to prevent ZAP from locking out an account. I tried to 'exclude' the logout URL from the scanner to prevent it from having to logout and back in...this did not work nor did it prevent the account from being locked out.

Thoughts?

Thank you.

[Simon Bennetts]

The ZAP active scanner doesnt try to 'brute force' login forms, but it does perform the standard set of attacks on them.
So you were right to exclude the login page from the active scanner.
Why the account is still getting locked out I dont know - that would depend on you application I guess. Can you fiond out how the lockout mechanism works?

By default ZAP will run active scans based on the last requests it received for each page.
So if you visit page1 with session1 and page2 with session2 then the active scanner will attack page1 with session1 and page2 with session2.
In fact all its doing is taking the last known request and duplicating it, and therefore duplicating things like session cookies.

You can use a specific session by setting it as the active session: https://code.google.com/p/zaproxy/wiki/HelpUiTabsHttpsessions
ZAP will then try to use that session for all requests to that app, even if the session is locked out.

You can use a specific user using the forced user mode: https://code.google.com/p/zaproxy/wiki/HelpUiTltoolbar#/_Force_User_Mode_On_/_Off
ZAP will then use the info you specified to check if the session is valid and if not try to get a new one.

This wont help if the user gets locked out, as presumably the credentials then wont work.

If you can automate the creation of new user accounts then you could create an 'authentication' script that actually registers a new user and then uses that.

Cheers,

Simon

[Mark Cadoc]

Hi,

I am having similar issues. I tried to exclude the login page, though I still see Zap trying to maybe code injection. 

I tried to open the URLs below, but it gives me "There was an error obtaining wiki data:"

[thc...@gmail.com]

Hi.

Updated links:
https://github.com/zaproxy/zap-core-help/wiki/HelpUiTabsHttpsessions
https://github.com/zaproxy/zap-core-help/wiki/HelpUiTltoolbar#--forced-user-mode-on--off

Best regards.

>>> 1. The app allows concurrent sessions to be established (i.e. from
>>> different browsers or devices).
>>> 2. The app has a built-in account lockout threshold of 6 failed
>>> attempts at 30 minutes.
>>> 3. If an account lockout occurs, it will NOT affect any already

>>> existing sessions that have been established for that user. So if that user
>>> is already logged on inside another browser it will remain authenticated.

>>> 4. The app I am testing is vulnerable to session fixation, meaning

>>> the session does not change through use of the application for a given user
>>> and the cookie has a really high max-age setting so it persists for a long
>>> time.

>>> 5. ZAP's HTTP Sessions tab only defines one active session/cookie for
>>> this user.
>>> 6. I defined the authentication type as "Form-based" and even

>>> provided a single user and password.

>>> 7. I set "Forced User" to the only user available.
>>>
>>>
>>> *The problem I am facing:*

>>> The application user account I am testing with repeatedly gets locked out
>>> while running the ZAP Active Scan. The session in ZAP was initially
>>> established via Mozilla Firefox proxied through ZAP, so ZAP has one active

>>> and fixed session. Once I begin the *Active Scan*, this user account

>>> gets locked out almost immediately. I verify this lockout by trying to
>>> authenticate in a separate browser (i.e. Chrome or IE).
>>>
>>> What I do not understand if ZAP is purposefully brute forcing the
>>> authentication page to cause this lockout. Furthermore, if the account is

>>> locked out...are all of the tests that are still running under *Active
>>> Scan* being performed authenticated with the fixed session initially
>>> established through Firefox and also available under the *HTTP Sessions*

>>> tab?
>>> Or are these tests hitting the account lockout page and preventing the
>>> tests from properly being carried out?
>>> How can I tell which is occuring?
>>> Is ZAP expected to re-use and re-try the hardcoded user name and password

>>> added in the *Users* setting during its *Active Scan*? Or is ZAP going
>>> to perform all *Active Scan* tests using the only available session
>>> token?
>>>
>>> *Goals for this post:*
>>>
>>> - I want to understand ZAP behavior in such a scenario so I can know

>>> if I have to re-run all of the Active Scan tests because the account
>>> lockout may have fudged the results.

>>> - I want to know if the session token under the HTTP Session tab *OR*

>>> the credentials under the User tab take precedent during an Active Scan.

>>> - I want to know how to prevent ZAP from locking out an account. I