Firewall-based secure communication method, apparatus, device, medium and product

Abstract

The present disclosure provides a firewall-based secure communication method, which can be applied to the technical field of information security. The firewall-based secure communication method comprises: preliminarily identifying a received access request to obtain an identification result, wherein the access request comprises a target route; for the access request with the identification result being non-script, verifying whether a front-end function is normal in the case of being redirected to a special route of WAF; in the case that the front-end function is normal, obtaining a fingerprint information plaintext of a device; in the case that the fingerprint information plaintext of the device is successfully obtained, querying a first data table based on the fingerprint information plaintext; in the case that the fingerprint information plaintext is successfully queried, obtaining a first risk value; and in the case that the first risk value is less than or equal to a preset threshold, redirecting to the target route to release the access. The present disclosure also provides a firewall-based secure communication device, equipment, medium and product.

Description

Technical Field

[0001] This disclosure relates to the field of information security technology, and specifically to a firewall-based secure communication method, apparatus, device, medium, and product. Background Technology

[0002] A Web Application Firewall (WAF) is a security solution used to protect web applications from cyberattacks. It can help enterprises improve the security of web applications and reduce the risk of cyberattacks and data breaches.

[0003] In addition to identifying malicious traffic and blocking cyberattacks based on rules, Web Application Firewalls (WAFs) can help detect and block access from blacklisted IP addresses. These blacklists typically contain IP addresses considered insecure, such as those from well-known hacking groups, as well as IP addresses deemed untrusted. Through IP-based blacklists or access control policies, WAFs can mitigate the threat of cyberattacks to businesses and organizations, thereby improving their network security.

[0004] However, attackers can attempt to use proxy servers, anonymous networks, or other techniques to hide their real IP addresses, thereby bypassing IP-based blacklists or access control policies. This poses a significant challenge for enterprise web application firewalls in detecting and blocking attacks. Summary of the Invention

[0005] In view of the above problems, this disclosure provides firewall-based secure communication methods, apparatus, devices, media and products that improve communication security and efficiency and reduce the frequency of firewall use.

[0006] According to a first aspect of this disclosure, a firewall-based secure communication method is provided, comprising: initially identifying a received access request and obtaining an identification result, the access request including a target route; for access requests whose identification result is non-script, verifying whether the front-end function is normal when redirected to a dedicated route of the WAF; if the front-end function is normal, acquiring plaintext fingerprint information of the device; if the acquisition of the plaintext fingerprint information of the device is successful, querying a first data table based on the plaintext fingerprint information, the first data table including N one-to-one corresponding fingerprint information and a danger value, where N is a positive integer; if the query of the first data table based on the plaintext fingerprint information is successful, obtaining a first danger value; and if the first danger value is less than or equal to a preset threshold, redirecting to the target route to allow access.

[0007] According to an embodiment of this disclosure, after the initial identification of the received access request and obtaining the identification result, the method further includes: for access requests whose identification result is a script, executing a comprehensive danger value calculation rule based on the target route to obtain a third danger value; and if the third danger value is less than or equal to a preset threshold, invoking WAF verification logic to redirect to the target route and allow access if the WAF verification logic passes; wherein, the comprehensive danger value calculation rule includes: querying a second data table based on the target route, or querying both the second and third data tables based on the target route to obtain a danger weight, wherein the second data table includes K routing information, and the third data table includes L one-to-one routing information and access counts, where K and L are positive integers; invoking WAF to calculate the danger value of the access prevention request to obtain a second danger value; and calculating a third danger value based on the danger weight and the second danger value.

[0008] According to an embodiment of this disclosure, after obtaining the plaintext fingerprint information of the device, the method further includes: if obtaining the plaintext fingerprint information of the device fails, for access requests whose identification result is non-script, executing a comprehensive risk value calculation rule to obtain a third risk value; and if the third risk value is less than or equal to a preset threshold, invoking WAF verification logic so that if the WAF verification logic passes, the user is redirected to the target route to allow access.

[0009] According to an embodiment of this disclosure, after querying the first data table in plaintext based on the fingerprint information, the method further includes: if the query to the first data table in plaintext based on the fingerprint information fails, invoking WAF verification logic so that if the WAF verification logic passes, the user is redirected to the target route to allow access.

[0010] According to embodiments of this disclosure, for access requests whose identification result is non-script, verifying whether the front-end function is normal when redirected to a dedicated route of the WAF includes: redirecting to a dedicated route of the WAF; verifying whether a refresh token is generated normally; generating a key pair when a refresh token is generated normally; writing the public key in the key pair into a preset first front-end execution logic to obtain a second front-end execution logic, wherein the first front-end execution logic includes logic for collecting device fingerprint information; transmitting the second front-end execution logic to the front-end execution; and receiving encrypted device fingerprint information when the second front-end execution logic is successfully executed, and determining that the front-end function is normal.

[0011] According to an embodiment of this disclosure, obtaining the plaintext fingerprint information of the device includes: decrypting the ciphertext fingerprint information based on the key pair to obtain the plaintext fingerprint information of the device.

[0012] According to embodiments of this disclosure, after verifying whether a refresh token is generated normally, the method further includes: intercepting the access request if a refresh token is not generated normally; after transmitting the second front-end execution logic to the front-end for execution, the method further includes: intercepting the access request if an abnormal jump event is detected; after querying the first data table based on the fingerprint information in plaintext to obtain a first danger value, the method further includes: intercepting the access request if the first danger value is greater than a preset threshold; and after executing the danger value comprehensive calculation rule based on the target route to obtain a third danger value, the method further includes: intercepting the access request if the third danger value is greater than a preset threshold.

[0013] According to embodiments of this disclosure, obtaining a danger weight based on querying the second data table based on the target route, or querying both the second and third data tables based on the target route, includes: querying the second data table based on the target route; if the query on the second data table is successful, determining the danger weight as a first danger weight; if the query on the second data table is unsuccessful, querying the third data table based on the target route; if the number of visits by the target route in the third data table is within a preset number of visits range, determining the danger weight as a second danger weight; and if the number of visits by the target route in the third data table is not within the preset number of visits range, or if the query on the third data table fails, determining the danger weight as a third danger weight.

