CN116389014A

CN116389014A - Access method, system, electronic device and computer readable storage medium

Info

Publication number: CN116389014A
Application number: CN202111582612.2A
Authority: CN
Inventors: 邱晨; 王晨光; 王波; 谭瑞环
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2021-12-22
Filing date: 2021-12-22
Publication date: 2023-07-04

Abstract

The embodiment of the application relates to the technical field of communication, and discloses an access method, an access system, electronic equipment and a computer readable storage medium. The access method comprises the following steps: receiving a login request of a client; after the login request is successfully checked, generating a random number seed and sending the random number seed to the client; receiving an access request sent by the client; the access request carries a name value pair, and the name in the name value pair is as follows: the client side carries out serialization operation according to the random number seeds to obtain a value; and checking the names in the name value pair, and determining that the values in the name value pair are legal after the checking is passed, so that the access security can be ensured and the system resources can be saved.

Description

Access method, system, electronic device and computer readable storage medium

Technical Field

Embodiments of the present application relate to the field of communications technologies, and in particular, to an access method, an access system, an electronic device, and a computer readable storage medium.

Background

Along with the continuous expansion of the scale of WEB application and the continuous development of network technology, the functional requirements of the Internet on the WEB application are increasingly complex, and at the same time, permeation attack means aiming at WEB security holes are endlessly layered. The security problem of the WEB application is increasingly prominent, and the WEB application is used as the most direct contact medium of hackers, so that more advanced security protection technology needs to be developed aiming at potential security threats.

At present, in order to protect a parameter value transmitted in an access process, a manner of directly encrypting the parameter value is generally adopted to avoid the parameter value from being attacked, however, the parameter value is generally complex and lengthy, so that the manner of directly encrypting the parameter value requires a large amount of calculation and occupies more system resources.

Disclosure of Invention

The main object of the embodiments of the present application is to provide an access method, system, electronic device and computer readable storage medium, so that system resources can be saved while access security is ensured.

In order to achieve at least the above object, an embodiment of the present application provides an access method, which is applied to a server, and includes: receiving a login request of a client; after the login request is successfully checked, generating a random number seed and sending the random number seed to the client; receiving an access request sent by the client; the access request carries a name value pair, and the name in the name value pair is as follows: the client side carries out serialization operation according to the random number seeds to obtain a value; and checking the names in the name value pair, and determining that the values in the name value pair are legal after the checking is passed.

In order to achieve at least the above object, an embodiment of the present application further provides an access method, which is applied to a client, and includes: a login request is sent to a server side, so that after the login request is successfully checked by the server side, a random number seed is generated; receiving the random number seed sent by the server; sending an access request to the server side so that the server side can check the names in the name value pairs carried in the access request, and determining that the values in the name value pairs are legal after the check is passed; wherein, the names in the name value pair are: and the client performs serialization operation according to the random number seeds to obtain a value.

To achieve at least the above object, an embodiment of the present application further provides an access system, including: the system comprises a server and a client; the client is used for sending a login request to the server; the server is used for generating a random number seed after the login request is successfully checked, and sending the random number seed to the client; the client is further configured to send an access request to the server; the access request carries a name value pair, and the name in the name value pair is as follows: the client side carries out serialization operation according to the random number seeds to obtain a value; the server is further configured to check a name in the name value pair carried in the access request, and determine that the value in the name value pair is legal after the check is passed.

To achieve at least the above object, an embodiment of the present application further provides an electronic device, including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executable by the at least one processor; in the case that the electronic device is a server, the at least one processor is capable of executing the above access method applied to the server; in the case that the electronic device is a client, the at least one processor is capable of executing the above-described access method applied to the client.

To achieve at least the above object, embodiments of the present application further provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above access method.

According to the access method provided by the embodiment of the application, after receiving the login request of the client, the server checks the login request, generates a random number seed and sends the random number seed to the client after the login request is successfully checked, receives the access request sent by the client, and carries a name value pair, wherein the name of the name value pair is as follows: the client performs serialization operation on the random number seeds to obtain values, the server performs verification on the names in the name value pair, and after the verification is passed, the server determines that the values in the name value pair are legal. That is, in the embodiment of the present application, encryption transmission is not required for a value that may be complex and lengthy in a name-value pair, and verification is performed on a name in the name-value pair to verify whether the value in the name-value pair is legal, so that system resources are saved as much as possible, and access security is improved while system resources are saved.

Drawings

Fig. 1 is a flow chart of an access method applied to a server in an embodiment of the present application;

FIG. 2 is a flowchart of the steps performed after verification of the names in the name-value pair in step 104 mentioned in the embodiments of the present application;

FIG. 3 is a simplified message comparison chart mentioned in the embodiment of the present application;

FIG. 4 is a flowchart of interaction between a server and a client according to an embodiment of the present application, where the access method is mentioned;

FIG. 5 is another interactive flow chart between a server and a client related to an access method in an embodiment of the present application;

FIG. 6 is a flowchart of still another interaction between a server and a client involved in mentioning an access method in an embodiment of the present application;

FIG. 7 is a flow chart of an access method applied to a client mentioned in an embodiment of the present application;

FIG. 8 is a schematic diagram of an access system as referred to in an embodiment of the present application;

fig. 9 is a schematic structural diagram of the electronic device mentioned in the embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the embodiments of the present application will be described in detail below with reference to the accompanying drawings. However, as will be appreciated by those of ordinary skill in the art, in the various embodiments of the present application, numerous technical details have been set forth in order to provide a better understanding of the present application. However, the technical solutions claimed in the present application can be implemented without these technical details and with various changes and modifications based on the following embodiments. The following embodiments are divided for convenience of description, and should not be construed as limiting the specific implementation of the present application, and the embodiments may be mutually combined and referred to without contradiction.

