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

Abstract

Embodiments of the present application relate to the technical field of communication, and disclose an access method, system, electronic device and computer readable storage medium. The access method comprises: receiving a login request of a client; generating a random number seed and sending the random number seed to the client after the login request is verified successfully; receiving an access request sent by the client; wherein the access request carries a name-value pair, the name in the name-value pair is a value obtained by the client after a serialization operation on the random number seed; and the name in the name-value pair is verified, and after the verification is passed, the value in the name-value pair is determined to be legal, so that system resources can be saved while ensuring access security.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an access method, system, electronic device, and computer-readable storage medium. Background Technology

[0002] With the continuous expansion of web applications and the development of network technology, the functional requirements of web applications are becoming increasingly complex. At the same time, penetration attack methods targeting web security vulnerabilities are constantly emerging. Web application security issues are becoming increasingly prominent. As the most direct medium for hackers, it is necessary to develop more advanced security protection technologies to address potential security threats.

[0003] Currently, in order to protect the parameter values ​​transmitted during the access process and prevent them from being attacked, the parameter values ​​are usually directly encrypted. However, the parameter values ​​themselves are usually quite complex and lengthy. Therefore, directly encrypting the parameter values ​​requires a large amount of computation and will consume a lot of system resources. Summary of the Invention

[0004] The main objective of this application is to provide an access method, system, electronic device, and computer-readable storage medium that can save system resources while ensuring access security.

[0005] To at least achieve the above objectives, embodiments of this application provide an access method applied to a server, comprising: receiving a login request from a client; after successfully verifying the login request, generating a random number seed and sending the random number seed to the client; receiving an access request sent by the client; wherein the access request carries a name-value pair, the name in the name-value pair being: the value obtained by the client after performing a serialization operation based on the random number seed; verifying the name in the name-value pair, and after passing the verification, determining that the value in the name-value pair is valid.

[0006] To at least achieve the above objectives, embodiments of this application also provide an access method applied to a client, comprising: sending a login request to a server, wherein the server generates a random number seed after successfully verifying the login request; receiving the random number seed sent by the server; sending an access request to the server, wherein the server verifies the name in the name-value pair carried in the access request, and determines that the value in the name-value pair is valid after the verification is successful; wherein the name in the name-value pair is the value obtained by the client after performing a serialization operation based on the random number seed.

[0007] To at least achieve the above objectives, embodiments of this application also provide an access system, including: a server and a client; the client is configured to send a login request to the server; the server is configured to generate a random number seed after successfully verifying the login request, and send the random number seed to the client; the client is further configured to send an access request to the server; wherein the access request carries a name-value pair, the name in the name-value pair being: the value obtained by the client after performing a serialization operation based on the random number seed; the server is further configured to verify the name in the name-value pair carried in the access request, and determine that the value in the name-value pair is valid after the verification is successful.

[0008] To at least achieve the above objectives, embodiments of this application also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor; when the electronic device is a server, the at least one processor is capable of executing the above-described access method applied to the server; when the electronic device is a client, the at least one processor is capable of executing the above-described access method applied to the client.

[0009] To at least achieve the above objectives, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the access method described above.

[0010] The access method provided in this application embodiment involves the server verifying a login request received from a client. Upon successful verification, the server generates a random number seed and sends it to the client. The server then receives an access request from the client, which carries a name-value pair. The name in the name-value pair is the value obtained by the client through serialization of the random number seed. The server verifies the name in the name-value pair, and if the verification passes, determines that the value in the name-value pair is valid. In other words, this application embodiment eliminates the need for encrypting potentially complex and lengthy values ​​in the name-value pair. Verifying the name in the name-value pair to confirm its validity helps conserve system resources, improving access security while saving system resources. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the access method applied to the server mentioned in the embodiments of this application;

[0012] Figure 2 This is a flowchart of the steps in step 104 mentioned in this application embodiment, which involves verifying the name in the name-value pair and executing the steps after successful verification.

[0013] Figure 3 This is a simplified message comparison diagram mentioned in the embodiments of this application;

[0014] Figure 4 This is an interaction flowchart between the server and the client involved in the access method mentioned in the embodiments of this application;

[0015] Figure 5 This is another interaction flowchart between the server and the client involved in the access method mentioned in the embodiments of this application;

[0016] Figure 6 This is another interaction flowchart between the server and the client involved in the access method mentioned in the embodiments of this application;

[0017] Figure 7 This is a flowchart illustrating the access method applied to the client mentioned in the embodiments of this application;

[0018] Figure 8 This is a schematic diagram of the access system mentioned in the embodiments of this application;

[0019] Figure 9 This is a schematic diagram of the structure of the electronic device mentioned in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0021] This application provides an access method applied to a server. The main application scenario of this embodiment can include client access to World Wide Web (WEB) applications, which include WEBServer, WEB Application Programming Interface (API), and other WEB services. This embodiment is applicable to session management between a WEB client and a server. WEB session management is a session state support technology used for the stateless Hypertext Transfer Protocol (HTTP) protocol. That is, this embodiment can be based on a stateless HTTP session management mechanism, and the client and server can be in an IP address-based internet environment. The server saves the client's state through session management, associating the client's requests. The access method in this embodiment can be implemented regardless of the network layer at which the client and server are located.

[0022] In one embodiment, a flowchart of the access method can be found here. Figure 1 ,include:

[0023] Step 101: Receive the login request from the client.

[0024] Step 102: After the login request is successfully verified, a random number seed is generated and sent to the client.

