From wap website authentication and authorization to csrf protocol analogy nature

Abstract: This article was brewing on Friday. The first half is a summary. The last section is just to illustrate the Security connectivity. It compares csrf to tcp, this article describes the essential causes of csrf from the Protocol perspective. I can't think of writing it to the left half to get a sore waist and a backache. Most of the content can only be carried by the grass. Many places need further explanation and cannot be further described. I have always said that I want to stick to fitness, but I have never been there. It is a sin. Let's take a look at it first. If you have any problems, please point it out.

Now there are more and more WAP sites, especially after the rise of SNS. However, because different browsers on different mobile phones have different support for cookies, wap websites generally cannot use cookies for user authentication for compatibility purposes. Cookie is the basis of the session, so the session is also unavailable. So how can we securely implement authorization for different users of the wap website? Here we will briefly summarize the two available reliable solutions. According to this conclusion, we will introduce the csrf issue of common websites. (Although session is based on cookies, they are described here as two different things)

The first solution is the pseudo-session solution. First, let's look at the session principle of traditional websites. The client cookie stores a unique session id, which corresponds to a file on the server, after expansion, it can be memory or stored in the database. When a user accesses a website, the cookie carries the session id. The server obtains the content of the corresponding file based on the session id to verify the user identity or perform other operations. The key to a traditional session lies in two points. The first point is that the server stores a unique name, which can be stored in files, memory, databases, or other places. The second is the unique name that the client saves the content and adds it to each visit to the website.

When the session scheme is used, there are two major changes after a common website is converted into a wap website, the first point is that the client sends the session id to the server each time a request is initiated without a cookie. Simply put, when a GET request is sent, the session id can be directly appended to the URL. When a POST request is sent, the session id is sent to the server as an implicit field of form, the server obtains the session id from the content and obtains the session content stored on the server for permission verification. The url generated by the final get request is similar to/getlist. do? Sid = sessionid, and post is an implicit field in form.

The second change is to implement a slightly different reading setting mechanism for session generation on the server and the method for transmitting the session id to the client. After a user logs on successfully, the server generates a session id based on the algorithm. The session id can be generated with a random number of sufficient lengths or an irreversible hash algorithm, such as the MD5 algorithm, session id = MD5 (loginname + logintime + salt ). At the same time, the session id is used as the file name to generate a file (of course, it can also be the memory, or database entry with the session id as the primary key) to save users' key information, such as the user login status. After generation is completed, when the login page is returned to the client, the session id is appended to the url of the get request and the form of the post request. The main change in pseudo-session reading and setting is the location of the session id, from the cookie to the get parameter or post content. This is very simple, after obtaining the session id, you can directly modify the corresponding file (or memory, database entry.

Through the above two points, you can implement a session mechanism in the wap site, which serves as the basis for operations such as permission judgment after login. With the development of the new web architecture, more systems are decentralized for the convenience of Server Load balancer, and the client maintains its own status.Two security issues for Restful WEB architectureAlso mentioned. Therefore, it is necessary to implement a pseudo cookie Mechanism as the basis for authentication and authorization.

The difference between the pseudo-cookie Mechanism and the pseudo-session mechanism is the same as that between the cookie mechanism and the session mechanism, both of which lies in whether key data is stored on the client, the session mechanism client only needs to save a session id that corresponds to the server, the server stores key information, and the cookie Mechanism stores all the information on the client. The implementation of the pseudo cookie Mechanism is similar to that of the pseudo session mechanism. The server sets the client and sends messages from the client to the server. The difference is that they are generated. This is because the session id only corresponds between the client and the server, and the cookie itself needs to be used as the verification data. Therefore, when using the cookie mechanism, ensure that the server can decrypt and read the content of the cookie, this determines that the pseudo-cookie Mechanism can only use reversible encryption algorithms, rather than MD5 HASH algorithms that generate session IDs.

I'm tired today, so I'm too lazy to elaborate on why. Just give a rough description. Cookie encryption algorithms use symmetric encryption such as AES or asymmetric RSA. The generated method is roughly base64 (RSA ("uniqid = random () & loginname = test & loginresult = success & logintime = 20090222235143", private_key )), the signature can be implemented using md5 (url + cookie + salt. Uniqid is used when the user exits. The logintime record timestamp is used to implement the pseudo cookie expiration mechanism. Others are easy to understand. As for the reason why the pseudo-session mechanism does not require a signature, the signature is required here because their security requirements are different. Even if the session id is forged during a pseudo-session, the session id does not exist on the server, so there is no security problem. The pseudo-cookie authorization mechanism, once the encryption algorithm cracks a forged cookie, can also be discarded by adding the md5 Signature of salt.

Continue to make quick improvements. Now let's talk about the role of this mechanism in wap in normal websites-defending against csrf attacks. It is easy to simply simplify the algorithm in the pseudo cookie Mechanism. The signature self-check ensures that the token is not forged, and the timestamp is used to ensure that the token is not replayed. In addition, compared with the traditional scheme, the server does not need to make a memory comparison on the generated random token string.

What is interesting is the reason why csrf is generated. Here I will not talk about it from the web perspective, but try to explain it from the Protocol perspective. My main purpose is to say that security is the same. Csrf simply says that after a user logs on to site a and accesses site B, the user initiates a request to site a at site B's background, and site a executes the request. From the Protocol point of view, this is because the http protocol is in the "get" Mode for multiple times and the response mode is stateless and chaotic. In the interaction between the user and Site a, a data packet is inserted and executed by site. So why does the insertion and execution of such packets not occur on the tcp layer eventually lead to chaotic results? The tcp packet has seq and ack serial numbers. Similarly, the udp protocol has a problem similar to csrf, and is inserted and forged in the Protocol. However, the udp-based dns protocol is relatively reliable. Why? Or because there is a dns id in the dns request and response. Based on the analogy of this Protocol, it is clear that all csrf solutions now implement a similar protocol id for the http protocol.

As the protocol serial number, generally it is the initial value generated by the client, and then changes in the interaction between the client and the server. Due to the WEB Client, the protocol serial numbers implemented by the csrf defense scheme can only be generated by the server and then interacted and changed. In tcp, when the initial values of seq and ack are known in a tcp session, the serial numbers of other packets can be inferred. In a sense, it is similar to tcp, in csrf's defense, a user's login activity is a life cycle of the protocol id, which is acceptable in terms of security.

Sleep on a heavy rain night. Now it is indeed a little old, and the energy is not good, it is only 11 o'clock tired.