Generally the accounts are locked when the attempt to login exceed a certain no. of unsuccessful attempts. The userids are locked by the application to thwart any further attempt to brute force. Generally the threshold is 3 unsuccessful attempts.
But I recently came across an application where there was a flaw which leads to bypass the account lockout.
Suppose an account is already locked and we try to provide the correct userid and password as now we remember the correct combination.
It acts like the below:
1. In one tab we'll access the login page and enter the userid/ password correctly. But the app will not let you in because the userid is locked and displays account locked message.
2. Now try accessing an internal url of the application in the second tab in the same browser since two tabs share the session id in most of the browsers.
3. The application lets you in the second tab!
This behavior of the application puzzled us until we inspected it closely and came to know about the below reason which could cause this.
1. In the first tab, when first time we try to login into a already locked user, using correct credentials, the application validates it and once it finds it correct, it sets the session ID before checking if the userid is locked or not.
2. When in the 2nd tab we try to access any internal url, now the application finds that this is a valid session and logs you in.
3. So the issue was the order in which the application was checking the session vs the locked account flag.
But I recently came across an application where there was a flaw which leads to bypass the account lockout.
Suppose an account is already locked and we try to provide the correct userid and password as now we remember the correct combination.
It acts like the below:
1. In one tab we'll access the login page and enter the userid/ password correctly. But the app will not let you in because the userid is locked and displays account locked message.
2. Now try accessing an internal url of the application in the second tab in the same browser since two tabs share the session id in most of the browsers.
3. The application lets you in the second tab!
This behavior of the application puzzled us until we inspected it closely and came to know about the below reason which could cause this.
1. In the first tab, when first time we try to login into a already locked user, using correct credentials, the application validates it and once it finds it correct, it sets the session ID before checking if the userid is locked or not.
2. When in the 2nd tab we try to access any internal url, now the application finds that this is a valid session and logs you in.
3. So the issue was the order in which the application was checking the session vs the locked account flag.
Comments