One thing we have to admit is that most web applications cannot do without session. This article will combine PHP and HTTP protocol to analyze how to establish a secure session management mechanism.
Let's start with a brief knowledge of HTTP to understand the stateless nature of the protocol. Then, learn some basic operations about cookies. Finally, I'll explain step by step how to use some simple and efficient methods to improve the security and stability of your PHP application.
I think most PHP junior programmers will think that the security of PHP's default session mechanism seems to be guaranteed. In fact, the opposite is true - the PHP team just provides a set of convenient session solutions for programmers to use. As for the security, it should be strengthened by programmers, which is the responsibility of the application development team. Because, there are many methods in it, so to speak, there is no best, only better. The way of attack is constantly changing, and the defenders need to constantly change their moves, so I personally think the PHP team is more sensible.
Stateless
HTTP is a stateless protocol. This is because this 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 an HTTP request to the server, and the server returns an HTTP response to the browser. In fact, a very simple concept, one request from the client and one reply from the server, is the whole communication process based on HTTP protocol.
Because web applications communicate based on 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 are born as an extension of HTTP. Their main purpose is to make up for the stateless feature of HTTP, providing a way to maintain the state between the client and the server. However, for the sake of security, some users are forbidden to drop cookies in the browser. In this case, the state information can only be passed to the server through the parameters in the URL, but the security of this way is very poor. In fact, according to the general idea, there should be a client to identify itself and maintain a state with the server, but for security reasons, we should all understand that information from the client cannot be fully trusted.
In spite of this, there are relatively elegant solutions for maintaining the state 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 techniques. These technologies can be used to maintain the state of the application and resist some attacks against session, such as session hijacking. And you can learn how cookies work, what PHP sessions do, and how to hijack sessions.
Overview of HTTP
How can we keep the state of web applications and choose the most appropriate solution? Before answering this question, you must first understand the underlying protocol of the web - Hypertext Transfer Protocol (HTTP).
When the user visits the domain name http://example.com, the browser will automatically establish a TCP / IP connection with the server, and then send the HTTP request to port 80 of the server of example.com. The syntax of the request 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 case) represents the path of the requested resource. The backslash represents the root; the server converts the root to a specific directory in the server file system.
Apache users often use the DocumentRoot command 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 resource path of the whole 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 the HTTP request, such as the user agent header. In PHP, you can obtain the header information carried in the request through $﹣ server [&; http﹣ user﹣ agent &;].
But unfortunately, in this request example, there is no information that uniquely identifies the client that is making the request. Some developers use the IP header in the request to uniquely identify the client issuing the request, but there are many problems in this way. Because some users visit through agents, for example, user a connects to the website www.example.com through agent B, The IP information obtained by the server is the IP address assigned by agent B to A. if the user disconnects the agent and connects with the agent again, its proxy IP address will change again, that is to say, a user corresponds to multiple IP addresses. In this case, if the server identifies the user according to the IP address, it will think that the request is from different users, in fact, the same user Households. Another case is that many users connect to the Internet through routing in the same LAN, and then visit www.example.com. Because these users share the same IP address of the Internet, the server will think that these users are requests from the same user, because they come from the same IP address.
The first step in maintaining application state is to know how to uniquely identify each client. Because only the information 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.
Cookies
If you look at cookies as an extension of the HTTP protocol, it's much easier to understand. In fact, cookies are essentially an extension of HTTP. There are two HTTP headers dedicated to setting and sending cookies. They are set cookie and cookie. When the server returns an HTTP response information to the client, if it contains the set cookie header, it means to instruct 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 the entire session, the browser will save the cookie in memory, and the cookie will be automatically cleared when the browser is closed. Another situation is that the cookie is saved 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 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.客户端发送一个http请求到服务器端
2.服务器端发送一个http响应到客户端，其中包含Set-Cookie头部
3.客户端发送一个http请求到服务器端，其中包含Cookie头部
4.服务器端发送一个http响应到客户端
The communication process can also be described as follows:
The cookie header contained in the client's second request provides the information that the server can use to uniquely identify the client. At this time, the server can also determine whether the client has enabled cookies. Although users may suddenly disable the use of cookies in the process of interaction with the application, this situation is basically unlikely to happen, so it can be ignored, which has also been proved correct in practice.
Session management
Until now, I've only discussed how to maintain the state of the application, but I've simply talked about how to maintain the relationship between requests. Next, I'll explain how to use more technologies in practice - session management. When it comes to session management, it's not just to maintain the state between requests, but also to maintain 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 specific user and the server. If you use PHP's built-in session management mechanism, session data is usually saved in the / tmp server-side folder, and the session data in it will be automatically saved to the super array $. One of the simplest examples of using session is to transfer the relevant session data from one page (Note: the actual transfer is the session ID) to another page. Let's use the example code 1, start.php to demonstrate this example:
Example code 1 – start.php
<?php
session_start();
$_SESSION['foo'] = 'bar';
?>
<a href="continue.php">continue.php</a>
If the user clicks the link in start.php to access continue.php, then in continue.php, the value 'bar' defined in start.php can be obtained through $﹐ u session [&﹐ foo & ﹐ 039;]. Look at the following example code 2:
Example code 2 – continue.php
<?php
session_start();
echo $_SESSION['foo']; /* bar */
?>
Isn't it very simple, but I want to point out that if you really write code like this, it means that you don't have a thorough understanding of the implementation mechanism of session at the bottom of PHP. Without knowing how many things PHP has done to you automatically, you will find that if the program goes wrong, such code will become very difficult to debug. In fact, such code has no security at all.
Security of session
For a long time, many developers think that PHP's built-in session management mechanism has certain security and can defend against general session attacks. In fact, this is a misunderstanding, and 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 most suitable one for you.
Now, let's look at the next more conventional attack against session:
1.用户访问http://www.example.org，并且登录。
2.example.org的服务器设置指示客户端设置相关cookie – PHPSESSID=12345
3.攻击者这时访问http://www.example.org/,并且在请求中携带了对应的cookie – PHPSESSID=12345
4.这样情况下，因为example.orge的服务器通过PHPSESSID来辨认对应的用户的，所以服务器错把攻击者当成了合法的用户。