Shulou(Shulou.com)06/03 Report--

The main content of this article is "detailed explanation of the working mechanism of php Session". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the detailed explanation of the working mechanism of php Session.

1. HTTP stateless

Http is a stateless protocol. This is because the protocol does not require the browser to identify itself in each request, and there is no persistent connection between the browser and the server for access between multiple pages. When a user visits a site, the user's browser sends a http request to the server, and the server returns a http response to the browser. In fact, a very simple concept, the client side a request, the server side a reply, this is the whole communication process based on the http protocol.

Because web applications communicate based on the http protocol, and we have said that http is stateless, which increases the difficulty of maintaining the state of web applications, which is not a small challenge for developers. Cookies was born as an extension of http, its main purpose is to make up for the stateless nature of http, and provides a way to maintain the state between the client and the server, but for security reasons, some users prohibit cookie in the browser. In this case, state information can only be passed to the server through parameters in url, but the security in this way is poor. In fact, according to the usual thinking, there should be a client to identify himself and maintain a state with the server, but for security reasons, we should all understand that information from the client cannot be fully trusted.

Even so, there are relatively elegant solutions to the problem of maintaining the state of web applications. However, it should be said that there is no perfect solution, no matter how good the solution can not be applied to all situations. This article will introduce some techniques. These techniques can be used to stably maintain the state of the application and defend against attacks against session, such as session hijacking. And you can learn how cookie works, what php's session does, and how to hijack session.

II. Overview of http

How can you maintain the state of your web application and choose the most appropriate solution? Before you can answer this question, you must first understand the underlying protocol of web-Hypertext Transfer Protocol (HTTP).

When the user accesses the domain name http://example.com, the browser automatically establishes a tcp/ip connection with the server and sends an http request to port 80 of the example.com server. The syntax of the request is as follows:

The copy code is 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 example) represents the path to the requested resource. The backslash represents the root directory; the server converts the root directory to a specific directory in the server file system.

Users of Apache often use the command DocumentRoot to set the document root path. If the requested url is http://example.org/path/to/script.php, then the requested path is / path/to/script.php. If document root is defined as usr/lcoal/apache/htdocs, the entire resource path of the request is / usr/local/apache/htdocs/path/to/script.php.

The second line describes the syntax of the http header. The header in this example is Host, which identifies the host of the domain name that the browser wants to get the resource. There are many other request headers that can be included in http requests, such as user-Agent headers, which can be obtained in php via $_ SERVER ['HTTP_USER_AGENT'].

Unfortunately, in this request example, there is no information that uniquely identifies the client that made the request. Some developers use the ip header in the request to uniquely identify the client that issued the request, but there are many problems with this approach. Because, some users access through the agent, for example, user A connects to the website www.example.com through agent B, and the ip information obtained by the server is the ip address assigned by agent B to A. if the user disconnects the agent at this time, and then connects to the agent again, its proxy ip address changes again, that is to say, one user corresponds to multiple ip addresses, in this case If the server identifies the user based on the ip address, it will assume that the request is from a different user, but in fact it is the same user. Another situation is, for example, if many users connect to the Internet through routing in the same local area network, and then all access www.example.com, because these users share the same extranet ip address, this will cause the server to think that these users are requests made by the same user because they are visiting from the same ip address.

The first step in maintaining the state of the application is to know how to uniquely identify each client. Because only the information carried in the request in the http can be used to identify the client, the request must include some information that can be used to identify the unique identity of the client. Cookie is designed to solve this problem.

III. Cookies

If you think of Cookies as an extension of the http protocol, it's much easier to understand, but cookies is essentially an extension of http. There are two http headers specifically responsible for setting up and sending cookie. They are Set-Cookie and Cookie. When the server returns a http response message to the client, if the header Set-Cookie is included, it means instructing the client to establish a cookie and automatically send the cookie to the server in subsequent http requests until the cookie expires. If the lifetime of the cookie is for the entire session, the browser keeps the cookie in memory and automatically clears the cookie when the browser is closed. Another situation is that it is saved in the client's hard disk, and the cookie will not be cleared if the browser is closed. The next time the browser is opened to visit the corresponding website, the cookie will be automatically sent to the server again. The setting and sending process of a cookie is divided into the following four steps:

1. The client sends a http request to the server

two。 The server sends a http response to the client, which contains the Set-Cookie header

3. The client sends a http request to the server, which contains the Cookie header

4. The server sends a http response to the client

This communication process can also be described by the following diagram:

