CN114844644A - Resource request method, device, electronic equipment and storage medium - Google Patents

Abstract

The application discloses a resource request method, a resource request device, electronic equipment and a storage medium. And the terminal encrypts the information corresponding to the request to obtain a token based on the session key of the server, and sends the token and the information corresponding to the request to the server along with the request. The server determines a terminal based on the Cookie in the request, encrypts information carried by the request according to a session key of the determined terminal to generate a corresponding token, verifies the token carried by the request based on the generated token, and sends corresponding resources to the determined terminal under the condition that the token carried by the request is matched with the generated token. In the scheme, the identity of the request terminal is verified through the token, and even if an attacker obtains the terminal Cookie and the token carried by the request, the attacker cannot request other resources except the resource corresponding to the token, so that session hijacking caused by Cookie leakage can be avoided, and the session safety of the server and the terminal equipment is improved.

Description

Resource request method, device, electronic device and storage medium

technical field

The present application relates to the field of network technologies, and in particular, to a resource request method, apparatus, electronic device, and storage medium.

Background technique

Cookies are data stored on terminal devices by electronic devices such as servers to identify users and track session sessions. After the cookie is leaked, the attacker can use the cookie to hijack the session, and the security of the session is low.

SUMMARY OF THE INVENTION

In view of this, the embodiments of the present application provide a resource request method, apparatus, electronic device, and storage medium, so as to at least solve the problem of low session security in the related art.

The technical solutions of the embodiments of the present application are implemented as follows:

An embodiment of the present application provides a resource request method, which is applied to a first terminal, and the method includes:

Encrypting the first information based on the first key to generate a first token; the first key represents a session key between the first terminal and the first server;

sending a first request to the first server; the first request is used to request a first resource from the first server, and carries the first token and the first information; wherein,

The first information includes description information of the first resource and a first time; the first time represents a time related to the first request; the first resource is stored in the first server based on the first time. A key and the first information are sent to the first terminal after passing the verification of the first token.

Wherein, in the above solution, encrypting the first information based on the first key to generate the first token includes:

Inputting the first information into a first component to obtain a first token output by the first component; wherein,

The first component is used for encrypting the input information according to the corresponding key, and generating and outputting a token; the code corresponding to the first component is obfuscated.

In the above solution, after the first information is input into the first component and before the first token output by the first component is obtained, the method further includes:

Based on the first operation on the second information, the first key is obtained; wherein,

The second information represents information obtained by performing a second operation on the first key; the second operation represents a segmented storage operation; and the first operation represents a reverse operation of the second operation.

In the above solution, the code corresponding to the first component is represented as the code of the first programming language, which is obtained by converting the code of the second programming language after obfuscation.

In the above solution, before the first information is encrypted based on the first key to generate the first token, the method further includes:

In the case that the first terminal successfully logs in to the first server, the first key issued by the first server is received.

In the above solution, before the receiving the first key issued by the first server, the method further includes:

sending a setting identifier to the first server; wherein,

The first server delivers the first key to the first terminal in the case of receiving the setting identifier.

The embodiment of the present application also provides a resource request method, which is applied to the first server, and the method includes:

receiving a second request; the second request is used to request a second resource, and carries a second token and third information; the third information includes description information and a second time of the second resource; the a second time characterizes the time associated with the second request;

The third information is encrypted based on the second key to generate a third token; the second key represents the session key between the second terminal and the first server; the second terminal according to The cookie in the second request is determined;

If the second token matches the third token, the second resource is sent to the second terminal.

In the above solution, before the receiving the second request, the method further includes:

When the second terminal successfully logs in to the first server, the second key is generated and delivered to the second terminal.

In the above solution, the generating and delivering the second key to the second terminal includes:

In the case of receiving the setting identifier sent by the second terminal, the second key is generated and delivered to the second terminal.

In the above solution, the generating the third token includes:

In the case that the second request satisfies the first set condition, generating a third token;

The first setting conditions include:

The cookie verification in the request is passed;

and / or,

The second time carried by the request is within the set time period.

In the above scheme, the method also includes:

If the second token does not match the third token, delete the corresponding cookie stored by the first server according to the cookie in the second request.

The embodiment of the present application also provides a resource requesting apparatus, which is applied to the first terminal, including:

a first generating unit, configured to encrypt the first information based on a first key to generate a first token; the first key represents a session key between the first terminal and the first server;

a first sending unit, configured to send a first request to the first server; the first request is used to request a first resource from the first server, and carries the first token and the first information; of which,

The first information includes description information of the first resource and a first time; the first time represents a time related to the first request; the first resource is stored in the first server based on the first time. A key and the first information are sent to the first terminal after passing the verification of the first token.

The embodiment of the present application also provides a resource requesting device, which is applied to the first server, including:

a first receiving unit, configured to receive a second request; the second request is used to request a second resource, and carries a second token and third information; the third information includes description information of the second resource and a second time; the second time represents the time associated with the second request;

a second generating unit, configured to encrypt the third information based on a second key to generate a third token; the second key represents a session key between the second terminal and the first server ; The second terminal determines according to the Cookie in the second request;

A second sending unit, configured to send the second resource to the second terminal when the second token matches the third token.

Embodiments of the present application also provide an electronic device, including: a processor and a memory for storing a computer program that can be executed on the processor,

Wherein, the processor is configured to execute the steps of any one of the above resource request methods when running the computer program.

Embodiments of the present application further provide a storage medium on which a computer program is stored, and when the computer program is executed by a processor, implements the steps of any of the foregoing resource request methods.

