a similar problem with a session exposure is conversation injection . This type of attack is based on your Web server's write permissions in addition to the Read permission to the session store directory. Therefore, there is a possibility to write a script that allows other users to add, edit, or delete sessions. The following example shows an HTML form that allows users to easily edit existing session data:
<?phpsession_start ();? ><form action= "inject.php" method= "POST" ><?php$path = Ini_get (' Session.save_path '); $handle = Dir ($path); while ($filename = $handle->read ()) {if (substr ($filename, 0, 5) = = ' Sess_ ') {$sess _data = file_get_contents ("$pa th/$filename "); if (!empty ($sess _data)) {Session_decode ($sess _data); $sess _data = $_session; $_session = Array (); $sess _name = substr ($filename, 5); $sess _name = htmlentities ($sess _name, ent_quotes, ' UTF-8 '); echo "
the script inject.php executes the modifications specified by the form:
<?phpsession_start (); $path = Ini_get (' Session.save_path '); foreach ($_post as $sess _name = $sess _data) { $_ SESSION = $sess _data; $sess _data = Session_encode; File_put_contents ("$path/$sess _name", $sess _data);} $_session = Array ();? >
This type of attack is very dangerous. Not only can an attacker edit your user's data, but it can also edit his or her own session data. It is more powerful than session hijacking because attackers can select all session data for modification, which makes it possible to bypass access restrictions and other security measures.
The best solution for this problem is to keep session data in the database. See the section on the front of the topic.
Extended ReadingThe list of topics for this article is as follows: http://www.nowamagic.net/librarys/veda/detail/2079
PHP Security Programming: Session Data injection