[0025] Step 103: Receive the access request sent by the client; wherein the access request carries a name-value pair, and the name in the name-value pair is the value obtained by the client after performing serialization operation based on the random number seed.

[0026] Step 104: Validate the name in the name-value pair, and if the validation passes, determine that the value in the name-value pair is valid.

[0027] In this embodiment, there is no need to encrypt the potentially complex and lengthy values ​​in the name-value pair. By verifying the name in the name-value pair to confirm whether the value in the name-value pair is valid, it is beneficial to save system resources as much as possible. This can improve access security while saving system resources.

[0028] In step 101, the client can send a login request to the server to log in to the web application. For example, the user can enter their registered username and password through the client, and the client will send the entered username and password along with the login request to the server.

[0029] In step 102, the server can verify the username and password carried in the login request to determine whether the login request verification was successful. Therefore, after successfully verifying the login request, the server generates a random number seed and sends the random number seed to the client.

[0030] After receiving the random number seed (Seed), the client can perform serialization operations on the seed to obtain C-Name0. When sending an access request to the server, the client will include Name0 as the name in the name-value pair. The value in the name-value pair carried in the access request can be a parameter value that you want to protect during the access process.

[0031] After generating a random number seed (Seed), the server can perform serialization operations on the seed to obtain S-Name0, and save S-Name0 for use in verifying the name in the name-value pair carried in subsequent access requests from clients.

[0032] In practical implementation, the server and client can pre-negotiate the serialization algorithm, ensuring that both use the same algorithm during serialization. The serialization algorithm can be an encryption algorithm that guarantees a unique result, including but not limited to irreversible encryption algorithms. The serialization algorithm can be selected based on actual needs; for example, a single encryption algorithm can be chosen, or multiple encryption algorithms can be combined to obtain the serialization algorithm. However, this embodiment does not specifically limit the algorithm used for serialization.

[0033] In step 103, the server receives an access request sent by the client; the access request carries a name-value pair, where the name is the value obtained by the client after performing a serialization operation on Seed.

[0034] In step 104, the server parses the name-value pair carried in the access request and verifies the name in the name-value pair. The verification method can be: determining whether the name in the name-value pair is the same as the value obtained by the server after serializing the Seed. If they are the same, the verification passes; otherwise, the verification fails.

[0035] In this embodiment, if the name in the name-value pair passes validation, the value in the name-value pair is determined to be valid, and the server can then respond to the access request from the client. If the name in the name-value pair fails validation, the value in the name-value pair is determined to be invalid, and the server rejects the access request from the client and can also close the current session between the server and the client. The validation method used in this embodiment helps to improve access security while saving system resources.

[0036] In one embodiment, the value in the name-value pair carried in the access request includes: a Session ID, a valid identifier of the currently valid session negotiated between the server and the client. That is, when the client sends an access request to the server, it can use the Session ID as the value in the name-value pair. This embodiment eliminates the need for encrypted transmission of the Session ID during access. By verifying the name in the name-value pair carried in the access request to determine the validity of the Session ID, system resources are conserved as much as possible, which is beneficial for high-security, high-reliability, and high-efficiency web secure access session management.

[0037] In this context, Session, as a session state, is commonly found in modern web application systems. It is primarily used to maintain state information related to the current client and to track each client's session. A Session is identified using a Session ID generated by the server to distinguish users. Each Session is unique to each client. When a user first logs into the web application and establishes a connection with the server, the server distributes a Session ID to the current client as a unique and valid identifier for the session.

[0038] The client can obtain the Session ID in one of the following ways: After successfully verifying the login request, the server receives the session negotiation request sent by the client, generates a valid Session ID to identify the current session, and sends the generated Session ID to the client. Alternatively, in a more specific implementation, the server can send both the random number seed and the Session ID to the client after generating the random number seed.

[0039] The applicant's research revealed that Session IDs are typically transmitted within message headers. Since the header is transmitted in plaintext, and the Session ID serves as a legitimate identifier for a session, it is highly susceptible to interception and forgery. Through attacks such as session prediction, session hijacking, and session immobilization, attackers can easily obtain valid Session IDs. This allows illegitimate sessions to masquerade as legitimate ones and launch unauthorized attacks on web applications. Attacks targeting Session IDs can easily bypass vulnerable security systems, causing significant damage. Currently, encrypted Session ID transmission mechanisms are commonly used to enhance security, but these consume substantial system resources for small terminal devices in the communication field. Furthermore, the security attributes and verification mechanisms for Session IDs bound to cookies are insufficient to address the increasingly severe security challenges. Therefore, in this embodiment, a name-value pair is included in the access request, with the value being the Session ID. Successful name verification indicates that the value in the name-value pair is legitimate. The name in the name-value pair is obtained by serialization operation combined with the random number seed. In this embodiment, it is equivalent to encrypting the relatively simple name in the name-value pair, rather than encrypting the relatively complex value. Therefore, while ensuring access security, it can also reduce the system resources occupied.

[0040] In one embodiment, after the server successfully verifies the login request, it generates a random number seed and a valid Session ID for the current session. The server performs serialization on the Seed to obtain the S-Session Name, and saves the Seed, S-Session Name, and Session ID. The server then returns the Seed and Session ID to the client as a name-value pair, Seed:Session ID. Upon receiving the Seed:Session ID pair, the client performs serialization on the Seed in the name-value pair to obtain the C-Session Name, and saves the Seed, C-Session Name, and Session ID. When the client needs to send an access request to the server, it includes the name-value pair C-Session Name:Session ID in the request. Upon receiving the access request, the server verifies whether the C-Session Name matches the saved S-Session Name. If they match, the server determines that the Session ID in the access request is valid; otherwise, the server determines that the Session ID in the access request is invalid, refuses to execute the access request, and closes the session. The Session ID is used to prove that the access request was sent by a legitimate client.