The embodiment of the application provides an access method which is applied to a server. The main application scenarios of this embodiment may include: the client accesses a World Wide Web (Web) application, which includes Web services such as Web Server, web application program interface (Application Programming Interface, API), and the like. The embodiment is suitable for session management between a WEB client and a server, and the WEB session management is a session state supporting technology for performing a stateless hypertext transfer protocol (Hyper Text Transfer Protocol, HTTP) protocol. That is, the present embodiment may be based on a stateless HTTP session management mechanism, and the client and the server may be in an IP address-based internet environment. The server saves the state of the client through session management and associates the requests of the client. The access method in this embodiment can be implemented regardless of the network layer in which the client and the server are located.

In one embodiment, a flow chart of an access method may refer to fig. 1, including:

step 101: and receiving a login request of the client.

Step 102: after the login request is successfully checked, a random number seed is generated and sent to the client.

Step 103: receiving an access request sent by a client; the access request carries a name value pair, and the names in the name value pair are as follows: and the client performs serialization operation according to the random number seeds to obtain a value.

Step 104: and checking the names in the name value pair, and determining that the values in the name value pair are legal after the checking is passed.

In the embodiment of the application, encryption transmission is not required for the possibly complex and lengthy value in the name value pair, and the name in the name value pair is checked to verify whether the value in the name value pair is legal, so that the system resource can be saved as much as possible, and the access security is improved and the system resource can be saved.

In step 101, the client may send a login request for logging in to the WEB application to the server. For example, the user may input the registered account number and password through the client, and the client sends the account number and password input by the user to the server in the login request.

In step 102, the server may check the account number and the password carried in the login request to determine whether the check on the login request is successful. Therefore, after the login request is successfully checked, the server generates a random number Seed and sends the random number Seed to the client.

After receiving the random number Seed, the client can perform serialization operation according to the Seed to obtain C-Name0, and when sending an access request to the server, the client takes Name0 as a Name in a Name value pair to be carried in the access request. The value in the name-value pair carried by the access request may be the parameter value that is desired to be protected during the access.

After the server generates the random number Seed, the server can perform serialization operation according to the Seed to obtain S-Name0, and store the S-Name0 for checking the Name in the Name value pair carried by the access request sent by the subsequent client.

In a specific implementation, the server and the client may negotiate an algorithm of the serialization operation in advance, so that the server and the client can use the same algorithm to perform the operation when performing the serialization operation. The algorithm of the serialization operation may be an encryption algorithm that ensures that the result of the operation is unique, including but not limited to an irreversible encryption algorithm. The algorithm of the serialization operation can be selected according to actual needs, for example, an encryption algorithm can be selected as the algorithm of the serialization operation, or a plurality of encryption algorithms are overlapped to obtain the algorithm of the serialization operation. However, the algorithm specifically adopted for the serialization operation in the present embodiment is not particularly limited.

In step 103, the server receives an access request sent by the client; the access request carries a name value pair, and the names in the name value pair are as follows: the client side carries out serialization operation on the Seed to obtain a value.

In step 104, the server analyzes the access request to obtain a name value pair carried in the access request, and verifies the name in the name value pair. The checking method can be as follows: and determining whether the names in the name value pair are the same as the value obtained by the server side after carrying out the serialization operation on the Seed. If so, a check pass may be determined, otherwise, a check fail is determined.

In this embodiment, after the verification of the name in the name value pair is passed, it is determined that the value in the name value pair is legal, so that the server may respond to the access request from the client, if the verification of the name in the name value pair is not passed, it is determined that the value in the name value pair is not legal, so that the server refuses the access request from the client, and the session between the server and the client may also be closed. The verification mode adopted in the embodiment is beneficial to saving system resources while improving access security.

In one embodiment, the values in the name-value pair carried by the access request include: the legal identification Session ID of the current effective Session negotiated by the server and the client. That is, when the client sends an access request to the server, the Session ID may be used as a value in the carried name value pair. In the embodiment, encryption transmission of the Session ID is not needed in the access process, and the validity of the Session ID is judged by checking the name in the name value pair carried by the access request, so that system resources are saved as much as possible, and the method is favorable for WEB security access Session management with high security, high reliability and high efficiency.

The Session is used as a Session state, and is commonly found in modern WEB application systems, and is mainly used for maintaining state information related to a current client, so as to track a Session of each client. Session is identified by using a Session ID generated by the server to distinguish users. Session is unique to each client, and when a user logs in a WEB application for the first time and establishes connection with a server, the server can distribute a Session ID to the current client as a unique legal identifier of an effective Session.

The manner in which the client obtains the Session ID may be: after the login request is successfully checked, the server receives a Session negotiation request sent by the client, the server generates a legal identification Session ID of the current effective Session, and the server sends the generated Session ID to the client. In a specific implementation, after the server generates the random number seed, the random number seed and the Session ID may be sent to the client together.

The applicant finds through research that the Session ID generally exists in the header for transmission, and is very easy to intercept and forge because the header is transmitted in the clear text, and the Session ID is used as a legal identifier of an effective Session. By means of attack means such as Session prediction, session hijacking, session fixing and the like, an attacker can easily acquire an effective Session ID, and further an illegal Session can be disguised as a legal Session to perform illegal operation attack on WEB application, so that the attack aiming at the Session ID is very easy to bypass a security protection system with security holes, and a large amount of damage is caused to the system. At present, a Session ID encryption transmission mechanism is commonly used to improve the security of the Session ID, but small terminal devices in the communication field occupy more system resources, and the Session ID binding Cookie security attribute and verification mechanism cannot cope with increasingly serious security challenges. Based on this, in this embodiment, by carrying a name value pair in the access request, the value in the name value pair is the Session ID, and the name in the name value pair is checked and passed, which represents that the value in the name value pair is legal. The names in the name-value pair are obtained by carrying out serialization operation in combination with the random number seed, which is equivalent to encrypting the relatively simple names in the name-value pair instead of encrypting the relatively complex values in the name-value pair, so that the access security is ensured and the occupied system resources are reduced.

