Session data exposure
Session data often contains some personal information and other sensitive data. For this reason, the exposure of session data is a matter of general concern. In general, the scope of exposure is not very large, because session data is stored in the server environment, not in the database or the file system. As a result, session data is naturally not publicly exposed.
Using SSL is a particularly effective means of minimizing the exposure to data when it is transmitted between the server and the client. This is important for applications that transmit sensitive data. SSL provides a layer of protection over HTTP so that all data in HTTP requests and responses is protected.
If you are concerned about the security of the session data store itself, you can encrypt the session data so that the contents of it cannot be read without the correct key. This is very easy to do in PHP, just use Session_set_save_handler () and write your own session to encrypt the storage and decrypt the read processing functions.
Session Hijacking
The most common attack method for a session is session hijacking. It is the generic term for all the means that an attacker can use to access other people's sessions. The first step in all of these techniques is to obtain a legitimate session ID to disguise as a legitimate user, so it is important to ensure that the session ID is not compromised. The previous knowledge about session exposure and pinning can help you ensure that the session ID is only available to the server and legitimate users.
The principle of depth prevention can be used on a session, and some obscure security measures provide some protection when the session ID is unfortunately known by the attacker. As a security-concerned developer, your goal should be to make the aforementioned camouflage process more complex. Remember that no matter how small the obstacles are, your app will protect you.
The key to making the camouflage process more complex is to strengthen validation. The session ID is the first 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 header of the user-agent (the browser type that issued this request) is optional, the browser that emits the header usually does not change its value. If you have a 1234 session ID user after login has been using Mozilla Firfox Browser, suddenly converted into IE, this is more suspicious. For example, at this point you can use the requirements to enter a password to mitigate the risk, while in the wrong time, this is also a relatively small impact on legitimate users. You can use the following code to detect User-agent consistency:
Copy CodeThe code is as follows:
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 Internet Explorer, when a user accesses a webpage and refreshes a webpage, the Accept header information is different, so the accept header cannot be used to judge consistency.
It is true that User-agent header information is consistent, but if the session ID is passed through a cookie (recommended way), it makes sense that if an attacker can obtain a session ID, he can also get other HTTP headers. Because cookie exposure is related to browser vulnerabilities or cross-site scripting vulnerabilities, victims need to visit the attacker's website and expose all header information. All the attackers have to do is rebuild the head to prevent any check of the header information consistency.
The better approach is to produce a token in the URL that can be thought of as the second form of validation (albeit weaker). Using this method requires some programming work and there is no corresponding function in PHP. For example, assuming that the tag is saved in $token, you need to include it in all of your app's internal links:
Copy CodeThe code is as follows:
$url = Array ();
$html = Array ();
$url [' token '] = Rawurlencode ($token);
$html [' token '] = htmlentities ($url [' token '], ent_quotes, ' UTF-8 ');
?>
">click here
To make it easier to manage this delivery process, you might put the entire request string in a variable. You can attach this variable to all links so that you can easily change your code even if you don't use it at first.
The tag needs to contain unpredictable content, even if the attacker knows all the information about the HTTP headers sent by the victim's browser. One way is to generate a random string as a token:
Copy CodeThe code is as follows:
$string = $_server[' http_user_agent ');
$string. = ' Shiflett ';
$token = MD5 ($string);
$_session[' token '] = $token;
?>
When you use a random string (such as Shiflett), it is unrealistic to predict it. At this point, the capture tag will be more convenient than the predictive markup, and the attack needs to fetch both of them by passing the tokens in the URL and passing the session ID in the cookie. This way, unless an attacker is able to see all the HTTP requests that the victim sends to your app, the original information is available, because in this case all the content is exposed. This type of attack is very difficult to implement (so it is rare) to prevent it from needing to use SSL.
There is an expert warning 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 for user-agent consistency. You can generate a random tag:
Copy CodeThe code is as follows:
$token = MD5 (Uniqid (rand (), TRUE));
$_session[' token '] = $token;
?>
Although the security of this method is weaker, it is more reliable. The two methods above provide a powerful means of preventing session hijacking. What you need to do is to strike a balance between security and reliability.
http://www.bkjia.com/PHPjc/825127.html www.bkjia.com true http://www.bkjia.com/PHPjc/825127.html techarticle session data exposure sessions often contain personal information and other sensitive data. For this reason, the exposure of session data is a matter of general concern. In general, the exposed ...