[0041] In this embodiment, the session negotiation request is a request initiated by the server during the session negotiation phase between the server and the client. The access request can be understood as a session validity verification request initiated by the client after successful session negotiation. After the client successfully logs in and successfully negotiates a Session ID with the server, every operation, every click, and every configuration by the client can be understood as an access request. The server will only process the access request and return the processing result to the client after confirming that the access request is valid.

[0042] In one embodiment, the value in the name-value pair carried in the access request includes the parameter value requested by the client for configuration. In this case, the access request can be understood as a parameter configuration request. Specifically, a parameter configuration request can be understood as a parameter configuration request initiated by the client after the server and client sessions have been successfully established. The parameter value requested by the client can be a sensitive parameter value, such as a user-inputted phone number or password. This embodiment can verify the validity of the parameter value requested for configuration, using simple parameter name serialization operations instead of complex parameter value encryption transmission. This reduces system resource consumption while ensuring security during parameter transmission, and has significant reference value for small terminal devices in the communication field.

[0043] In one embodiment, after the server successfully verifies the login request, it generates a random number seed, performs serialization on the seed to obtain the S-Name, saves the seed and S-Name, and returns the seed to the client. Upon receiving the seed, the client performs serialization on the seed to obtain the C-Name, and saves the seed and C-Name. When the client needs to send a parameter configuration request to the server, it includes the name-value pair C-Name:parameter value in the parameter configuration request. Upon receiving the parameter configuration request, the server verifies whether the included C-Name matches the saved S-Name. If they match, the parameter value in the current parameter configuration request is considered valid; otherwise, the parameter value is considered invalid, and the parameter configuration request is rejected.

[0044] In one embodiment, the name-value pairs carried in the access request may include multiple pairs, such as the aforementioned name-value pair C-Session Name: Session ID and name-value pair C-Name: Parameter value. The server verifies the validity of the Session ID included in the access request to prove that the request was sent by a legitimate user. After verifying the validity of the Session ID, if the parameter value in the name-value pair C-Name: Parameter value is also valid, the server configures the parameter value from the access request to the server.

[0045] In one embodiment, the name-value pair is carried in the header of the access request, or it is carried in the form parameters of the access request body. In this embodiment, the name-value pair can be carried in different positions within the access request, which helps meet different needs in practical applications. Since form parameters support encrypted transmission, when the name-value pair is carried in form parameters, it can be further combined with asymmetric encryption / decryption processes for encrypted transmission. This provides a simple, direct, and secure framework for application scenarios where request data requires encryption / decryption, exhibiting high adaptability and scalability, and further enhancing access security.

[0046] In one embodiment, the name-value pair carried in the access request can be C-Session Name:Session ID, which can be carried in the header of the access request or in the form parameters of the body of the access request.

[0047] In one embodiment, the name-value pair carried in the access request can be a C-Name parameter value, which can be carried in the header of the access request or in the form parameter of the body of the access request.

[0048] In one embodiment, receiving the access request sent by the client in step 103 includes: receiving the i-th access request sent by the client. The implementation process for verifying the name in the name-value pair in step 104 can be found in [reference needed]. Figure 2 ,include:

[0049] Step 1041: Determine whether the name carried in the i-th access request is consistent with the value obtained after the (2i-1)-th serialization operation on the server; if so, proceed to step 1042, otherwise proceed to step 1043.

[0050] When i=1, the first access request carries the value: the value obtained by the client in the first serialization operation based on the random number seed; the value obtained by the server after the first serialization operation is: the value obtained by the server in the first serialization operation based on the random number seed.

[0051] When 1 < i ≤ n, the i-th access request carries the following value: the value obtained by the client performing the i-th serialization operation based on the random number seed and the value obtained by the server after the (2i-2)-th serialization operation; the value obtained by the server after the (2i-1)-th serialization operation is the value obtained by the server performing the (2i-1)-th serialization operation based on the random number seed and the value obtained by the server after the (2i-2)-th serialization operation, where n is a natural number greater than or equal to 2.

[0052] Step 1042: Verification passed.

[0053] Step 1043: Determine that the verification failed.

[0054] Understandably, once a client logs into the server's web application, the client will continuously send multiple access requests to the server during the session. In this embodiment, each access request sent by the client carries a different name in its name-value pair. Furthermore, the names in the name-value pairs of subsequent access requests are obtained by serialization operations combining previous historical data and a random number seed. This increases the difficulty of attacking the names in the name-value pairs. For example, if an attacker intercepts the name in a name-value pair carried in a certain access request, since there is no name and seed from previous access requests, serialization operations cannot be performed, and therefore the request will fail the server's verification, greatly improving the security of the access process.

[0055] The following explanation uses a session negotiation request as an example:

