PHP Security-fixed session

Session fixation the main concern for Sessions is the confidentiality of session identifiers. If it is confidential, there will be no risk of session hijacking. With a valid session ID, an attacker can be very successful...

Fixed session

Concerning sessions, the main concern is the confidentiality of session identifiers. If it is confidential, there will be no risk of session hijacking. With a valid session ID, an attacker can successfully impersonate a user.

An attacker can obtain valid session IDs in three ways:

L guess

L capture

L fixed

PHP generates a highly random session ID, so the risk of being guessed does not exist. It is common to capture network communication data to get the session id. To avoid the risk of session identity capturing, you can use SSL and promptly fix browser vulnerabilities.

Tips

Remember that the browser will include a cookie header in all subsequent requests according to the requirements in the request's Set-Cookie header. The most common is that session IDs are exposed to some requests embedded in resource slices. For example, when requesting a web page containing 10 images, the browser will send 11 requests with session IDs, but only one request must be identified. To prevent unnecessary exposure, you can consider placing all the embedded resources on a server with another domain name.

Session fixation is an attack that tricks victims into using the session id specified by the attacker. This is the easiest way for attackers to obtain valid session IDs.

In this simplest example, a link is used for session fixation attacks:

  Click Here

Another method is to use a Protocol-Level turning statement:

This can also be done through the Refresh header. the method for generating this header is specified through the real HTTP header or the http-equiv attribute of the meta tag. The attacker aims to allow users to access a URL containing the session id specified by the attacker. This is the first step of a basic attack. for the complete attack process, see-3.

Figure 4-3. Fixed session attacks using the session id specified by the attacker

If successful, attackers can bypass the need to capture or guess the valid session ID, which makes it possible to initiate more and more dangerous attacks.

The best way to better understand this step is to try it on your own. First, create a script named fixation. php:

Make sure that you do not store any cookies on the current server or clear all cookies to ensure this. Access fixation. php through a URL containing PHPSESSID:

#

It creates a session variable username with the value of chris. After checking the session storage area, 1234 is the session id of the data:

  $ cat /tmp/sess_1234  username|s:5:"chris";

Create the second script test. php, which is input when $ _ SESSION ['username'] exists:

Access the following URL on another computer or in another browser, and specify the same Session ID:

#

This allows you to recover sessions established in fixation. php on another computer or in a browser (imitating the attacker's location. In this way, you have successfully hijacked a session as an attacker.

Obviously, we don't want this to happen. Through the above method, attackers will provide a link to your application. users who access your website through this link will use the session id specified by the attacker.

One cause of this problem is that the session is created by the session id in the URL. When no session id is specified, PHP automatically generates one. This opens the door for attackers. Fortunately, we can use the session_regenerate_id () function to prevent this situation.

This ensures a new session id during session initialization. However, this is not an effective solution to prevent session fixation attacks. Attackers can easily access your website, determine the session id provided by PHP, and use the session id in session fixation attacks.

This does not allow an attacker to specify a simple session ID, such as 1234. However, the attacker can still check the cookie or URL (depending on the identity transfer method) obtain the session id specified by PHP. This process is shown in 4-4.

This figure illustrates the weakness of a session and helps you understand the scope of the problem. Session fixation is only a foundation. The attack aims to obtain an identifier that can be used to hijack a session. This is usually used in such a system. In this system, attackers can legally obtain lower permissions (this level only requires logon ), it is very useful to hijack a session with higher permissions.

If the session id is re-generated when the permission level changes, you can actually avoid the fixed risk of the session:

Figure 4-4. initiate a session to initiate a fixed session attack

Tips

I do not recommend that you regenerate the session id on each page. Although this seems like a safe method. However, there is no more protection means than re-generating session IDs when the permission levels change. More importantly, on the contrary, it will also affect your legal users, especially when Session IDs are transmitted through URLs. The user may use the browser's access history mechanism to access the previously accessed page, so that the link on this page will point to a session id that no longer exists.

If you only generate a new session ID when the permission level changes, this can also happen. However, when a user accesses a page before the permission change, it is not surprising that the session is lost, at the same time, this situation is not common.

The above is the fixed session content for PHP Security. For more information, see PHP Chinese website (www.php1.cn )!