Two security issues for Restful WEB architecture

FromXinlu

Recently, I have written an article about session and cookie security in the current WEB architecture, "a security risk that is easily overlooked in a Restful architecture". I proposed a solution when I discussed it with him at the company. He also mentioned in the article that he had discussed with others in the Post-article comments. Today, let's take a look at some of the issues that need to be paid attention to in the popular WEB system security architecture.

By the way, we will first mention the so-called popular WEB architecture. In terms of network architecture, the current popular trend is different from that of traditional portal websites using layer-7 switching or layer-4 Switching centralized deployment for load balancing, which tends to be distributed nodes in physical locations, use smart DNS to guide users to access the nearest node. Some of these CDN nodes are actually WEB servers, but most of them may be reverse proxies such as Squid or Nginx. The first advantage is a better user experience, and the second is a more flexible way to respond to denial-of-service attacks.

In view of the trend of distributed system deployment, the Restful style mentioned above has become popular in coding. In essence, the so-called Restful style means that the client maintains its own State and the server trusts the State maintained by the client. Return different pages based on different statuses obtained from the client. Here, we try to reduce the server's judgment and other work to reduce the client's dependence on the WEB system. The server only returns results based on the status and sets a new status for the server as needed, this is the so-called state change. This is similar to P2P decentralization. clients do not care about which server they connect to, as long as they maintain their status, the results of connecting to any server in the WEB system are the same. Currently, the popular practice is that session is not applicable only to cookies. Of course, it is also possible to use database sessions. However, I think we should try our best to do these things to the client to reduce the maintenance cost and fault risks of the database server, so that the decentralization is more thorough.

Currently, this distributed cache node is widely used and the client maintains its own state architecture. Two security risks are the risks of sensitive content caching and the risk of client state theft or forgery, it has never been more prominent.

The key aspect of the status check and anti-theft maintained by the client lies in the strength of the cookie encryption algorithm and the reliability of the Integrity check. This reduces the risk when the client status is stolen. I have mentioned how to add a cookie to the timestamp scheme. This article has a very detailed discussion, and many comments will be added after the package.

For more information about user exit and anti-theft. With the Session solution, you can destroy the Session on the server when you exit. Even if a cookie is stolen, refreshing the sessionid saved in the cookie is invalid because the session entity does not exist on the server. In the new no-session solution, implementation will be troublesome. In my opinion, a database is required to record the user's logout status. When a user exits, the user's cookie is cleared, and the user has logged on to the database. Next time, the user no longer uses cookie authentication, and the user must enter a password to log on. In this way, the user can exit the stolen cookie without timeout. It is a pity that a database is added in this way. In combination, the Session is stored in a centralized database, and the deployment is not much worse than simply using cookies.

Sensitive Content caching risks mainly refer to the fact that when user A accesses A node on the CDN, he/she can view some pages that contain his/her own information. However, the WEB system does not guarantee sufficient security in caching, the sensitive information may be inadvertently viewed by user B. Although the cache server may not cache this content, as the cache contacts expand rapidly, the small probability problem will gradually increase. To solve this problem, you can take any of the two points of the cache server and code. Although security can be ensured by configuring Proxy Server policies, the defense should be multi-layered and three-dimensional, And the cache must be clearly controlled in the code. For security, it is necessary to ensure the security of the system in an insecure environment as much as possible. There is no security control in the Code. The cache system deployed this time is secure, and the cache system deployed next time may be neglected. What's more, other third-party cache servers cannot be controlled.

The cache control in the WEB system is described in section 14.9 in RFC2616. The options include public, private, no-cache, and no-store. You can read the RFC documentation carefully. It is worth mentioning the difference between no-cache and no-store. no-store is more strictly controlled than no-cache, according to the original RFC: even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g ., with a "Save As" dialog ).

In general, this popular architecture focuses on distributed deployment and client status maintenance. Therefore, in the architecture, you need to consider cache security and client cookie security. At the beginning of coding, we need to pay attention to these issues. It will be too late to modify the code later.