In the embodiment of the present application, the terminal obtains the token based on the information corresponding to the session key encryption request of the server, including the description information of the resource to be requested and the time related to the request, and sends the above information corresponding to the token and the request with the request. sent to the server. The server determines the terminal based on the cookie in the request, encrypts the information carried in the request according to the session key of the determined terminal, including the description information of the requested resource and the time related to the request, generates a corresponding token, and generates a corresponding token based on the generated token. The token carried in the request is verified, and in the case that the token carried in the request matches the generated token, the server sends the corresponding resource to the determined terminal. In the above scheme of distributing resources based on the token-based verification result, the identity of the requesting terminal is verified by the token. Since the token is related to the request, the attacker cannot request for the removal of the token even if he obtains the terminal cookie and token carried in the request. In this way, session hijacking caused by cookie leakage can be avoided, and the security of the session between the server and the terminal device is improved.

Description of drawings

FIG. 1 is a schematic flowchart of a terminal-side implementation of a resource request method provided by an embodiment of the present application;

FIG. 2 is a schematic flowchart of an implementation of generating a first token in a resource request method provided by another embodiment of the present application;

3 is a schematic diagram of programming language conversion in a resource request method provided by another embodiment of the present application;

4 is a schematic diagram of grouping in a resource request method provided by another embodiment of the present application;

FIG. 5 is a schematic diagram of an implementation flow of a resource requester according to another embodiment of the present application;

FIG. 6 is a schematic flowchart of a server-side implementation of a resource request method provided by another embodiment of the present application;

FIG. 7 is a schematic diagram of an implementation flowchart of a resource request method provided by another embodiment of the present application;

FIG. 8 is a schematic diagram of an implementation flowchart of a resource request method provided by another embodiment of the present application;

FIG. 9 is an interactive schematic diagram of a resource request method provided by an application embodiment of the present application;

FIG. 10 is a schematic structural diagram of a resource requesting apparatus provided by an embodiment of the present application;

FIG. 11 is a schematic structural diagram of a resource requesting apparatus provided by another embodiment of the present application;

FIG. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed ways

Cookies are data stored on terminal devices by electronic devices such as servers to identify users and track session sessions. During a session, an attacker can use a cookie as a third party to participate, insert malicious data into the data packet, request resources, monitor the session, or even take over the session instead of one party. The security of the session is low.

Based on this, in various embodiments of the present application, the terminal obtains the token based on the information corresponding to the server's session key encryption request, including the description information of the resource to be requested and the time related to the request, and associates the token with the request. The corresponding above information is sent to the server along with the request. The server determines the terminal based on the cookie in the request, encrypts the information carried in the request according to the session key of the determined terminal, including the description information of the requested resource and the time related to the request, generates a corresponding token, and generates a corresponding token based on the generated token. The token carried in the request is verified, and in the case that the token carried in the request matches the generated token, the server sends the corresponding resource to the determined terminal. In the above scheme of distributing resources based on the token-based verification result, the identity of the requesting terminal is verified by the token. Since the token is related to the request, the attacker cannot request for the removal of the token even if he obtains the terminal cookie and token carried in the request. In this way, session hijacking caused by cookie leakage can be avoided, and the security of the session between the server and the terminal device is improved.

In order to make the purpose, technical solutions and advantages of the present application more clearly understood, the present application will be described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application.

The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems will be specifically described in detail below with reference to the accompanying drawings. The following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

FIG. 1 is a schematic diagram of an implementation flow of a resource request method provided by an embodiment of the present application. An embodiment of the present application provides a resource request method, which is applied to a first terminal, where the first terminal includes but is not limited to electronic devices such as mobile phones and tablets. . The first terminal may implement the resource request method by loading a browser or the like. Resource request methods include:

Step 101: Encrypt the first information based on the first key to generate a first token.

Wherein, the first key represents a session key between the first terminal and the first server.

Step 102: Send a first request to the first server; the first request is used to request a first resource from the first server, and carries the first token and the first information.

Wherein, the first information includes description information of the first resource and a first time; the first time represents a time related to the first request; the first resource is stored in the first server based on the The first key and the first information are sent to the first terminal after passing the verification of the first token.

In step 101, a session relationship is pre-established between the first terminal and the first server, and the first terminal has a session key (that is, a first key) with the first server. The first terminal determines the description information of the first resource to be requested, and determines the first time according to the time related to the current request. The first terminal takes the first information (including the description information of the first resource and the first time) as the input of the calculation, and uses the first key to calculate the hash function to obtain the first token that is output by the calculation. The calculation of the token can be achieved through a hash-based message authentication code (HMAC, Hash-based MessageAuthentication Code), based on a hash function and a session key.

The first information represents information corresponding to the current request, including the first time and description information of the first resource. A unique token can be generated based on the first information to identify the corresponding request. The first time can distinguish the current request from previous or subsequent requests, and may be, for example, a time or a time period within the time period in which the request is currently generated. Preferably, the first terminal determines the first time according to the execution time of the set behavior that needs to be executed for each request, including but not limited to: the time when the terminal receives an instruction instructing to initiate a resource request; the time when the terminal generates the first token . In some embodiments, the first time may be in the form of a timestamp.

The first resource refers to an object that can be accessed, such as data such as documents, images, and sounds. The description information of the first resource represents the description information of the corresponding resource location, and according to different request methods, the description information includes: request website and/or web form information. Since the first time corresponding to each request is different, the first token corresponding to each request is different, and there is a corresponding relationship between the first token and the first request.

The first key represents the session key of the session between the first terminal and the first server, and is determined by the terminal and the server through negotiation, and the session key may represent the identity of the terminal communicating with the server in this session.

In step 102, the first terminal generates and sends a request message of the first request to the first server based on at least the generated first token and the first information (that is, the information corresponding to the first token), so as to request the first request. A server delivers the first resource. In the case that the first server passes the verification of the first token, the first terminal receives the first resource correspondingly sent by the first server based on the first request. Here, the request message also carries the cookie of the first terminal. The server determines the identity of the corresponding terminal according to the cookie carried in the received request message, and determines the session key corresponding to the terminal identity from the session key stored by the server. , so as to verify the first token according to the session key and the first information.