[0056] After the server successfully verifies the client's login request, it generates a valid identifier for the current session, a Session ID, and a corresponding random number seed, Seed. The Seed is then serialized to obtain the Session Name. The server saves the Seed, Session Name, and Session ID and sends the name-value pair Seed:Session ID to the client for storage. This data is used in subsequent client session negotiation requests for processing the name-value pair. The client sends a name in its first session negotiation request. This name is the value obtained by the client performing the first serialization operation on the random number seed. In other words, the name in the name-value pair Session Name:Session ID sent by the client in the first session negotiation request is the value obtained by serializing the seed. Subsequently, the server needs to serialize the Session Name with the seed and save it, and send the newly generated name-value pair Session Name:Session ID to the client. When the client submits the next session negotiation request, it also needs to use the value obtained by serializing the new Session Name with the seed as the name in the name-value pair sent in the session negotiation request, so that the server can verify the name in the name-value pair and save the serialized value as the historical Session Name. Thus, when an attacker intercepts the intermediate transmission of the Session Name, since there is no historical Session Name and Seed, serialization cannot be performed, and therefore the server-side Session Name verification mechanism cannot pass. The server will consider the Session ID value corresponding to the Session Name to be invalid, and thus cannot forge the current session request using the Session ID.

[0057] To better understand the difference between the name-value pairs carried in the multiple session negotiation requests obtained using serialization in this embodiment and those carried in traditional multiple session negotiation requests, please refer to [link to relevant documentation]. Figure 3 A simplified message comparison diagram. Figure 3 On the left are the name-value pairs carried in a traditional multiple session negotiation request. It can be seen that the name-value pairs carried in the traditional multiple session negotiation request are all the same, and it is obvious that the string after Session-ID means the value of the Session ID parameter. If any multiple session negotiation request is intercepted, the name-value pairs carried in it can be easily stolen, so attackers can easily forge session negotiation requests. Figure 3The right side shows the name-value pairs carried in multiple session negotiation requests obtained by serialization operation in this embodiment. AfG1YL can be understood as the name in the name-value pair carried in the first session negotiation request, ZHOPsY can be understood as the name in the name-value pair carried in the second session negotiation request, and VHGsq2 can be understood as the name in the name-value pair carried in the third session negotiation request. Figure 3 The name-value pairs carried in the three session negotiation requests on the right are all different, and it is not clear which parameter the values ​​after the names AfG1YL, ZHOPsY, and VHGsq2 represent. Therefore, in the technical solution of this embodiment, even if an attacker intercepts the name-value pairs carried in the session negotiation requests, since the names in the name-value pairs are obtained after serialization, the attacker cannot obtain valid information from the intercepted name-value pairs, and thus cannot forge session negotiation requests using the intercepted name-value pairs.

[0058] This embodiment provides a web application security access protection method based on a random number seed serialization operation mechanism for Session IDs. This ensures that even if an attacker intercepts the Session Name after the seed serialization operation, they still cannot pass the verification to use a valid and legitimate Session ID. This protects against attack methods such as session prediction, session hijacking, and session fixation, thereby enhancing the security level of web application access.

[0059] In one embodiment, after determining that the verification passed in step 1042, the method further includes:

[0060] Step 105: Based on the value obtained after the (2i-1)th serialization operation on the server and the random number seed, perform the 2ith serialization operation to determine the value obtained after the 2ith serialization operation on the server.

[0061] Step 106: Send the value obtained after the 2ith serialization operation on the server to the client, so that the client can perform the (i+1)th serialization operation based on the value obtained after the 2ith serialization operation on the server and the random number seed, so as to determine the value obtained after the (i+1)th serialization operation on the client.

[0062] Step 107: Based on the value obtained after the 2ith serialization operation on the server and the random number seed, perform the 2i+1th serialization operation to determine the value obtained after the 2i+1th serialization operation on the server; wherein, the value obtained after the 2i+1th serialization operation on the server is used by the server to verify the name in the name-value pair carried in the i+1th access request.

[0063] In this embodiment, after the server verifies the name carried in each access request, it calculates the data required for the next verification. This facilitates the verification of the next received access request, thereby enabling a highly secure, reliable, and efficient web secure access session management through a random number seed serialization growth and evolution mechanism throughout the entire session.

[0064] The following explanation uses i=1 and i=3 as examples:

[0065] When i=1, that is, the server receives the first access request sent by the client. After the name in the name-value pair carried by the first access request passes the name verification, the server performs the second (2)th serialization operation based on the value obtained after the server's second (2i-1)th serialization operation and the random number seed Seed to determine the value obtained after the server's second (2)th serialization operation. The server sends the value obtained after the server's second (2)th serialization operation to the client, so that the client can perform the first (i+1)th (2)th serialization operation based on the value obtained after the server's second (2)th serialization operation and the random number seed Seed to determine the value obtained after the client's first (i+1)th (2)th serialization operation. The server then performs the 2i+1(3)th serialization operation based on the value obtained after the 2i(2)th serialization operation and the random number seed, in order to determine the value obtained after the 2i+1(3)th serialization operation. The value obtained after the 2i+1(3)th serialization operation is used by the server to verify the name in the name-value pair carried by the i+1(2)th access request.

[0066] When i=3, that is, the server receives the third access request from the client. After the name verification of the name-value pair carried in the third access request passes, the server performs the second (6th) serialization operation based on the value obtained after the server's second (2i-1) (5th) serialization operation and the random number seed Seed to determine the value obtained after the server's second (6th) serialization operation. The server sends the value obtained after the server's second (6th) serialization operation to the client, so that the client can perform the (i+1) (4th) serialization operation based on the value obtained after the server's second (6th) serialization operation and the random number seed Seed to determine the value obtained after the client's (i+1) (4th) serialization operation. The server then performs the 2i+1(7)th serialization operation based on the value obtained after the 2i(6)th serialization operation and the random number seed, in order to determine the value obtained after the 2i+1(7)th serialization operation. The value obtained after the 2i+1(7)th serialization operation is used by the server to verify the name in the name-value pair carried by the i+1(4)th access request.