In one embodiment, after the login request is successfully checked by the server side, generating a random number Seed and a legal identification Session ID of the current effective Session, performing serialization operation on the Seed by the server side to obtain an S-Session Name, storing the Seed, the S-Session Name and the Session ID, and returning the Seed and the Session ID to the client side in the form of Name value to Seed: session ID. After receiving the Name-value pair Session ID, the client side carries out serialization operation on the Name Seed in the Name-value pair to obtain a C-Session Name, and saves the Seed, the C-Session Name and the Session ID. When the client needs to send an access request to the server, the client sends a Name value pair C-Session Name: the Session ID is carried in the access request, after the server receives the access request, the server checks whether the carried Name C-Session Name is consistent with the stored S-Session Name, if so, the Session ID carried in the access request is legal, if not, the Session ID carried in the access request is illegal, the execution of the access request is refused, and the Session is closed. The Session ID is legal to prove that the access request is issued by a legal client.

In this embodiment, the session negotiation request is a request initiated by the server side in the session negotiation stage between the server side and the client side, and the access request may be understood as a session validity check request initiated by the client side after the session negotiation is successful. After the client logs in successfully and successfully negotiates with the server to obtain the Session ID, each operation, each click and each configuration of the client can be understood as an access request, and the server confirms that the access request is legal and processes the request and returns a processing result response to the client.

In one embodiment, the values in the name-value pair carried by the access request include: the client requests the configured parameter values. At this time, the access request can be understood as a parameter configuration request. The parameter configuration request may be understood as a parameter configuration request initiated by the client after the session between the server and the client is established successfully. The parameter value requested to be configured by the client may be a parameter value of a sensitive parameter, such as a mobile phone number, a password, etc. input by a user. In the embodiment, the validity of the parameter value of the parameter requiring configuration can be checked, the complicated parameter value encryption transmission is replaced by using simple parameter name serialization operation, the system resource consumption is reduced, the safety in the parameter transmission process is considered, and the method has great reference value for small terminal equipment in the communication field.

In one embodiment, after the login request is successfully checked by the server side, a random number Seed is generated, the server side performs serialization operation on the Seed to obtain an S-Name, the Seed and the S-Name are stored, and the Seed is returned to the client side. After receiving the Seed, the client performs serialization operation on the Seed to obtain a C Name, and stores the Seed and the C-Name. When the client needs to send a parameter configuration request to the server, the client sends a Name value pair C-Name: the parameter value is carried in the parameter configuration request, after the server receives the parameter configuration request, the server checks whether the Name C-Name carried by the parameter value is consistent with the stored S-Name, if so, the parameter value carried in the parameter configuration request is legal, if not, the parameter value carried in the parameter configuration request is illegal, and the execution of the parameter configuration request is refused.

In one embodiment, the Name-value pair carried in the access request may include a plurality of Name-value pairs, for example, including the Name-value pair C-Session Name described above: session ID, name value pair C-Name: parameter values. The server confirms that the Session ID contained in the access request is legal, so as to prove that the request is sent by a legal user. After confirming that the Session ID is legal, if the Name value pair C-Name: and if the parameter value in the parameter values is legal, configuring the parameter value in the access request to the server.

In one embodiment, the name-value pairs are carried in the header of the access request or in form parameters of the body of the access request. In this embodiment, the name value pair may be carried in different locations in the access request, which is beneficial to meeting different needs in practical applications. Because the form parameters support ciphertext transmission, when the name value pairs are carried in the form parameters, the ciphertext transmission can be further carried out by combining the parameter asymmetric encryption and decryption processes, simple and direct safe frame support is provided for an application scene requiring encryption and decryption of the request data, and the method has very high adaptability and expandability, and is beneficial to further improving the safety of access.

In one embodiment, the Name value pair carried in the access request may be a C-Session Name: session ID, which may be carried in a header of the access request or in a form parameter of a body of the access request.

In one embodiment, the Name value pair carried in the access request may be C-Name: parameter value, the C-Name: the parameter values may be carried in the header of the access request or in form parameters of the body of the access request.

In one embodiment, the receiving the access request sent by the client in step 103 includes: the implementation flow of checking the name in the name value pair in step 104, which may refer to fig. 2, includes:

step 1041: determining whether the name carried in the ith access request is consistent with a value obtained by 2i-1 th serialization operation of the server side; if yes, go to step 1042, otherwise go to step 1043.

When i=1, the name carried in the 1 st access request is: the client performs the 1 st serialization operation according to the random number seed to obtain a value; the value obtained after the 1 st serialization operation of the server is as follows: the server side performs the 1 st serialization operation according to the random number seeds to obtain a value;

When i is more than 1 and less than or equal to n, the name carried in the ith access request is as follows: the client performs the ith serialization operation according to the random number seed and the value obtained after the 2 nd (i-2) th serialization operation of the server, and the obtained value; the value obtained after the 2i-1 th serialization operation of the server is as follows: the server performs 2i-1 th serialization operation according to the random number seed and the value obtained after 2i-2 nd serialization operation of the server, and n is a natural number greater than or equal to 2.

Step 1042: and determining that the verification passes.

Step 1043: and determining that the verification is not passed.