In the above solution for issuing resources based on the token-based verification result, for each resource request, the first terminal needs to perform step 101 to generate a corresponding token, and send the request in step 102 with the generated token to obtain the The resource issued after the token carried in the request is verified.

As another embodiment of the present application, as shown in FIG. 2 , encrypting the first information based on the first key to generate the first token includes:

Step 1011: Input the first information into the first component to obtain the first token output by the first component.

Wherein, the first component is used for encrypting the input information according to the corresponding key, and generating and outputting a token; the code corresponding to the first component is obfuscated.

The first terminal inputs the first information into the first component, and the first component encrypts the input first information according to the corresponding key (that is, the first key) to generate the first token, and the first terminal obtains the first token. The first token output by the component. Among them, the code corresponding to the first component is obfuscated, and the first component is equivalent to a black box, so as to protect the code logic of the first component and improve the difficulty of reverse analysis and cracking by attackers, that is, the code corresponding to the first component is The obfuscation process can reduce the risk of reverse cracking.

The first terminal obtains the first token by invoking the first component whose code has undergone obfuscation processing to implement encryption processing of the first information based on the first key. In the process of resource request, the obfuscated component is used to generate the token. In this way, the code logic for generating the first token is invisible to the front-end, which improves the security of the front-end operation and increases the difficulty and time cost of reverse engineering for attackers. Thus, the security of the session is improved.

As an embodiment of the present application, the code corresponding to the first component is represented as the code of the first programming language, which is obtained by converting the code of the second programming language after obfuscation processing.

First, the code of the second programming language corresponding to the first component is generated, and then code obfuscation is performed on the code of the second programming language, and the obfuscated second programming language code is converted into the code of the first programming language. In practical applications, the second programming language may be C/C++, and the first programming language may be JS.

The code conversion of different programming languages can be implemented with the backend of OLLVM, which increases the time cost and difficulty of reverse engineering.

In this way, the difficulty and time cost of reverse engineering by the attacker are increased, and the risk of being reversely cracked is reduced, thereby improving the security of the session.

As an embodiment of the present application, with reference to the schematic diagram of programming language conversion shown in FIG. 3, the C/C++ (second programming language) code corresponding to the first component is generated, and the C/C++ code is converted into LLVM IRcode through the Clang front-end , and then negatively optimize the IR code generated by the front-end with the help of the back-end of OLLVM. The obfuscation strategies used are basic block segmentation, instruction inflation, false block filling and control flow flattening. Convert the obfuscated IR code to front-end js (first programming language) code using the LLVM webasm backend and wasm-ld linker.

As an embodiment of the present application, after the first information is input into the first component, and before the first token output by the first component is obtained, the method further includes:

Based on the first operation on the second information, the first key is obtained; wherein,

The second information represents information obtained by performing a second operation on the first key; the second operation represents a segmented storage operation; and the first operation represents a reverse operation of the second operation.

The first terminal performs a segmented storage operation (second operation) on the first key to obtain the second information stored in the setting storage medium. After the first information is input into the first component, the first component performs data reading and restoration processing (first operation) on the second information stored in the setting storage medium to obtain the first key. The segment storage operation includes splitting the session key into a first set number of fields according to FIG. 4 , grouping the split fields, and storing each group of data in a storage medium in segments. The setting component reads the data stored in different locations in segments, and then restores the first key according to the reverse operation in FIG. 4 . When grouping, the split fields can be equally or unequally divided into a second set number of groups.

Here, the second operation can be considered as an encoding operation, the first operation is a corresponding decoding operation, the first key is stored with the corresponding encoding result, and the first key is obtained by restoring the first component.

In practical applications, the grouping diagram shown in FIG. 4 is taken as an example for description, the session key is split into 16 fields, the split fields are arranged as shown in the figure, and divided into 4 groups.

In this way, the first key is hidden in the first component of the black box, which ensures that the session key is invisible to the front end, which increases the difficulty and time cost of reverse engineering by the attacker, thereby improving the security of the session.

As another embodiment of the present application, as shown in FIG. 5 , before the first information is encrypted based on the first key to generate the first token, the method further includes:

Step 501: In the case that the first terminal successfully logs in to the first server, receive the first key issued by the first server.

The first terminal sends the login information to the first server, and the first server performs user authentication on the first terminal based on the login information. After the server determines that the user authentication is successful, that is, after the first terminal successfully logs in to the first server, a session relationship is successfully established between the first terminal and the first server, and the first server generates a Cookie and a session key for the newly created session ( That is, the first key), and deliver the cookie and the first key to the first terminal. The login information is used for the authentication of the terminal by the server, including but not limited to: user ID (uid) and/or password (pwd).

As an embodiment of the present application, before the receiving the first key issued by the first server, the method further includes:

Send a setting identifier to the first server.

Wherein, the first server delivers the first key to the first terminal in the case of receiving the setting identifier.

During the process of establishing a session relationship between the first terminal and the first server, the first terminal sends a setting identifier to the first server to indicate that the first terminal supports a specific session authentication mode and protocol version, where the specific session authentication mode and protocol The version corresponds to the resource request method in the embodiment of this application, and is different from the standard Cookies authentication method. After receiving the setting identifier, the server determines that the first terminal supports a specific session authentication mode and protocol version, and issues a cookie and a first key to the first terminal.

The manner in which the first terminal sends the setting identifier to the first server may be sent to the first server together with the login information, or may be additionally sent to the first server, which is not limited herein. Preferably, the setting identifier is carried in the login information in the form of a message header.

By setting the identifier, the first terminal transmits information that the terminal supports a specific session authentication method and protocol version to the first server, and the first server determines to communicate with the first terminal in a manner corresponding to the embodiment of the present application after learning the information.

FIG. 6 is a schematic diagram of an implementation flowchart of a resource request method provided by another embodiment of the present application. An embodiment of the present application provides a resource request method, which is applied to a first server. Resource request methods include:

Step 601: Receive a second request.

The second request is used to request a second resource, and carries a second token and third information; the third information includes description information of the second resource and a second time; the second time Characterizes the time associated with the second request.

Step 602: Encrypt the third information based on the second key to generate a third token.

Wherein, the second key represents a session key between the second terminal and the first server; the second terminal is determined according to the cookie in the second request.

Step 603: In the case that the second token matches the third token, send the second resource to the second terminal.

The first server establishes session relationships with some terminals in advance, and generates and issues corresponding session keys and cookies. The request received by the first server may be sent by the user using his own identity through the terminal, or may be sent by the identity of the user terminal used by the attacker, and the first server can only determine the corresponding request according to the cookie carried in the request. The identity of the terminal is not able to distinguish whether the sender of the request is the identity of the cookie, that is to say, the first server cannot distinguish whether the request is sent by the user terminal or the attacker.

In step 601, the first server receives a second request, and the second request carries a second token, third information corresponding to the second token, and a cookie. The third information represents information corresponding to the current request, including the second time and description information of the second resource. A unique token can be generated based on the third information to identify the corresponding request. For the request sent by the user through the terminal, the second time can distinguish the current request from the previous or subsequent requests, for example, it may be a moment or a time period within the time period in which the request is currently generated. Preferably, the second terminal determines the second time according to the execution time of the set behavior that needs to be executed for each request. In some embodiments, the second time may be in the form of a timestamp. The second token is obtained by the terminal by encrypting the corresponding source data with the session key. The source data of the second token may or may not be the third information. For example, for the purpose of attack, a third party (attack (user) intercepts and initiates a resource request by using the second token, and the requested resource is usually different from the originally requested resource, so the source data of the second token is not the third information.

Therefore, in step 602, the first server determines that the terminal identity is the second terminal according to the cookie carried by the second request, and encrypts the third information with the session key (that is, the second key) of the second terminal to obtain the first terminal. Three tokens, the third token is used to verify the second token, so as to realize the identification of the sender. Here, the way that the first server verifies the second token with the third token may be to compare the third token with the second token, and in the case that the data of the third token and the second token are the same Next, it is determined that the second token matches the third token. Here, the second terminal determined according to the cookie may be the identity of the user terminal that sends the second request, or may be the identity fraudulently used by the attacker.

As an embodiment of the present application, the generating the third token includes:

In the case that the second request satisfies the first set condition, generating a third token;

The first setting conditions include:

The cookie verification in the request is passed;

and / or,

The second time carried by the request is within the set time period.

The first server determines whether the received second request satisfies the first set condition, and generates a third token if the first set condition is met. The first setting condition may be that the cookie in the request has passed the verification, the second time carried in the request can be within the set time period, or the cookie in the request has passed the verification and the second time carried in the request has been set within the time period. It should be noted that the second request satisfies the first set condition, which is a precondition for the first server to generate the third token.

In practical applications, the first set condition includes that the cookie in the request has passed the verification and the second time carried in the request is within the set time period as an example, to illustrate the judgment conditions before the third token is generated: the first server verifies Cookie, if the cookie verification fails, a prompt message is returned; if the cookie verification passes, it is determined whether the second time is within the set time period; if the second time is within the set time period, the first server generates a third token. Wherein, determining whether the second time is within the set time period needs to be based on the time alignment of the terminal and the server. The time period is a set time range, which can be set according to the needs of each server. If the security requirements are high, the set time range should be smaller.

In step 603, in the case that the second token carried in the request matches the generated third token, the first server determines that the source data of the second token is the third information, in other words, the second request is made by Sent by the user terminal. At this time, the first server sends the second resource requested by the second request to the second terminal.

As an embodiment of the present application, as shown in FIG. 7 , the method further includes:

Step 604: If the second token does not match the third token, delete the corresponding cookie stored by the first server according to the cookie in the second request.

In the case that the second token carried in the request does not match the generated third token, the first server determines that the second request is not sent by the user terminal, but is sent by a third party (an attacker). Since the third party has obtained the cookie information of the corresponding user terminal and used the cookie information to initiate a second request, the cookie of the session with the second terminal has been leaked, and the first server deletes the corresponding cookie, and can also send a message to request the second terminal to log in again.

The identity of the requesting terminal is verified by the token. Since the token is related to the request, even if the attacker obtains the terminal cookie and token carried in the request, he cannot request other resources except the resource corresponding to the token. In this way, the leakage of cookies can be avoided. Session hijacking, which improves the security of server and terminal device sessions.

As another embodiment of the present application, as shown in FIG. 8 , before the receiving the second request, the method further includes:

Step 801: When the second terminal successfully logs in to the first server, generate and deliver the second key to the second terminal.

The second terminal sends the login information to the first server, and the first server performs user authentication on the second terminal based on the login information. After the server determines that the user authentication is successful, that is, after the second terminal successfully logs in to the first server, a session relationship is successfully established between the second terminal and the first server, and the first server generates a Cookie and a session key for the newly created session ( That is, the second key), and deliver the cookie and the second key to the second terminal. The login information is used for the authentication of the terminal by the server, including but not limited to: user ID (uid) and/or password (pwd).

As an embodiment of the present application, the generating and delivering the second key to the second terminal includes:

In the case of receiving the setting identifier sent by the second terminal, the second key is generated and delivered to the second terminal.

During the process of establishing a session relationship between the second terminal and the first server, the second terminal sends a setting identifier to the first server to indicate that the second terminal supports a specific session authentication mode and protocol version, where the specific session authentication mode and protocol The version corresponds to the resource request method in the embodiment of this application, and is different from the standard Cookies authentication method. In the case of receiving the setting identifier sent by the second terminal, the first server determines that the second terminal supports a specific session authentication method and protocol version, and generates and delivers a cookie and a second key to the second terminal. It should be noted that the reception of the setting identifier sent by the second terminal by the first server is a precondition for the first server to generate and distribute the cookie and the second key to the second terminal.

The manner in which the second terminal sends the setting identifier to the first server may be sent to the first server together with the login information, or may be additionally sent to the first server, which is not limited herein. Preferably, the setting identifier is carried in the login information in the form of a message header.

By setting the identifier, the second terminal transmits information that the terminal supports a specific session authentication method and protocol version to the first server, and the first server determines to communicate with the second terminal in a manner corresponding to the embodiment of the present application after learning the information.

The present application will be described in further detail below in conjunction with application examples.

After the cookie is leaked, the attacker can reuse the cookie to initiate a session, and the security of the session is low. At the same time, it is difficult for the server to distinguish the attacker's request from the user's request, resulting in resource information leakage.

Based on this, an application embodiment of the present application proposes a black-box-based OTC anti-cookie hijacking authentication reinforcement solution. FIG. 9 shows a schematic diagram of interaction provided by an application embodiment of the present application. In the figure, the browser/client represents the terminal side, and the server represents the service side (server side). The whole process includes at least:

(1) Initialization stage

The initialization phase occurs when the user logs in. The server distributes the session key (k _s ) representing the identity of the session. After the browser/client receives the key, the black box implementation method is used to hide the session key.

1.1 Login operation

The browser sends the user ID (uid) and password (pwd) to the server along with a special HTTP header field: X-OTC (ie, set ID). This header field indicates that the browser supports OTC session authentication and OTC protocol version (v).

1.2 Authenticating users

After successful user authentication, the server checks the request for the presence of the X-OTC header field.

If this header field is present, the server generates a cookie and session key (k _s ) for the newly created session (cid). The session key represents the browser/client identity for this communication with the server.

If the X-OTC header field is not present in the browser request, it can switch to standard Cookies authentication, or it can stop the communication and inform the user that OTC support is mandatory.

The server then stores the user ID (uid), session ID (cid) and the session key ( _ks ).

1.3 Return operation

The server returns the generated cookie and the symmetric encrypted session key (k _s ) to the browser/client.

1.4 Hidden key operation

In order to ensure the confidentiality of the browser/client storage, the browser/client performs segment storage processing on the encrypted session key (k _s ) through the setting component at the front end.

The encrypted session key is split into a first set number of fields, the split fields are grouped, and each group of data is segmented and stored in a storage medium. The segmented storage process will be described with reference to FIG. 4 . The encrypted session key is split into 16 fields, and the split fields are grouped according to the manner in FIG. 4 .

In order to ensure the security of the front-end operation, code obfuscation is performed on the JS code corresponding to the setting component. The setting component here can perform the hidden key operation, the key retrieval operation and some request operations in this application embodiment. Specifically, Encoding and decoding of session keys and token generation can be performed.

(2) Request stage

The request phase occurs when the client initiates each request through the terminal, the browser/client reverses the session key (k _s ) and generates a unique OTC token.

2.1 Key operation

The setting component takes out the segmented data stored in different locations, restores it according to the reverse operation in FIG. 4 , obtains the encrypted session key (k _s ), and finally decrypts to obtain the session key.

2.2 Request operation

For each request, the browser appends an OTC token (ie, the first token) to the Cookie field. Subsequently, the browser/client sends the cookie and OTC token (token generation time (t) and HMAC value) to the server.

where the OTC token uses a hash-based message authentication code (HMAC(k _s , url|t|data)) generated by the session key. The HMAC calculation includes the requested URL (url), the token generation time (t), and any web form information (data) included for POST requests, while the parameters for GET requests are included in the URL. Therefore, for the token carried by each request, the corresponding generation time is different, corresponding to a unique message authentication code, thereby ensuring the uniqueness of the token. Even if the same resource is requested (the requested URL and any web form information included in the POST request), the corresponding token is not the same. An attacker can only replay the exact same request, requesting the same resource, because modifying any payload of the request will change the corresponding HMAC, thus failing the verification. Therefore, attackers cannot reuse OTC tokens to illegally redirect sessions.

(3) Verification stage

The verification phase occurs after the request phase, and the server will verify the user's request. Returns data if authentication is successful, otherwise requires the user to log in again.

3.1 Verify operation

The server first verifies the information in the cookie, and if the verification is unsuccessful, it returns the cookie invalid or cookie error message. Second, the server checks whether the token generation time (t) is within the set time period. The premise of this step is to align the time between the browser/client and the server to determine whether the timestamp carried in the request is within the time period. The time period is a set time range, which can be set according to the needs of each server. If the security requirements are high, the set time range should be smaller. Then, the server computes a new HMAC using the session key _ks and the information in the request (url and data). The server then compares the newly calculated HMAC with the HMAC contained in the token.

3.2 Return operation

If the HMAC value matches, the request verification is passed, and the server returns the resource corresponding to the request. If the HMAC values do not match, or any of the checks mentioned above fail, the request will be rejected and the check will fail.

(4) Cancellation stage

4.1 Logout operation

The session will continue until the session ticket expires or the user instructs to log out. On logout, the browser/client sends the cookie and a request with the corresponding OTC token to the server, the header field just contains an HMAC(k _s , 0) with a value of zero (0), which instructs the browser to delete this Credentials for the domain (browser enforcement policy).

4.2 Logout verification operation

The browser/server side deletes the credentials for this domain based on HMAC. At the same time, it prevents attackers from tricking the server into responding to arbitrary deletion or modification of OTC credentials.

4.3 Successful logout

The logout is successful and the session is complete.

As mentioned above, code obfuscation is performed on the JS code corresponding to the setting component. Preferably, the relevant C/C++ code is converted into LLVM Ir code, followed by code obfuscation through OLLVM. If it is on the browser/server side, it is compiled into front-end js code through the LLVM-webasm backend. As shown in Figure 3, the specific process is as follows:

First, the C/C++ code that implements the above OTC algorithm is generated.

Second, the Clang front end converts the C/C++ code to LLVM IR code.

Third, with the backend of OLLVM, the IR code generated by the frontend is negatively optimized, and the obfuscation strategies used are basic block segmentation, instruction inflation, false block filling, and control flow flattening.

Fourth, use the LLVM webasm backend and wasm-ld linker to convert the obfuscated IR code into front-end js code.

In the solution provided in this application example, a hash-based message authentication code is generated for each request packet (including the time stamp and the description information of the requested resource) through the session key bound to the user (terminal) session, and the Integrity check to prevent Cookie from being reused after being hijacked. At the same time, the black box implementation method can ensure that the acquisition of the device key and the implementation of the HMAC are invisible to the user. The solution provided in this application example has at least one of the following effects:

(1) Cookies cannot be reused after being leaked, which can prevent attackers from obtaining more system information;

(2) The obfuscated code is a black box, and it is difficult to obtain the logic of the source code itself through reverse analysis, thus reducing the risk of reverse cracking;

(3) System resources (operational performance) consumed by running the setting component that implements code obfuscation are reduced.

Here, the terms appearing in this application embodiment are explained.

OTC (One-Time Cookie): A one-time cookie, which is a client-side anti-hijacking scheme that prevents the cookie from being reused after being leaked. Cookies are data stored on the user terminal. When the browser requests the website again, the browser submits the requested URL together with the cookie to the server. The server checks the cookie to identify the user's status.

OLLVM: An open source obfuscation scheme based on the LLVM compiler, which greatly increases the time cost and difficulty of reverse engineering. The main obfuscation strategies are basic block splitting, instruction bloat, spurious block filling and control flow flattening.

Clang: Front-end compiler based on the LLVM backend, fully supports the C++11 standard and is almost fully compatible with the GNU C language specification. In the compilation process, it is mainly responsible for lexical analysis, syntax analysis, semantic analysis, and intermediate code (IR) generation.

LLVM-webAsm: One of the LLVM backends that converts intermediate code to JS code. The responsibility of the back end of the compiler is to optimize the intermediate code (IR code) generated by the front end, and generate the corresponding terminal code according to the target platform specified at compile time. Here webAsm can be seen as a platform like x86, x86_64, aarch64.

HMAC (Hash-based Message Authentication Code): It is a mechanism that uses the hash function in cryptography to perform message authentication. The message authentication that can be provided includes message integrity verification and source identity authentication. The HMAC algorithm is more like an encryption algorithm. Since the HMAC algorithm introduces a key, the security is not completely dependent on the Hash algorithm used.

In order to implement the method of the embodiment of the present application, the embodiment of the present application further provides a resource requesting apparatus, which is applied to the first terminal. As shown in FIG. 10 , the apparatus includes:

a first generating unit 1001, configured to encrypt the first information based on a first key to generate a first token; the first key represents a session key between the first terminal and the first server;

A first sending unit 1002, configured to send a first request to the first server; the first request is used to request a first resource from the first server, and carries the first token and the first request an information; of which,

The first information includes description information of the first resource and a first time; the first time represents a time related to the first request; the first resource is stored in the first server based on the first time. A key and the first information are sent to the first terminal after passing the verification of the first token.

Wherein, in one embodiment, the first generating unit 1001 is configured to:

Inputting the first information into a first component to obtain a first token output by the first component; wherein,

The first component is used for encrypting the input information according to the corresponding key, and generating and outputting a token; the code corresponding to the first component is obfuscated.

In one embodiment, the apparatus further includes:

an operation unit, configured to obtain the first key based on a first operation on the second information after the first information is input into the first component and before the first token output by the first component is obtained ; wherein, the second information represents the information obtained after performing the second operation on the first key; the second operation represents a segmented storage operation; the first operation represents the reverse operation of the second operation .

In one embodiment, the code corresponding to the first component is represented as the code of the first programming language, which is obtained by converting the code of the second programming language after obfuscation processing.

In one embodiment, the apparatus further comprises:

The second receiving unit is configured to, before the first generating unit 1001 encrypts the first information based on the first key and generates the first token, when the first terminal successfully logs in to the first server Next, receive the first key issued by the first server.

In one embodiment, the apparatus further comprises:

a third sending unit, configured to send a setting identifier to the first server before the second receiving unit receives the first key issued by the first server; wherein the first server is in The first key is delivered to the first terminal when the setting identifier is received.

In practical application, the first sending unit 1002, the second receiving unit, and the third sending unit may be implemented by a communication interface in the resource requesting device, and the first generating unit 1001 and the operating unit may be implemented by a resource request-based device. A processor implementation in a resource requesting device.

It should be noted that: when the resource requesting device provided in the above embodiment performs resource request, only the division of the above program modules is used as an example for illustration. That is, the internal structure of the device is divided into different program modules to complete all or part of the processing described above. In addition, the resource requesting apparatus and the resource requesting method embodiments provided by the above embodiments belong to the same concept, and the specific implementation process thereof is detailed in the method embodiments, which will not be repeated here.

In order to implement the method of the embodiment of the present application, the embodiment of the present application further provides a resource requesting apparatus, which is applied to the first server. As shown in FIG. 11 , the apparatus includes:

The first receiving unit 1101 is configured to receive a second request; the second request is used to request a second resource, and carries a second token and third information; the third information includes a description of the second resource information and a second time; the second time characterizes the time associated with the second request;

The second generating unit 1102 is configured to perform encryption processing on the third information based on a second key to generate a third token; the second key represents the session encryption between the second terminal and the first server key; the second terminal determines according to the Cookie in the second request;

The second sending unit 1103 is configured to send the second resource to the second terminal when the second token matches the third token.

Wherein, in one embodiment, the device further includes:

a fourth sending unit, configured to generate and deliver the second request to the second terminal when the second terminal successfully logs in to the first server before the first receiving unit 1101 receives the second request. second key.

In one embodiment, the fourth sending unit is used for:

In the case of receiving the setting identifier sent by the second terminal, the second key is generated and delivered to the second terminal.

In one embodiment, the second generating unit 1102 is configured to:

In the case that the second request satisfies the first set condition, generating a third token;

The first setting conditions include:

The cookie verification in the request is passed;

and / or,

The second time carried by the request is within the set time period.

In one embodiment, the apparatus further comprises:

A deletion unit, configured to delete the corresponding cookie stored by the first server according to the cookie in the second request when the second token does not match the third token.

In practical applications, the first receiving unit 1101 and the second sending unit 1103 can be implemented by a communication interface in the resource request-based device, and the second generation unit 1102 and the deletion unit can be implemented by a processor in the resource-based device. , the fourth sending unit may be implemented by a processor in the resource request-based device in combination with a communication interface.

It should be noted that: when the resource requesting device provided in the above embodiment performs resource request, only the division of the above program modules is used as an example for illustration. That is, the internal structure of the device is divided into different program modules to complete all or part of the processing described above. In addition, the resource requesting apparatus and the resource requesting method embodiments provided by the above embodiments belong to the same concept, and the specific implementation process thereof is detailed in the method embodiments, which will not be repeated here.

Based on the hardware implementation of the above program modules, and in order to implement the resource request method of the embodiment of the present application, the embodiment of the present application further provides an electronic device. FIG. 12 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application. As shown in FIG. 12 , the electronic device includes:

Communication interface 1, which can exchange information with other devices such as network devices;

The processor 2 is connected to the communication interface 1 to realize information interaction with other devices, and is used to execute the method provided by one or more of the above technical solutions when running the computer program. The computer program is instead stored on the memory 3 .

Of course, in practical application, various components in the electronic device are coupled together through the bus system 4 . It can be understood that the bus system 4 is used to realize the connection communication between these components. In addition to the data bus, the bus system 4 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the various buses are designated as bus system 4 in FIG. 12 .

The memory 3 in the embodiment of the present application is used to store various types of data to support the operation of the electronic device. Examples of such data include: any computer program used to operate on an electronic device.

It is understood that the memory 3 may be a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memory. Among them, the non-volatile memory may be a read-only memory (ROM, Read Only Memory), a programmable read-only memory (PROM, Programmable Read-Only Memory), an erasable programmable read-only memory (EPROM, Erasable Programmable Read-only memory) Only Memory), Electrically Erasable Programmable Read-Only Memory (EEPROM, Electrically Erasable Programmable Read-Only Memory), Magnetic Random Access Memory (FRAM, ferromagnetic random access memory), Flash Memory (Flash Memory), Magnetic Surface Memory , CD-ROM, or Compact Disc Read-Only Memory (CD-ROM, Compact Disc Read-Only Memory); the magnetic surface memory can be a magnetic disk memory or a tape memory. The volatile memory may be Random Access Memory (RAM), which is used as an external cache memory. By way of example and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory Memory (DRAM, Dynamic Random Access Memory), Synchronous Dynamic Random Access Memory (SDRAM, SynchronousDynamic Random Access Memory), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM, Double Data Rate Synchronous Dynamic Random Access Memory), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM, Enhanced Synchronous Dynamic Random Access Memory), Synchronous Link Dynamic Random Access Memory (SLDRAM, SyncLink Dynamic Random Access Memory), Direct Memory Bus Random Access Memory (DRRAM, Direct Rambus Random Access Memory) . The memory 2 described in the embodiments of the present application is intended to include but not limited to these and any other suitable types of memory.