[0014] A second aspect of this disclosure provides a firewall-based secure communication device, comprising: a preliminary identification module for preliminary identification of received access requests and obtaining identification results, wherein the access request includes a target route; a non-script access front-end verification module for verifying whether the front-end function is normal when the access request identified as non-script is redirected to a dedicated route of the WAF; a fingerprint information plaintext acquisition module for acquiring the device's fingerprint information plaintext when the front-end function is normal; a first data table query module for querying a first data table based on the fingerprint information plaintext when the acquisition of the device's fingerprint information plaintext is successful, wherein the first data table includes N one-to-one corresponding fingerprint information and a danger value; a first danger value determination module for obtaining a first danger value when the fingerprint information plaintext query of the first data table is successful; and a WAF verification logic call module for redirecting to the target route and allowing access when the first danger value is less than or equal to a preset threshold.

[0015] According to an embodiment of this disclosure, the apparatus further includes: a hazard value comprehensive calculation module, configured to, for an access request whose identification result is a script, execute a hazard value comprehensive calculation rule based on the target route to obtain a third hazard value; and a WAF verification logic invocation module, further configured to, if the third hazard value is less than or equal to a preset threshold, invoke WAF verification logic to redirect to the target route and allow access if the WAF verification logic passes; wherein, the hazard value comprehensive calculation rule includes: querying a second data table based on the target route, or querying both the second and third data tables based on the target route to obtain a hazard weight, wherein the second data table includes K routing information entries, and the third data table includes L one-to-one corresponding routing information entries and access counts, where K and L are positive integers; invoking WAF to calculate the hazard value of the access request to obtain a second hazard value; and calculating a third hazard value based on the hazard weight and the second hazard value.

[0016] According to embodiments of this disclosure, the danger value comprehensive calculation module is further configured to, in the event of failure to obtain plaintext fingerprint information of the device, execute the danger value comprehensive calculation rule for access requests whose identification result is non-script, and obtain a third danger value; and the WAF verification logic calling module is further configured to, in the event that the third danger value is less than or equal to a preset threshold, call the WAF verification logic, so that if the WAF verification logic passes, the access is redirected to the target route.

[0017] According to an embodiment of this disclosure, the WAF verification logic calling module is further configured to call the WAF verification logic when the fingerprint information fails to query the first data table in plaintext, so that if the WAF verification logic passes, the user is redirected to the target route to allow access.

[0018] According to embodiments of this disclosure, the non-script access front-end verification module includes: a WAF dedicated route redirection unit, a refresh token verification unit, a key pair generation unit, a key pair writing unit, a code transmission unit, and a fingerprint information encrypted receiving unit. The WAF dedicated route redirection unit is used to redirect to a dedicated WAF route; the refresh token verification unit is used to verify whether a refresh token is generated normally; the key pair generation unit is used to generate a key pair when a refresh token is generated normally; the key pair writing unit is used to write the public key from the key pair into a preset first front-end execution logic to obtain a second front-end execution logic, the first front-end execution logic including logic for collecting device fingerprint information; the code transmission unit is used to transmit the second front-end execution logic to the front-end execution unit; and the fingerprint information encrypted receiving unit is used to receive the device fingerprint information encrypted text when the second front-end execution logic is successfully executed, and to determine that the front-end function is normal.

[0019] According to an embodiment of this disclosure, obtaining the plaintext fingerprint information of the device includes: decrypting the ciphertext fingerprint information based on the key pair to obtain the plaintext fingerprint information of the device.

[0020] According to embodiments of this disclosure, the apparatus further includes an interception module, which is configured to intercept the access request if a refresh token is not generated normally; the interception module is also configured to intercept the access request if an abnormal jump event is detected; the interception module is also configured to intercept the access request if a first danger value is greater than a preset threshold; and the interception module is also configured to intercept the access request if a third danger value is greater than a preset threshold.

[0021] According to embodiments of this disclosure, the hazard value comprehensive calculation module includes: a second data table query unit, a first hazard weight determination unit, a third data table query unit, and a third hazard weight determination unit. The second data table query unit is used to query the second data table based on the target route. If the first hazard weight determination unit successfully queries the second data table using the target route, it determines the hazard weight as a first hazard weight. The third data table query unit is used to query the third data table based on the target route if the query fails. The second hazard weight determination unit is used to determine the hazard weight as a second hazard weight if the number of visits by the target route to the third data table is within a preset number of visits. The third hazard weight determination unit is used to determine the hazard weight as a third hazard weight if the number of visits by the target route to the third data table is not within the preset number of visits, or if the query fails.

[0022] A third aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the aforementioned firewall-based secure communication method.

[0023] A fourth aspect of this disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the aforementioned firewall-based secure communication method.

[0024] The fifth aspect of this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned firewall-based secure communication method.

[0025] In the embodiments of this disclosure, to address the technical problems of insufficient accuracy and coverage in the identification and interception of web attacks in the prior art, the embodiments of this disclosure design an auxiliary firewall interception scheme. After preliminary identification, verification of front-end functions, and judgment of danger values, the original WAF verification logic is called according to the specific situation. This process can filter out most access requests with high-risk behaviors, improve coverage, reduce the frequency of WAF verification logic calls, and efficiently intercept most access attacks. Furthermore, access is redirected to a dedicated route, which enables interaction with the front-end and completes the front-end (client or browser) verification. This avoids abnormal events (front-end functions not working, forged data packets, etc.) during the interaction between the front-end and the server. At the same time, the dedicated route is independent of access to the existing network, preventing the verification process from affecting normal access operations. Attached Figure Description

[0026] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0027] Figure 1 This diagram illustrates an application scenario of a firewall-based secure communication method according to an embodiment of the present disclosure.

[0028] Figure 2 A flowchart illustrating a firewall-based secure communication method according to an embodiment of the present disclosure is shown schematically.

[0029] Figure 3 A flowchart illustrating another firewall-based secure communication method according to an embodiment of the present disclosure is shown schematically.

[0030] Figure 4 A flowchart illustrating a front-end function verification method according to an embodiment of the present disclosure is shown schematically.

