Let’s first briefly understand some knowledge of http to understand the stateless nature of the protocol. Then, learn some basic operations about cookies. Finally, I will 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 junior PHP programmers will think that the security of PHP's default session mechanism seems to be guaranteed. In fact, it is exactly the opposite - the PHP team only provides a set of convenient session solutions for programs. As for security, it should be strengthened by programmers. This is the responsibility of the application development team. Because there are many methods, so to speak, there is no best, only better. The methods of attack are constantly changing, and the defenders also need to constantly change their tactics. Therefore, I personally think the approach of the PHP team is relatively wise.
1. HTTP statelessness
Http is a stateless protocol. This is because this 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 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, it is a very simple concept. The client makes a request and the server replies. This is the entire communication process based on the http protocol.
Because web applications communicate based on the http protocol, and we have already mentioned that http is stateless, this increases the difficulty of maintaining the state of web applications, which is a big problem for developers. challenge. Cookies were born as an extension of http. Their main purpose is to make up for the stateless characteristics of http and provide a way to maintain the state between the client and the server. However, due to security considerations, some users Cookies are disabled in the browser. In this case, the status information can only be passed to the server through the parameters in the URL, but the security of this method is very poor. In fact, according to the usual thinking, there should be a client to identify itself and maintain a state with the server. However, for security reasons, we should all understand one thing - the information from the client cannot Completely trustworthy.
Despite this, there are relatively elegant solutions to the problem of maintaining web application state. However, it should be said that there is no perfect solution, and no matter how good the solution is, it cannot be suitable for all situations. This article will introduce some techniques. These technologies can be used to maintain the state of the application more stably and resist some attacks against the session, such as session hijacking. And you can learn how cookies work, what PHP sessions do, and how to hijack sessions.
2. HTTP Overview
How can you maintain the status of your web application 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 a user accesses the domain name http://example.com, the browser will automatically establish a tcp/ip connection with the server, and then send an http request to port 80 of the example.com server. The syntax of this request is as follows:
以上第一行叫做请求行，第二个参数（一个反斜线在这个例子中）表示所请求资源的路径。反斜线代表了根目录；服务器会转换这个根目录为服务器文件系统中的一个具体目录。
Apache的用户常用DocumentRoot这个命令来设置这个文档根路径。如果请求的url是http://example.org/path/to/script.php,那么请求的路径就是/path/to/script.php。假如document root 被定义为usr/lcoal/apache/htdocs的话,整个请求的资源路径就是/usr/local/apache/htdocs/path/to/script.php。
第二行描述的是http头部的语法。在这个例子中的头部是Host, 它标识了浏览器希望获取资源的域名主机。还有很多其它的请求头部可以包含在http请求中，比如user-Agent头部，在php可以通过$_SERVER['HTTP_USER_AGENT']获取请求中所携带的这个头部信息。
但是遗憾的是，在这个请求例子中，没有任何信息可以唯一标识当前这个发出请求的客户端。有些开发者借助请求中的ip头部来唯一标识发出此次请求的客户端，但是这种方式存在很多问题。因为，有些用户是通过代理来访问的，比如用户A通过代理B连接网站www.example.com, 服务器端获取的ip信息是代理B分配给A的ip地址，如果用户这时断开代理，然后再次连接代理的话，它的代理ip地址又再次改变，也就说一个用户对应了多个ip地址，这种情况下，服务器端根据ip地址来标识用户的话，会认为请求是来自不同的用户，事实上是同一个用户。 还用另外一种情况就是，比如很多用户是在同一个局域网里通过路由连接互联网，然后都访问www.example.com的话，由于这些用户共享同一个外网ip地址，这会导致服务器认为这些用户是同一个用户发出的请求，因为他们是来自同一个ip地址的访问。
保持应用程序状态的第一步就是要知道如何来唯一地标识每个客户端。因为只有在http中请求中携带的信息才能用来标识客户端，所以在请求中必须包含某种可以用来标识客户端唯一身份的信息。Cookie设计出来就是用来解决这一问题的。
三、cookies
如果你把Cookies看成为http协议的一个扩展的话，理解起来就容易的多了，其实本质上cookies就是http的一个扩展。有两个http头部是专门负责设置以及发送cookie的,它们分别是Set-Cookie以及Cookie。当服务器返回给客户端一个http响应信息时，其中如果包含Set-Cookie这个头部时，意思就是指示客户端建立一个cookie，并且在后续的http请求中自动发送这个cookie到服务器端，直到这个cookie过期。如果cookie的生存时间是整个会话期间的话，那么浏览器会将cookie保存在内存中，浏览器关闭时就会自动清除这个cookie。另外一种情况就是保存在客户端的硬盘中，浏览器关闭的话，该cookie也不会被清除，下次打开浏览器访问对应网站时，这个cookie就会自动再次发送到服务器端。一个cookie的设置以及发送过程分为以下四步：
1.客户端发送一个http请求到服务器端
2.服务器端发送一个http响应到客户端，其中包含Set-Cookie头部
3.客户端发送一个http请求到服务器端，其中包含Cookie头部
4.服务器端发送一个http响应到客户端
这个通讯过程也可以用以下下示意图来描述：
 |