The Cookie header contained in the client's second request provides the server with information that can be used to uniquely identify the client. At this point, the server side can also determine whether the client has cookies enabled. Although users may suddenly disable the use of cookies while interacting with the application, this is unlikely to happen, so it can be ignored, which has been proved to be true in practice.

IV. Get and post data

In addition to cookies, the client can also include the data sent to the server in the url of the request, such as the parameter or path of the request. Let's look at an example:

The copy code is 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, you can use $_ GET ['foo'] to get the value of the foo parameter in the corresponding url, that is,' bar'. Most php developers say such data will GET data, and a few call it query data or url variables. However, you need to note that GET data can only be included in requests of type HTTP GET. GET data can also be included in requests of type HTTP POST, as long as the relevant GET data is included in the url of the request. In other words, the transmission of GET data does not depend on the specific type of request.

Another way for the client to pass data to the server is to include the data in the content area of the http request. This approach requires that the type of request is POST, as shown in the following example:

The copy code is 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 script index.php can get the corresponding value bar by calling $_ POST ['foo']. Developers call this data POST data, which is also known as the way form submits requests in post.

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

The copy code is 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 cookie may be disabled, but this is not the case when passing data in GET and POST. We can include the 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 header, but the drawback is that the developer needs to attach the session id to the url or add it as a hidden field to the form. Unlike cookie, as long as the server indicates that the client has successfully created the cookie, the client will automatically pass the corresponding non-expired cookie to the server in subsequent requests. Of course, php can also automatically append session id to url and hidden fields in the form when session.use_trans_sid is turned on, but this option is not recommended because of security issues. In this way, it is easy to disclose session id, for example, some users will bookmark a url or share a url, then session id will also expose that joining this session id has not expired, and there are certain security problems, unless on the server side, in addition to session id, there are other ways to verify the legitimacy of users!

Although it is much safer to pass session id words in the POST way than in the GET way. However, the disadvantage of this approach is that it is troublesome, because it is obviously not appropriate to compare all requests to post requests in your application.

V. Management of session

Until now, I've only discussed how to maintain the state of the application, and it's simply about how to maintain the relationship between requests. Next, I will elaborate on the management of Session, which is more commonly used in practice. When it comes to the management of session, you need to maintain not only the state between requests, but also the data used for each specific user during the session. We often call this data session data because it is associated with a session between a particular user and the server. If you use php's built-in session management mechanism, the session data is usually saved in the server-side folder / tmp, and the session data in it is automatically saved to the super array $_ SESSION. One of the simplest examples of using session is to pass relevant session data from one page (note: it is actually session id) to another page. Here is an example of this with sample code 1, start.php:

Sample code 1-start.php

The copy code is as follows:

Continue.php

If the user clicks the link in start.php to access continue.php, then the value 'bar'' defined in start.php can be obtained in continue.php through $_ SESSION ['foo']. Look at the following sample code 2:

Sample code 2-continue.php

The copy code is as follows:

It's not very simple, but I'd like to point out that if you really write code like this, you don't have a good understanding of the underlying php implementation mechanism for session. Without knowing how much php automatically does for you, you will find that if the program goes wrong, such code will become very difficult to debug, in fact, such code is not secure at all.

VI. Security of session

For a long time, many developers have believed that php's built-in session management mechanism has a certain degree of security and can defend against general session attacks. In fact, this is a misunderstanding that the php team has only implemented a convenient and effective mechanism. Specific security measures should be implemented by the application development team. As mentioned at the beginning, there is no best solution, only the one that works best for you.

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

1.。 The user accesses http://www.example.org and logs in.

The server settings of 2.example.org instruct the client to set relevant cookie-PHPSESSID=12345

3. The attacker now 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 identifies the corresponding user through PHPSESSID, the server mistook the attacker for a legitimate user.

For a description of the whole process, see the following example diagram:

Of course, the precondition of this kind of attack is that the attacker must fix, hijack or guess the PHPSESSID of a legitimate user by some means. Although this may seem difficult, it is not impossible.

VII. Strengthening of security

There are many techniques that can be used to enhance the security of Session, the main idea is to make the authentication process as simple as possible for legitimate users, and then for attackers, the more complex the steps, the better. Of course, this seems to be difficult to balance, and decisions should be made based on the specific design of your application.

The simplest HTTP/1.1-resident requests include the request line and some Host headers:

The copy code is as follows:

GET / HTTP/1.1

Host: example.org

If the client passes the relevant session identifier through PHPSESSID, you can pass the PHPSESSID in the cookie header:

The copy code is as follows:

GET / HTTP/1.1

Host: example.org