[0031] Figure 5 A flowchart illustrating a method for determining a danger weight according to an embodiment of the present disclosure is shown schematically.

[0032] Figure 6 A schematic diagram illustrating the full flow of a firewall-based secure communication method according to an embodiment of the present disclosure is provided.

[0033] Figure 7 A schematic diagram illustrating a firewall-based secure communication device according to embodiments of the present disclosure is shown; and

[0034] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a firewall-based secure communication method according to an embodiment of the present disclosure. Detailed Implementation

[0035] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0036] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0037] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0038] When using expressions such as "at least one of A, B, and C", they should generally be interpreted in accordance with the meaning that is commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc.).

[0039] In existing technologies, to ensure secure access to application servers, access requests are typically detected and blocked using the built-in verification logic of a Web Application Firewall (WAF) to protect the security of the web application. The blocking logic of a WAF varies depending on the vendor and configuration. Generally speaking, its main function is to prevent malicious traffic attacks. Besides IP addresses, blocking mechanisms can also include request characteristics and rule bases. By identifying and analyzing characteristics in HTTP requests, it can determine whether an attack is malicious and take appropriate blocking measures.

[0040] However, WAF verification logic itself has certain limitations, such as detection accuracy and processing cost. Regarding detection accuracy: when attackers use proxy servers, anonymous networks, or other technologies to hide their real IP addresses, accurate detection becomes a complex matter. The lack of some key information can lead to errors in the detection results, potentially resulting in false detections. Regarding processing cost: when there is a large number of anti-cheating requests to be identified, if the complex mechanisms of WAF verification logic are called for each anti-cheating request (for example, some verification mechanisms involve machine learning identification schemes, which are expensive), there will be a huge and unnecessary resource overhead, significantly reducing detection efficiency.

[0041] In order to solve the technical problems existing in the prior art, the inventors aim to improve the correctness and coverage of interception by providing an auxiliary interception scheme that pre-validates access requests before executing WAF verification logic.

[0042] This disclosure provides a firewall-based secure communication method. The method initially identifies received access requests and obtains an identification result, where the access request includes a target route. For access requests whose identification result is non-scripted, if redirected to a dedicated route in the WAF, the method verifies whether the front-end function is normal. If the front-end function is normal, the method obtains the device's fingerprint information in plaintext. If the device's fingerprint information in plaintext is successfully obtained, the method queries a first data table based on the fingerprint information in plaintext. The first data table includes N one-to-one corresponding fingerprint information and a danger value, where N is a positive integer. If the fingerprint information in plaintext query to the first data table is successful, a first danger value is obtained. Finally, if the first danger value is less than or equal to a preset threshold, the method redirects to the target route to allow access.

[0043] In the embodiments of this disclosure, to address the technical problems of insufficient accuracy and coverage in the identification and interception of web attacks in the prior art, the embodiments of this disclosure design an auxiliary firewall interception scheme. After preliminary identification, verification of front-end functions, and judgment of danger values, the original WAF verification logic is called according to the specific situation. This process can filter out most access requests with high-risk behaviors, improve coverage, reduce the frequency of WAF verification logic calls, and efficiently intercept most access attacks. Furthermore, access is redirected to a dedicated route. During this process, interaction with the front-end can be achieved, thereby completing the front-end (client or browser) verification. This avoids abnormal events (front-end functions not working, forged data packets, etc.) during the interaction between the front-end and the server. At the same time, the dedicated route is independent of access to the existing network, preventing the verification process from affecting normal access operations.

[0044] Figure 1 The diagram illustrates an application scenario of a firewall-based secure communication method according to an embodiment of the present disclosure.

[0045] like Figure 1 As shown, application scenario 100 according to this embodiment may include terminal devices 101, 102, and 103, network 104, and server 105. Network 104 is used as a medium to provide a communication link between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0046] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0047] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0048] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using terminal devices 101, 102, and 103 (for example only). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0049] It should be noted that the firewall-based secure communication method provided in this disclosure embodiment can generally be executed by server 105. Correspondingly, the firewall-based secure communication device provided in this disclosure embodiment can generally be located in server 105. The firewall-based secure communication method provided in this disclosure embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105. Correspondingly, the firewall-based secure communication device provided in this disclosure embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105.

[0050] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0051] The following will be based on Figure 1 The described scene, through Figures 2-6 The firewall-based secure communication method of the disclosed embodiments is described in detail.

[0052] Figure 2 A flowchart illustrating a firewall-based secure communication method according to an embodiment of the present disclosure is shown schematically.

[0053] like Figure 2 As shown, the firewall-based secure communication method of this embodiment includes operations S210 to S260, and the firewall-based secure communication method can be executed by server 105.

[0054] In operation S210, the received access request is initially identified, and the identification result is obtained. The access request includes the target route.

[0055] The initial step is to identify whether the received access request originates from a front-end (such as a browser or client) or a script (such as a web crawler). For example, by checking if the User-Agent is valid, it can be determined whether the access request is coming from a browser.

[0056] In operation S220, for access requests whose identification result is non-script, the front-end function is verified to be normal when redirected to a dedicated route of the WAF.

[0057] Specifically, the route for redirecting the access request is redirected to a dedicated route in the WAF, initiating subsequent verification operations. Once the access request is identified as a legitimate request, it is then redirected back to the original target route. This avoids impacting the live network during the verification process. It should be noted that if the current access request is not a script-based request, a more thorough check is required to avoid mistakenly blocking legitimate access requests.

[0058] Among them, the WAF's dedicated routing is used to defend against malicious intrusions and attacks, solve data leakage and compliance and privacy protection issues, thereby ensuring data security and application availability. The WAF's dedicated routing can be a proprietary device or a general device configured with corresponding logic.

[0059] Verifying the front-end functionality involves checking whether the front-end can execute certain representative functions correctly during the front-end-back-end interaction. The following primarily verifies whether the front-end cookies are valid and whether the front-end page executes JavaScript code correctly, as detailed below:

[0060] Figure 4 A flowchart illustrating a front-end function verification method according to an embodiment of the present disclosure is shown.