[0067] In a specific implementation, the random number seed serialization mechanism in this embodiment can be applied to the secure access process of a web application, including but not limited to web client request legitimacy verification and web session management. Optionally, the random number seed serialization mechanism can also be applied to encrypted data access and transmission in a web application, including but not limited to data encryption transmitted between the web client and the web server.

[0068] In one embodiment, the access request sent by the client carries a name-value pair containing a Session ID. This name-value pair is sent to the server via the message header. A flowchart illustrating the interaction between the server and client involved in the access method can be found in [reference needed]. Figure 4 ,include:

[0069] Step 401: The user logs into the server's web application through the client.

[0070] Step 402: After successful server login verification, a valid Session ID is generated to identify the current session. A random number seed, Seed, is also generated. The first serialization operation is performed on Seed to obtain S-Session Name0. Seed, S-Session Name0, and Session ID are saved, and the name-value pair Seed:Session ID is returned to the client. The Session ID can be generated by the server after receiving the session negotiation request from the client. It should be noted that... Figure 4 The process of the client sending a negotiation request is not shown in the diagram. Figure 4 Request 1 and Request 2 can both be understood as session validity verification requests initiated by the client after the client sends a session negotiation request and negotiates the Session ID with the server.

[0071] S-Session Name0 is the value obtained after the first serialization operation on the server side.

[0072] Step 403: After receiving the name-value pair Seed:Session ID, the client performs the first serialization operation based on the name Seed to obtain C-Session Name0, and saves Seed, C-Session Name0 and Session ID.

[0073] C-Session Name0 is the value obtained after the client's first serialization operation.

[0074] Step 404: When the client sends its first access request, it includes the name-value pair C-Session Name0:Session ID in the request header. Upon receiving the first access request, the server verifies whether the name C-Session Name0 matches the stored S-Session Name0 (i.e., verifying C-Session Name0 in the diagram). If they do not match, the Session ID is considered invalid, the request is rejected, and the session is closed. Figure 4 Request 1 in the text refers to the first access request.

[0075] Step 405: If the C-Session Name0 verification in step 404 passes (also known as successful validation), then the Session ID value is deemed valid. The server performs a second serialization operation based on S-Session Name0 and Seed to obtain S-Session Name1 and returns the name-value pair S-Session Name1:Session ID to the client. Then, the server performs a third serialization operation based on S-Session Name1 and Seed to obtain S-Session Name2 and saves S-Session Name2 for verification of C-Session Name2 in the client's next access request.

[0076] Here, S-Session Name1 is the value obtained after the second serialization operation on the server side. S-Session Name2 is the value obtained after the third serialization operation on the server side.

[0077] Step 406: The client receives S-Session Name1, performs a second serialization operation based on S-Session Name1 and the saved Seed to obtain C-Session Name2, and then saves C-Session Name2.

[0078] C-Session Name2 is the value obtained after the client's second serialization operation.

[0079] Step 407: When the client sends the second access request, it includes the name-value pair C-Session Name2:Session ID in the request header. Upon receiving the second access request, the server verifies whether the name C-Session Name2 matches the stored S-Session Name2. If they do not match, the value Session ID is considered invalid, the request is rejected, and the session is closed. Figure 4 Request 2 in the text refers to the second access request.

[0080] Step 408: If the C-Session Name2 verification in step 407 passes, the Session ID value is considered valid. The server performs a fourth serialization operation based on S-Session Name2 and Seed to obtain S-Session Name3 and returns the name-value pair S-Session Name3:Session ID to the client. Then, the server performs a fifth serialization operation based on S-Session Name3 and Seed to obtain S-Session Name4 and saves S-Session Name4 for verification of C-Session Name4 in the next access request sent by the client.

[0081] S-Session Name3 is the value obtained after the server's fourth serialization operation. S-Session Name4 is the value obtained after the server's fifth serialization operation.

[0082] Step 409: The client receives S-Session Name3, performs the third serialization operation based on S-Session Name3 and Seed to generate C-Session Name4, and then saves C-Session Name4.

[0083] C-Session Name4 is the value obtained after the third serialization operation by the client.

[0084] When the client sends its third access request, it includes the name-value pair C-Session Name4:Session ID in the request header. Upon receiving the third access request, the server verifies whether the name C-Session Name4 matches the stored S-Session Name4. If they do not match, the value Session ID is considered invalid, the request is rejected, and the session is closed. If C-Session Name4 passes verification, the value Session ID is considered valid. The server then performs a sixth serialization operation based on S-Session Name4 and Seed to obtain S-Session Name5 and returns the name-value pair S-Session Name5:Session ID to the client. The server then performs a seventh serialization operation based on S-Session Name5 and Seed to obtain S-Session Name6 and stores S-Session Name6 for verification in the client's next access request.

[0085] Repeat the above Session Name generation and verification process until the session ends. After the session ends, the web application clears the saved Seed, Session Name, and Session ID.

