Security on Habré
And I will tell you today about the feature that I recently needed to do in one project. Namely, the function "Remember me on this computer." Isn't that funny? What's so complicated? Save cookies for two weeks, a month, then pull out and restore the session. Yeah, it's simple. And I was stumped. I am often confused by the simplest things. So it embarrassed me ...
And what cookies to store, I thought. Id user and password hash? This data is stored in cookies, for example, on vkontakte.ru. Somehow for me too in the forehead and childish. Why then in the database to store the password hash? It is correct that an attacker, having acquired this same hash, could not use it or, at least, would decrypt it for a very long time. It turns out vkontakte - a paradise for intruders. Stole a hash, drove it into cookies and smiled =)
And I decided to see how it is implemented on the habr. And I found only one cookie PHPSESSID. It turns out, Habr stores only the session identifier (the cookie expires somewhere in 2047), and the session itself on the server has an extended lifetime (about a month, as I understand it). That's what I need, I thought. Simple, concise and tasteful. One standard cookie.
')
But something confused me again. And I did an experiment. I logged off from the habr and created this PHPSESSID cookie with the value 1111111111 in the browser. Then I logged in. Cook and its meaning remained the same, i.e. PHPSESSID = 1111111111. Further on another computer with a different ip and in another browser, I again created a cookie PHPSESSID = 1111111111. And, I logged in on =))
And now the manic scenario of using this method by the attacker. The attacker comes to a public access point (Internet cafe) and writes PHPSESSID with a value known to him on a computer (or at all). Then he goes home and writes a simple script that accesses the habr and checks the session with this cookie every n minutes. And goes to drink beer. An active habrauser Vasya comes to the Internet cafe and logs in to habre. After n minutes, he discovers that he has been kicked out of the site and is unable to come back in. And the attacker buys himself another beer. A curtain.
Maybe the script is just too manic, and who may need someone else's account on Habré? Well, firstly, there are many dissatisfied with their karma (for example, I =))). Secondly, such a session storage method can be implemented on more serious services.
Well, how many times have we been taught here not to trust the data that came from the user? Yeah, even if it's a session cookie! And the solution is very simple: we are looking for a session cookie among active sessions on the server, if there is no match, generate a new identifier and set a new cookie.
Are you reinsured,% username%?
And what cookies to store, I thought. Id user and password hash? This data is stored in cookies, for example, on vkontakte.ru. Somehow for me too in the forehead and childish. Why then in the database to store the password hash? It is correct that an attacker, having acquired this same hash, could not use it or, at least, would decrypt it for a very long time. It turns out vkontakte - a paradise for intruders. Stole a hash, drove it into cookies and smiled =)
And I decided to see how it is implemented on the habr. And I found only one cookie PHPSESSID. It turns out, Habr stores only the session identifier (the cookie expires somewhere in 2047), and the session itself on the server has an extended lifetime (about a month, as I understand it). That's what I need, I thought. Simple, concise and tasteful. One standard cookie.
')
But something confused me again. And I did an experiment. I logged off from the habr and created this PHPSESSID cookie with the value 1111111111 in the browser. Then I logged in. Cook and its meaning remained the same, i.e. PHPSESSID = 1111111111. Further on another computer with a different ip and in another browser, I again created a cookie PHPSESSID = 1111111111. And, I logged in on =))
And now the manic scenario of using this method by the attacker. The attacker comes to a public access point (Internet cafe) and writes PHPSESSID with a value known to him on a computer (or at all). Then he goes home and writes a simple script that accesses the habr and checks the session with this cookie every n minutes. And goes to drink beer. An active habrauser Vasya comes to the Internet cafe and logs in to habre. After n minutes, he discovers that he has been kicked out of the site and is unable to come back in. And the attacker buys himself another beer. A curtain.
Maybe the script is just too manic, and who may need someone else's account on Habré? Well, firstly, there are many dissatisfied with their karma (for example, I =))). Secondly, such a session storage method can be implemented on more serious services.
Well, how many times have we been taught here not to trust the data that came from the user? Yeah, even if it's a session cookie! And the solution is very simple: we are looking for a session cookie among active sessions on the server, if there is no match, generate a new identifier and set a new cookie.
Are you reinsured,% username%?
Source: https://habr.com/ru/post/40714/
All Articles