Session data exposure
Session data often contains personal information and other sensitive data. For this reason, the exposure of session data is a matter of general concern. Generally speaking, the scope of exposure is not very large, because session data is stored in the server environment, not in the database or file system. As a result, session data is naturally not exposed publicly.
Using SSL is a particularly effective way to minimize the likelihood that data will be exposed between servers and clients. This is important for applications that transmit sensitive data. SSL provides a protective layer over HTTP so that all data in HTTP requests and responses are protected.
If you are concerned about the security of the session data store itself, you can encrypt the session data so that the content cannot be read without the correct key. This is very easy to do in PHP, you just use Session_set_save_handler () and write your own session encryption to store and decrypt read processing functions.
Session Hijacking
The most common means of attack against a session is session hijacking. It is a generic term for all attackers to access other people's conversations. The first step in all of these tools is to get a legitimate session ID to disguise itself as a legitimate user, so it is important to ensure that the session ID is not compromised. Previous knowledge of session exposure and fixation can help you ensure that session identities are only known to servers and legitimate users.
The defense-in-depth principle can be used on sessions, and some obscure security measures provide some protection when the session ID is unfortunately known to the attacker. As a developer concerned about security, your goal should be to make the aforementioned camouflage process more complex. Remember that no matter how small the obstacles are, they will be protected by your application.
The key to getting the camouflage process more complex is to strengthen validation. Session identification is the primary method of validation, and you can supplement it with other data. All the data you can use is just the data in each HTTP request:
get/http/1.1
Host:example.org
user-agent:firefox/1.0
Accept:text/html, Image/png, Image/jpeg, Image/gif, */*
cookie:phpsessid=1234
You should be aware of the consistency of the request and consider the inconsistent behavior to be suspicious. For example, although the user-agent (the browser type that makes the request) is optional, the browser that emits the header usually does not change its value. If you have a 1234 session identity users have been logged in with Mozilla Firfox Browser, suddenly converted to IE, this is more suspicious. For example, at this point you can use a password to reduce the risk, while in the wrong time, this also has a relatively small impact on legitimate users. You can use the following code to detect the consistency of user-agent:
Copy Code code as follows:
<?php
Session_Start ();
if (Isset ($_session[' http_user_agent '))
{
if ($_session[' http_user_agent ']!= MD5 ($_server[' http_user_agent '))
{
/* Prompt for Password * *
Exit
}
}
Else
{
$_session[' http_user_agent '] = MD5 ($_server[' http_user_agent '));
}
?>
I have observed that in some versions of IE browsers, users normally visit a Web page and refresh a Web page with different accept headers, so the accept head cannot be used to determine consistency.
It is effective to ensure that the User-agent header information is consistent, but if the session ID is passed through a cookie (recommended), it makes sense that if the attacker can get the session ID, he can also get the other HTTP headers. Because cookie exposure is associated with a browser vulnerability or Cross-site scripting vulnerability, the victim needs to visit the attacker's website and expose all header information. All the attackers have to do is rebuild the head to prevent any inspection of the consistency of the header information.
A better approach is to generate a token in a URL that can be considered a second form of authentication (albeit weaker). Using this method requires some programming work, there is no corresponding function in PHP. For example, assuming that the tag is stored in $token, you need to include it in all of your application's internal links:
Copy Code code as follows:
<?php
$url = Array ();
$html = Array ();
$url [' token '] = Rawurlencode ($token);
$html [' token '] = htmlentities ($url [' token '], ent_quotes, ' UTF-8 ');
?>
<a href= "index.php?token=<?php echo $html [' token '];?>" >click here</a>
In order to manage this delivery process more easily, you might put the entire request string in a variable. You can attach this variable to all the links so that you can easily change your code in the future even if you don't use it in the first place.
The tag needs to contain unpredictable content, even if the attacker knows all the information about the HTTP header emitted by the victim's browser. One way to do this is to generate a random string as a marker:
Copy Code code as follows:
<?php
$string = $_server[' http_user_agent '];
$string. = ' Shiflett ';
$token = MD5 ($string);
$_session[' token ' = $token;
?>
When you use a random string (such as a Shiflett), it is unrealistic to predict it. At this point, capturing the markup will be more convenient than the predictive markup, by passing the tag in the URL and passing the session identity in the cookie, the attack needs to crawl both of them at the same time. This will not be possible unless an attacker is able to see all HTTP request raw information that the victim has sent to your application, because all content is exposed in this situation. This type of attack is very difficult to implement (and therefore very rare) to prevent it from needing to use SSL.
There are expert warnings not to rely on checking the consistency of user-agent. This is because the HTTP proxy server in the server cluster edits the user-agent, and multiple proxy servers in this cluster may be inconsistent when editing the value. If you don't want to rely on checking the consistency of user-agent. You can generate a random tag:
Copy Code code as follows:
<?php
$token = MD5 (Uniqid (rand (), TRUE);
$_session[' token ' = $token;
?>
Although the security of this method is weak, it is more reliable. The above two methods provide a powerful means of preventing session hijacking. What you need to do is to strike a balance between security and reliability.
