CN114844644A

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

Info

Publication number: CN114844644A
Application number: CN202210259476.1A
Authority: CN
Inventors: 李想; 朱昌亮; 钟武杰
Original assignee: Sangfor Technologies Co Ltd
Current assignee: Sangfor Technologies Co Ltd
Priority date: 2022-03-16
Filing date: 2022-03-16
Publication date: 2022-08-02

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 equipment and storage medium

Technical Field

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

Background

A Cookie is data stored in a terminal device by an electronic device such as a server for Session tracking in order to identify a user identity. After the Cookie is leaked, an attacker can hijack the session by using the Cookie, and the security of the session is low.

Disclosure of Invention

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

The technical scheme of the embodiment of the application is realized as follows:

the embodiment of the application provides a resource request method, which is applied to a first terminal and comprises the following steps:

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.

In the foregoing scheme, the 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 to generate and output a token; and the codes corresponding to the first components are subjected to obfuscation processing.

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

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.

In the above scheme, 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.

In the foregoing solution, before the encrypting the first information based on the first key to generate the first token, the method further includes:

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

In the foregoing solution, before the receiving the first key sent by the first server, the method further includes:

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.

The embodiment of the application further provides a resource request method, which is applied to a first server, and the method comprises the following steps:

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.

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

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

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

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

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

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.

In the above scheme, the method further comprises:

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.

The embodiment of the present application further provides a resource request apparatus, applied to a first terminal, including:

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,

An embodiment of the present application further provides a resource request apparatus, applied to a first server, including:

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.

An embodiment of the present application further provides an electronic device, including: a processor and a memory for storing a computer program capable of running on the processor,

wherein the processor is configured to execute any of the steps of the resource request method when running the computer program.

The embodiment of the present application further provides a storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the steps of any of the above-mentioned resource request methods.

In the embodiment of the 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 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, including description information of the request resource and time related to the request, according to a session key of the determined terminal, generates a corresponding token, verifies the token carried by the request based on the generated token, and sends the corresponding resource to the determined terminal under the condition that the token carried by the request is matched with the generated token. In the scheme for issuing the resources based on the verification result of the token, the identity of the request terminal is verified through the token, and due to the fact that the token is related to the request, an attacker cannot request other resources except the resources corresponding to the token even if the attacker acquires the terminal Cookie and the token carried by the request, so that session hijacking caused by Cookie leakage can be avoided, and the security of the session between the server and the terminal equipment is improved.

Drawings

Fig. 1 is a schematic diagram of a terminal-side implementation flow of a resource request method according to an embodiment of the present application;

fig. 2 is a schematic flow chart illustrating an implementation of generating a first token in a resource request method according to another embodiment of the present application;

FIG. 3 is a schematic diagram illustrating programming language conversion in a resource request method according to another embodiment of the present application;

fig. 4 is a schematic grouping diagram in a resource request method according to another embodiment of the present application;

fig. 5 is a schematic flow chart illustrating an implementation of a resource requester according to another embodiment of the present application;

fig. 6 is a schematic server-side implementation flowchart of a resource request method according to another embodiment of the present application;

fig. 7 is a schematic flowchart illustrating an implementation of a resource request method according to another embodiment of the present application;

fig. 8 is a schematic flow chart illustrating an implementation of a resource request method according to another embodiment of the present application;

fig. 9 is an interaction diagram of a resource request method according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a resource request apparatus according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a resource request apparatus according to 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 Description

A Cookie is data stored in a terminal device by an electronic device such as a server for Session tracking in order to identify a user identity. In the process of one session, an attacker can use Cookie as a third party to participate, insert malicious data, request resources and monitor the session in a data packet, and even replace one party to take over the session, so that 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 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 token and the above 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, including description information of the request resource and time related to the request, according to a session key of the determined terminal, generates a corresponding token, verifies the token carried by the request based on the generated token, and sends the corresponding resource to the determined terminal under the condition that the token carried by the request is matched with the generated token. In the scheme for issuing the resources based on the verification result of the token, the identity of the request terminal is verified through the token, and due to the fact that the token is related to the request, an attacker cannot request other resources except the resources corresponding to the token even if the attacker acquires the terminal Cookie and the token carried by the request, so that session hijacking caused by Cookie leakage can be avoided, and the security of the session between the server and the terminal equipment is improved.

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