[0086] In this embodiment, the risk of Session ID transmission in the message header being easily intercepted and forged is reduced. Instead, the message header transmits a serialized operation name-value pair, Session Name:Session ID, and a verification name, Session Name, is used to verify the legitimacy of the Session ID value. This makes the transmission of Session ID in web technology applications more secure and reliable. Any Session Name intercepted by an attacker cannot be traced back to its historical origins or evolve, solving security protection problems in web applications such as session prediction, session hijacking, and session fixation. Moreover, there is no need to encrypt the transmission of excessively long and complex Session ID values. Only the corresponding Session Name combined with the Seed is serialized, and the legitimacy of the Session ID value is determined by verifying the transmitted Session Name. This saves system resources as much as possible, maximizing both session access security and transmission efficiency.

[0087] In one embodiment, the name-value pair carried in the access request sent by the client contains the Session ID. This name-value pair is sent to the server via form parameters. A flowchart illustrating the interaction between the server and client involved in the access method can be found in [reference needed]. Figure 5 ,include:

[0088] Step 501: The user logs into the server's web application through the client.

[0089] Step 502: After successful server-side login verification, a valid Session ID is generated to identify the current session. A random number seed, Seed, is also generated. The first serialization operation is performed on Seed to obtain S-Name0. Seed, S-Name0, and Session ID are saved, and the name-value pair Seed:Session ID is returned to the client via a form parameter. The Session ID can be generated by the server after receiving the session negotiation request from the client. It should be noted that... Figure 5 The process of the client sending a negotiation request is not shown in the diagram. Figure 5 Request 1 and Request 2 can both be understood as session validity verification requests initiated by the client after the client sends a session negotiation request and negotiates the Session ID with the server.

[0090] S-Name0 is the value obtained after the first serialization operation on the server.

[0091] Step 503: After receiving the name-value pair Seed:Session ID, the client performs the first serialization operation based on the name Seed to obtain C-Name0, and saves Seed, C-Name0 and Session ID.

[0092] C-Name0 is the value obtained after the first serialization operation by the client.

[0093] Step 504: When the client sends its first access request, it includes the name-value pair C-Name0:Session ID in the form parameters. Upon receiving the first access request, the server verifies whether the name C-Name0 matches the stored S-Name0. If they do not match, the value "Session ID" is considered invalid, the request is rejected, and the session is closed. Figure 5 Request 1 in the text refers to the first access request.

[0094] Step 505: If C-Name0 passes the verification in step 504, the Session ID value is confirmed to be valid. The server performs a second serialization operation based on S-Name0 and Seed to obtain S-Name1 and returns the name-value pair S-Name1:Session ID to the client. Then, the server performs a third serialization operation based on S-Name1 and Seed to obtain S-Name2 and saves S-Name2 for verification of C-Name2 in the next access request sent by the client.

[0095] Where S-Name1 is the value obtained after the second serialization operation on the server side. S-Name2 is the value obtained after the third serialization operation on the server side.

[0096] Step 506: The client receives S-Name1, performs a second serialization operation based on S-Name1 and the saved Seed to obtain C-Name2, and then saves C-Name2.

[0097] C-Name2 is the value obtained after the second serialization operation by the client.

[0098] Step 507: When the client sends the second access request, it includes the name-value pair C-Name2:Session ID in the form parameters. Upon receiving the second access request, the server verifies whether the name C-Name2 matches the saved S-Name2. If they do not match, the value "Session ID" is considered invalid, the request is rejected, and the session is closed. Figure 5Request 2 in the text refers to the second access request.

[0099] Step 508: If C-Name2 passes the verification in step 507, the Session ID value is considered valid. The server performs a fourth serialization operation based on S-Name2 and Seed to obtain S-Name3 and returns the name-value pair S-Name3:Session ID to the client. Then, the server performs a fifth serialization operation based on S-Name3 and Seed to obtain S-Name4 and saves S-Name4 for verification of C-Name4 in the next access request sent by the client.

[0100] S-Name3 is the value obtained after the fourth serialization operation on the server side. S-Name4 is the value obtained after the fifth serialization operation on the server side.

[0101] Step 509: The client receives S-Name3, performs the third serialization operation based on S-Name3 and Seed to generate C-Name4, and then saves C-Name4.

[0102] C-Name4 is the value obtained after the third serialization operation by the client.

[0103] Repeat the Name generation and validation process described above until the session ends. After the session ends, the web application clears the saved Seed, Name, and Session ID.

[0104] In this embodiment, name-value pairs are stored in form parameters for transmission. The transmission of form parameters supports encrypted transmission. Therefore, in addition to saving a lot of system resources for small terminal devices in the communication field, this embodiment can also combine parameter asymmetric encryption and decryption processes for encrypted transmission. This can effectively perform cross-site request forgery (CSRF) verification, session forgery verification, and session hijacking protection, avoiding the single nature of web application security verification. By verifying the legitimacy of web sessions through multiple checks, the security risks during web application access can be reduced as much as possible.

[0105] In one embodiment, the name-value pair carried in the access request sent by the client contains parameters configured in the client request. This name-value pair is sent to the server via form parameters. A flowchart illustrating the interaction between the server and client involved in the access method can be found in [reference needed]. Figure 6 ,include:

[0106] Step 601: The user logs into the server's web application through the client.

[0107] Step 602: After successful server login verification, a random number seed (Seed) is generated. The first serialization operation is performed on the Seed to obtain S-Name0. The Seed and S-Name0 are saved, and the Seed is returned to the client.

[0108] S-Name0 is the value obtained after the first serialization operation on the server.

[0109] Step 603: After receiving Seed, the client performs the first serialization operation based on the name Seed to obtain C-Name0, and saves Seed and C-Name0.

[0110] C-Name0 is the value obtained after the first serialization operation by the client.