The methods disclosed in the above embodiments of the present application may be applied to the processor 2 or implemented by the processor 2 . The processor 2 may be an integrated circuit chip with signal processing capability. In the implementation process, each step of the above-mentioned method can be completed by a hardware integrated logic circuit in the processor 2 or an instruction in the form of software. The above-mentioned processor 2 may be a general-purpose processor, a DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. The processor 2 may implement or execute the methods, steps, and logical block diagrams disclosed in the embodiments of this application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, the storage medium is located in the memory 3, and the processor 2 reads the program in the memory 3, and completes the steps of the foregoing method in combination with its hardware.

When the processor 2 executes the program, the corresponding process in each method of the embodiments of the present application is implemented, which is not repeated here for brevity.

In an exemplary embodiment, the embodiment of the present application further provides a storage medium, that is, a computer storage medium, specifically a computer-readable storage medium, for example, including a memory 3 storing a computer program, and the above-mentioned computer program can be executed by the processor 2, to complete the steps described in the preceding method. The computer-readable storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disk, or CD-ROM.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus, electronic device and method may be implemented in other manners. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined, or Can be integrated into another system, or some features can be ignored, or not implemented. In addition, the coupling, or direct coupling, or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical or other forms. of.

The unit described above as a separate component may or may not be physically separated, and the component displayed as a unit may or may not be a physical unit, that is, it may be located in one place or distributed to multiple network units; Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.