The following describes in detail the technical solutions of the present application and how the technical solutions of the present application solve the above technical problems by embodiments and with reference to the drawings. These several specific embodiments may be combined with each other below, and details of the same or similar concepts or processes may not be repeated in some embodiments.

Fig. 1 is a schematic view of an implementation flow of a resource request method provided in an embodiment of the present application, which is applied to a first terminal, where the first terminal includes but is not limited to an electronic device such as a mobile phone and a tablet. The first terminal can implement the resource request method by loading a browser and the like. The resource request method comprises the following steps:

step 101: and encrypting the first information based on the first key to generate a first token.

Wherein the first key characterizes a session key between the first terminal and a first server.

Step 102: 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.

In step 101, a session relationship is pre-established between a first terminal and a first server, and the first terminal possesses a session key (i.e. 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 first information (including description information and first time of a first resource) as input of calculation, and performs hash function calculation by using a first key to obtain a first token output by calculation. The calculation of the token may be performed by a Hash-based Message Authentication Code (HMAC), based on a Hash function and a session key.

The first information represents information corresponding to the current request, and comprises description information of the first time and 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, e.g., may be a time or period within the period of time the request is currently generated. Preferably, the first terminal determines the first time according to the execution time of the setting action that needs to be executed each time, including but not limited to: the time when the terminal receives an instruction for initiating a resource request; the time at which the terminal generated 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 of a document, an image, a sound, and the like. The description information of the first resource represents the description information of the corresponding resource position, and according to the difference of the request modes, the description information comprises: requesting web site and/or web form information. Because the first time corresponding to each request is different, and the first token corresponding to each request is different, the first token and the first request have a corresponding relation.

The first key is indicative of a session key for a session between the first terminal and the first server, and the session key may represent an identity of a terminal communicating with the server in the session, as determined by the terminal and the server through negotiation.

In step 102, the first terminal generates and sends a first request message to the first server based on at least the generated first token and the first information (i.e., information corresponding to the first token), so as to request the first server to issue the first resource. And under the condition that the first server verifies 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 a Cookie of the first terminal, the server determines the identity of the corresponding terminal according to the Cookie carried by the received request message, and determines a session key corresponding to the terminal identity from session keys stored in the server, so as to verify the first token according to the session key and the first information.

In the above scheme for issuing resources based on the token verification result, for each resource request, the first terminal needs to execute step 101 to generate a corresponding token, and carry the generated token when the request is sent in step 102, so as to obtain the resource issued by the server after the token carried by the request passes verification.

As another embodiment of the present application, as shown in fig. 2, the generating a first token by encrypting first information based on a first key includes:

step 1011: and inputting the first information into a first component to obtain a first token output by the first component.

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

The first terminal inputs first information into the first component, the first component encrypts the input first information according to a corresponding key (namely the first key) to generate a first token, and the first terminal obtains the first token output by the first component. The code corresponding to the first component is subjected to obfuscation processing, and the first component is equivalent to a black box, so that the code logic of the first component is protected, the difficulty of reverse analysis and cracking of an attacker is improved, namely, the obfuscation processing of the code corresponding to the first component can reduce the risk of reverse cracking.

The first terminal obtains the first token by calling the first component of the code subjected to the obfuscation processing to realize the encryption processing of the first information based on the first key. In the resource request process, the token is generated by using the obfuscated component, so that the code logic for generating the first token is invisible to the front end, the security of the front end operation is improved, the difficulty and the time cost of reverse engineering of an attacker are increased, and the security of a session is improved.

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

Firstly, generating codes of a second programming language corresponding to the first component, then carrying out code obfuscation processing on the codes of the second programming language, and converting the obfuscated codes of the second programming language into codes 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 codes of different programming languages are converted by means of the backend of the OLLVM, and the time cost and difficulty of reverse engineering are increased.

Therefore, difficulty and time cost of reverse engineering of an attacker are increased, and risk of reverse cracking is reduced, so that session safety is improved.

As an embodiment of the application, the description is made with reference to FIG. 3 showing a programming language conversion diagram, a C/C + + (second programming language) code corresponding to a first component is generated, the C/C + + code is converted into an LLVM IR code by a Clang front end, and the IR code generated by the front end is negatively optimized by a back end of an OLLVM, and the confusion policy used includes basic block partitioning, instruction inflation, dummy block filling and control flow flattening. The obfuscated IR code is converted to front-end js (first programming language) code using the LLVM webasm's back-end and the wasm-ld linker.

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

The first terminal obtains second information stored in the setting storage medium through a segment storage operation (second operation) on the first key. After the first information is input to the first component, the first component performs data reading and restoring processing (first operation) on the second information stored in the setting storage medium to obtain a first key. The segment storage operation comprises the steps of splitting the session key into a first set number of fields according to the graph 4, grouping the split fields, and storing each group of data segments in the storage medium. The setting component reads the data stored in different positions in a segmented manner, and then restores the data according to the reverse operation of fig. 4 to obtain the first secret key. In grouping, the split fields may be equally or unequally split into a second set number of groups.

Here, the second operation may be considered as an encoding operation, the first operation is a corresponding decoding operation, the first key is stored as a corresponding encoding result, and the first key is restored at the first component.

In practical application, the packet diagram shown in fig. 4 is taken as an example for explanation, the session key is split into 16 fields, and the split fields are arranged in the manner shown in the figure and are divided into 4 groups.

Therefore, the first secret key is hidden in the first component of the black box, the front end of the session secret key is not visible, the difficulty and the time cost of reverse engineering of an attacker are increased, and the security of the session is improved.

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

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

The first terminal sends the login information to the first server, and the first server carries out 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 the first server, the session relationship is successfully established between the first terminal and the first server, the first server generates a Cookie and a session key (that is, a first key) for the newly created session, and issues the Cookie and the first key to the first terminal. The login information is used for the server to authenticate the terminal, and includes but is not limited to: a user identification (uid) and/or a password (pwd).

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

and sending a setting identifier to the first server.

In the process of establishing a session relationship between a first terminal and a 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 a specific protocol version, wherein the specific session authentication mode and the specific protocol version correspond to the resource request method in the embodiment of the application and are different from a standard Cookies authentication mode. And the server determines that the first terminal supports a specific session authentication mode and a protocol version after receiving the set identifier, and issues the Cookie and the first key to the first terminal.

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

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

Fig. 6 is a schematic view of an implementation flow of a resource request method according to another embodiment of the present application. The resource request method comprises the following steps:

step 601: a second request is received.

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.

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

Wherein the second key characterizes a session key between a second terminal and the first server; and the second terminal determines according to the Cookie in the second request.

Step 603: and sending the second resource to the second terminal when the second token is matched with the third token.

The first server establishes session relations with some terminals in advance, and generates and issues corresponding session keys and Cookies. The first server may receive a request sent by a user through a terminal using an identity of the user, or may send the request through an identity of a user terminal impersonated by an attacker, and the first server may only determine a terminal identity corresponding to the request according to a Cookie carried by the request, and cannot distinguish whether a sender of the request is the identity of the Cookie, that is, 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, where the second request carries a second token, third information corresponding to the second token, and a Cookie. And the third information represents information corresponding to the current request, and comprises the second time and the description information of the second resource. A unique token can be generated based on the third information to identify the corresponding request. For a request sent by the user via the terminal, the second time can distinguish the current request from previous or subsequent requests, e.g. may be a time or a time period within the time period of the current generation of the request. Preferably, the second terminal determines the second time according to an execution time of the setting action that needs to be executed every request. In some embodiments, the second time may be in the form of a timestamp. The second token is obtained by the terminal through session key encryption processing on corresponding source data, and the source data of the second token may be third information or not, for example, for the purpose of attack, a third party (attacker) 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 in the second request, encrypts the third information by using the session key (i.e., the second key) with the second terminal to obtain a third token, and verifies the second token by using the third token, thereby implementing the identification of the sender. Here, the first server verifies the second token with the third token, which may be by comparing the third token with the second token, and determining that the second token matches the third token when the data of the third token is the same as the data of the second token. Here, the second terminal determined according to the Cookie may be an identity of the user terminal that sent the second request, or an identity spoofed by an attacker.

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

the first setting condition includes:

the Cookie in the request passes the verification;

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

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

The first server judges whether the received second request meets a first set condition or not, and generates a third token under the condition that the first set condition is met. The first setting condition may be that the Cookie in the request passes verification, the second time carried by the request is within a set time period, or the Cookie in the request passes verification and the second time carried by the request is within the set time period. It should be noted that the second request satisfies the first setting condition, which is a precondition for the first server to generate the third token.

In practical application, taking the first setting condition including that the Cookie verification in the request passes and the second time carried by the request is in the set time period as an example, the judgment condition before the third token is generated is described as follows: the first server verifies the Cookie, and if the Cookie is not verified, prompt information is returned; if the Cookie passes the verification, judging whether the second time is in a set time period; and if the second time is within the set time period, the first server generates a third token. And judging whether the second time is in the set time period or not on the premise of time alignment between the terminal and the server. The time period is a set time range, can be set according to the needs of each server, and if the security requirement is higher, the set time range should be smaller.

In step 603, in the case that the second token carried by 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 sent by the user terminal. At this time, the first server transmits 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: 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.

In the case that the second token carried by 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 by a third party (attacker). Because the third party has obtained the Cookie information of the corresponding user terminal and initiated the second request by using the Cookie information, the Cookie of the session with the second terminal is revealed, 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 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.

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

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

And 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 the first server, the session relationship is successfully established between the second terminal and the first server, the first server generates a Cookie and a session key (that is, a second key) for the newly created session, and issues the Cookie and the second key to the second terminal. The login information is used for the server to authenticate the terminal, and includes but is not limited to: a user identification (uid) and/or a password (pwd).

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

In 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 a specific protocol version, wherein the specific session authentication mode and the specific protocol version correspond to the resource request method in the embodiment of the application and are different from a standard Cookies authentication mode. And the first server determines that the second terminal supports a specific session authentication mode and a protocol version under the condition of receiving the set identifier sent by the second terminal, and generates and sends the Cookie and the second key to the second terminal. It should be noted that the receiving of the setting identifier sent by the second terminal by the first server is a precondition for the first server to generate and issue 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 sending the setting identifier to the first server together with the login information, or sending the setting identifier to the first server in addition, which is not limited herein. Preferably, the setting identifier is carried in the login information in a message header manner.

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

The present application will be described in further detail with reference to the following application examples.

After the Cookie is leaked, an attacker can repeatedly utilize the Cookie to initiate a session, and the security of the session is low. Meanwhile, it is difficult for the server to distinguish the request of the attacker from the request of the user, resulting in leakage of resource information.

Based on this, the application embodiment of the application provides a scheme for realizing OTC Cookie hijack prevention authentication reinforcement based on a black box. Fig. 9 shows an interaction diagram provided by an embodiment of the application, where a browser/client represents a terminal side and a server represents a service side (server side), and the whole process at least includes:

(1) initialization phase

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

1.1 Login operation

The browser sends the user identification (uid) and password (pwd) to the server, as well as a special HTTP header field, X-OTC (i.e. the set identification). The header field indicates that the browser supports OTC session authentication and OTC protocol version (v).

1.2 authenticating a user

After successful user authentication, the server checks if the X-OTC header field is present in the request.

If the header field exists, the server generates a Cookie and a session key (k) for the newly created session (cid) _s ). The session key represents the browser/client identity that is communicating with the server this time.