It can be understood that, when the client logs in the WEB application of the server, the client and the server continuously send multiple access requests to the server in the session process. In this embodiment, names in the name value pair carried by the access request sent by the client each time are different, and names in the name value pair carried by other access requests after the first access request are combined with some previous historical data and random number seeds to perform serialization operation, so that the difficulty that the names in the name value pair are attacked is increased, for example, when an attacker intercepts the names in the name value pair carried by a certain access request, the serialization operation cannot be performed due to the fact that no names and no Seed in the name value pair carried by the historical access request exist, so that verification of the server cannot be passed, and safety in the access process is greatly improved.

The following description will take an access request as a session negotiation request as an example:

after the login request of the client is successfully checked, the server generates a legal identification Session ID of the current effective Session, generates a corresponding random number Seed Seed, performs serialization operation on the Seed to obtain a Session Name, stores the Session Name and Session ID, and sends a Session ID to the client for storage, wherein the Session ID is used for the operation of a Session negotiation request carried Name value pair sent by the subsequent client. The name carried in the 1 st session negotiation request is sent by the client side: the client side carries out the 1 st serialization operation on the random number Seed to obtain a value, namely the client side sends a Name value pair Session Name carried in the 1 st Session negotiation request, the Name Session Name in Session ID is a value obtained by serialization operation on Seed, the Session Name of the subsequent server side needs to be stored after serialization operation on Seed, the newly generated Name value pair Session Name is sent to the client side, and the client side also needs to take the value obtained by serialization operation on the received new Session Name and Seed as a Name in a Name value pair carried in the Session negotiation request when submitting the next Session negotiation request, so that the server side checks the Name in the Name value pair and stores the value after serialization operation as a history Session Name. Thus, when an attacker intercepts the Session Name transmitted in the middle, since no history Session Name and no Seed can be processed in a serialization operation, the server cannot pass through the server Session Name checking mechanism, and the server can consider that the value Session ID corresponding to the Name Session Name is illegal, and further cannot forge the current Session request through the Session ID.

In order to facilitate understanding of the difference between the name value pairs carried in the multiple session negotiation requests obtained by adopting the serialization operation manner in this embodiment and the name value pairs carried in the conventional multiple session negotiation requests, reference may be made to the simple message comparison diagram in fig. 3. The left part of fig. 3 is a name value pair carried in a conventional multiple session negotiation request, and it can be seen that: the name value pairs carried in the traditional multiple Session negotiation requests are relatively identical, and the meaning of a string of character strings behind the Session-ID is the value of the parameter of the Session ID, so that any one time of interception of the multiple Session negotiation requests easily causes theft of the name value pairs carried in the Session negotiation requests, and an attacker easily falsifies the Session negotiation requests. The right side of fig. 3 is a name value pair carried in the multiple session negotiation requests obtained by adopting the serialization operation manner in this embodiment, where AfG YL may be understood as a name in a name value pair carried by the 1 st session negotiation request, zhompsy may be understood as a name in a name value pair carried by the 2 nd session negotiation request, and VHGsq2 may be understood as a name in a name value pair carried by the 3 rd session negotiation request. The name value pairs carried in the 3 session negotiation requests on the right of fig. 3 are all different, and it cannot be seen which parameter value the values after the names AfG1YL, ZHOPsY, VHGsq represent. Therefore, in the technical solution of this embodiment, even if an attacker intercepts a name value pair carried in a session negotiation request, since the name in the name value pair is a name obtained after the serialization operation, the attacker cannot obtain valid information from the intercepted name value pair, and further cannot falsify the session negotiation request through the intercepted name value pair.

The embodiment provides a WEB application safety access protection method based on the Session ID of the random number seed serialization operation mechanism, so that an attacker can not use the valid legal Session ID through verification even if intercepting the Session Name after the seed serialization operation, thereby protecting attack means such as Session prediction, session hijacking, session fixing and the like and enhancing the safety degree of WEB application access.

In one embodiment, after determining that the verification passes in step 1042, the method further comprises:

step 105: and carrying out the 2 i-th serialization operation according to the value obtained after the 2 i-1-th serialization operation of the server and the random number seed to determine the value obtained after the 2 i-th serialization operation of the server.

Step 106: and sending the value obtained after the 2 i-th serialization operation of the server to the client so that the client can perform the i+1-th serialization operation according to the value obtained after the 2 i-th serialization operation of the server and the random number seed to determine the value obtained after the i+1-th serialization operation of the client.

Step 107: according to the value obtained after the 2 i-th serialization operation of the server and the random number seed, 2i+1-th serialization operation is carried out to determine the value obtained after the 2i+1-th serialization operation of the server; the value obtained after the 2i+1st serialization operation of the server is used for the server to verify the name in the name value pair carried by the (i+1) th access request.

In this embodiment, after each time the name verification carried in the access request passes, the server calculates the data required by the next verification, so that the verification of the next received access request is facilitated, and the WEB security access session management with high security, high reliability and high efficiency is realized through a random number seed serialization growth evolution mechanism in the whole session process.

The following description will be given with i=1 and i=3, respectively:

when i=1, that is, the server receives the 1 st access request sent by the client, after the name verification of the 1 st access request carried by the name value pair passes, the server performs the 2i (2) th serialization operation according to the value obtained by the 2i-1 (1) th serialization operation of the server and the random number Seed, so as to determine the value obtained by the 2i (2) th serialization operation of the server. The server sends the value obtained after the server 2i (2) order serialization operation to the client, so that the client can perform the i+1 (2) th order serialization operation according to the value obtained after the server 2i (2) order serialization operation and the random number Seed, and the value obtained after the client i+1 (2) order serialization operation is determined. The server end performs 2i+1 (3) th serialization operation according to the value obtained by the 2i (2) th serialization operation of the server end and the random number seed to determine the value obtained by the 2i+1 (3) th serialization operation of the server end; the value obtained after the 2i+1 (3) sequence operation of the server is used for the server to verify the name in the name value pair carried by the (i+1) th access request.

