[Security Science] The nature of sessions you must understand

One thing we must admit is that most web applications are inseparable from the use of sessions. This article will analyze how to establish a secure session management mechanism based on php and http protocol.

First, let's briefly understand some http knowledge to understand the stateless features of the Protocol. Then, learn some basic operations on cookies. Finally, I will explain step by step how to use simple and efficient methods to improve the security and stability of your php application.

I think most php beginners will surely think that the security of the default session mechanism of php seems to be guaranteed, the opposite is true-the php team only provides a set of convenient session solutions for programmers. As for security, it should be enhanced by programmers, which is the responsibility of the application development team. This is because there are many methods, so let's say that there is no best, but better. The attack methods are constantly changing, and the defender also needs to change their tactics. Therefore, I personally think the php team's approach is wise.

Stateless

Http is a stateless protocol. This is because this Protocol does not require the browser to indicate its identity in each request, and there is no persistent connection between the browser and the server 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 simple concept is that the client sends a request and the server sends a response. This is the entire http-based communication process.

Because web applications communicate based on the http protocol, we have already mentioned that http is stateless, which increases the difficulty of maintaining the status of web applications. For developers, it is not a small challenge. Cookies were born as an extension of http. They are mainly used to make up for the stateless feature of http and provide a way to maintain the status between the client and the server, however, for security reasons, some users disable cookies in browsers. In this case, the status information can only be transmitted to the server through parameters in the url. However, this method is of poor security. In fact, according to the general idea, there should be a client to indicate its identity, so as to maintain a state with the server, but for the sake of security, we should all understand that the information from the client cannot be fully trusted.

Despite this, there are still elegant solutions to the problem of maintaining the status of web applications. 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 technologies. These technologies can be used to maintain the application state and defend against session attacks, such as session hijacking. You can also learn how cookies work, what php sessions do, and how they can be hijacked.

Http Overview

How can we maintain the status of web applications and select the most appropriate solution? Before answering this question, you must first understand the underlying web Protocol Hypertext Transfer Protocol (HTTP ).

When the user accesses the http://example.com domain name, the browser will automatically establish a TCP/IP connection with the server, and then send an http request to port 80 of the server of example.com. The request syntax is as follows:

 

GET / HTTP/1.1Host: example.org

The first line is called the request line, and the second parameter (a backslash in this example) indicates the path of the requested resource. The backslash represents the root directory. The server converts the root directory to a specific directory in the Server File System.

Apache users often use the DocumentRoot command to set the root path of this document. If the requested url is http://example.org/path/to/script.php, then the requested url is: // path/to/script.php. If document root is defined as usr/lcoal/apache/htdocs, the resource path of 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 header is Host, which identifies the domain name Host that the browser wants to obtain resources. There are many other request headers that can be included in http requests, such as the user-Agent header. in php, you can use $ _ SERVER [& #039; HTTP_USER_AGENT & #039;] obtain the header information carried in the request.

Unfortunately, in this request example, there is no information that uniquely identifies the client currently sending the request. Some developers use the ip header in the request to uniquely identify the client sending the request, but this method has many problems. For example, if user A connects to www.example.com through proxy B, the server obtains the ip address assigned by proxy B to user, if the user disconnects the proxy and then connects to the proxy again, the proxy IP address changes again, that is, a user corresponds to multiple IP addresses. In this case, if the server identifies a user based on the IP address, the request is considered to be from different users, but actually the same user. Another scenario is that many users connect to the Internet through a route in the same LAN and then access www.example.com. Because these users share the same Internet IP address, this causes the server to think that these users are requests sent by the same user because they are accessed from the same IP address.

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

Cookies

If you think of Cookies as an extension of the http protocol, it will be much easier to understand. In fact, cookies are essentially an extension of http. Two http headers are responsible for setting and sending cookies. They are Set-cookie and Cookie. When the server returns an http Response to the client, if it contains the Set-Cookie header, it indicates that the client creates a cookie, in addition, the cookie is automatically sent to the server in subsequent http requests until the cookie expires. If the cookie is stored throughout the session, the browser saves the cookie in the memory and automatically clears the cookie when the browser closes. In another case, the cookie is stored in the client's hard disk. If the browser is closed, the cookie will not be cleared. The next time you open the browser to access the corresponding website, this cookie is automatically sent to the server again. The setting and sending process of a cookie are divided into the following four steps:

1. the client sends an http request to the server. the server sends an http Response to the client, including the Set-Cookie header. the client sends an http request to the server, including the Cookie header. the server sends an http Response to the client.

The communication process can also be described as follows:

The Cookie header contained in the second request of the client is provided to the server for uniquely identifying the client. Then, the server can determine whether the client has enabled cookies. Although the user may suddenly disable the use of cookies when interacting with the application, this situation is basically unlikely, so you may not consider it, this is also proved to be true in practice.

Session management

Until now, I have only discussed how to maintain the state of the application, but simply involves maintaining the relationship between requests. Next, I will explain how to use more technology-Session management in practice. When session management is involved, it is not only necessary to maintain the status between requests, but also to maintain the data used for each specific user during the session. We often call this data session data because the data is associated with sessions between a specific user and the server. If you use the php built-in session management mechanism, session data is generally stored in the/tmp server-side folder, the session data is automatically saved to the super array $ _ SESSION. The simplest example of using a session is to transfer the relevant session data from one page (Note: The session id is actually passed) to another page. The following uses example code 1, start. php to demonstrate this example:

Sample Code 1-start. php

<?phpsession_start();$_SESSION[&#039;foo&#039;] = &#039;bar&#039;;?>        <a href="continue.php">continue.php</a>

If you click start. php connection to continue. php, then in continue. in php, you can use $ _ SESSION [& #039; foo & #039;] To get it at start. the value 'bar' defined in php '. See the following sample code 2: Sample Code 2-continue. php

<?phpsession_start();echo $_SESSION[&#039;foo&#039;]; /* bar */?>

Is it very simple, but I want to point out that if you write code like this, it means that you are not very familiar with the underlying session implementation mechanism of php. Without understanding how many things php has automatically done for you, you will find that such code will become difficult to debug if the program fails. In fact, such code is completely insecure. Session Security Issues

Many developers have always believed that php's built-in session management mechanism is secure and can defend against general session attacks. In fact, this is a misunderstanding. The php team only implements a convenient and effective mechanism. Specific security measures should be implemented by the application development team. As mentioned in the beginning, there is no best solution, but the best solution for you.

Now, let's look at the next common session Attack:

1. the user accesses the http://www.example.org and logs in. 2.example.org server settings instruct the client to set related cookies-PHPSESSID = 123453. the attacker then accesses http://www.example.org/and carries the cookie-PHPSESSID = 123454 in the request. in this case, because example. the orge server uses PHPSESSID to identify the corresponding user, so the server mistakenly treats the attacker as a legal user.