[0061] like Figure 4 As shown, another front-end function verification method in this embodiment includes operations S410 to S460, which are performed after the above-mentioned operation S220.

[0062] In operation S410, redirect to a dedicated route to the WAF.

[0063] In the S420 operation, verify whether the refresh token is generated correctly.

[0064] Specifically, a refresh token is issued by setting a Set-Cookie in the redirect response packet.

[0065] In operation S430, a key pair is generated when a refresh token is generated normally.

[0066] When a refresh token is generated normally, an asymmetric key pair, namely a public key and a private key, is generated. This public key and private key can be stored in the session for subsequent encryption and decryption when transmitting device fingerprints.

[0067] It should be noted that, in order to ensure the security of the fingerprint information transmitted subsequently, dynamic key pairs are generated in real time instead of static keys. Furthermore, considering the usability of generating dynamic key pairs (for example, if the key generation logic is executed after operation S410, but the verification fails after operation S420, the generated key pair becomes meaningless, drastically increasing the computational overhead), the key pair generation logic is placed after the refresh token verification is successful, which can reduce the calling frequency of the key generation logic.

[0068] According to an embodiment of this disclosure, after verifying whether a refresh token is generated normally, the method further includes: if a refresh token is not generated normally, intercepting the access request.

[0069] If a refresh token is not generated correctly, it is considered that there is an anomaly in the front-end function, suspected of being high-risk access, and the request is blocked. During the operation, the backend sets a custom "state" bit in the session. If the refresh token is successfully generated, the "state" bit is 0. If the "state" bit is not found to be 0, it indicates that the refresh token was not generated correctly.

[0070] It should be noted that in the embodiments disclosed herein, the intercepted access request will not access the target route, but the intercepted access request can be recorded or its abnormal behavior can be analyzed to improve the auxiliary interception scheme.

[0071] In operation S440, the public key in the key pair is written into a preset first front-end execution logic to obtain a second front-end execution logic. The first front-end execution logic includes logic for collecting device fingerprint information.

[0072] The first front-end execution logic is written in JavaScript and includes logic for automatically collecting device fingerprint information from the front end. Based on this, the key pair generated above is written into the first front-end execution logic to achieve a further defined second front-end execution logic: that is, after the device fingerprint information is collected, it is encrypted using a public key to realize the conversion of fingerprint information from plaintext to ciphertext.

[0073] It is understandable that verifying whether the front-end successfully executes JavaScript does not require specific logic; execution is sufficient. In the embodiments disclosed herein, the code logic in the JavaScript is limited to the logic of obtaining device fingerprint information. This not only verifies the functionality of code execution but also allows the collected device fingerprint information to be used for subsequent verification, achieving multiple benefits. Encrypted propagation effectively prevents data tampering.

[0074] The device's fingerprint information includes: operating system version, browser version, screen dimensions, time zone, language preference, list of plugins, number of CPU cores, and supported JavaScript features (such as WebSocket). This information is concatenated and combined to calculate a hash value, which serves as the device's fingerprint.

[0075] In operation S450, the second front-end execution logic is transferred to the front-end execution.

[0076] Specifically, HTML and JavaScript code are sent to the front end so that the front end can execute the JavaScript code.

[0077] According to an embodiment of this disclosure, after the second front-end execution logic is transmitted to the front-end for execution, the method further includes: intercepting the access request if an abnormal jump event is detected.

[0078] If an abnormal jumping event is detected, it is determined that there is an anomaly in the front-end function, which is suspected to be a high-risk access, and the access is blocked.

[0079] The "abnormal jump event" refers to the following: During the operation, the backend sets a custom "state" bit in the session. If fingerprint information is successfully collected, the "state" bit is set to 1. Specifically, the interception here is to ensure that the current session has reached the fingerprint extraction step (state = 1), and that the data packet is sent directly without skipping the previous steps of verifying cookie availability and generating key pairs. If state is not 1, it may be a packet sent by a script or other tool specifically targeting this step, and it can be directly intercepted. It's understandable that, considering that the JavaScript used for fingerprint extraction can indeed execute abnormally in some demanding browser environments, the interception doesn't directly address cases where frontend logic fails to execute; instead, it targets behaviors with obvious subjective forgery characteristics in such abnormal jump events.

[0080] In operation S460, if the second front-end execution logic is successfully executed, the encrypted device fingerprint information is received, and the front-end function is determined to be normal.

[0081] Specifically, when the front-end successfully executes the JavaScript of the second front-end execution logic, it will return the encrypted fingerprint information ciphertext, and at the same time determine that the front-end function is normal and no abnormality has occurred.

[0082] In operation S230, if the front-end function is normal, the plaintext fingerprint information of the device is acquired.

[0083] According to an embodiment of this disclosure, obtaining the plaintext fingerprint information of the device includes: decrypting the ciphertext fingerprint information based on the key pair to obtain the plaintext fingerprint information of the device.

[0084] Specifically, if the front-end function is normal, it only returns encrypted fingerprint information. The process of converting the encrypted fingerprint information to plaintext fingerprint information requires decryption using a pre-stored key pair, which can result in either successful decryption or decryption failure.

[0085] In operation S240, if the fingerprint information plaintext of the device is successfully acquired, the first data table is queried based on the fingerprint information plaintext. The first data table includes N one-to-one corresponding fingerprint information and danger values, where N is a positive integer.

[0086] If decryption is successful, the fingerprint information is used to query the first data table that has been maintained in advance. The first data table stores multiple "fingerprint information - danger value" information, and then the fingerprint information obtained this time is used to look up the table.

[0087] The first data table maintains historical data. The fingerprint information and corresponding risk values ​​in the first data table are stored and maintained based on past secure communication processes. This means that if the device fingerprint corresponding to the access request has been accessed before, the "fingerprint information - risk value" information will be stored in the first data table; if the device fingerprint corresponding to the access request has not been accessed before, the "fingerprint information - risk value" information will not be stored in the first data table. Therefore, when querying the first data table, two results will occur: successful query and failed query.