When i=3, that is, the server receives the 3 rd access request sent by the client, after the name verification of the name value pair carried by the 3 rd access request passes, the server performs the 2i (6) th serialization operation according to the value obtained by the 2i-1 (5) th serialization operation of the server and the random number Seed, so as to determine the value obtained by the 2i (6) th serialization operation of the server. The server sends the value obtained after the 2i (6) th serialization operation of the server to the client, so that the client can perform the (i+1) (4) th serialization operation according to the value obtained after the 2i (6) th serialization operation of the server and the random number Seed, and the value obtained after the (i+1) (4) th serialization operation of the client is determined. The server end then carries out 2i+1 (7) th serialization operation according to the value obtained after 2i (6) th serialization operation of the server end and the random number seed to determine the value obtained after 2i+1 (7) th serialization operation of the server end; the value obtained after the 2i+1 (7) sequence operation of the server is used for the server to verify the name in the name value pair carried by the (i+1) th access request.

In a specific implementation, the random number seed serialization operation mechanism in this embodiment may be applied to a secure access procedure of a WEB application, including, but not limited to, WEB client request validity verification and WEB session management. Optionally, the random number seed serialization operation mechanism can also be applied to data encryption access transmission of the WEB application, including but not limited to data encryption transmitted by the WEB client and the WEB server.

In one embodiment, the value in the name value pair carried by the access request sent by the client is a Session ID, the name value pair is sent to the server through the header, and the interaction flow chart between the server and the client related to the access method can refer to fig. 4, which includes:

step 401: and the user logs in the WEB application of the server through the client.

Step 402: after successful login verification, the server generates a legal identification Session ID of the current effective Session, generates a random number Seed Seed, performs 1 st serialization operation according to the Name Seed to obtain an S-Session Name0, stores Seed, the S-Session Name0 and Session ID, and returns a Name value pair Session ID to the client. The Session ID may be generated after the server receives the Session negotiation request of the client. It should be noted that, the process of sending the negotiation request by the client is not shown in fig. 4, and both the request 1 and the request 2 in fig. 4 can be understood as a Session validity check request initiated by the client after the client sends the Session negotiation request and the server negotiates the Session ID.

Wherein, S-Session Name0 is the value obtained after the 1 st serialization operation of the server.

Step 403: after receiving the Name value pair Session ID, the client performs the 1 st serialization operation according to the Name Seed to obtain C-Session Name0, and saves Seed, C-Session Name0 and Session ID.

Wherein, C-Session Name0 is the value obtained after the 1 st serialization operation of the client.

Step 404: when the client sends the 1 st access request, the Name value pair C-Session Name0: session ID is carried in the request message header, after the server receives the 1 st access request, the server checks whether the carried Name C-Session Name0 is consistent with the stored S-Session Name0 (namely, the verification C-Session Name0 in the figure), if not, the value pair C-Session ID is considered illegal, and the server refuses to execute the request and closes the Session. Request 1 in fig. 4 is the 1 st access request.

Step 405: if the check of the C-Session Name0 is passed (may also be referred to as verification pass) in step 404, the determination of the value Session ID is legal, and the server performs the 2 nd order listing operation according to the S-Session Name0 and the Seed to obtain the S-Session Name1 and returns the Name value pair S-Session Name1: session ID to the client. And then the server side performs the 3 rd serialization operation according to the S-Session Name1 and the Seed to obtain the S-Session Name2, and stores the C-Session Name2 in the access request sent next by the client side for verification.

The S-Session Name1 is a value obtained after the 2 nd serialization operation of the server. S-Session Name2 is the value obtained after the 3 rd serialization operation of the server.

Step 406: and the client receives the S-Session Name1, performs the 2 nd serialization operation according to the S-Session Name1 and the stored Seed to obtain C-Session Name2, and then stores the C-Session Name2.

Wherein, C-Session Name2 is the value obtained after the client-side 2 nd order listing operation.

Step 407: when the client sends the 2 nd access request, the Name value pair C-Session Name2: session ID is carried in the request message header, after the server receives the 2 nd access request, the server checks whether the carried Name C-Session Name2 is consistent with the stored S-Session Name2, if not, the value Session ID is considered illegal, and the server refuses to execute the request and closes the Session. Request 2 in fig. 4 is the 2 nd access request.

In step 408, if the check of the C-Session Name2 in step 407 is passed, the value Session ID is considered legal, and the server performs the 4 th serialization operation according to the S-Session Name2 and the Seed to obtain the S-Session Name3 and returns the Name value pair S-Session Name3:session ID to the client. And then the server side performs 5 th serialization operation according to the S-Session Name3 and the Seed to obtain an S-Session Name4, and stores the C-Session Name4 in the access request sent next by the client side for verification.

Wherein S-Session Name3 is a value obtained after the 4 th serialization operation of the server. S-Session Name4 is a value obtained after the 5 th serialization operation of the server.

And 409, receiving the S-Session Name3 by the client, performing the 3 rd serialization operation according to the S-Session Name3 and the Seed to generate C-Session Name4, and then storing the C-Session Name4.

Wherein, C-Session Name4 is the value obtained after the 3 rd serialization operation of the client.

