The premise of fixed session attack?

An attacker provides a link that contains a known session ID, such as: 点击, to induce the victim to click on the link, the user click on the link may be a series of actions, and then the attacker then use the session ID landing site, thereby hijacking the user's session, resulting in fixed session attacks.
But the general PHP settings session.use_cookiesAnd session.use_only_cookiesis 1, that is, the attacker could not hijack the session through a URL to pass the conversation ID, and in this case, could it possibly cause a session fixed attack?

Reply content:

An attacker provides a link that contains a known session ID, for example 点击 , to induce the victim to click on the link, a series of actions may be taken after the user clicks on the link, and then the attacker can then use the session ID to log on to the website, thereby hijacking the user's session and causing a fixed session attack.
However, the general PHP settings session.use_cookies and session.use_only_cookies All are 1, that is, the attacker can not pass the URL of the session ID to hijack sessions, in this case, it is possible to cause the session fixed attack?

You can rewrite the session yourself to make it easy to set up checks on various rules.

Don't you check the IP and security hash?

Assume that the actual session of the current user is PrimaryKey hash(ip+uid) . The$_SESSION[md5(ip.uid)]['login']

The root cause of fixed attack in the next session is analyzed first:

1. The attacker succeeded in acquiring a fixed sessionid;

2. The attacker uses certain methods to allow the attacker to request the server and perform authorization operations with the known sessionid as the attacker's sessionid;

3. The attacker requests the server with the session ID obtained to obtain the same authorization as the attacker.

The focus here is "2", which is the most straightforward way to entice an attacker to click through a URL (in case the server supports get session), but the ultimate goal is to have the attacker "carry a known SessionID" request Server to open Session.use_only_ In the case of cookies, the use of the cookie "carry a known SessionID" request service side is retained, in which case the attacker only needs to "use certain methods" (such as XSS) to modify the cookie value to a known sessionid to achieve the same effect. The ultimate defense approach should be to redistribute sessionid after each authorization change.
Answer reference: https://www.douban.com/note/299072454/