[0088] According to an embodiment of this disclosure, after obtaining the plaintext fingerprint information of the device, the method further includes: if obtaining the plaintext fingerprint information of the device fails, for access requests whose identification result is non-script, executing a comprehensive risk value calculation rule to obtain a third risk value; and if the third risk value is less than or equal to a preset threshold, invoking WAF verification logic so that if the WAF verification logic passes, the user is redirected to the target route to allow access.

[0089] In cases where decryption fails, it suggests potential data tampering, but the interaction with the front-end appears normal. To address this, a real-time risk value calculation scheme (instead of the aforementioned pre-storage) is introduced. The detailed rules for this risk value calculation will be revealed later.

[0090] In operation S250, if the fingerprint information is successfully queried in plaintext from the first data table, a first danger value is obtained.

[0091] If the query to the first data table is successful, it means that the device has accessed the server before, and the dangerous value in the first data table will be directly used as the first dangerous value.

[0092] According to an embodiment of this disclosure, after querying the first data table in plaintext based on the fingerprint information, the method further includes: if the query to the first data table in plaintext based on the fingerprint information fails, invoking WAF verification logic so that if the WAF verification logic passes, the user is redirected to the target route to allow access.

[0093] If querying the first data table fails, it means that the device has not accessed the server before. The WAF verification logic is invoked to perform a comprehensive calculation. If the verification passes, the device is redirected to the original target route to allow access.

[0094] It is important to emphasize that for access requests containing plaintext fingerprint information that have never been accessed before, in order to maintain the aforementioned first data table, the WAF can directly calculate its risk value and store it in the first data table. However, the WAF's direct calculation of the risk value is significantly affected by the vendor and its settings; therefore, the calculation method for this risk value will not be elaborated upon here.

[0095] According to an embodiment of this disclosure, the step of querying the first data table in plaintext based on the fingerprint information to obtain a first danger value further includes: intercepting the access request if the first danger value is greater than a preset threshold.

[0096] Specifically, for devices that have previously engaged in access activities, if the corresponding danger value is found to be at a high level, their access requests will also be blocked.

[0097] In operation S260, if the first danger value is less than or equal to a preset threshold, the user is redirected to the target route to allow access.

[0098] Specifically, if the device corresponding to the access request has been accessed in the past and the risk is low, the access request is allowed, and there is no need to call the WAF verification logic for identification and verification.

[0099] In the embodiments of this disclosure, to address the technical problems of insufficient accuracy and coverage in the identification and interception of web attacks in the prior art, the embodiments of this disclosure design an auxiliary firewall interception scheme. After preliminary identification, verification of front-end functions, and judgment of danger values, the original WAF verification logic is called according to the specific situation. This process can filter out most access requests with high-risk behaviors, improve coverage, reduce the frequency of WAF verification logic calls, and efficiently intercept most access attacks. Furthermore, redirecting the request to a dedicated route allows for interaction with the front-end, thereby completing the front-end (client or browser) verification and preventing abnormal events (front-end functions not working, forged data packets, etc.) during the interaction between the front-end and the server. At the same time, the dedicated route is independent of access to the existing network, preventing the verification process from affecting normal access operations.

[0100] Operations S220 to S260 described above detail the secure communication logic for non-script access requests identified after initial identification. The secure communication logic for script access requests after initial identification is as follows:

[0101] Figure 3 A flowchart illustrating another firewall-based secure communication method according to an embodiment of this disclosure is shown schematically.

[0102] like Figure 3 As shown, another firewall-based secure communication method in this embodiment includes operations S310 to S320, which are performed after the above-mentioned operation S210.

[0103] In operation S310, for access requests whose identification result is a script, a hazard value comprehensive calculation rule is executed based on the target route to obtain a third hazard value.

[0104] Specifically, for script access requests, there is no need to redirect to the WAF dedicated route to perform multiple rounds of verification and operation. Instead, the comprehensive calculation rules for danger values ​​are directly applied to the script, and then the original WAF verification logic is called to verify it.

[0105] According to an embodiment of this disclosure, the comprehensive calculation rule for the danger value includes: querying a second data table based on the target route, or querying both the second and third data tables based on the target route to obtain a danger weight, wherein the second data table includes K routing information entries, and the third data table includes L one-to-one corresponding routing information entries and access counts, where K and L are positive integers; calling the WAF to calculate the danger value of the access request to obtain a second danger value; and calculating a third danger value based on the danger weight and the second danger value.

[0106] The second data table is the route whitelist, and the third route table records the number of accesses to different routes (i.e., the "route-number" table). The danger weight is determined by querying the route whitelist, or by querying both the route whitelist and the "route-number" table.

[0107] The second danger value is calculated by WAF in real time. This second danger value is different from the first danger value. For this second danger value, it needs to be multiplied by a danger weight, which is a coefficient greater than 1, to increase the scrutiny of script access.

[0108] Then, the third hazard value is obtained by multiplying the hazard weight by the second hazard value.

[0109] In operation S320, if the third danger value is less than or equal to a preset threshold, the WAF verification logic is invoked so that if the WAF verification logic passes, the target route is redirected to allow access.

[0110] If the third danger value is passed, the WAF verification logic is invoked to perform a comprehensive calculation. If the verification passes, the user is redirected back to the original target route to allow access.

[0111] According to an embodiment of this disclosure, after the third danger value is obtained by performing a comprehensive danger value calculation rule based on the target route, the method further includes: if the third danger value is greater than a preset threshold, intercepting the access request.

[0112] If the third risk value is too high, the access request will be blocked.

[0113] Figure 5 A flowchart illustrating a method for determining a danger weight according to an embodiment of the present disclosure is shown schematically.

[0114] like Figure 5 As shown, the method for determining the danger weight in this embodiment includes operations S510 to S550.

[0115] In operation S510, the second data table is queried based on the target route.

[0116] In operation S520, if the target route query of the second data table is successful, the danger weight is determined to be the first danger weight.

[0117] Specifically, the target route is queried to see if a corresponding route record exists in the route whitelist. Typically, the first danger weight corresponds to the route whitelist, and therefore, the first danger weight will be less than the second and third danger weights described below.

[0118] In operation S530, if the second data table is not successfully queried based on the target route, the third data table is queried based on the target route.

[0119] Specifically, if the target route is not in the route whitelist, check if the target route exists in the table that records the historical access count of the route.