When the client sends the 3 rd access request, the Name value pair C-Session Name4: session ID is carried in a request message header, after the server receives the 3 rd access request, the server checks whether the carried Name C-Session Name4 is consistent with the stored S-Session Name4, if not, the value Session ID is considered illegal, and the server refuses to execute the request and closes the Session. If the C-Session Name4 passes the verification, the Session ID is considered legal, and the server side carries out the 6 th serialization operation according to the S-Session Name4 and the Seed to obtain the S-Session Name5 and returns a Name value pair S-Session Name5: session ID to the client side. And then the server side performs 7 th serialization operation according to the S-Session Name5 and the Seed to obtain an S-Session Name6, and stores the Name in the access request sent next by the client side in the S-Session Name6 for verification.

And repeating the Session Name generation and verification flow until the Session is ended, and clearing the saved Seed, session Name and Session ID by the WEB application after the Session is ended.

In the embodiment, the risk that the Session ID is very easy to intercept and forge is reduced when the message header is transmitted, and instead, the Session Name is checked to verify the validity of the Session ID by using the Session Name, so that the Session ID is transmitted in the WEB technology more safely and reliably, any Session Name intercepted by an attacker cannot trace the history to evolve and solve the safety protection problems of WEB applications such as Session prediction, session hijacking, session fixing and the like. And the encryption transmission of the overlong and complicated value Session ID is not needed, the serialization operation is only needed to be carried out on the corresponding Name Session Name combined with the Seed Seed, and the validity of the value Session ID is judged by checking the transmitted Name Session Name, so that the system resource is saved as much as possible, and the maximum guarantee of the transmission efficiency is considered on the aspect of improving the safety of Session access to the maximum extent.

In one embodiment, the value in the name value pair carried by the access request sent by the client is a Session ID, the name value pair is sent to the server through a form parameter, and the interaction flow chart between the server and the client related to the access method can refer to fig. 5, which includes:

Step 501: and the user logs in the WEB application of the server through the client.

Step 502: after successful login verification, the server generates a legal identification Session ID of the current effective Session, generates a random number Seed Seed, performs 1 st serialization operation according to the Name Seed to obtain S-Name0, stores Seed, S-Name0 and Session ID, and returns a Name value pair Session ID to the client through form parameters. The Session ID may be generated after the server receives the Session negotiation request of the client. It should be noted that, the process of sending the negotiation request by the client is not shown in fig. 5, and both the request 1 and the request 2 in fig. 5 can be understood as a Session validity check request initiated by the client after the client sends the Session negotiation request and the server negotiates the Session ID.

Wherein, S-Name0 is the value obtained after the 1 st serialization operation of the server.

Step 503: after receiving the Name value pair Seed, the client performs the 1 st serialization operation according to the Name Seed to obtain C-Name0, and stores the Seed, C-Name0 and the Session ID.

Wherein, C-Name0 is the value obtained after the 1 st serialization operation of the client.

Step 504: when the client sends the 1 st access request, the Name value pair C-Name0: session ID is carried in the form parameter, after the server receives the 1 st access request, the server checks whether the carried Name C-Name0 is consistent with the stored S-Name0, if not, the value Session ID is considered illegal, and the server refuses to execute the request and closes the Session. Request 1 in fig. 5 is the 1 st access request.

Step 505: if the check of C-Name0 is passed in step 504, determining that the Session ID of the value is legal, and the server performs the 2 nd order listing operation according to S-Name0 and Seed to obtain S-Name1 and returns the Name value pair S-Name1: session ID to the client. And then the server side performs the 3 rd serialization operation according to the S-Name1 and the Seed to obtain the S-Name2, and stores the S-Name2 for checking the C-Name2 in the access request sent by the client side next time.

Wherein S-Name1 is the value obtained after the 2 nd serialization operation of the server. S-Name2 is the value obtained after the 3 rd serialization operation of the server.

Step 506: and the client receives the S-Name1, performs the 2 nd serialization operation according to the S-Name1 and the stored Seed to obtain C-Name2, and then stores the C-Name2.

Wherein, C-Name2 is the value obtained after the client-side 2 nd order serialization operation.

Step 507: when the client sends the 2 nd access, the Name value pair C-Name2: session ID is carried in the form parameter, after the server receives the 2 nd access request, the server checks whether the carried Name C-Name2 is consistent with the stored S-Name2, if not, the value Session ID is considered illegal, the execution request is refused, and the Session is closed. Request 2 in fig. 5 is the 2 nd access request.

And 508, if the C-Name2 check in the step 507 passes, the value of the Session ID is considered legal, and the server side performs the 4 th serialization operation according to the S-Name2 and the Seed to obtain the S-Name3 and returns a Name value pair S-Name3: the Session ID to the client side. And then the server side performs 5 th serialization operation according to the S-Name3 and the Seed to obtain the S-Name4, and stores the S-Name4 for checking the C-Name4 in the access request sent by the client side next time.

Wherein S-Name3 is the value obtained after the 4 th serialization operation of the server. S-Name4 is the value obtained after the 5 th serialization operation of the server.

Step 509, the client receives the S-Name3, performs the 3 rd serialization operation according to the S-Name3 and the Seed to generate a C-Name4, and then stores the C-Name4.

Wherein, C-Name4 is the value obtained after the 3 rd serialization operation of the client.

And repeating the Name generation and verification process until the session is ended. After the Session is ended, the WEB application clears the stored Seed, name and Session ID.

In this embodiment, the name value pair is stored in the form parameter for transmission, and the transmission of the form parameter supports ciphertext transmission, so in this embodiment, besides the effect of saving a lot of system resources for small terminal devices in the communication field, the ciphertext transmission can be performed in combination with the parameter asymmetric encryption and decryption process, so that security risks in the WEB application access process can be reduced as much as possible by avoiding WEB application security check singleness, and by multiple checks of validity of WEB sessions.