4. get and post data
In addition to cookies, the client can also include data sent to the server in the requested URL, such as request parameters or request path. Let’s look at an example:
The above is a regular http get request. The get request is sent to the index.php script under the web server corresponding to the example.org domain name. In the index.php script, it can be obtained through $_GET['foo'] The value of the foo parameter in the corresponding url, which is 'bar'. Most PHP developers call such data GET data, and a few call it query data or url variables. But everyone needs to pay attention to one thing. It does not mean that GET data can only be included in HTTP GET type requests. GET data can also be included in HTTP POST type requests. As long as the relevant GET data is included in the requested URL, that is. That is to say, the delivery of GET data does not depend on the specific request type.
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 method requires the request type to be POST. See the following example:
In one request, both forms of data can be included:
Although it is much safer to pass the session id in POST than GET. However, the disadvantage of this method is that it is more troublesome, because in this case, it is obviously not appropriate to convert all requests into post requests in your application.
5. Session management
Until now, I have only discussed how to maintain the state of the application, and only briefly touched on how to maintain the relationship between requests. Next, I will explain a technology that is used more in practice – Session management. When it comes to session management, it is not just about maintaining the state between each request, but also needing to maintain the data used for each specific user during the session. We often call this data session data because this data is associated with the session between a specific user and the server. If you use PHP's built-in session management mechanism, the session data is generally saved in the server-side folder /tmp, and the session data will be automatically saved to the super array $_SESSION. One of the simplest examples of using sessions is to pass relevant session data from one page (note: what is actually passed is the session id) to another page. The following uses sample code 1, start.php, to demonstrate this example:
Sample code 1 – start.php
Sample code 2 – continue.php
六、session的安全性问题
一直以来很多开发者都认为php内置的session管理机制是具有一定的安全性，可以对一般的session攻击起到防御。事实上，这是一种误解，php团队只实现了一种方便有效的机制。具体的安全措施，应该有应用程序的开发团队来实施。 就像开篇谈到的，没有最好的解决方案，只有最合适你的方案。
现在，我们来看下一个比较常规的针对session的攻击：
1..用户访问http://www.example.org，并且登录。
2.example.org的服务器设置指示客户端设置相关cookie – PHPSESSID=12345
3.攻击者这时访问http://www.example.org/,并且在请求中携带了对应的cookie – PHPSESSID=12345
4.这样情况下，因为example.orge的服务器通过PHPSESSID来辨认对应的用户的，所以服务器错把攻击者当成了合法的用户。
整个过程的描述，请看下面的示例图：
 |
7. Security enhancement
There are many techniques that can be used to strengthen Session security. The main idea is to make the verification process as simple as possible for legitimate users, and then make the steps as complex as possible for attackers. Of course, this seems to be a difficult balance, and the decision should be made based on the specific design of your application.
The simplest HTTP/1.1 request includes the request line and some Host headers:
PHP will automatically generate a random session ID, which is basically impossible to guess, so the security in this area is still guaranteed. However, it is quite difficult to prevent attackers from obtaining a legitimate session ID, which is basically beyond the control of developers.
In fact, many situations may lead to the leakage of session ID. For example, if the session ID is passed through GET data, this sensitive identity information may be exposed. Because some users may cache, save, or send links with session IDs in email content. Cookies are a relatively secure mechanism, but users can disable cookies in the client! There are also serious security vulnerabilities in some IE versions. The most famous one is that it leaks cookies to some evil sites with security risks.
Therefore, as a developer, you can be sure that the session ID cannot be guessed, but it may still be obtained by an attacker using certain methods. Therefore, some additional security measures must be taken to prevent such situations from happening in your application.
In fact, in addition to the mandatory headers such as Host, a standard HTTP request also contains some optional headers. For an example, look at the following request:
In this case, if you find that the header of the browser has changed, but you are not sure whether this is a request from the attacker, a better measure is to pop up an input box asking for a password for the user to enter, like this If so, the impact on user experience will not be great and attacks can be effectively prevented.
Of course, you can add code to check the User-Agent header in the system, similar to the code in Example 3:
Sample code 3:
3. Carry the attacker’s token in the request
4 .There is a problem here. If the session ID and token are both passed through GET data, then an attacker who can obtain the session ID can also obtain the token. Therefore, a safer and more reliable way should be to use two different data transfer methods to transfer session id and token respectively. For example, pass the session id through cookie, and then pass the token through GET data. Therefore, if an attacker obtains this unique user identity through some means, it is unlikely that he can easily obtain this token at the same time. It is still relatively safe.
There are many technical means that can be used to enhance the security of your session mechanism. I hope that after you have a rough understanding of the internal nature of the session, you can design a verification mechanism suitable for your application system, thereby greatly improving the security of the system. After all, you are one of the developers who is most familiar with the system you are developing and can implement some unique and additional security measures based on the actual situation.
The above only briefly describes the working mechanism of session and briefly explains some security measures. But remember, the above methods can enhance security, but they do not mean that they can completely protect your system. I hope readers will investigate the relevant content themselves. During this research process, I believe you will learn solutions that are of great practical value.
http://www.bkjia.com/PHPjc/751932.htmlwww.bkjia.com
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