If the X-OTC header field does not exist in the browser request, switching to standard Cookies authentication is possible, and communication can also be stopped and the user is informed that OTC support is mandatory.

Subsequently, the server stores the user identification (uid), the session identification (cid) and the session key (k) _s )。

1.3 Return operation

The server generates Cookie and symmetric encrypted session key (k) _s ) Back to the browser/client.

1.4 hidden Key operations

In order to ensure the confidentiality of the browser/client storage, the browser/client sends the encrypted session key (k) to the front end through a setting component _s ) And carrying out segmented storage processing.

The encrypted session key is divided into a first set number of fields, the divided fields are grouped, and each group of data segments are stored in a storage medium. Describing the storage process with reference to fig. 4, the encrypted session key is split into 16 fields, and the split fields are grouped according to the method shown in fig. 4.

In order to ensure the security of the front-end operation, the JS code corresponding to the provisioning component is subjected to code obfuscation, where the provisioning component may perform the hidden key operation, the key fetching operation, and the partial request operation in the embodiment of the present application, and specifically, may perform the encoding and decoding processing of the session key and the token generation.

(2) Request phase

The request phase occurs when the browser/client operates the session key (k) in reverse upon each request initiated by the client via the terminal _s ) And generates a unique OTC token.

2.1 get Key operation