In one embodiment, the value in the name value pair carried by the access request sent by the client is a parameter configured by the client, the name value pair is sent to the server through a form parameter, and the interaction flow chart between the server and the client related to the access method can refer to fig. 6, which includes:

step 601: and the user logs in the WEB application of the server through the client.

Step 602: after successful login verification, the server generates a random number Seed, performs 1 st serialization operation according to the Name Seed to obtain S-Name0, stores the Seed and the S-Name0, and returns the Seed to the client.

Step 603: after receiving the Seed, the client performs the 1 st serialization operation according to the Name of the Seed to obtain C-Name0, and stores the Seed and the C-Name0.

Step 604: when the client sends the 1 st parameter configuration request, carrying the parameter of the Name value pair C-Name0 in the form parameter, and after the server receives the 1 st parameter configuration request, checking whether the carried Name C-Name0 is consistent with the stored S-Name0, if not, considering that the value parameter is illegal, and refusing to execute the parameter configuration request. The request 1 in fig. 6 is the 1 st parameter configuration request, and may be understood as the 1 st access request.

Step 605: if the check of the C-Name0 is passed in step 604, it is determined that the value parameter is legal, and the server performs the 2 nd order listing operation according to the S-Name0 and the Seed to obtain the S-Name1 and returns the Name value pair S-Name1 to the client. And then the server side performs the 3 rd serialization operation according to the S-Name1 and the Seed to obtain the S-Name2, and stores the S-Name2 for checking the C-Name2 in the parameter configuration request sent by the client side next time.

Step 606: and the client receives the S-Name1, performs the 2 nd serialization operation according to the S-Name1 and the stored Seed to obtain C-Name2, and then stores the C-Name2.

Step 607: when the client sends the 2 nd parameter configuration request, carrying the Name value pair C-Name2 parameter in the form parameter, after the server receives the 2 nd session negotiation request, checking whether the carried Name C-Name2 is consistent with the stored S-Name2, if not, considering that the value parameter is illegal, refusing to execute the request and closing the session. The request 2 in fig. 6 is the parameter configuration request 2, and may be understood as the access request 2.

Step 608, if the C-Name2 check in step 607 passes, the value parameter is considered legal, and the server performs the 4 th serialization operation according to the S-Name2 and the Seed to obtain the S-Name3 and returns the S-Name3 to the client. And then the server side performs 5 th serialization operation according to the S-Name3 and the Seed to obtain the S-Name4, and stores the C-Name4 in the parameter configuration request sent by the client side next time for verification.

Step 609, the client receives the S-Name3, performs the 3 rd serialization operation according to the S-Name3 and the Seed to generate a C-Name4, and then stores the C-Name4.

And repeating the Name generation and parameter validity checking flow until the session is ended. After the session is ended, the WEB application clears the stored Seed and Name.

In this embodiment, the purposes of verifying the validity of the parameter and safely transmitting the parameter can be achieved by performing the serialization operation on the simple parameter name (i.e., the name in the name pair) in the reverse direction without performing the encryption transmission on the parameter which is too long and complex (also can be called as the parameter value, i.e., the value in the name pair), and a lot of system resources are saved for small terminal equipment in the communication field. In other words, in this embodiment, the random number seed serialization operation mechanism is applied to the parameter validity check, and the simple parameter name serialization operation is used to replace the complex parameter encryption transmission, so that the system resource consumption is reduced, the safety in the parameter transmission process is simultaneously considered, and the method has a great reference value for small terminal equipment in the communication field.

One embodiment of the present application relates to an access method, applied to a client, referring to fig. 7, including:

step 701: and sending a login request to the server side so that the server side can generate a random number seed after the login request is successfully checked.

Step 702: and receiving the random number seed sent by the server.

Step 703: sending an access request to a server side so that the server side can check the names in the name value pairs carried in the access request, and determining that the values in the name value pairs are legal after the check is passed; wherein, the names in the name value pair are: and the client performs serialization operation according to the random number seeds to obtain a value.

Since this embodiment corresponds to the above embodiment of the access method applied to the server, this embodiment can be implemented in cooperation with the above embodiment of the access method applied to the server. The related technical details mentioned in the embodiment of the access method applied to the server are still valid in this embodiment, and the technical effects that can be achieved in the embodiment of the access method applied to the server are also achieved in this embodiment, so that repetition is reduced and no further description is given here. Accordingly, the related-art details mentioned in the present embodiment can also be applied to the second embodiment.

It should be noted that, the foregoing examples in the embodiments of the present application are all illustrative for easy understanding, and do not limit the technical solution of the present invention.

The above steps of the methods are divided, for clarity of description, and may be combined into one step or split into multiple steps when implemented, so long as they include the same logic relationship, and they are all within the protection scope of this patent; it is within the scope of this patent to add insignificant modifications to the algorithm or flow or introduce insignificant designs, but not to alter the core design of its algorithm and flow.

One embodiment of the present application relates to an access system, referring to fig. 8, comprising: a server 801 and a client 802;

a client 802 for sending a login request to the server 801.

The server 801 is configured to generate a random number seed after the login request is successfully checked, and send the random number seed to the client 802.

The client 802 is further configured to send an access request to the server 801; the access request carries a name value pair, and the names in the name value pair are as follows: the client 802 performs a serialization operation according to the random number seed to obtain a value.

The server 801 is further configured to check a name in a name value pair carried in the access request, and determine that a value in the name value pair is legal after the check is passed.

It is to be noted that this embodiment is a system embodiment corresponding to the above-described method embodiment, and this embodiment may be implemented in cooperation with the above-described method embodiment. The related technical details and technical effects mentioned in the above method embodiments are still valid in this embodiment, and in order to reduce repetition, they are not described here again. Accordingly, the related technical details mentioned in the present embodiment can also be applied in the above-described method embodiments.

