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 login and password, and if they correspond to the data in the database, the person is considered authorized, a session is generated for him and written to the cookie. Probably all you heard about brutfors . Many people remember it and implement protection in the form of limited attempts to enter a login / password at some intervals. But almost everyone forgets that a session hidden in a cookie can also be brutalized. Moreover, during authentication you should know the login and password, and here only the session. And the session template (the number of characters, which characters) can be viewed by an attacker by registering on the portal.
I want to share my thoughts on how to organize protection.
At once I will make a reservation that by the word session I will understand not a process, but a set of characters, which is stored in a cookie to identify the user in the future.
1) Set binding to IP.
If the session value from the cookie is equal to the session value from the database, but the user's IP is different from the user's IP recorded in the database (with successful authorization), then output the authorization form asking for the login and password.
Of course, you need to give users the ability to disable this option, because sometimes providers change external IP (when nating) and in half an hour a user can be kicked several times using this algorithm. But by default the option should be enabled! This will severely limit the cracker.
')
2) The session should be as large as possible, its length should vary and consist of all possible characters.
The shorter the session, the smaller its possible variations and the greater the likelihood of selecting an existing session.
With a constant length, the hacker, having registered an account for himself, will easily determine by what length the program needs to be set up - brute force, which minimizes its time.
Because The cracker can register on the portal, he can also collect statistics on the sessions, of what characters it consists. If he sees that the session consists only of lowercase Latin letters, then by making these rules in his program, he will significantly save the selection time. By adding only one extra character, you significantly increase the hacking time!
3) Consider using the HTTP_USER_AGENT environment variable.
If you write information about the browser and the system of an authorized user into the database and check for this condition when accepting a session, then at least increase the hacking time several times.
The bottom line: of course, it is possible to detect attempts at bruteforce sessions, but you cannot block the IP from which bruteforce is performed, because By doing this, you will not be able to properly use sessions of real users from this IP. Therefore, we can only increase the time of the brute force. When using the three points mentioned above, you can easily increase the time so much that the intruder will simply abandon this idea.
I hope that this information will be useful to web developers.
I want to share my thoughts on how to organize protection.
At once I will make a reservation that by the word session I will understand not a process, but a set of characters, which is stored in a cookie to identify the user in the future.
1) Set binding to IP.
If the session value from the cookie is equal to the session value from the database, but the user's IP is different from the user's IP recorded in the database (with successful authorization), then output the authorization form asking for the login and password.
Of course, you need to give users the ability to disable this option, because sometimes providers change external IP (when nating) and in half an hour a user can be kicked several times using this algorithm. But by default the option should be enabled! This will severely limit the cracker.
')
2) The session should be as large as possible, its length should vary and consist of all possible characters.
The shorter the session, the smaller its possible variations and the greater the likelihood of selecting an existing session.
With a constant length, the hacker, having registered an account for himself, will easily determine by what length the program needs to be set up - brute force, which minimizes its time.
Because The cracker can register on the portal, he can also collect statistics on the sessions, of what characters it consists. If he sees that the session consists only of lowercase Latin letters, then by making these rules in his program, he will significantly save the selection time. By adding only one extra character, you significantly increase the hacking time!
3) Consider using the HTTP_USER_AGENT environment variable.
If you write information about the browser and the system of an authorized user into the database and check for this condition when accepting a session, then at least increase the hacking time several times.
The bottom line: of course, it is possible to detect attempts at bruteforce sessions, but you cannot block the IP from which bruteforce is performed, because By doing this, you will not be able to properly use sessions of real users from this IP. Therefore, we can only increase the time of the brute force. When using the three points mentioned above, you can easily increase the time so much that the intruder will simply abandon this idea.
I hope that this information will be useful to web developers.
Source: https://habr.com/ru/post/68165/
All Articles