This can be a quick and easy goal, but when it comes to storing information, it tends to have some sensitive things that may become targets for attack, such as bank accounts, credit card transactions, or records. This requires that security measures be taken to reduce the likelihood of a successful attack when writing code.
The main security measures are in the following two areas.
1, to prevent the attacker to obtain the user's session ID.
There are many ways to get a session ID, an attacker can obtain it by looking at plaintext traffic, so it is dangerous to place the session ID in a URL or in a cookie transmitted via an unencrypted connection, and it is also unsafe to pass the session ID in the URL (as the _get () parameter). Because the URL is stored in the browser history cache, it is easy to read. (You may consider using SSH for encrypted transmissions)
There is also a more covert approach, where an attacker redirects a user on a hacked site to another site through a Web site that is breached by a script attack, and then inserts the following code into the URL of the redirected site:
? phpsessid=213456465412312365465412312;
Last sent to the Web application. When a user views a Web application, PHP finds no data associated with the session ID and creates some data. The user does not know what happened, but the attacker knows the session ID and can use the session ID to enter the application.
There are two ways to prevent this type of attack.
(1) Check whether the Session.use_only_cookie is open in the php.ini. If this is the case, PHP rejects the session ID based on the URL.
(2) When the session is started, a variable is placed in the session data that indicates that the session was created by the user, and if the session data is found to be false, the SESSION_REGENERATE_ID function can be called and a new session ID is assigned to the existing session.
Example:
By determining whether a variable exists to determine the true and false of the session ID, if present, the session ID is true, otherwise it is false, and the session ID is changed using the session_regenerate_id () function to recreate a new session ID for the session.
The code is as follows:
Copy Code code as follows:
< PHP
Session_Start ();
if (!isset ($_session[' shili1 ')) {//Determine if the SHILI1 variable is configured
$old _id = session_id (); Variable name of the original session ID
SESSION_REGENERATE_ID (); Get a new session ID
$new _id = session_id (); The variable name of the new session ID
echo "Old: $old _id<br/>"; Output the original session ID
echo "NEW: $new _id<br/>"; Output a new session ID
$_session[' shili1 '] = TRUE; }
?>
The results of the run are as shown in the figure:
This is just an example of the output session ID for better understanding and application of this function, while in program design there is no need to output session IDs.
2, limit the attacker to get the session ID.
The following methods are used to limit the attacker's access to the session ID.
(1) Use a function (MD5) to compute the hash value (hash) of the user-agent header plus some additional string data. (hash function) accepts an arbitrarily large dataset and converts it to a seemingly completely different data, which is very short. The resulting hash value is completely not reproducible and cannot be generated by another input. ）
After adding some data after the user-agent string, an attacker cannot try to probe the user-agent string by calculating the MD5 encoding of a common proxy value.
(2) Save the encoded string in the user's session data.
(3) Check this hash value every time a request is received from this user.
The code for this scenario is as follows:
Copy Code code as follows:
<?php
Define (' Ua_seed ', ' WebApp ');
Session_Start ();
if (!isset ($_session[' user_agent ')) {
$_session[' user_agent '] = MD5 ($_server[' http_user_agent '].ua_seed);
}else{
if ($_session[' user_agent ']!= MD5 ($_server[' http_user_agent '].ua_seed)}}
?>
By creating some trouble for an attacker, the attacker could not damage the system even if he acquired the session ID.
