How safe is using sessions in php?

Question

PHP

After the user has logged in to the site, I save the user id to the session , which I also store in the database . If a user visits private pages, such as profile settings, notifications, etc., I take his id from the session and substitute a query in sql => if there is no such id , then nothing will be returned.

How secure is such a system? It turns out that in order to gain access to someone else's private information, you just need to substitute the correct id in your session. Can the user even do this?

Are there ways to secure such a system?

Answer 1

The session is a Cookie with the name PHPSESSID (which can be changed by default) and a value like 8jae35cosacp2f5qv6g2uqe6i7 . All session data ($_SESSION array) is stored on the server side in a file named 8jae35cosacp2f5qv6g2uqe6i7 in JSON format (it can also be stored in the database).
That is, you do not need to add 1, but guess this name, which is unrealistic. You can set the HttpOnly
flag for Cookies - such Cookies are not visible to the browser code (javascript), but are only sent to the server. Javascript embedded on the page will not be able to access such a Cookie. The cookie can be intercepted during transmission over the network, there are mechanisms to protect against this: - set the HSTS header
- in the session itself, you can store the IP address (binding the session to IP). Then, even with the correct Cookie, you won't be able to log in, because the IP (which is stored in $_SESSION on the server side) will not match. It is inconvenient if the provider changes the IP every time you reconnect.
- you can store the User Agent in the session (Cook anyway - it is only for this browser). But with an automatic browser update, you will have to log in again, and who was smart enough to intercept Cookie will also intercept the name of the User Agent. - you can store browser fingerprint
in the session(or even the entire computer), you just need to figure out how to safely transfer it to the server in order to save it in the session (and for comparison during authorization). He, too, can be intercepted.
- with each authorization by Cookie, and every ## seconds you can (and should) do a session_regenerate_id (changes 8jae35cosacp2f5qv6g2uqe6i7 to another), there is an example on the link how to do it right inside the session. That is, the stolen Cook quickly stops working.
- You can make a "session" Cookie (do not specify its lifetime). Such a Cookie lives until the browser is closed, but after closing the browser, you will have to re-enter your login / password
You can add your own security - for example, send an email to the user at each authorization by Cookie, if the User has not been active for more than 12 hours.
PS: If you use sessions correctly, they are quite safe, almost all authorization on the Internet is based on them.

Answer 2

The system is quite reliable but there is one BUT. Session lifetime. Usually it is 1440 seconds. I implemented this by leaving a cookie with a session ID and a lifetime of a month, when visiting, I checked for the presence of cookies and if it changed, then compared the cookie user, if it is the same, then updated this variable. I also implemented an authorization mechanism after the guest mode with rewriting the basket to the user. The main thing is the user and the session is secondary.