Cookie: PHPSESSID=12345

Similarly, the client can pass the session identifier in the requested url.

The copy code is as follows:

GET /? PHPSESSID=12345

HTTP/1.1Host: example.org

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

Because information from TCP/IP may not be fully trusted, it is not appropriate for web developers to use the information in TCP/IP to enhance security. However, an attacker must also provide a unique identifier of a legitimate user to enter the system pretending to be a legitimate user. 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 to do both.

PHP will automatically generate a random session ID, which is basically impossible to guess, so there is a certain degree of security in this area. However, it is quite difficult to prevent an attacker from obtaining a legitimate session ID, which is basically beyond the developer's control.

In fact, in many cases, it is possible to cause the leakage of session ID. For example, if session ID is passed through GET data, it is possible to expose this sensitive identity information. Because, some users may cache, collect or send links with session ID in their e-mail content. Cookies is a relatively secure mechanism, but users can disable cookies in the client! There are also serious security vulnerabilities in some versions of IE, more famously leaking cookies to some evil sites with security risks.

Therefore, as a developer, it is certain that session ID cannot be guessed, but it is still possible for an attacker to use some methods to get it. Therefore, some additional security measures must be taken to prevent this from happening in your application.

In fact, a standard HTTP request contains optional headers in addition to the headers that must be included such as Host. For example, take a look at the following request:

The copy code is 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, * / *; qroom0.1

Accept-Charset: ISO-8859-1, utf-8;q=0.66, *; qroom0.66

Accept-Language: en

We can see that four additional headers are included in the above request example, 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, it is certain that they will be carried in the next request sent by the same user through the same browser. Of course, there will be very few special circumstances. If the above example is a request from a current user who has established a session with the server, consider the following request:

The copy code is as follows:

GET / HTTP/1.1

Host: example.org

Cookie: PHPSESSID=12345

User-Agent: Mozilla/5.0

Because the same session id is contained in the Cookie header of the request, the same php session will be 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 made by the same user?

In this case, it is found that the header of the browser has changed, but it is not sure whether this is a request from the attacker, it is better to pop up an input box asking for a password for the user to enter, in this case, the impact on the user experience will not be great, and it can effectively prevent attacks.

Of course, you can add the code to check the User-Agent header in the system, similar to the code in example 3:

Sample code 3:

The copy code is as follows:

Of course, you must first encrypt the user agent information with the MD5 algorithm and save it in session when initializing the session on the first request, similar to the code in example 4 below:

Sample code 4:

The copy code is as follows:

Although it is not necessary to use MD5 to encrypt the User-Agent information, there is no need to filter the $_ SERVER ['HTTP_USER_AGENT'] data in this way. Otherwise, data filtering must be done before using this data, because any data from the client cannot be trusted, and this must be noted.

After you check the User-Agent client header information, as an attacker must complete two steps to hijack a session:

1. Get a legal session id

two。 Contains the same User-Agent header in the bogus request

You might say that an attacker can get a valid session id, so it's not difficult to forge the same User-Agent at his level. Yes, but we can say that this at least adds some trouble to him and increases the security of the session mechanism to some extent.

As you can also imagine, since we can check the User-Agent header to enhance security, 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 was generated. It's like if you use a credit card to pay in the supermarket, you must have a credit card (such as session id), and you must enter a payment password (such as token). If both match, you can successfully enter the account to pay. Take a look at the following code:

The copy code is as follows:

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

After you add this very difficult to guess token to your authentication mechanism, the security will be greatly improved. If the token is passed in the same way as session id, in this case, an attacker must complete the necessary three steps to hijack the user's session:

1. Get a legal session ID

two。 Add the same User-Agent header to the request, using the same as generating token

3. Carry the attacker's token in the request

4. There's a problem here. If both session id and token are passed through GET data, then the token can also be obtained for attackers who can obtain session ID. Therefore, a more secure and reliable way should be to use two different ways of data transmission to pass session id and token respectively. For example, session id is passed through cookie, and then token is passed through GET data. Therefore, if an attacker obtains this unique user identity by some means, it is unlikely that the token can be easily obtained at the same time, and it is still relatively secure.

There are also many techniques that can be used to enhance the security of your session mechanism. I hope that after you have a general understanding of the internal nature of session, you can design a verification mechanism suitable for your application system, so as to greatly improve the security of the system. After all, you are one of the developers who are most familiar with the system you are developing today, and you can implement some unique and additional security measures according to the actual situation.

At this point, I believe you have a deeper understanding of the "detailed explanation of the working mechanism of php Session". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.