What are the prerequisites for fixed SESSION attacks?

The attacker provides a link containing a known session ID, for example, & amp; lt; ahref & #039; login. php? PHPSESSID1234 & #039; & amp; gt; click & amp; lt; a & amp; gt; To trick victims into clicking this link. Users may perform a series of operations after clicking this link, then, attackers can use this session ID to log on to the website... the attacker provides a link containing a known session ID, for example: ClickTo trick the victim into clicking this link. After the user clicks the link, a series of operations may be performed. Then, the attacker uses this session id to log on to the website, hijack the user SESSION, and cause a fixed SESSION attack.
However, php settings session.use_cookiesAnd session.use_only_cookiesIn this case, the attacker cannot hijack the SESSION by passing the session id through the url. Is it possible to cause a fixed SESSION attack?

Reply content:

The attacker provides a link containing a known session ID, for example:ClickTo trick the victim into clicking this link. After the user clicks the link, a series of operations may be performed. Then, the attacker uses this session id to log on to the website, hijack the user SESSION, and cause a fixed SESSION attack.
However, php settingssession.use_cookiesAndsession.use_only_cookiesIn this case, the attacker cannot hijack the SESSION by passing the session id through the url. Is it possible to cause a fixed SESSION attack?

You can rewrite the session on your own to set and verify various rules.

Don't you verify the IP address and secure HASH?

Assume that the actual SESSION PrimaryKey of the current user ishash(ip+uid). Then$_SESSION[md5(ip.uid)]['login']

First, analyze the root cause of Session fixed Attacks:

1. The attacker successfully obtained a fixed sessionID;

2. Attackers use some methods to request the server and perform authorization operations by using the acquired known sessionID as the sessionID of the attacker;

3. The attacker sends a session ID to the server to obtain the same authorization as the session ID obtained by the attacker.

The key here is "2" (when the server supports GET session). It is the most direct way to trick attackers into clicking through a URL, however, the ultimate goal is to allow attackers to "carry known sessionID" to request the server to enable the session. when use_only_cookies are used, the method of sending requests to the server using the cookie "carrying known sessionID" is retained. In this case, attackers only need to "use some methods" (such as XSS) you can change the cookie value to a known sessionID to achieve the same effect. The final defense method should be re-allocated after each authorization change.
Reference: https://www.douban.com/note/299072454/