Session of the working mechanism of detailed and security issues (PHP examples to explain) _php instance

Let's understand the stateless nature of the protocol by simply understanding some of the HTTP knowledge. Then, learn some basic things about cookies. Finally, I'll explain step-by-step how to use some simple, efficient ways to improve the security and stability of your PHP application.

I think most PHP novice programmers will certainly think that PHP default session mechanism security seems to be guaranteed, the fact that the opposite –php team just provides a convenient session of the solution provided to programmers to use, as for security, should be strengthened by programmers, This is the responsibility of the application development team. Because, there are many ways, so to speak, there is no best, only better. The way the attack is changing and the defender needs to be constantly changing, so I personally think that the PHP team's approach is more sensible.

HTTP non-state

HTTP is a stateless protocol. This is because the protocol does not require the browser to identify itself in each request, and the browser and the server do not maintain a persistent connection for access between multiple pages. When a user accesses a site, the user's browser sends an HTTP request to the server, and the server returns an HTTP response to the browser. In fact, a very simple concept, the client a request, the server side of a reply, this is the entire HTTP protocol based communication process.
Because the Web application communicates based on the HTTP protocol, and we've talked about HTTP being stateless, this increases the difficulty of maintaining the state of the Web application, which is a small challenge for developers. Cookies are born as an extension of HTTP, the main purpose of which is to make up for HTTP stateless features, provides a way to maintain the state between the client and server, but for security reasons, some users in the browser is forbidden to drop cookies. In this case, the state information can only be passed to the server side through the parameters in the URL, but the security of this approach is poor. In fact, the usual idea is that there should be a client to identify itself and maintain a state between servers, but for security reasons we should all be aware that the information from the client is not fully trusted.
Despite this, there is a relatively elegant solution to the problem of maintaining the state of the Web application. However, it should be said that there is no perfect solution, and no good solution can be applied to all situations. This article will introduce some techniques. These techniques can be used to maintain the state of the application more stably and to protect against some attacks against the session, such as the conversation hijacking. And you can learn how cookies work, what PHP does with the session, and how to hijack the session.

Ii. Overview of HTTP

How do you maintain the state of your Web application and choose the most appropriate solution? Before you answer this question, you must first understand the web's underlying protocol –hypertext Transfer Protocol (HTTP).

When a user accesses the domain name of http://example.com, the browser automatically establishes a TCP/IP connection to the server and then sends an HTTP request to port 80 on the example.com server. The syntax for the request is as follows:

Copy Code code as follows:

get/http/1.1
Host:example.org