The setting component takes out the data stored in different positions in segments and restores the data according to the reverse operation of the figure 4 to obtain the encrypted session key (k) _s ) And finally, decrypting to obtain the session key.

2.2 request operation

For each request, the browser appends an OTC token (i.e., the first token) outside the Cookie field. The browser/client then sends the Cookie and OTC token (token generation time (t) and HMAC value) to the server.

Wherein the OTC token uses a hash-based message authentication code (HMAC (k) generated by the session key _s Url | t | data)). The HMAC calculation includes the web address (url) of the request, the token generation time (t), any web form information (data) also contained for the POST request, and the parameters of the GET request are contained in the web address. Therefore, for the token carried by each request, the corresponding generation time is different, and the token corresponds to a unique message identity authentication code, so that the uniqueness of the token is ensured. Even if the same resource (the requested web address and any web form information contained in the POST request) is requested, 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, the corresponding HMAC will change and fail to verify. Thus, an attacker cannot reuse the OTC token to illegally redirect the session.

(3) Verification phase

The authentication phase occurs after the request phase, and the server will authenticate the user's request. If the verification is successful, the data is returned, otherwise, the user is required to log in again.

3.1 verification operation

The server firstly verifies the information in the Cookie, and if the verification is unsuccessful, the server returns the information that the Cookie is invalid or the Cookie is wrong. Next, the server checks whether the token generation time (t) is within a set time period. The premise of this step is to align the time of the browser/client and the server, and determine whether the timestamp carried by the request is within the time period. The time period is a set time range, and can be set according to the needs of each server, and if the security requirement is higher, the set time range should be smaller. Subsequently, the server uses the session key k _s And the information in the request (url and data) calculates a new HMAC. The server then compares the newly computed HMAC with the HMAC contained in the token.