In addition, each functional unit in each embodiment of the present application may all be integrated into one processing unit, or each unit may be separately used as a unit, or two or more units may be integrated into one unit; the above integration The unit can be implemented either in the form of hardware or in the form of hardware plus software functional units.

Those of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiments can be completed by program instructions related to hardware, the aforementioned program can be stored in a computer-readable storage medium, and when the program is executed, execute It includes the steps of the above method embodiments; and the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic disk or an optical disk and other media that can store program codes.

Alternatively, if the above-mentioned integrated units of the present application are implemented in the form of software function modules and sold or used as independent products, they may also be stored in a computer-readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application can be embodied in the form of software products in essence or in the parts that make contributions to the prior art. The computer software products are stored in a storage medium and include several instructions for A computer device (which may be a personal computer, a server, or a network device, etc.) is caused to execute all or part of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic disk or an optical disk and other mediums that can store program codes.

It can be understood that, in the embodiments of this application, the data related to user information, when the embodiments of this application are applied to specific products or technologies, the user's permission or consent needs to be obtained, and the collection, use and processing of relevant data require Comply with relevant laws, regulations and standards of relevant countries and regions.

It should be noted that the technical solutions described in the embodiments of the present application may be combined arbitrarily unless there is a conflict. Unless otherwise stated and defined, the term "connection" should be understood in a broad sense, for example, it may be an electrical connection, or a communication between two elements, a direct connection, or an indirect connection through an intermediate medium. For those of ordinary skill, the specific meanings of the above terms can be understood according to specific situations.