[0120] In operation S540, if the number of times the target route is accessed in the third data table is within a preset access number range, the danger weight is determined to be the second danger weight.

[0121] When the target route is found to exist in the table that records the number of historical accesses to the route, it is determined whether the number of accesses to the target route is within a preset access range (e.g., the top 90%). If so, a second danger weight is determined, wherein the second danger weight is less than the third danger weight.

[0122] In operation S550, if the number of times the target route accesses the third data table is not within the preset number of accesses, or if the target route fails to query the third data table, the danger weight is determined to be the third danger weight.

[0123] If the target route is not found in the table recording the number of historical accesses, or if the number of accesses to the target route is not within the preset access range (e.g., the top 90%), then a third danger weight is determined, wherein the second danger weight is less than the third danger weight.

[0124] Figure 6 A schematic diagram illustrating the full flow of a firewall-based secure communication method according to an embodiment of the present disclosure is provided.

[0125] like Figure 6 As shown, the firewall-based secure communication method includes operations S601 to S614.

[0126] In operation S601, a request is received.

[0127] In operation S602, the User-Agent is used to initially distinguish between browser access and script access such as web crawlers. If it is a normal browser User-Agent, proceed to operation S603. If it is not a User-Agent or is empty, proceed to operation S207.

[0128] In operation S603, the system redirects to a dedicated route on the WAF, and a Refresh-Token is sent via Set-Cookie in the 302 response packet of the redirect. The backend session records the state attribute as 0 (this state corresponds to the Refresh-Token) and the route attribute as the original route accessed before the redirect. (This session has a 5-second expiration time). Proceed to operation S604.

[0129] In operation S604, this route verifies whether the state corresponding to the Refresh-Token in the Session is 0. If the verification fails, the process is intercepted and ends. If the verification succeeds, the state attribute in the Session is updated to 1, the server generates a pair of private and public keys for an asymmetric encryption algorithm and stores them in the Session, then proceeds to operation S605.

[0130] In operation S605, JavaScript code (carrying the public key of an asymmetric encryption algorithm) is embedded in the response page, and a meta tag is added to automatically reload the page without relying on JavaScript (with a 0.5-second delay). The code checks if JavaScript is enabled; if so, it extracts the device's fingerprint information. The extracted device fingerprint information is then encrypted using the public key of the asymmetric encryption algorithm and written to the Dev-Token in the cookie. The page reload is executed immediately after the core JavaScript code completes its function. If JavaScript cannot be executed, the page is reloaded via the meta tag after 0.5 seconds. After the page reloads, the backend verifies if the Refresh-Token's state is 1. If the verification fails, the process is blocked and ends. If the verification succeeds, operation S606 is initiated.

[0131] In operation S606, the backend retrieves the private key of the asymmetric encryption algorithm from the Session based on the Refresh-Token and decrypts the value of the Dev-Token in the Cookie. If the fingerprint information can be successfully decrypted, proceed to operation S610; otherwise, proceed to operation S607.

[0132] In operation S607, the currently accessed route is obtained. If the accessed route is a WAF-specific route, the Route corresponding to the Refresh-Token is extracted from the Session. The whitelist route table T11 is checked to see if the route exists. If the route exists, operation S611 is executed. If it does not exist, operation S608 is executed.

[0133] In operation S608, the "Route-Count" table T12 is sorted from largest to smallest by count, and the position of the current route in the table is found. If the position is in the top 90% (including 90%), proceed to operation S612. Otherwise, proceed to operation S609.

[0134] In operation S609, the danger weight is set to 1.7. Proceed to operation S614.

[0135] In operation S610, after decrypting the fingerprint information, the "Fingerprint-Risk Value" table T21 is queried. If the fingerprint exists, proceed to operation S613. If the fingerprint does not exist, proceed to operation S614.

[0136] In operation S611, the danger weight is set to 1.1. Proceed to operation S614.

[0137] In operation S612, the danger weight is set to 1.2. Proceed to operation S614.

[0138] In operation S613, the "Fingerprint-Risk Value" table T21 is queried to obtain the risk value corresponding to the fingerprint. If the risk value is greater than a preset threshold, the process is blocked and ends. If the risk value is less than or equal to the preset threshold, operation S614 is initiated.

[0139] In operation S614, the subsequent normal identification and interception functions of the WAF are entered. When calculating the danger value, the danger weight calculated in the pre-judgment process needs to be multiplied, and the decision on whether to intercept is based on the danger value obtained from the multiplication. If no attack is identified and the current access is to a dedicated route of the WAF, the Route corresponding to the Refresh-Token is extracted from the Session and redirected to the original route. If an attack is identified and the request carries a Dev-Token, a new danger value is calculated based on the attack severity in the results returned by subsequent modules of the WAF, and the "fingerprint-danger value" table is updated.

[0140] Based on the aforementioned firewall-based secure communication method, this disclosure also provides a firewall-based secure communication device. The following will be combined with... Figure 7 The device is described in detail.

[0141] Figure 7 A schematic block diagram of a firewall-based secure communication device according to an embodiment of the present disclosure is shown.

[0142] like Figure 7 As shown, the firewall-based secure communication device 700 of this embodiment includes a preliminary identification module 710, a non-script access front-end verification module 720, a fingerprint information plaintext acquisition module 730, a first data table query module 740, a first danger value determination module 750, and a WAF verification logic call module 760.

[0143] The preliminary identification module 710 is used to initially identify the received access request and obtain an identification result, wherein the access request includes a target route. In one embodiment, the preliminary identification module 710 can be used to perform the operation S210 described above, which will not be repeated here.

[0144] The non-script access front-end verification module 720 is used to verify whether the front-end function is normal when the access request identified as non-script is redirected to a dedicated route of the WAF. In one embodiment, the non-script access front-end verification module 720 can be used to perform the operation S220 described above, which will not be repeated here.

[0145] The fingerprint information plaintext acquisition module 730 is used to acquire the fingerprint information plaintext of the device when the front-end function is normal. In one embodiment, the fingerprint information plaintext acquisition module 730 can be used to perform the operation S230 described above, which will not be repeated here.