3.2 Return operation

And if the HMAC values are matched, the request passes the verification, 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 denied, returning that the check failed.

(4) Logout stage

4.1 logout operation

The session will continue until the session ticket expires or the user indicates logoff. Upon logoff, the browser/client sends a Cookie and a request with a corresponding OTC token to the server, the header field containing only HMAC (k) with value zero (0) _s 0), the HMAC instructs the browser to delete the credentials for this domain (browser-enforced policy).

4.2 logging off authentication operations

The browser/server side deletes the credentials for this domain based on the HMAC. At the same time, an attacker is prevented from spoofing the server response to arbitrarily delete or modify the OTC credentials.

4.3 Log off successfully

The logoff is successful, and the session is completed.

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

first, code of C/C + + for implementing the OTC algorithm is generated.

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

Thirdly, the IR code generated by the front-end is negatively optimized by the back-end of OLLVM, using obfuscation strategies like basic block partitioning, instruction dilation, dummy block filling and control flow flattening.

Fourth, the obfuscated IR code is converted to front-end js code using the LLVM webasm's back-end and the wasm-ld linker.

In the scheme provided by the application embodiment, the hash-based message authentication code is generated for each request packet (including the timestamp and the description information of the request resource) through the session key bound with the session of the user (terminal), integrity check is performed, and the Cookie is prevented from being hijacked and reused. Meanwhile, 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 scheme provided by the application embodiment has at least one of the following effects:

(1) cookie can not be reused after being leaked, so that attackers can be prevented from acquiring more system information;

(2) the confused codes are black boxes, and the logic of the source codes is difficult to analyze reversely, so that the risk of reverse cracking is reduced;

(3) system resources (execution performance) consumed to run the setup component implementing the code obfuscation are reduced.

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

OTC (One-Time Cookie): the disposable Cookie is a client anti-hijack scheme for preventing the Cookie from being repeatedly utilized after being leaked. The Cookie is data stored on the user terminal, and when the browser requests the web site again, the browser submits the requested web site to the server together with the Cookie. The server checks the Cookie to identify the user state.

OLLVM: an open source obfuscation scheme based on the LLVM compiler greatly increases the time cost and difficulty of reverse engineering. The main obfuscation strategies are basic block partitioning, instruction inflation, dummy block filling, and control flow flattening.

Clang: the front-end compiler based on the LLVM back-end fully supports the C + +11 standard and is almost fully compatible with the GNU C language specification. And the compiling process is mainly responsible for lexical analysis, syntactic analysis, semantic analysis and intermediate code (IR) generation.

LLVM-webAsm one of the LLVM backend can convert the intermediate code into JS code. The compiler backend is responsible for optimizing the intermediate code (IR code) generated by the front-end and generating the corresponding terminal code according to the target platform specified at compile time. Here the webAsm can be seen as a platform just like x86, x86_64, aarch 64.

HMAC (Hash-based Message Authentication Code): is a mechanism for message authentication using a hash function in cryptography, which can provide message authentication including message integrity verification and source identity authentication. The HMAC algorithm is more like an encryption algorithm, and since the HMAC algorithm introduces a key, security is not completely dependent on the Hash algorithm used.

In order to implement the method of the embodiment of the present application, an embodiment of the present application further provides a resource request device, which is applied to a first terminal, and as shown in fig. 10, the device includes:

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

a first sending unit 1002, 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,

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

In one embodiment, the apparatus further comprises:

the operation unit is used for obtaining the first key based on a first operation on second information before obtaining a first token output by the first component after the first information is input into the first component; 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.

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

In one embodiment, the apparatus further comprises:

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

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; and the first server issues the first key to the first terminal under the condition of receiving the set identifier.

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

It should be noted that: in the resource request device provided in the above embodiment, only the division of the program modules is exemplified when the resource request device performs the resource request, and in practical applications, the processing allocation may be completed by different program modules according to needs, 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 request apparatus and the resource request method provided in the foregoing embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments and are not described herein again.

To implement the method of the embodiment of the present application, an embodiment of the present application further provides a resource request device, which is applied to a first server, and as shown in fig. 11, the device includes:

a first receiving unit 1101 for 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;

a second generating unit 1102 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 1103, configured to send the second resource to the second terminal when the second token matches the third token.

Wherein, in one embodiment, the apparatus further comprises:

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