The first line above is called the request line, and the second parameter (a backslash in this case) represents the path of the requested resource. The backslash represents the root directory, and the server converts the root directory to a specific directory in the server file system.
Apache users often documentroot this command to set the document root path. If the requested URL is http://example.org/path/to/script.php, then the path to the request is/path/to/script.php. If document root is defined as Usr/lcoal/apache/htdocs, the resource path for the entire request is/usr/local/apache/htdocs/path/to/script.php.
The second line describes the syntax of the HTTP header. In this example, the head is host, which identifies the domain host to which the browser wants to acquire resources. There are many other request headers that can be included in the HTTP request, such as the user-agent header, where PHP can get the header information that is carried in the request via $_server[' Http_user_agent '.
Unfortunately, in this request example, there is no information that uniquely identifies the client that is currently making the request. Some developers use the IP headers in the request to uniquely identify the client that sent the request, but there are many problems with this approach. Because, some users are through the proxy to access, such as user A through the agent B to connect the site www.example.com, server-side access to IP information is a proxy b assigned to a IP address, if the user then disconnect the agent, and then again connect the agent, its proxy IP address again changed, Also say a user corresponds to multiple IP address, in this case, the server side according to the IP address to identify the user, it will be thought that the request is from different users, in fact, the same user. In other cases, for example, many users connect to the Internet via routing on the same LAN. Then all access to www.example.com, because these users share the same extranet IP address, this causes the server to think that these users are requests from the same user because they are accessed from the same IP address.
The first step in keeping the application state is to know how to uniquely identify each client. Because only the information that is carried in the request in HTTP can be used to identify the client, the request must contain some information that can be used to identify the unique identity of the client. Cookies are designed to solve this problem.

Third, cookies

If you look at cookies as an extension of the HTTP protocol, it's much easier to understand, in essence cookies are an extension of HTTP. There are two HTTP headers that are specifically responsible for setting up and sending cookies, respectively, Set-cookie and cookies. When the server returns an HTTP response message to the client, if it contains the Set-cookie header, it means to instruct the client to create a cookie and automatically send the cookie to the server side in subsequent HTTP requests until the cookie expires. If the cookie's lifetime is the entire session, the browser saves the cookie in memory and automatically clears the cookie when the browser closes. Another situation is to save on the client's hard disk, the browser is closed, the cookie will not be cleared, the next time the browser to open the Web site, the cookie will be automatically sent to the server side. The setting of a cookie and the sending process are divided into the following four steps:

1. The client sends an HTTP request to the server side
2. Server-side sends an HTTP response to the client, which contains the Set-cookie header
3. The client sends an HTTP request to the server side, which contains the cookie header
4. Server-side sends an HTTP response to the client
This communication process can also be described in the following schematic diagram:

In the cookie header included in the second request from the client, the server-side information that can be used to uniquely identify the client is provided. At this point, the server side can also determine whether the client has cookies enabled. Although the user may suddenly disable the use of cookies in the course of interacting with the application, this situation is largely unlikely, so it is not possible to consider it, which is also proved to be right in practice.

Four, get and post data

In addition to cookies, the client can include the data sent to the server in the requested URL, such as the requested parameter or the requested path. Let's take a look at an example:

Copy Code code as follows:

Get/index.php?foo=bar http/1.1
Host:example.org

The above is a regular HTTP GET request, which is sent to the index.php script under the Web server corresponding to the example.org domain name, in the index.php script, through $_get[' foo ' To get the value of the Foo parameter in the corresponding URL, which is ' bar '. Most PHP developers call this data to get data, and a few call it query data or URL variables. However, it is important to note that the get data is not only included in the HTTP Get type request, but also can be included in the HTTP Post type request, as long as the related got data is included in the requested URL. That is, the delivery of get data is not dependent on the type of the specific request.

Another way for a client to pass data to the server side is to include the data in the content area of the HTTP request. This method requires the type of the request to be post, look at one of the following examples:

Copy Code code as follows:

post/index.php http/1.1
Host:example.org
content-type:application/x-www-form-urlencoded
Content-length:7

Foo=bar

In this case, the corresponding value bar can be obtained in the script index.php by calling $_post[' foo '. Developers call this data the post data, known as the way in which the form submits the request in a post manner.

In a request, you can include both forms of data:

Copy Code code as follows:

Post/index.php?myget=foo http/1.1
host:example.orgcontent-type:application/x-www-form-urlencoded
Content-length:11

Mypost=bar
[Code]
These two ways of passing data are more stable than using cookies to pass data, because cookies may be disabled, but this is not the case when passing data in get and post. We can include PHPSESSID in the URL of the HTTP request, as in the following example:
[Code]
Get/index.php? phpsessid=12345 http/1.1
Host:example.org

Passing the session ID in this way can achieve the same effect as passing the session ID with the cookie head, but the disadvantage is that the developer is expected to attach the session ID to the URL or join the form as a hidden field. Unlike cookies, as long as the server side instructs the client to create a cookie successfully, the client will automatically pass the corresponding cookie to the server side in subsequent requests. Of course, PHP can also automatically append the session ID to the URL and the hidden fields of the form after Session.use_trans_sid is turned on, but this option is not recommended because there are security issues. In this way, it is easy to disclose the session ID, such as some users will bookmark a URL or share a URL, then the session ID will be exposed, add this session ID has not expired, there is a certain security problems exist, unless the server side, In addition to the session ID, there are additional ways to verify the legality of the user!

Although the session ID is passed as a post, it is much more secure relative to get. However, the disadvantage of this approach is that it is more cumbersome, because in this case, it is obviously not appropriate to compare all requests to post in your application.

V. Management of Session

Until now, I've only discussed how to maintain the state of an application, simply by involving the relationship between requests. Next, I elaborated in the actual use the more technical –session management. The management of sessions involves not just maintaining the state of each request, but also maintaining the data that is used for each particular user during the session. We often call this data the session data, because the data is associated with a particular user's conversation with the server. If you use PHP's built-in session management mechanism, the session data is typically kept in the folder on the/TMP server side, and sessions data is automatically saved to the Super array $_session. One of the simplest examples of using the session is to pass the relevant session data from one page (Note: The session ID is actually passed) to another page. Here's a demo of this example with example code 1, start.php:

Sample Code 1–start.php

Copy Code code as follows:

<!--? php
Session_Start ();
$_session[' foo '] = ' bar ';
?-->

<a href= "continue.php" >continue.php</a>

If the user clicks on the link in start.php to access continue.php, then in continue.php you can get the value ' bar ' defined in start.php by $_session[' foo '. Look at the following example code 2:

Sample Code 2–continue.php

Copy Code code as follows:

<!--? php
Session_Start ();
echo $_session[' foo ']; /* Bar *
?-->

is not very simple, but I would like to point out, if you really write code like this, you are the bottom of PHP for the session of the implementation mechanism is not very thorough understanding. Without knowing how much internal PHP has done to you automatically, you will find that if a program goes wrong, such code will be difficult to debug, in fact, there is no security at all.

VI. security issues in session

Many developers have long believed that PHP built-in session management mechanism is a certain degree of security, you can attack the general session of the defense. In fact, this is a misconception that the PHP team has only implemented a convenient and efficient mechanism. Specific security measures should be implemented by the development team of the application. As the opening address, there is no best solution, only the best solution for you.

Now, let's take a look at the next more conventional attack against the session:

1. The user accesses the http://www.example.org and logs in.
2.example.org server settings instruct the client to set the related cookie–phpsessid=12345
3. The attacker then accesses the http://www.example.org/and carries the corresponding cookie–phpsessid=12345 in the request
4. In this case, because the Example.orge server uses PHPSESSID to identify the corresponding user, the server mistakenly treats the attacker as a legitimate user.
For a description of the entire process, see the following example diagram:

Of course, the way this attack, the premise is that the attacker must be fixed by some means, hijacked or guessed the phpsessid of a legitimate user. Although this may seem difficult, it is not impossible.

Vii. Strengthening of security

There are a number of techniques that can be used to enhance the security of the session, the main idea is to make the validation process for the legitimate user, the simpler the better, and then for the attacker, the step to the more complex the better. Of course, this seems to be more difficult to balance, to make decisions based on your application's specific design.

The simplest resident http/1.1 request includes the request line and some host's head:

Copy Code code as follows:

get/http/1.1
Host:example.org

If the client passes the associated session identifier through PHPSESSID, the PHPSESSID can be passed in the cookie header:

Copy Code code as follows:

get/http/1.1
Host:example.org
cookie:phpsessid=12345

Similarly, the client can also place the session identifier in the requested URL for delivery.

Copy Code code as follows:

Get/? phpsessid=12345
http/1.1host:example.org

Of course, the session identifier can also be included in the post data, but this has an impact on the user experience, so this approach is rarely used.

Since TCP/IP information may not necessarily be fully trusted, it is not appropriate for Web developers to use information from TCP/IP to enhance security. However, an attacker would also have to provide a unique identifier for a legitimate user in order to impersonate a legitimate user into the system. Therefore, it seems that the only effective way to protect the system is to hide the session identifier as much as possible or make it difficult to guess. The best thing is that both can be implemented.

PHP will automatically generate a random session ID, basically it is impossible to be guessed out, so the security of this aspect has certain protection. However, it is quite difficult to prevent an attacker from acquiring a valid session ID, which is largely out of the control of the developer.

In fact, in many cases, it is possible to cause a session ID to leak. For example, if the session ID is passed through the get data, it is possible to expose the sensitive identity information. Because, some users may cache, bookmark, or send a link with a session ID to the content of the message. Cookies are a relatively safe mechanism, but users can prohibit cookies in the client! In some versions of IE also have a more serious security vulnerabilities, more famous is that will reveal cookies to some of the evil sites with security risks.

Therefore, as a developer, it is certain that the session ID cannot be guessed, but it is still possible that an attacker could obtain it by using certain methods. Therefore, some additional security measures must be taken to prevent such situations from occurring in your application.

In fact, a standard HTTP request contains a number of optional headers In addition to the head that must be included in the host. For example, look at one of the following requests:

Copy Code code as follows:

get/http/1.1
Host:example.org
cookie:phpsessid=12345
user-agent:mozilla/5.0 (Macintosh; U Intel Mac OS X; En-us; rv:1.8.1.1) gecko/20061204 firefox/2.0.0.1
accept:text/html;q=0.9, */*;q=0.1
Accept-charset:iso-8859-1, utf-8;q=0.66, *;q=0.66
Accept-language:en

We can see that in one of the above request examples there are four additional headers, namely User-agent, Accept, Accept-charset, and Accept-language. Because these headers are not necessary, it is unwise to rely entirely on them to play a role in your application. However, if a user's browser does send these headers to the server, then it is certain that the same user will inevitably carry the headers in the next request sent by the same browser. Of course, there will be a very small number of special events. If the above example is a request made by a current user who has established a session with the server, consider one of the following requests:

Copy Code code as follows:

get/http/1.1
Host:example.org
cookie:phpsessid=12345
user-agent:mozilla/5.0

Because the same session ID is included in the requested cookie header, the same PHP sessions are accessed. However, the user-agent header in the request is different from the information in the previous request, can the system assume that the two requests are issued by the same user?

As in this case, found that the browser's head has changed, but not sure if this is a request from the attacker, the better thing is to pop a request to enter the password input box to allow users to input, so that the user experience will not be very great impact, but also very effective to prevent attacks.

Of course, you can include the code that verifies the User-agent header in the system, similar to the code in Example 3:

Example Code 3:

Copy Code code as follows:

<!--? php
Session_Start ();

if (MD5 ($_server[' http_user_agent '))!= $_session[' http_user_agent ']
{/* Pop-up password input box * * EXIT;
}

* * Other code * *
?-->

Of course, you first have to initialize the session at the first request, using the MD5 algorithm to encrypt the user agent information and save it in session, similar to the code in example 4 below:

Example Code 4:

Copy Code code as follows:

<!--? php
Session_Start ();

$_session[' http_user_agent '] = MD5 ($_server[' http_user_agent '));

?-->

Although it is not necessary to use MD5 to encrypt this user-agent information, it is no longer necessary to filter this $_server[' http_user_agent ' data in this way. Otherwise, data filtering must be done before this data is used, because any data from the client is untrusted and must be noted.

After you examine this user-agent client header information, as an attacker, you must complete two steps to hijack a session:

1. Get a valid session ID
2. Contains an identical user-agent head in a forged request

You might say that an attacker can get a valid session ID, so it's not difficult to forge an identical user-agent at his level. Yes, but we can say that at least he added some trouble to him, to some extent also increased the security of the session mechanism.

You can also think that since we can check the head of user-agent to enhance security, then we might as well use some other header information, combine them to generate an encrypted token, and let the client carry the token! in subsequent requests In this way, it is almost impossible for an attacker to guess how such a token is generated. It's like you pay with a credit card at the supermarket, one you have to have a credit card (like the session ID), and you must also enter a payment password (like token), which has both of these in the case that you can successfully enter the account payment. Look at the following code:

Copy Code code as follows:

<!--? php
Session_Start ();

$_session[' http_user_agent '] = MD5 ($_server[' http_user_agent '));

?-->

Note: Accept this head should not be used to generate token, because some browsers will automatically change the head when the user refreshes the browser.

After adding this very difficult token to your validation mechanism, security can be greatly improved. If the token is passed in the same way as the session ID, an attacker would have to complete the necessary 3 steps to hijack a user's session:

1. Get a valid session ID
2. Add the same user-agent head to the request and generate the token
3. Carrying the token of the victim in the request
4. There is a problem here. If the session ID and token are passed through get data, the same token can be obtained for an attacker who gets the session ID. Therefore, the safer and more reliable way is to use two different data delivery methods to pass the session ID and token respectively. For example, pass the session ID through a cookie and pass the token through the get data. Therefore, if an attacker obtains this unique user identity by some means, it is unlikely that the token can be easily acquired at the same time, and it is relatively safe.

There are a number of technical tools that can be used to enhance the security of your session mechanism. I hope you have a general understanding of the internal nature of the session, you can design a suitable application system verification mechanism, so as to greatly improve the security of the system. After all, you are one of the most knowledgeable developers of the system you are developing and can implement specific, additional security measures based on the actual situation.

Viii. Summary

The above is just a general description of the working mechanism of the session, as well as a simple set of security measures. But keep in mind that the above approach is to enhance security, not that you can completely protect your system, I hope the reader to investigate the relevant content. In this research process, I believe you will learn the practical use of the value of the program.