[0146] The first data table query module 740 is used to query a first data table based on the plaintext fingerprint information when the fingerprint information of the device is successfully acquired. The first data table includes N one-to-one corresponding fingerprint information and danger values. In one embodiment, the first data table query module 740 can be used to perform the operation S240 described above, which will not be repeated here.

[0147] The first danger value determination module 750 is used to obtain a first danger value when the fingerprint information is successfully queried in plaintext from the first data table. In one embodiment, the first danger value determination module 750 can be used to perform the operation S250 described above, which will not be repeated here.

[0148] The WAF verification logic call module 760 is used to redirect access to the target route when the first danger value is less than or equal to a preset threshold. In one embodiment, the WAF verification logic call module 760 can be used to perform the operation S260 described above, which will not be repeated here.

[0149] In the embodiments of this disclosure, to address the technical problems of insufficient accuracy and coverage in the identification and interception of web attacks in the prior art, the embodiments of this disclosure design an auxiliary firewall interception scheme. After preliminary identification, verification of front-end functions, and judgment of danger values, the original WAF verification logic is called according to the specific situation. This process can filter out most access requests with high-risk behaviors, improve coverage, reduce the frequency of WAF verification logic calls, and efficiently intercept most access attacks. Furthermore, access is redirected to a dedicated route, which enables interaction with the front-end and completes the front-end (client or browser) verification. This avoids abnormal events (front-end functions not working, forged data packets, etc.) during the interaction between the front-end and the server. At the same time, the dedicated route is independent of access to the existing network, preventing the verification process from affecting normal access operations.

[0150] According to an embodiment of this disclosure, the apparatus further includes: a hazard value comprehensive calculation module, configured to, for an access request whose identification result is a script, execute a hazard value comprehensive calculation rule based on the target route to obtain a third hazard value; and a WAF verification logic invocation module, further configured to, if the third hazard value is less than or equal to a preset threshold, invoke WAF verification logic to redirect to the target route and allow access if the WAF verification logic passes; wherein, the hazard value comprehensive calculation rule includes: querying a second data table based on the target route, or querying both the second and third data tables based on the target route to obtain a hazard weight, wherein the second data table includes K routing information entries, and the third data table includes L one-to-one corresponding routing information entries and access counts, where K and L are positive integers; invoking WAF to calculate the hazard value of the access request to obtain a second hazard value; and calculating a third hazard value based on the hazard weight and the second hazard value.

[0151] According to embodiments of this disclosure, the danger value comprehensive calculation module is further configured to, in the event of failure to obtain plaintext fingerprint information of the device, execute the danger value comprehensive calculation rule for access requests whose identification result is non-script, and obtain a third danger value; and the WAF verification logic calling module is further configured to, in the event that the third danger value is less than or equal to a preset threshold, call the WAF verification logic, so that if the WAF verification logic passes, the access is redirected to the target route.

[0152] According to an embodiment of this disclosure, the WAF verification logic calling module is further configured to call the WAF verification logic when the fingerprint information fails to query the first data table in plaintext, so that if the WAF verification logic passes, the user is redirected to the target route to allow access.

[0153] According to embodiments of this disclosure, the non-script access front-end verification module includes: a WAF dedicated route redirection unit, a refresh token verification unit, a key pair generation unit, a key pair writing unit, a code transmission unit, and a fingerprint information encrypted receiving unit. The WAF dedicated route redirection unit is used to redirect to a dedicated WAF route; the refresh token verification unit is used to verify whether a refresh token is generated normally; the key pair generation unit is used to generate a key pair when a refresh token is generated normally; the key pair writing unit is used to write the public key from the key pair into a preset first front-end execution logic to obtain a second front-end execution logic, the first front-end execution logic including logic for collecting device fingerprint information; the code transmission unit is used to transmit the second front-end execution logic to the front-end execution unit; and the fingerprint information encrypted receiving unit is used to receive the device fingerprint information encrypted text when the second front-end execution logic is successfully executed, and to determine that the front-end function is normal.

[0154] According to an embodiment of this disclosure, obtaining the plaintext fingerprint information of the device includes: decrypting the ciphertext fingerprint information based on the key pair to obtain the plaintext fingerprint information of the device.

[0155] According to embodiments of this disclosure, the apparatus further includes an interception module, configured to intercept the access request if a refresh token is not generated normally; the interception module is also configured to intercept the access request if an abnormal jump event is detected; the interception module is also configured to intercept the access request if a first danger value is greater than a preset threshold; and the interception module is also configured to intercept the access request if a third danger value is greater than a preset threshold.

[0156] According to embodiments of this disclosure, the hazard value comprehensive calculation module includes: a second data table query unit, a first hazard weight determination unit, a third data table query unit, and a third hazard weight determination unit. The second data table query unit is used to query the second data table based on the target route. If the first hazard weight determination unit successfully queries the second data table using the target route, it determines the hazard weight as a first hazard weight. The third data table query unit is used to query the third data table based on the target route if the query fails. The second hazard weight determination unit is used to determine the hazard weight as a second hazard weight if the number of visits by the target route in the third data table is within a preset number of visits range. The third hazard weight determination unit is used to determine the hazard weight as a third hazard weight if the number of visits by the target route in the third data table is not within the preset number of visits range, or if the query fails.

[0157] According to embodiments of this disclosure, any and multiple modules among the preliminary identification module 710, the non-script access front-end verification module 720, the fingerprint information plaintext acquisition module 730, the first data table query module 740, the first danger value determination module 750, and the WAF verification logic call module 760 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the preliminary identification module 710, the non-script access front-end verification module 720, the fingerprint information plaintext acquisition module 730, the first data table query module 740, the first danger value determination module 750, and the WAF verification logic call module 760 can be at least partially implemented as a hardware circuit, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or can be implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuit, or implemented in software, hardware, and firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the preliminary identification module 710, the non-script access front-end verification module 720, the fingerprint information plaintext acquisition module 730, the first data table query module 740, the first danger value determination module 750, and the WAF verification logic call module 760 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0158] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a firewall-based secure communication method according to an embodiment of the present disclosure.