[0111] Step 604: When the client sends the first parameter configuration request, it includes the name-value pair C-Name0 in the form parameters. Upon receiving the first parameter configuration request, the server verifies whether the name C-Name0 matches the saved S-Name0. If they do not match, the value parameter is considered invalid, and the parameter configuration request is rejected. Figure 6 Request 1 in the text refers to the first parameter configuration request, which can also be understood as the first access request.

[0112] Step 605: If C-Name0 passes the verification in step 604, the value parameter is deemed valid. The server performs a second serialization operation based on S-Name0 and Seed to obtain S-Name1 and returns the name-value pair S-Name1 to the client. Then, the server performs a third serialization operation based on S-Name1 and Seed to obtain S-Name2 and saves S-Name2 for verification of C-Name2 in the next parameter configuration request sent by the client.

[0113] Where S-Name1 is the value obtained after the second serialization operation on the server side. S-Name2 is the value obtained after the third serialization operation on the server side.

[0114] Step 606: The client receives S-Name1, performs a second serialization operation based on S-Name1 and the saved Seed to obtain C-Name2, and then saves C-Name2.

[0115] C-Name2 is the value obtained after the second serialization operation by the client.

[0116] Step 607: When the client sends the second parameter configuration request, it includes the name-value pair C-Name2 in the form parameters. Upon receiving the second session negotiation request, the server verifies whether the name C-Name2 included matches the saved S-Name2. If they do not match, the value parameter is considered invalid, the request is rejected, and the session is closed. Figure 6 Request 2 in the text refers to the second parameter configuration request, which can also be understood as the second access request.

[0117] Step 608: If C-Name2 passes the verification in step 607, the value parameter is considered valid. The server performs a fourth serialization operation based on S-Name2 and Seed to obtain S-Name3 and returns S-Name3 to the client. Then, the server performs a fifth serialization operation based on S-Name3 and Seed to obtain S-Name4 and saves S-Name4 for verification of C-Name4 in the next parameter configuration request sent by the client.

[0118] S-Name3 is the value obtained after the fourth serialization operation on the server side. S-Name4 is the value obtained after the fifth serialization operation on the server side.

[0119] Step 609: The client receives S-Name3, performs the third serialization operation based on S-Name3 and Seed to generate C-Name4, and then saves C-Name4.

[0120] C-Name4 is the value obtained after the third serialization operation by the client.

[0121] Repeat the Name generation and parameter validity verification process described above until the session ends. After the session ends, the web application clears the saved Seed and Name.

[0122] In this embodiment, there is no need to encrypt and transmit excessively long and complex parameters (also known as parameter values, i.e., the values ​​in name-value pairs). Simply performing a serialization operation on the simple parameter names (i.e., the names in name-value pairs) achieves the purpose of parameter validity verification and secure transmission. This saves significant system resources for small terminal devices in the communication field. In other words, this embodiment applies a random number seed serialization mechanism to parameter validity verification, using simple parameter name serialization operations instead of complex parameter encryption transmission. This reduces system resource consumption while ensuring security during parameter transmission, providing valuable reference for small terminal devices in the communication field.

[0123] One embodiment of this application relates to an access method applied to a client, see below. Figure 7 ,include:

[0124] Step 701: Send a login request to the server so that the server can generate a random number seed after successfully verifying the login request.

[0125] Step 702: Receive the random number seed sent by the server.

[0126] Step 703: Send an access request to the server so that the server can verify the name in the name-value pair carried in the access request, and determine that the value in the name-value pair is valid after the verification is successful; wherein, the name in the name-value pair is the value obtained by the client after performing serialization operation based on the random number seed.

[0127] Since this embodiment corresponds to the above-described embodiment of the access method applied to the server, this embodiment can be implemented in conjunction with the above-described embodiment of the access method applied to the server. The relevant technical details mentioned in the above-described embodiment of the access method applied to the server are still valid in this embodiment, and the technical effects achievable in the above-described embodiment of the access method applied to the server can also be achieved in this embodiment. To reduce repetition, they will not be repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the second embodiment.

[0128] It should be noted that the examples described above in the embodiments of this application are merely illustrative for ease of understanding and do not constitute a limitation on the technical solution of the present invention.

[0129] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.

[0130] One embodiment of this application relates to an access system, see [link / reference] Figure 8 This includes: server-side 801 and client-side 802;

[0131] Client 802 is used to send a login request to server 801.

[0132] Server 801 is used to generate a random number seed after successfully verifying the login request, and then send the random number seed to the client 802.

[0133] Client 802 is also used to send access requests to server 801; the access request carries a name-value pair, where the name is the value obtained by client 802 after performing serialization operation based on the random number seed.

[0134] The server-side 801 checksum is also used to validate the name in the name-value pair carried in the access request, and to determine the validity of the value in the name-value pair after the validation passes.

[0135] It is not difficult to see that this embodiment is a system embodiment corresponding to the above method embodiments, and this embodiment can be implemented in conjunction with the above method embodiments. The relevant technical details and technical effects mentioned in the above method embodiments are still effective in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above method embodiments.

[0136] One embodiment of this application relates to an electronic device, see [reference] Figure 9 The device includes: at least one processor 901; and a memory 902 communicatively connected to at least one processor 901; wherein the memory 902 stores instructions executable by at least one processor 901, and the instructions are executed by at least one processor 901; when the electronic device is a server, at least one processor 901 is capable of executing the above-described access method applied to the server; when the electronic device is a client, at least one processor 901 is capable of executing the above-described access method applied to the client.