In addition, in the examples of the present application, "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the "first\second\third" distinctions may be interchanged under appropriate circumstances so that the embodiments of the application described herein may be practiced in sequences other than those illustrated or described herein.

The term "and/or" in this article is only an association relationship to describe the associated objects, indicating that there can be three kinds of relationships, for example, A and/or B, it can mean that A exists alone, A and B exist at the same time, and A and B exist independently B these three cases. In addition, the term "at least one" herein refers to any combination of any one of a plurality or at least two of a plurality, for example, including at least one of A, B, and C, may mean including from A, B, and C Any one or more elements selected from the set.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited to this. should be covered within the scope of protection of this application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

The specific technical features in the various embodiments described in the detailed description can be combined in various ways if there is no contradiction. For example, different specific technical features can be combined to form different implementations. In order to avoid inconsistencies Necessary repetition, various possible combinations of various specific technical features in this application will not be described separately.

Claims (15)

1. A resource request method, applied to a first terminal, includes:

encrypting the first information based on the first key to generate a first token; the first key characterizes a session key between the first terminal and a first server;

sending a first request to the first server; the first request is used for requesting a first resource from the first server and carries the first token and the first information; wherein,

the first information comprises description information and a first time of the first resource; the first time characterizes a time associated with the first request; and the first resource is issued to the first terminal after the first server verifies the first token based on the first key and the first information.

