Bruteforce cookies, forgot?
Practically on all more or less large projects there is a user authorization system by the entered login and password. A person enters a username and password and if they correspond to the data in the database, then the person is considered authorized, a session is generated for him and recorded in cookies. Probably all of you have heard about brute force . Many people remember it and implement protection in the form of limited attempts to enter a username / password with a certain interval. But almost everyone forgets that a session hidden in a cookie can also be brute force. Moreover, during authentication you should know the username and password, and here only the session. Yes, and the session template (the number of characters, what characters) the attacker can see by registering on the portal.
I want to share my thoughts on how to organize a defense.
I’ll immediately make a reservation that by the word session I will understand not a process, but a set of characters that are stored in a cookie to identify the user in the future.
1) Make a binding to IP.
If the session value from the cookie is equal to the session value from the database, but the IP of the user is different from the IP of the user recorded in the database (with successful authorization), then output the authorization form with a login and password request.
Of course, you need to give users the opportunity to disable this option, because sometimes providers change their external IPs (when hooking) and in half an hour a user can kick several times using this algorithm. But by default the option should be enabled! This will greatly limit the cracker.
2)The session should be as large as possible, its length should vary and it should consist of all possible characters.
The shorter the session, the less possible its variations and the greater the likelihood of selecting an existing session.
With a constant length, the cracker, having registered an account for himself, can easily determine for what length you need to configure the program - brute force, which minimizes its time.
Because the cracker can register on the portal, he can also collect statistics on sessions, what symbols it consists of. If he sees that the session consists only of lowercase Latin letters, then making these rules in his program, he will significantly save the time of selection. By adding only one additional character, you significantly increase the time of hacking!
3)Consider using the environment variable HTTP_USER_AGENT.
If you write down information about the browser and the system of an authorized user in the database and will check for this condition when accepting a session, then at least increase the hacking time by several times.
Bottom line: of course you can detect an attempt to brute force sessions, but you can’t block the IP from which brute force is performed, because this will make it impossible for you to normally use the sessions of real users from this IP. Therefore, we can only increase the time of brute force. Using the three points mentioned above, you can easily increase the time so much that the cracker simply abandons this idea.
I hope that this information will be useful to web developers.
I want to share my thoughts on how to organize a defense.
I’ll immediately make a reservation that by the word session I will understand not a process, but a set of characters that are stored in a cookie to identify the user in the future.
1) Make a binding to IP.
If the session value from the cookie is equal to the session value from the database, but the IP of the user is different from the IP of the user recorded in the database (with successful authorization), then output the authorization form with a login and password request.
Of course, you need to give users the opportunity to disable this option, because sometimes providers change their external IPs (when hooking) and in half an hour a user can kick several times using this algorithm. But by default the option should be enabled! This will greatly limit the cracker.
2)The session should be as large as possible, its length should vary and it should consist of all possible characters.
The shorter the session, the less possible its variations and the greater the likelihood of selecting an existing session.
With a constant length, the cracker, having registered an account for himself, can easily determine for what length you need to configure the program - brute force, which minimizes its time.
Because the cracker can register on the portal, he can also collect statistics on sessions, what symbols it consists of. If he sees that the session consists only of lowercase Latin letters, then making these rules in his program, he will significantly save the time of selection. By adding only one additional character, you significantly increase the time of hacking!
3)Consider using the environment variable HTTP_USER_AGENT.
If you write down information about the browser and the system of an authorized user in the database and will check for this condition when accepting a session, then at least increase the hacking time by several times.
Bottom line: of course you can detect an attempt to brute force sessions, but you can’t block the IP from which brute force is performed, because this will make it impossible for you to normally use the sessions of real users from this IP. Therefore, we can only increase the time of brute force. Using the three points mentioned above, you can easily increase the time so much that the cracker simply abandons this idea.
I hope that this information will be useful to web developers.