[0137] The memory 902 and processor 901 are connected via a bus, which can include any number of interconnecting buses and bridges. The bus connects various circuits of one or more processors 901 and memory 902. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 901 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 901.

[0138] Processor 901 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 902 can be used to store data used by processor 901 during operation.

[0139] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the above-described method embodiments.

[0140] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0141] Those skilled in the art will understand that the above embodiments are specific examples of implementing the present invention, and in practical applications, various changes in form and detail may be made without departing from the spirit and scope of the present invention.

Claims

1. An access method, characterized in that, Applied to the server side, including: Receive login requests from clients; After the login request is successfully verified, a random number seed is generated and sent to the client. Receive an access request sent by the client; wherein the access request carries a name-value pair, and the name in the name-value pair is: the value obtained by the client after performing a serialization operation based on the random number seed; The name in the name-value pair is validated, and if the validation passes, the value in the name-value pair is determined to be valid. Based on the value obtained after the server-side serialization operation and the random number seed, a serialization operation is performed to generate a first serialization result and a second serialization result. The first serialization result is sent to the client. The number of serialization operations for the second serialization result is greater than the number of serialization operations for the first serialization result. The first serialization result is used by the client to calculate the name in the next access request, and the second serialization result is used to verify the name in the client's next access request.

2. The access method according to claim 1, characterized in that, The value in the name-value pair carried in the access request includes: the Session ID, a valid identifier of the currently valid session negotiated by the server and the client.

3. The access method according to claim 1, characterized in that, The values ​​in the name-value pairs carried in the access request include the parameter values ​​configured in the client request.

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

5. The access method according to any one of claims 1 to 4, characterized in that, Receiving the access request sent by the client includes: Receive the i-th access request sent by the client; The validation of the name in the name-value pair includes: Determine whether the name carried in the i-th access request is consistent with the value obtained after the (2i-1)-th serialization operation on the server. Wherein, when i=1, the name carried in the first access request is: the value obtained by the client performing the first serialization operation according to the random number seed; the value obtained by the server after the first serialization operation is: the value obtained by the server performing the first serialization operation according to the random number seed. When 1 < i ≤ n, the name carried in the i-th access request is: the name of the name carried by the client according to the random number seed and The value obtained after the (2i-2)th serialization operation on the server side is the value obtained after the (i-1)th serialization operation on the server side; the value obtained after the (2i-1)th serialization operation on the server side is the value obtained after the (2i-2)th serialization operation on the server side, where n is a natural number greater than or equal to 2. If the name carried in the i-th access request is consistent with the value obtained after the (2i-1)-th serialization operation by the server, then the verification is confirmed to be successful.

6. The access method according to claim 5, characterized in that, The step of performing serialization operations based on the value obtained after serialization operations on the server and the random number seed to generate a first serialization result and a second serialization result, and sending the first serialization result to the client, includes: Based on the value obtained after the (2i-1)th serialization operation on the server side and the random number seed, the 2ith serialization operation is performed to determine the value obtained after the 2ith serialization operation on the server side. The value obtained after the 2ith serialization operation on the server is sent to the client as the first serialization result, so that the client can perform the (i+1)th serialization operation based on the value obtained after the 2ith serialization operation on the server and the random number seed, so as to determine the value obtained after the (i+1)th serialization operation on the client. Based on the value obtained after the 2ith serialization operation on the server and the random number seed, a 2i+1th serialization operation is performed to determine the value obtained after the 2i+1th serialization operation on the server; wherein, the value obtained after the 2i+1th serialization operation on the server is used as the second serialization result, which is used by the server to verify the name in the name-value pair carried in the i+1th access request.

7. An access method, characterized in that, Applied to the client side, including: Send a login request to the server so that the server can generate a random number seed after successfully verifying the login request; Receive the random number seed sent by the server; An access request is sent to the server so that the server can verify the name in the name-value pair carried in the access request, and determine that the value in the name-value pair is valid after the verification is successful; wherein, the name in the name-value pair is the value obtained by the client after performing serialization operation based on the random number seed; The server receives a first serialization result sent by the client; wherein the first serialization result is used by the client to calculate the name in the next access request, and the server verifies the name in the next access request by the client through a second serialization result. The first serialization result and the second serialization result are generated by the server through serialization operation based on the value obtained after the server's serialization operation and the random number seed. The number of serialization operations of the second serialization result is greater than the number of serialization operations of the first serialization result.

8. An access system, characterized in that, include: Server and client; The client is used to send a login request to the server; The server is configured to generate a random number seed after successfully verifying the login request, and then send the random number seed to the client. The client is also configured to send an access request to the server; wherein the access request carries a name-value pair, and the name in the name-value pair is the value obtained by the client after performing a serialization operation based on the random number seed; The server is further configured to verify the name in the name-value pair carried in the access request, and determine that the value in the name-value pair is valid after the verification is passed; perform serialization operation on the value obtained after the serialization operation by the server and the random number seed to generate a first serialization result and a second serialization result, and send the first serialization result to the client; wherein the number of serialization operations of the second serialization result is greater than the number of serialization operations of the first serialization result, the first serialization result is used by the client to calculate the name in the next access request, and the second serialization result is used to verify the name in the next access request of the client.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor; When the electronic device is a server, the at least one processor is capable of executing the access method as described in any one of claims 1 to 6; When the electronic device is a client, the at least one processor is capable of executing the access method as described in claim 7.

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

Images