2. The method of claim 1, wherein the encrypting the first information based on the first key to generate the first token comprises:

inputting the first information into a first component to obtain a first token output by the first component; wherein,

the first component is used for encrypting the input information according to the corresponding key to generate and output a token; and the codes corresponding to the first components are subjected to obfuscation processing.

3. The method of claim 2, wherein after inputting the first information into the first component, before obtaining the first token output by the first component, further comprising:

obtaining the first key based on a first operation on second information; wherein,

the second information represents information obtained after second operation is carried out on the first secret key; the second operation characterizes a segmented storage operation; the first operation characterizes a reverse operation of the second operation.

4. The method of claim 2, wherein the code corresponding to the first component is characterized as a code of a first programming language, and is obtained by converting a code of a second programming language after obfuscation processing.

5. The method of claim 1, wherein prior to said cryptographically processing the first information based on the first key to generate the first token, the method further comprises:

and receiving the first key issued by the first server under the condition that the first terminal successfully logs in the first server.

6. The method of claim 5, wherein before the receiving the first key sent by the first server, the method further comprises:

sending a setting identifier to the first server; wherein,

and the first server issues the first key to the first terminal under the condition of receiving the set identifier.

7. A resource request method applied to a first server, the method comprising:

receiving a second request; the second request is used for requesting a second resource and carries a second token and third information; the third information comprises description information of the second resource and a second time; the second time characterizes a time associated with the second request;

encrypting the third information based on a second key to generate a third token; the second key characterizes a session key between a second terminal and the first server; the second terminal determines according to the Cookie in the second request;

and sending the second resource to the second terminal under the condition that the second token is matched with the third token.

8. The method of claim 7, wherein prior to said receiving the second request, the method further comprises:

and under the condition that the second terminal successfully logs in the first server, generating and issuing the second key to the second terminal.

9. The method of claim 8, wherein the generating and issuing the second key to the second terminal comprises:

and generating and issuing the second key to the second terminal under the condition of receiving the setting identifier sent by the second terminal.

10. The method of claim 7, wherein generating the third token comprises:

generating a third token under the condition that the second request meets a first set condition;

the first setting condition includes:

the Cookie in the request passes the verification;

and/or the presence of a gas in the gas,

the second time carried by the request is within a set time period.

11. The method of claim 7, further comprising:

and under the condition that the second token is not matched with the third token, deleting the corresponding Cookie stored in the first server according to the Cookie in the second request.

12. A resource request device, applied to a first terminal, includes:

a first generation unit configured to perform encryption processing on first information based on a first key to generate a first token; the first key characterizes a session key between the first terminal and a first server;

a first sending unit, configured to send a first request to the first server; the first request is used for requesting a first resource from the first server and carries the first token and the first information; wherein,

the first information comprises description information and a first time of the first resource; the first time characterizes a time associated with the first request; and the first resource is issued to the first terminal after the first server verifies the first token based on the first key and the first information.

13. A resource request apparatus, applied to a first server, comprising:

a first receiving unit configured to receive a second request; the second request is used for requesting a second resource and carries a second token and third information; the third information comprises description information of the second resource and a second time; the second time characterizes a time associated with the second request;

a second generation unit configured to perform encryption processing on the third information based on a second key to generate a third token; the second key characterizes a session key between a second terminal and the first server; the second terminal determines according to the Cookie in the second request;

a second sending unit, configured to send the second resource to the second terminal when the second token matches the third token.

14. An electronic device, comprising: a processor and a memory for storing a computer program capable of running on the processor,

wherein the processor is adapted to perform the steps of the method of any one of claims 1 to 6, or to perform the steps of the method of any one of claims 7 to 11, when the computer program is run.

15. A storage medium having a computer program stored thereon, wherein the computer program when executed by a processor implements at least one of:

the steps of the method of any one of claims 1 to 6;

the process steps of any one of claims 7 to 11.

Images