can not understand regenerating session id

Question 1

Throughout the lifetime of a website, there will be many 'sessions'. Each of these sessions is identified by an ID, and is how the web site knows who is who and is able to keep state between different requests.

A session fixation attack is really only possible if you can get ahold of the session id. Some sites allow sessions to persist between different actual browsing sessions (aka 'Remember Me' functionality), and are more vulnerable to this attack if the same session id is used.

If I get ahold of your session id then I can impersonate you only so long as that session id is valid. Using session_regenerate_id, the old ID becomes invalidated, making it useless to anyone who may have intercepted it. If you generate a new ID once a user successfully authenticates themselves, then any of the attempts at capturing a session identifier will no longer yield a valid identifier for an authenticated user (only the 'anonymous' session that the user had prior to authenticating themselves), meaning attackers can only 'impersonate' anonymous users.

Some more security conscious frameworks actually regenerate the session id within browsing sessions (using a timeout as low as 2-3 minutes) rather than just whenever a user logs in to help guard against people grabbing the session id via packet sniffing on the network. Session IDs can only be regenerated in response to a request.

Question 2

The key point to have in mind is that in order to maintain session state, on every request the client reports its current session id to the server. The reporting mechanism itself (e.g. through a cookie or a URL parameter) is not important here.

From the viewpoint of the server, and excluding advanced precautions being taken¹, the session id reported by the client is authoritative: the server doesn't have a notion of a "correct" or "real" session id for any particular client. Clients are who they say they are.

Of course this raises the question: what is then preventing me from declaring that I am a site administrator with privileges to do anything on your application? Only the fact that I don't know the session id of the real administrator (assuming the real admin does have a session). If I did, I could impersonate the admin and do whatever they can do.

So now from the attacker's viewpoint: how can I learn the admin's session id? Tricking the admin into reporting to the server a specific session id of my own choosing would work! This is the essence of the session fixation attack.

There are several ways to prevent or mitigate the effects of this attack, and one of them is to make the server tell the client "I changed your session id; from now on, use this one". Of course the client is not forced to comply, but friendly clients will of course do so (and the server can refuse to recognize clients even if they were hostile). So even if the attacker manages to trick the admin into using a specific session id known to the attacker, the attack will work only as long as the server doesn't instruct the client to switch to a different session id.

And that's exactly what session_regenerate_id does.

¹ Advanced precautions: for example, the server might keep a track of the last IP address used by the client for each session id. If the server sees a request with a given session id coming from a different IP address then that could be considered suspicious. Of course this simplistic example cannot account for the sophistication of modern internet infrastructure, but the idea is clear. High-security services (e.g. Gmail) use sophisticated techniques of the same type to detect and prevent suspicious activity.

Question 3

It the session ID is in the URL and the attacker somehow gets another user to visit this URL, the attacker will know the session ID.

e.g. suppose the attacker places this code snippet on their own website "evil.com" (session ID trimmed for brevity)

<a href="https://www.example.com/login.php?PHPSESSID=a123">Login to site to continue</a>

and then induces their victim to visit their site (e.g. sending them an email containing a link to "evil.com"). If the user visits the attackers website, and then follows the link to "example.com" and then logs in it may be possible for the attacker to follow the same link and hijack the now logged in session (as the IDs will match). e.g. the link could be to a funny video on Facebook but will contain the session ID in the URL rather than just a straight login page.

However, if however session_regenerate_id() is called as part of the login process (just after username & password are verified) the session ID will now be new and the attacker will have no way of hijacking the session using this method.

This is not a vulnerability restricted to session IDs in the URL. Say the rest of the website is HTTP and after login the session is moved to HTTPS then it is also wise to regenerate the Session ID because the existing Session ID could have been intercepted when the traffic was on HTTP.