One embodiment of the present application relates to an electronic device, referring to fig. 9, comprising: at least one processor 901; and a memory 902 communicatively coupled to the at least one processor 901; wherein the memory 902 stores instructions executable by the at least one processor 901, the instructions being executable by the at least one processor 901; in the case that the electronic device is a server, the at least one processor 901 is capable of executing the above access method applied to the server; in the case that the electronic device is a client, the at least one processor 901 is capable of executing the above-described access method applied to the client.

Where the memory 902 and the processor 901 are connected by a bus, the bus may comprise any number of interconnected buses and bridges, the buses connecting the various circuits of the one or more processors 901 and the memory 902 together. The bus may also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver may be one element or may be a plurality of elements, such as a plurality of receivers and transmitters, providing a means for communicating with various other apparatus over a transmission medium. The data processed by the processor 901 is transmitted over a wireless medium via an antenna, which further receives the data and transmits the data to the processor 901.

The processor 901 is responsible for managing the bus and general processing and may also provide various functions including timing, peripheral interfaces, voltage regulation, power management, and other control functions. And memory 902 may be used to store data used by processor 901 in performing operations.

Embodiments of the present application also provide a computer-readable storage medium storing a computer program. The computer program implements the above-described method embodiments when executed by a processor.

That is, it will be understood by those skilled in the art that all or part of the steps in implementing the methods of the embodiments described above may be implemented by a program stored in a storage medium, where the program includes several instructions for causing a device (which may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps in the methods of the embodiments described herein. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

It will be understood by those of ordinary skill in the art that the foregoing embodiments are specific examples of carrying out the invention and that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

Claims

1. An access method, applied to a server, comprises:

Receiving a login request of a client;

after the login request is successfully checked, generating a random number seed and sending the random number seed to the client;

receiving an access request sent by the client; the access request carries a name value pair, and the name in the name value pair is as follows: the client side carries out serialization operation according to the random number seeds to obtain a value;

and checking the names in the name value pair, and determining that the values in the name value pair are legal after the checking is passed.

2. The access method according to claim 1, wherein the values in the name-value pair carried by the access request include: and the legal identifier SessionID of the current effective session negotiated by the server and the client.

3. The access method according to claim 1, wherein the values in the name-value pair carried by the access request include: the client requests configured parameter values.

4. The access method according to claim 1, wherein the name-value pair is carried in a header of the access request or in a form parameter of a body of the access request.

5. The access method according to any one of claims 1 to 4, wherein the receiving the access request sent by the client includes:

receiving an ith access request sent by the client;

the verifying the names in the name value pair comprises the following steps:

determining whether the name carried in the ith access request is consistent with a value obtained after 2i-1 th serialization operation of the server side;

when i is more than 1 and less than or equal to n, the name carried in the ith access request is as follows: the client side seed sums according to the random numbers

The server side performs the ith serialization operation on the value obtained after the 2i-2 nd serialization operation; the value obtained after the 2i-1 th serialization operation of the server is as follows: the server side carries out 2i-1 th serialization operation according to the random number seed and the value obtained after 2i-2 nd serialization operation of the server side, and n is a natural number greater than or equal to 2;

And if the name carried in the ith access request is consistent with the value obtained after the 2i-1 th serialization operation of the server, determining that the verification passes.

6. The access method of claim 5, further comprising, after the determining that the verification passes:

according to the value obtained after the 2i-1 th serialization operation of the server and the random number seed, carrying out the 2 i-th serialization operation to determine the value obtained after the 2 i-th serialization operation of the server;

the value obtained after the 2 i-th order serialization operation of the server side is sent to the client side, so that the client side can perform the (i+1) -th order serialization operation according to the value obtained after the 2 i-th order serialization operation of the server side and the random number seed to determine the value obtained after the (i+1) -th order serialization operation of the client side;

according to the value obtained after the server-side 2i < th > sequence serialization operation and the random number seed, 2i+1st time serialization operation is carried out to determine the value obtained after the server-side 2i+1st time serialization operation; the value obtained after the 2i+1st serialization operation of the server is used for checking the name in the name value pair carried by the (i+1) th access request by the server.

7. An access method, applied to a client, comprising:

a login request is sent to a server side, so that after the login request is successfully checked by the server side, a random number seed is generated;

receiving the random number seed sent by the server;

sending an access request to the server side so that the server side can check the names in the name value pairs carried in the access request, and determining that the values in the name value pairs are legal after the check is passed; wherein, the names in the name value pair are: and the client performs serialization operation according to the random number seeds to obtain a value.

8. An access system, comprising: the system comprises a server and a client;

the client is used for sending a login request to the server;

the server is used for generating a random number seed after the login request is successfully checked, and sending the random number seed to the client;

the client is further configured to send an access request to the server; the access request carries a name value pair, and the name in the name value pair is as follows: the client side carries out serialization operation according to the random number seeds to obtain a value;

The server is further configured to check a name in the name value pair carried in the access request, and determine that the value in the name value pair is legal after the check is passed.

9. An electronic device, comprising: at least one processor; the method comprises the steps of,

a memory communicatively coupled to the at least one processor; wherein, the liquid crystal display device comprises a liquid crystal display device,

the memory stores instructions executable by the at least one processor, the instructions being executable by the at least one processor;

in the case where the electronic device is a server, the at least one processor is capable of executing the access method according to any one of claims 1 to 6;

in case the electronic device is a client, the at least one processor is capable of performing the access method of claim 7.

10. A computer readable storage medium storing a computer program, characterized in that the computer program, when executed by a processor, implements the access method of any one of claims 1 to 6 or implements the access method of claim 7.