PHP Security-session data exposure (2)

Session Data exposure when you focus on preventing source code exposure, your session data is only at risk. By default, sessions are stored in the tmp directory. This is convenient in many cases, one of which is...

Session Data exposure

When you focus on preventing source code exposure, your session data is only at risk. By default, sessions are stored in the/tmp directory. This is convenient in many cases. one of them is that all users have the write permission for/tmp, so Apache also has the permission to write data. Although other users cannot directly read these session files from the shell environment, they can write a simple script for reading:

 
 read())  {    if (substr($filename, 0, 5) == 'sess_')    {      $data =file_get_contents("$path/$filename");       if (!empty($data))      {        session_decode($data);        $session = $_SESSION;        $_SESSION = array();        echo "Session [" . substr($filename, 5) ."]\n";        print_r($session);        echo "\n--\n\n";      }    }  }   ?>

This script searches for files prefixed with sess _ in the session file storage directory defined by session. save_path. After finding the file, parse its content and use the print_r () function to display its content. In this way, other developers can easily obtain the session data of your users.

The best way to solve this problem is to store your session data in a database protected by the user name and password. Because database access is controlled, an additional layer of protection is added. Using the techniques mentioned in the previous section of the application, the database can provide a safe place to store your sensitive data. at the same time, you should be cautious that your database security is becoming more and more important.

To save session data in the database, you must first create a data table:

  CREATE TABLE sessions  (    id varchar(32) NOT NULL,    access int(10) unsigned,    data text,    PRIMARY KEY (id)  );

If you are using MySQL, the table structure is described as follows:

   mysql> DESCRIBE sessions; +--------+------------------+------+-----+---------+-------+  | Field  | Type             | Null | Key | Default| Extra | +--------+------------------+------+-----+---------+-------+  | id     | varchar(32)      |      | PRI |        |       |  | access | int(10) unsigned | YES  |     | NULL   |       |  | data   | text             | YES  |     | NULL   |       | +--------+------------------+------+-----+---------+-------+

To save session data in this table, you need to use the session_set_save_handler () function to edit the PHP built-in session mechanism:

Each of these six arguments is the name of afunction that you must write. These functions handle the following tasks:

Each of the above six parameters represents the name of the function to be compiled. they process the following tasks:

L open session storage

L disable session storage

L read session data

L write session data

L eliminate session data

L clear old session data

I intentionally used meaningful names so that you can see their purpose. Naming is arbitrary, but you may want to start with an underscore (as shown in this case) or other naming conventions to prevent name conflicts. The following is an example of these functions (using MySQL:

You must call the session_set_save_handler () function before session_start (), but you can define these functions anywhere.

The beauty of this process is that you do not need to edit the code or change the way you use sessions. $ _ The SESSION still exists, and the behavior remains the same. it is identified by PHP for generation and transfer, and the configuration change for the SESSION will also take effect. All you need to do is call this function (and create all the functions specified by it), and PHP will take care of the rest.

The above is the content of PHP Security-session data exposure (2). For more information, see PHP Chinese network (www.php1.cn )!