PHP Security-session pinning

Session pinning

The main concern about sessions is the confidentiality of session identities. If it is confidential, there is no risk of session hijacking. With a legitimate session ID, an attacker can be very successful in posing as one of your users.

There are three ways an attacker can obtain a valid session ID:

L Guess

L Capture

L Fixed

PHP generates a very random session ID, so the risk of being guessed does not exist. It is common to obtain a session ID by capturing network traffic data. In order to avoid the risk of the session identity being captured, SSL can be used while patching the browser vulnerability in a timely manner.

Little Tips

Remember that the browser will include a corresponding cookie header in all requests after the request in the Set-cookie header. The most common is that the session ID is unnecessarily exposed in requests for some embedded resource slices. For example, when you request a Web page with 10 images, the browser issues 11 requests with a session ID, but only one is required to be identified. To prevent this senseless exposure, you might consider putting all of your embedded resources on a server with another domain name.

Session pinning is a means of tricking a victim into using an attacker-specified session identity. This is the simplest way for an attacker to obtain a legitimate session identity.

In this simplest case, a link is used for session pinning attacks:

  <ahref= "http://example.org/index.php?PHPSESSID=1234" >click here</a>

Another approach is to use a protocol-level steering statement:

<?php   Header (' location:http://www.php.cn/');   ? >

This can also be done through the refresh header, which is specified by the Http-equiv property of the real HTTP header or meta tag. The attacker's goal is to have the user access a URL that contains the session ID specified by the attacker. This is the first step in a basic attack, and the complete attack process is shown in Figure 4-3.

Figure 4-3. Session pinning attack using the session ID specified by the attacker

If successful, the attacker can bypass the need to crawl or guess legitimate session identities, which makes it possible to initiate more and more dangerous attacks.

To better make you understand this step, the best way is to try it yourself. Start by creating a script named fixation.php:

<?php   session_start ();  $_session[' username ' = ' chris ';   ? >

Verify that you have not saved any cookies for the current server, or that you have cleared all cookies to ensure this. Access fixation.php via a URL that contains PHPSESSID:

http://www.php.cn/

It establishes a session variable username that has a value of Chris. After the session store is checked, 1234 session IDs are found for that data:

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

Create the second paragraph of script test.php, which will enter this value in the presence of $_session[' username '):

<?php   session_start ();   if (isset ($_session[' username '))  {    echo $_session[' username '];  }   ? >

The following URL is accessed on another computer or in another browser, and the URL specifies the same session ID:

http://www.php.cn/

This allows you to restore the previously established session in fixation.php on another computer or in the browser (mimicking where the attacker is). This allows you to successfully hijack a session as an attacker.

Obviously, we don't want this to happen. Because the above method, the attacker will provide a link to your application, as long as the link to your site access to the user will use the attacker's designated session ID.

One reason for 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 from happening.

<?php   session_start ();   if (!isset ($_session[' initiated '))  {    session_regenerate_id ();    $_session[' initiated ' = TRUE;  }   ? >

This ensures that a new session ID is available during session initialization. However, this is not an effective solution to prevent session pinning attacks. An attacker could simply access your Web site, determine the session ID given by PHP, and use that session ID in a session pinning attack.

This does not give the attacker the opportunity to specify a simple session ID, such as 1234, but the attacker can still get the session ID specified by PHP by checking the cookie or URL (depending on how the identity is passed). This is shown in process 4-4.

This diagram illustrates this weakness of the session, and it can help you understand the scope of the problem. Session pinning is only the basis for an attack to obtain an identity that can be used to hijack a session. This is typically used for a system in which an attacker can legitimately obtain lower privileges (the level of permission can be logged on only), so it is useful to hijack a session with a higher privilege.

If the session ID is regenerated when the permission level has changed, you can avoid the risk of session pinning in fact:

<?php   $_session[' logged_in '] = FALSE;   if (Check_login ())  {    session_regenerate_id ();    $_session[' logged_in ' = TRUE;  }   ? >

Figure 4-4. Session pinning attack by first initializing session

Little Tips

I do not recommend rebuilding the session ID on each page. Although it does seem to be a safe approach. However, it does not provide more protection than rebuilding the session identity when the permission level changes. More importantly, it will also have an impact on your legitimate users, especially when the session ID is passed through the URL. Users may use the browser's access history mechanism to access previously visited pages so that the links on the page point to a session ID that no longer exists.

If you regenerate the session ID only when the permission level changes, the same situation can occur, but the user will not be surprised by the loss of the session when the page before the access changes, and this is not a common situation.

The above is the PHP security-session fixed content, more relevant content please pay attention to topic.alibabacloud.com (www.php.cn)!