[0159] like Figure 8 As shown, an electronic device 800 according to an embodiment of this disclosure includes a processor 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage portion 808 into a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this disclosure.

[0160] RAM 803 stores various programs and data required for the operation of electronic device 800. Processor 801, ROM 802, and RAM 803 are interconnected via bus 804. Processor 801 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 802 and / or RAM 803. It should be noted that the programs may also be stored in one or more memories other than ROM 802 and RAM 803. Processor 801 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0161] According to embodiments of this disclosure, the electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to a bus 804. The electronic device 800 may also include one or more of the following components connected to the I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 810 as needed so that computer programs read from it can be installed into the storage section 808 as needed.

[0162] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0163] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 802 and / or RAM 803 and / or one or more memories other than ROM 802 and RAM 803 described above.

[0164] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the item recommendation method provided in the embodiments of this disclosure.

[0165] When the computer program is executed by the processor 801, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0166] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 809, and / or installed from a removable medium 811. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0167] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by processor 801, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0168] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0169] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0170] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0171] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A secure communication method based on a firewall, characterized in that, The method includes: The received access request is initially identified, and the identification result is obtained. The access request includes the target route. For access requests whose identification results are non-script, verify whether the front-end functionality is normal when redirected to a dedicated WAF route; Under normal front-end functionality, the device's fingerprint information in plaintext is acquired. If the plaintext fingerprint information of the device is successfully acquired, the first data table is queried based on the plaintext fingerprint information. The first data table includes N one-to-one corresponding fingerprint information and risk values, where N is a positive integer. If the fingerprint information is successfully queried in plaintext from the first data table, a first danger value is obtained; and If the first danger value is less than or equal to a preset threshold, the user is redirected to the target route and access is granted.

2. The method according to claim 1, characterized in that, After initially identifying the received access request and obtaining the identification result, the process further includes: For access requests whose identification result is a script, a third danger value is obtained by performing a comprehensive danger value calculation rule based on the target route; and If the third danger value is less than or equal to a preset threshold, the WAF verification logic is invoked so that if the WAF verification logic passes, the user is redirected to the target route to allow access. The comprehensive calculation rules for the hazard value include: The danger weight is obtained by querying the second data table based on the target route, or by querying the second and third data tables based on the target route. The second data table includes K routing information, and the third data table includes L one-to-one corresponding routing information and access counts, where K and L are positive integers. The WAF is invoked to calculate the danger value of the access request, resulting in a second danger value; and Based on the aforementioned hazard weight and the second hazard value, a third hazard value is calculated.

3. The method according to claim 2, characterized in that, After obtaining the plaintext fingerprint information from the device, the method further includes: In the event that obtaining the device's fingerprint information in plaintext fails, for access requests where the identification result is non-scripted, a comprehensive risk value calculation rule is executed to obtain a third risk value; and If the third danger value is less than or equal to a preset threshold, the WAF verification logic is invoked so that if the WAF verification logic passes, the user is redirected to the target route to allow access.

4. The method according to claim 2, characterized in that, After querying the first data table in plaintext based on the fingerprint information, the method further includes: If the plaintext query of the fingerprint information fails, the WAF verification logic is invoked so that if the WAF verification logic passes, the user is redirected to the target route to allow access.

5. The method according to any one of claims 2 to 4, characterized in that, For access requests whose identification result is non-script, when redirected to a dedicated route in the WAF, verifying whether the front-end functionality is normal includes: Redirecting to a dedicated route for the WAF; Verify whether the refresh token was generated correctly; Generate a key pair under the normal refresh token generation method; The public key in the key pair is written into a preset first front-end execution logic to obtain a second front-end execution logic. The first front-end execution logic includes logic for collecting device fingerprint information. Transmit the second front-end execution logic to the front-end execution; and If the second front-end execution logic is successfully executed, the encrypted device fingerprint information is received, and the front-end function is determined to be normal.

6. The method according to claim 5, characterized in that, The plaintext fingerprint information of the acquisition device includes: The fingerprint information ciphertext is decrypted based on the key pair to obtain the plaintext fingerprint information of the device.

7. The method according to claim 5, characterized in that, After verifying whether a refresh token is generated normally, the method further includes: if a refresh token is not generated normally, intercepting the access request; After transferring the second front-end execution logic to the front-end execution, the method further includes: If an abnormal jump event is detected, the access request will be intercepted; The method of querying a first data table in plaintext based on the fingerprint information to obtain a first danger value further includes: intercepting the access request if the first danger value is greater than a preset threshold; and After obtaining the third danger value by performing a comprehensive danger value calculation rule based on the target route, the method further includes: if the third danger value is greater than a preset threshold, intercepting the access request.

8. The method according to any one of claims 2, 3, and 4, characterized in that, The step of querying the second data table based on the target route, or querying both the second and third data tables based on the target route to obtain the danger weight, includes: Based on the target route, query the second data table; If the target route query to the second data table is successful, the danger weight is determined to be the first danger weight. If the target route query to the second data table fails, the third data table is queried based on the target route. If the number of visits to the target route in the third data table falls within a preset number of visits range, the danger weight is determined to be the second danger weight; and If the number of times the target route is accessed in the third data table is not within the preset access number range, or if the target route fails to query the third data table, the danger weight is determined to be the third danger weight.

9. A firewall-based secure communication device, characterized in that, The device includes: The preliminary identification module is used to initially identify the received access request and obtain the identification result, wherein the access request includes the target route; The non-script access front-end verification module is used to verify whether the front-end function is normal when the access request whose identification result is non-script is redirected to the dedicated route of the WAF. The fingerprint information plaintext acquisition module is used to acquire the fingerprint information plaintext of the device when the front-end function is normal. The first data table query module is used to query the first data table based on the fingerprint information plaintext when the fingerprint information plaintext of the device is successfully obtained. The first data table includes N one-to-one corresponding fingerprint information and danger values. The first danger value determination module is used to obtain a first danger value when the fingerprint information is successfully queried in plaintext from the first data table; and The WAF verification logic call module is used to redirect to the target route to allow access if the first danger value is less than or equal to a preset threshold.

10. An electronic device, comprising: One or more processors; Storage device for storing one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images