In one embodiment, the fourth sending unit is configured to:

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

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.

In one embodiment, the apparatus further comprises:

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

In actual application, the first receiving unit 1101 and the second sending unit 1103 may be implemented by a communication interface in a resource request device, the second generating unit 1102 and the deleting unit may be implemented by a processor in the resource request device, and the fourth sending unit may be implemented by a processor in the resource request device in combination with the communication interface.

Based on the hardware implementation of the program module, and in order to implement the resource request method in the embodiment of the present application, an 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, and as shown in fig. 12, the electronic device includes:

a communication interface 1 capable of information interaction with other devices such as network devices and the like;

and the processor 2 is connected with the communication interface 1 to realize information interaction with other equipment, and is used for executing the method provided by one or more technical schemes when running a computer program. And the computer program is stored on the memory 3.

In practice, of course, the various components in the electronic device are coupled together by the bus system 4. It will be appreciated that the bus system 4 is used to enable connection communication between these components. The bus system 4 comprises, in addition to a data bus, a power bus, a control bus and a status signal bus. For clarity of illustration, however, the various buses are labeled 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 for operating on an electronic device.

It will be appreciated that the memory 3 may be either volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. Among them, the nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a magnetic random access Memory (FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical disk, or a Compact Disc Read-Only Memory (CD-ROM); the magnetic surface storage may be disk storage or tape storage. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of illustration 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 (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Enhanced Synchronous Dynamic Random Access Memory (Enhanced DRAM), Synchronous Dynamic Random Access Memory (SLDRAM), Direct Memory (DRmb Access), and Random Access Memory (DRAM). The memory 2 described in the embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

The method disclosed in the above embodiment 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 having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 2. The processor 2 described above may be a general purpose processor, a DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor 2 may implement or perform the methods, steps and logic blocks disclosed in the embodiments of the present 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 may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium located in the memory 3, and the processor 2 reads the program in the memory 3 and in combination with its hardware performs the steps of the aforementioned method.

When the processor 2 executes the program, the corresponding processes in the methods according to the embodiments of the present application are realized, and for brevity, are not described herein again.

In an exemplary embodiment, the present application further provides a storage medium, i.e. a computer storage medium, specifically a computer readable storage medium, for example, including a memory 3 storing a computer program, which can be executed by a processor 2 to implement the steps of the foregoing 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 the present application, it should be understood that the disclosed apparatus, electronic device and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media that can store program code.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or portions thereof contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media that can store program code.

It is understood that in the embodiments of the present application, data related to user information needs to obtain user permission or consent when the embodiments of the present application are applied to specific products or technologies, and collection, use and processing of related data need to comply with relevant laws and regulations and standards of relevant countries and regions.

The technical means described in the embodiments of the present application may be arbitrarily combined without conflict. Unless otherwise specified and limited, the term "coupled" is to be construed broadly, e.g., as meaning electrical connections, or as meaning communications between two elements, either directly or indirectly through intervening media, as well as the specific meanings of such terms as understood by those skilled in the art.

In addition, in the examples of the present application, "first", "second", and the like are used for distinguishing similar objects, and are not necessarily used for describing a specific order or a sequential order. It should be understood that "first \ second \ third" distinct objects may be interchanged under appropriate circumstances such that the embodiments of the application described herein may be implemented in an order other than those illustrated or described herein.

The term "and/or" herein is merely an association describing an associated object, meaning that three relationships may exist, e.g., a and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the term "at least one" herein means any combination of at least two of any one or more of a plurality, for example, including at least one of A, B, C, and may mean including any one or more elements selected from the group consisting of A, B and C.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Various combinations of the specific features in the embodiments described in the detailed description may be made without contradiction, for example, different embodiments may be formed by different combinations of the specific features, and in order to avoid unnecessary repetition, various possible combinations of the specific features in the present application will not be described separately.

Claims

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

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

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:

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:

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,

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

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

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

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

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:

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

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

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.