Vulnerability identification method and device

Abstract

The invention provides a vulnerability identification method and device, and relates to the technical field of network security. The method comprises the following steps: acquiring a request message sent to a server by a client; when the request message comprises an origin field, the request message is forwarded to the server side; if it is confirmed that the response of the server side is unsuccessful, determining that the server side does not have a cross-domain resource sharing CORS vulnerability; if a response message fed back by the server is received, performing CORS vulnerability identification according to a response header in the response message; and when whether the response message has the CORS vulnerability is not identified based on the response header, performing CORS vulnerability identification based on the origin field, thereby realizing rapid and accurate identification of the CORS vulnerability.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a vulnerability identification method and device. Background Art

[0002] With the rapid development of the Internet, web applications are becoming more and more common and complex. At the same time, web application security issues are becoming increasingly important. Cross-origin resource sharing (CORSs-Origin Resource Sharing, CORS) is a mechanism for implementing cross-domain requests, which allows web pages under a certain domain to send requests to another domain and obtain resource data. Current browsers implement the same-origin policy, which blocks access to resources from one domain to another by default, thereby protecting user security. However, CORS provides developers with a flexible way to bypass the same-origin policy and allow safe and legal cross-domain data requests. However, improper or misconfigured CORS can lead to serious security vulnerabilities, which in turn lead to problems such as sensitive information leakage and unauthorized insecure access.

[0003] The current CORS vulnerability attack process is roughly as follows: the attacker sends detection traffic to the internal server of the intranet, and determines whether there is a CORS vulnerability and whether the vulnerability is exploitable based on the response content of the internal server; the attacker constructs an illegal request in the external server based on the information fed back by the internal server, such as a forged website; when the internal host of the intranet clicks on the forged website of the external server, the external server can obtain the login information of the internal user, etc.; the external server can request access to the internal server based on the internal user information, and then obtain the user's sensitive data, or further perform malicious operations, thereby achieving the purpose of the attack.

[0004] Currently, the methods for identifying CORS vulnerability attacks mainly focus on static analysis and dynamic manual scanning analysis. Among them, static analysis can only analyze the configuration in the code, but cannot detect the dynamic behavior at runtime. It has great limitations and the detection accuracy is not high enough. Dynamic analysis requires testers to write test code to actively send cross-domain requests. This method is not only time-consuming and inefficient, but also prone to test omissions. Summary of the invention

[0005] In view of this, the present application provides a vulnerability identification method and device for quickly and accurately identifying CORS vulnerabilities.

[0006] Specifically, the present application is implemented through the following technical solutions:

[0007] According to a first aspect of the present application, a vulnerability identification method is provided, which is applied to a network security device, and the method includes:

[0008] Get the request message sent by the client to the server;

[0009] When the request message includes an origin field, forwarding the request message to the server;

[0010] If it is confirmed that the server responds unsuccessfully, it is determined that the server does not have a cross-origin resource sharing (CORS) vulnerability;

[0011] If a response message fed back by the server is received, CORS vulnerability identification is performed according to the response header in the response message;

[0012] When it is not identified whether the response message has a CORS vulnerability based on the response header, CORS vulnerability identification is performed based on the origin field.

[0013] According to a second aspect of the present application, a vulnerability identification device is provided, which is applied to a network security device, and the device includes:

[0014] An acquisition unit, used to acquire a request message sent from the client to the server;

[0015] a forwarding unit, configured to forward the request message to the server when the request message includes an origin field;

[0016] A determination unit, configured to determine that the server does not have a cross-origin resource sharing (CORS) vulnerability if it is determined that the server response is unsuccessful;

[0017] The first identification unit is further configured to identify a CORS vulnerability according to a response header in the response message if a response message fed back by the server is received;

[0018] The second identification unit is used to identify the CORS vulnerability based on the origin field when the first identification unit fails to identify whether the response message has a CORS vulnerability based on the response header.

[0019] According to the third aspect of the present application, an electronic device is provided, including a processor and a machine-readable storage medium, the machine-readable storage medium storing a computer program that can be executed by the processor, and the processor is prompted by the computer program to execute the method provided in the first aspect of the embodiment of the present application.

[0020] According to the fourth aspect of the present application, a machine-readable storage medium is provided, which stores a computer program. When called and executed by a processor, the computer program prompts the processor to execute the method provided in the first aspect of the embodiment of the present application.

[0021] Beneficial effects of the embodiments of the present application:

[0022] In the CORS vulnerability identification method and device provided in the embodiment of the present application, a request message sent from the client to the server is obtained; when the request message includes an origin field, the request message is forwarded to the server; if it is confirmed that the server response is unsuccessful, it is determined that there is no cross-domain resource sharing CORS vulnerability on the server; if a response message fed back by the server is received, CORS vulnerability identification is performed based on the response header in the response message; when it is not determined whether the response message has a CORS vulnerability based on the response header, CORS vulnerability identification is performed based on the origin field. Thus, CORS identification is performed based on the response message and the request message, and the dynamic behavior of the message can be detected, thereby not only improving the accuracy of the CORS vulnerability identification result, but also eliminating the need for manual operation, thereby improving the CORS vulnerability identification speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a flowchart of a vulnerability identification method provided by an embodiment of the present application;

[0024] Figure 2 It is a schematic diagram of the model structure of a BiLSTM model provided in an embodiment of the present application;

[0025] Figure 3 It is a recognition logic diagram based on a CORS vulnerability recognition model provided in an embodiment of the present application;

[0026] Figure 4 It is a structural schematic diagram of a vulnerability identification device provided in an embodiment of the present application;

[0027] Figure 5 It is a hardware structure diagram of an electronic device for implementing a vulnerability identification method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] Here, exemplary embodiments will be described in detail, and examples thereof are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application.

[0029] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more corresponding listed items.

[0030] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0031] The vulnerability identification method provided by this application is described in detail below.

[0032] See also Figure 1 , Figure 1 This is a flowchart of a vulnerability identification method provided by the present application. The method can be applied to a network security device, which can be, but is not limited to, a firewall device, a security gateway, etc. When the network security device implements the method, the following steps may be included:

[0033] Step 101: Obtain a request message sent from the client to the server.

[0034] In this step, in order to ensure the security of the intranet, the traffic sent to the intranet server will be security checked. Based on this, the network security device can capture the request message sent from the client to the server.

[0035] In addition, the network security device can also construct a request message sent by the client to the server to identify CORS vulnerabilities. In order to better understand the present application, the following embodiments are described by taking the request message sent by the client to the server as a message for accessing business traffic as an example.

[0036] Step 102: When the request message includes an origin field, forward the request message to the server.

[0037] In this step, generally, when the request message includes the origin field, it indicates that CORS vulnerability identification is currently required; based on this, this embodiment proposes to first perform CORS vulnerability identification based on whether the server responds to the request message. Based on this, the network security device first forwards the request message containing the origin field to the server corresponding to the destination IP address in the request message in the intranet.

[0038] Step 103: If it is confirmed that the server responds unsuccessfully, it is determined that there is no cross-origin resource sharing (CORS) vulnerability on the server.

[0039] In this step, when the server receives the request message, if it recognizes that the content requested by the current request message does not exist, it refuses to respond to the above request message. Based on this, if the network security device does not receive any feedback from the server within the set time, it can be confirmed that the server's response is unsuccessful. Since this access has been blocked, based on this, it can be directly determined that there is no CORS vulnerability on the server when currently accessing the server.

[0040] Step 104: If a response message fed back by the server is received, CORS vulnerability identification is performed according to the response header in the response message.

[0041] In this step, if the server responds to the above request message, it indicates that a CORS vulnerability may exist at present. Based on this, this embodiment proposes to identify the CORS vulnerability based on the response message, that is, extract the response header from the above response message, and then identify whether a CORS vulnerability exists based on the response header.

[0042] Step 105: When it is not identified whether the response message has a CORS vulnerability based on the response header, CORS vulnerability identification is performed based on the origin field.

[0043] In this step, when CORS vulnerability identification is performed based on the response header, the identification results can be the following three situations: identification of the existence of a CORS vulnerability, identification of the non-existence of a CORS vulnerability, and inability to identify whether a CORS vulnerability exists. The above situation where it is impossible to identify whether a CORS vulnerability exists does not mean that there is no CORS vulnerability at present. Therefore, in order to improve the accuracy of CORS vulnerability identification, it is proposed to perform CORS vulnerability identification in combination with the request message, that is, to identify the CORS vulnerability based on the origin field in the request message to confirm whether a CORS vulnerability exists.

[0044] In the implementation of the vulnerability identification method provided by the present application, a request message sent from a client to a server is obtained; when the request message includes an origin field, the request message is forwarded to the server; if it is confirmed that the server response is unsuccessful, it is determined that there is no cross-domain resource sharing (CORS) vulnerability on the server; if a response message fed back by the server is received, CORS vulnerability identification is performed based on the response header in the response message; when it is not determined whether the response message has a CORS vulnerability based on the response header, CORS vulnerability identification is performed based on the origin field. Thus, CORS identification is performed based on response messages and request messages, and the dynamic behavior of the message can be detected, thereby not only improving the accuracy of the CORS vulnerability identification results, but also eliminating the need for manual operation, thereby improving the CORS vulnerability identification speed.

[0045] Optionally, based on the above embodiment, in this embodiment, step 104 can be performed according to the following process: if the response header includes Access-Control-Allow-Origin or Access-Control-Allow-Credentials, it is identified that the response message does not have a CORS vulnerability; if the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, when the value of the Access-Control-Allow-Origin is a first set value, it is identified that the response message does not have a CORS vulnerability; when the value of the Access-Control-Allow-Origin is a second set value, it is identified that the response message has a CORS vulnerability; if the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, when the value of the Access-Control-Allow-Credentials is not true, it is identified that the response message does not have a CORS vulnerability.

[0046] Specifically, the Access-Control-Allow-Origin is used to indicate the origin that allows cross-domain resource sharing, and the Access-Control-Allow-Credentials is used to indicate the identity credentials that allow cross-domain transmission. When the response header does not include both the Access-Control-Allow-Origin and Access-Control-Allow-Credentials fields, it indicates that there is no CORS vulnerability. When the response header includes both the Access-Control-Allow-Origin and Access-Control-Allow-Credentials fields, it indicates that a CORS vulnerability may exist currently. In order to further identify whether a CORS vulnerability exists in the current access service traffic, this embodiment proposes the above process, that is, when the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, CORS vulnerability identification can be performed based on the value of the Access-Control-Allow-Origin. Specifically, the first setting value can be, but is not limited to, the setting character "*" or Null; the second setting value can be, but is not limited to, null. On this basis, when the value of Access-Control-Allow-Origin is "*" or Null, it can be directly determined that there is no CORS vulnerability currently; and when the value of Access-Control-Allow-Origin is null, it can be directly determined that a CORS vulnerability exists currently and the CORS vulnerability is exploitable, that is, a CORS vulnerability exists on the server and the CORS vulnerability is exploitable. When the value of Access-Control-Allow-Origin is other than the first set value and the second set value, it cannot indicate that a CORS vulnerability does not exist or exists. Based on this, in order to further accurately identify whether a CORS vulnerability exists, this application will further identify it in combination with the request message, which will be described in detail later.

[0047] When the above-mentioned response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, when CORS vulnerability identification is performed based on the value of Access-Control-Allow-Credentials, when the response header includes the Access-Control-Allow-Credentials field, it indicates that there may be a CORS vulnerability caused by a possible incorrect configuration of the website configuration. In order to accurately identify whether there is a CORS vulnerability, this embodiment proposes that it is possible to determine whether the value of Access-Control-Allow-Credentials is true. When the value of Access-Control-Allow-Credentials is not true, it can be directly determined that there is no CORS vulnerability at present; and when the value of Access-Control-Allow-Credentials is true, it cannot indicate that there is no CORS vulnerability at present. In order to further accurately identify whether there is a CORS vulnerability, this application will combine the request message for further identification, which will be described in detail later.

[0048] Further, a method for determining whether a CORS vulnerability exists in the response message based on the response header not being able to identify the presence of the response message is as follows: if the value of Access-Control-Allow-Origin included in the response header points to a specified site or any site, or if the value of Access-Control-Allow-Credentials included in the response header is true, then determining whether a CORS vulnerability exists in the response message based on the response header not being able to identify the presence of the response message.

[0049] Specifically, based on the above description, since the security of the above-mentioned designated site fed back by the response message cannot be confirmed, and since the network security device used for detection cannot directly determine whether the designated site is a designated trusted site or a site forged by an attacker, that is, the designated site may be a secure host (safe_host) or an unsafe host, and the client is located in the host. Therefore, when the value of Access-Control-Allow-Origin is a designated site, since the security of the designated site cannot be evaluated, and it is also impossible to determine whether the security problem is caused by a CORS vulnerability, it can be determined at this time that the response message does not identify whether there is a CORS vulnerability based on the response header. Similarly, in actual applications, the value of Access-Control-Allow-Origin may also point to any site (all_host), and pointing to any site itself poses a security threat because the site is not fixed. On the other hand, any site itself may also have security issues and may be a site forged by an attacker. Therefore, a security assessment is required, but since it is impossible to determine the security of any site itself, and it is also impossible to determine whether the security problem is caused by a CORS vulnerability, it can be determined at this security level that the response message does not identify whether there is a CORS vulnerability based on the response header.

[0050] Optionally, when it is impossible to identify whether the response message has a CORS vulnerability based on the response header, the present embodiment proposes that the step of identifying a CORS vulnerability based on the origin field in step 105 can be performed according to the following process: when the value of the origin field does not exist or is not alive, or when the value of the origin field exists and does not conform to a set format, it is determined that the request message has a CORS vulnerability detection and exploitation behavior; when the value of the origin field conforms to a set format, the value of the origin field is matched with the value of the origin field of the malicious intelligence recorded in the intelligence library; when the match is successful, it is determined that the request message has a CORS vulnerability detection and exploitation behavior; when the match is unsuccessful, feature extraction is performed on the origin field to obtain features to be detected; based on the features to be detected and a pre-trained CORS vulnerability identification model, it is identified whether the request message has a CORS vulnerability detection and exploitation behavior.

[0051] Specifically, when judging whether the value of the origin field exists and is alive, it can be detected through the currently existing whois, ping and other methods, which will not be described in detail here. In actual applications, in secure and reliable traffic access, the value of the origin field in the request message is generally present and alive. Therefore, when it is identified that the value of the origin field does not exist or is not alive, it can be directly determined that the request message has a detection behavior that attempts to exploit the CORS vulnerability. When the value of the origin field is alive, it cannot be directly said that the CORS vulnerability does not exist at this time, and the value of the origin field needs to be judged for legitimacy. For example, when the legitimacy judgment includes format judgment, it can be judged whether the value of the origin field conforms to the set format. When it does not conform to the set format, it can be directly determined that the request message has a detection behavior that attempts to exploit the CORS vulnerability.

[0052] When it meets the set format, it can be determined that the format of the origin field is legal and meets the format of the origin field value required by normal business traffic. However, it cannot be directly determined that there is no CORS vulnerability at this time. Further judgment is required, that is, the value of the origin field is matched with the value of the origin field of the malicious intelligence recorded in the intelligence library. The intelligence library is pre-established. Since the intelligence library includes the value of the origin field in the request message of the malicious intelligence, the value of the origin field extracted by this application can be matched with the intelligence library. When the match is successful, it can be directly indicated that there is currently a detection behavior that attempts to exploit the CORS vulnerability. When the match fails, it cannot be directly determined that there is no CORS vulnerability at this time. In order to identify the CORS vulnerability more accurately, a CORS vulnerability identification model is introduced, and the CORS vulnerability identification model uses the above-mentioned feature detection method to identify the CORS vulnerability. As a result, the accuracy of CORS vulnerability identification is further improved.

[0053] In order to better understand the above format judgment, we can take the value of the origin field including the IP address, port and domain name as an example. Based on this, we can judge whether the format of the IP address conforms to the required format of the IP address, whether the port meets the port setting requirements, whether the format of the domain name meets the format of the legal domain name, etc.; when the judgment results are all yes, it is determined that the value of the origin field conforms to the set format.

[0054] Of course, in practical applications, the judgment on the legitimacy of the origin field may also include other judgment conditions, which may be determined according to actual conditions, and this embodiment does not limit this.

[0055] In addition, when matching the intelligence library, the value of the origin field may include an IP address and port, or a domain name and port, etc. Based on this, the origin value of the malicious intelligence included in the intelligence library may also be an IP address and port, or a domain name and port. Based on this, the IP address and port in the origin field are matched with the intelligence library, or the domain name and port in the origin field are matched with the intelligence library.

[0056] When the intelligence library fails to identify whether there is a CORS vulnerability, since the request message at this time may also contain CORS vulnerability detection and exploitation behavior, in order to further improve the accuracy of the identification results, it is proposed to introduce a CORS vulnerability identification model for identification.

[0057] Optionally, the CORS vulnerability identification model is obtained by training a bidirectional long short-term memory model (BiLSTM) using training samples; the training samples include sample features obtained by extracting features from the origin field in each request message sample sent from the client to the server within a set time period.

[0058] Optionally, the sample features may be obtained based on a request message sent from the same client to the same server, or may be obtained based on a request message sent from different clients to different servers, which is not limited in this embodiment.

[0059] Specifically, when it is impossible to identify whether there is CORS vulnerability detection and exploitation behavior based on the above situation, it is proposed to identify CORS vulnerability based on CORS vulnerability identification model. This model is obtained by training the BiLSTM model. The structure diagram of the BiLSTM model can be referred to Figure 2 As shown. The network structure of the BiLSTM model roughly includes word vector dimension definition, embedding layer (Embedding), network layer and classifier, among which the network layer includes Bidirection (LSTM()) layer, Dropout layer, Dense layer. The model construction process is roughly as follows: This application adopts the deep learning framework Keras and uses its built-in LSTM layer to implement bidirectional LSTM. Specifically, a bidirectional LSTM layer is defined: LSTM (units, return_sequences = True, bidirectional = True) to ensure that the output of each time point will be returned and the forward and reverse information flows will be calculated at the same time. After the hierarchical structure of the model is constructed, the compiled model is executed. This application adopts a binary classification method, that is, the loss function adopts binary cross entropy (binary_crossentropy). The optimizer selects the Adam adaptive learning rate optimizer, and thus the complete BiLSTM model is built.

[0060] The model training process is as follows: Model training is performed by calling the Keras framework model's model.fit(x,y,batch_size=12,epochs=16,verbose=1,validation_data=(x_val,y_val)) method. In each training cycle, when the training sample is input into the BiLSTM model, the model will try to predict the output based on the current weight parameters, and calculate the loss by comparing the predicted results with the true labels. Then the back propagation algorithm will update the weight parameters in the model according to the gradient of the loss function. Repeat the above training process until the specified number of training cycles is reached or other stop conditions are met.

[0061] The construction process of the above training samples is roughly as follows: collect training samples, for example, collect request messages sent from the client to the server within 60 seconds, and then extract sample features from the request messages; after extracting the sample features, encode the sample features to obtain the encoded sample features, thereby constructing the training samples.

[0062] It is worth noting that in actual applications, most of the business traffic captured by network security devices within a set time period is safe, that is, most of the captured request messages are safe and reliable. Therefore, in order to avoid a large number of safe and reliable request messages participating in model training as training samples, there will be too many safe and reliable training samples resulting in uneven features, which in turn leads to a high F1 value for evaluating model training. In view of this, this embodiment proposes that the training samples can be removed, for example, the sample features of the trusted request messages are removed, and at the same time, the trusted IP address is written into the whitelist, which can include the source IP address and the destination IP address.

[0063] On this basis, after executing step 101 and before executing step 102, the IP address of the request message can be matched with the above whitelist. When the above whitelist is hit, it indicates that the current request message is credible. At this time, the request message can be directly forwarded without CORS vulnerability identification.

[0064] It should be noted that an aging time can be set for each trusted IP address in the above whitelist. When the aging time of each trusted IP address is reached, the trusted IP address is deleted from the whitelist. This avoids the situation where a trusted IP address was previously trusted, but there is a subsequent CORS vulnerability detection and exploitation behavior, and the trusted IP address is in the whitelist, resulting in an unidentified security risk.

[0065] On this basis, the step of identifying whether the request message has CORS vulnerability detection and exploitation behavior based on the features to be detected and the pre-trained CORS vulnerability identification model can be performed according to the following process: the features to be detected are input into the CORS vulnerability identification model; when the identification result output by the CORS vulnerability identification model meets the CORS vulnerability identification condition, it is identified that the request message has CORS vulnerability detection and exploitation behavior.

[0066] Specifically, the above-mentioned CORS vulnerability identification model characterizes the mapping relationship between features and CORS vulnerabilities. Therefore, after obtaining the features to be detected, they can be input into the CORS vulnerability identification model, and the model can output an evaluation value. Then obtain the pre-set CORS vulnerability evaluation condition. For example, the CORS vulnerability identification condition is: greater than the evaluation threshold of the CORS vulnerability. Based on this, when the evaluation value is greater than the above-mentioned evaluation threshold, it can be directly determined that there is currently a CORS vulnerability detection and exploitation behavior, that is, there is a CORS vulnerability detection and exploitation behavior in the business traffic currently accessing the server. If it is not greater than the above-mentioned evaluation threshold, it indicates that there is currently no CORS vulnerability detection and exploitation behavior. Therefore, CORS vulnerability identification is performed based on the CORS vulnerability identification model and the aforementioned response header and origin field, which further improves the accuracy of CORS vulnerabilities.

[0067] Optionally, the above-mentioned features to be detected include at least: source IP address, destination IP address, location of source IP address, identification result of whether the value of origin is in the asset domain name and whitelist, the number of occurrences of the value of origin within a set time, domain name features when the value of origin includes a domain name, etc. On this basis, the obtained training samples can be shown in Table 1. It should be noted that Table 1 is only an example and does not constitute a specific limitation on the value of sample features.

[0068] Table 1

[0069]

[0070] After obtaining the above training samples, the sample features can be encoded. Taking the sample features shown in Table 1 as an example, the general encoding process is: organize the 6 sample features into 6-dimensional sample data, and then one-hit encode the sample data. For example, encode the collected source IP address and destination IP address as positive integers from 1 to n, encode the source IP address's location as a positive integer from 1 to n, encode the above recognition result as 1 or 2, encode the above number of occurrences as a positive integer from 1 to n, and encode the domain name features as a positive integer from 1 to n, where n is a fixed size and is filled with 0 if it is not enough. In this way, the encoded sample features are obtained. The BiLSTM model is then trained with the encoded sample features to obtain the CORS vulnerability recognition model. The training logic reference Figure 3 shown.

[0071] Correspondingly, after obtaining the features to be detected, the features to be detected also need to be encoded to obtain variable features, and then the encoded features are input into the trained CORS vulnerability recognition model to obtain the CORS vulnerability recognition results, that is, whether there is CORS vulnerability detection and exploitation behavior. The recognition logic can refer to Figure 3 shown.

[0072] At this point, by adopting the above vulnerability identification method, it is helpful to accurately identify whether there is a CORS vulnerability attack at present. When the CORS vulnerability detection and exploitation behavior is identified, corresponding protection measures are adopted, thus reducing the security risks in business traffic access. In addition, the method can be universal and can be applied to security products or security platforms.

[0073] Based on the same inventive concept, the present application also provides a vulnerability identification device corresponding to the above vulnerability identification method. The implementation of the vulnerability identification device can refer to the above description of the vulnerability identification method, which will not be discussed here one by one.

[0074] See also Figure 4 , Figure 4 A vulnerability identification device provided by an exemplary embodiment of the present application is applied to a network security device, and the device includes:

[0075] The acquisition unit 401 is used to acquire the request message sent by the client to the server;

[0076] A forwarding unit 402, configured to forward the request message to the server when the request message includes an origin field;

[0077] The determination unit 403 is used to determine that there is no cross-origin resource sharing (CORS) vulnerability on the server if it is confirmed that the server response is unsuccessful;

[0078] The first identification unit 404 is further configured to identify a CORS vulnerability according to a response header in the response message if a response message fed back by the server is received;

[0079] The second identification unit 405 is configured to perform CORS vulnerability identification based on the origin field when the first identification unit 404 fails to identify whether the response message has a CORS vulnerability based on the response header.

[0080] Therefore, in the present application, CORS identification is performed based on response messages and request messages, and the dynamic behavior of the messages can be detected. This not only improves the accuracy of the CORS vulnerability identification results, but also does not require manual operation, thereby improving the CORS vulnerability identification speed.

[0081] Optionally, the above-mentioned first identification unit 404 is specifically used for the first identification unit, specifically for identifying that the response message does not have a CORS vulnerability if the response header includes Access-Control-Allow-Origin or Access-Control-Allow-Credentials; if the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, then when the value of the Access-Control-Allow-Origin is a first set value, it is identified that the response message does not have a CORS vulnerability; when the value of the Access-Control-Allow-Origin is a second set value, it is identified that the response message has a CORS vulnerability; if the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, then when the value of the Access-Control-Allow-Credentials is not true, it is identified that the response message does not have a CORS vulnerability.

[0082] Furthermore, the above-mentioned first identification unit 404 is also used to determine whether there is a CORS vulnerability in the response message that is not identified based on the response header if the value of Access-Control-Allow-Origin included in the response header points to a specified site or any site, or if the value of Access-Control-Allow-Credentials included in the response header is true.

[0083] Optionally, based on any of the above embodiments, in this embodiment, the above-mentioned second identification unit 405 is specifically used to determine that the request message has CORS vulnerability detection and exploitation behavior when the value of the origin field does not exist or is not alive, or the value of the origin field exists and does not conform to a set format; when the value of the origin field conforms to a set format, the value of the origin field is matched with the value of the origin field of the malicious intelligence recorded in the intelligence library; when the match is successful, it is determined that the request message has CORS vulnerability detection and exploitation behavior; when the match is unsuccessful, feature extraction is performed on the origin field to obtain features to be detected; based on the features to be detected and a pre-trained CORS vulnerability identification model, it is identified whether the request message has CORS vulnerability detection and exploitation behavior.

[0084] Furthermore, in this embodiment, the CORS vulnerability identification model is obtained by training a bidirectional long short-term memory model using training samples; the training samples include sample features obtained by extracting features from the origin field in each request message sample sent from the client to the server within a set time period;

[0085] On this basis, the second identification unit 405 is specifically used to input the feature to be detected into the CORS vulnerability identification model; when the identification result output by the CORS vulnerability identification model meets the CORS vulnerability identification condition, it is identified that the request message contains CORS vulnerability detection and exploitation behavior.

[0086] Based on the same inventive concept, an embodiment of the present application provides an electronic device, which can be the above-mentioned network security device. Figure 5 As shown, the electronic device may include a processor 501 and a machine-readable storage medium 502, the machine-readable storage medium 502 stores a computer program that can be executed by the processor 501, and the processor 501 is prompted by the computer program to execute the vulnerability identification method provided by any embodiment of the present application. In addition, the electronic device also includes a communication interface 503 and a communication bus 504, wherein the processor 501, the communication interface 503, and the machine-readable storage medium 502 communicate with each other through the communication bus 504.

[0087] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0088] The communication interface is used for communication between the above electronic device and other devices.

[0089] The machine-readable storage medium 502 may be a memory, which may include a random access memory (RAM), a DDR SRAM (Double Data Rate Synchronous Dynamic Random Access Memory), or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the processor.

[0090] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0091] In addition, this embodiment also provides a machine-readable storage medium, which stores a computer program. When called and executed by a processor, the computer program prompts the processor to execute the method provided by any embodiment of the present application.

[0092] As for the electronic device and machine-readable storage medium embodiments, since the method contents involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0093] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0094] The implementation process of the functions and effects of each unit / module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0095] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are merely schematic, wherein the units / modules described as separate components may or may not be physically separated, and the components displayed as units / modules may or may not be physical units / modules, that is, they may be located in one place, or they may be distributed on multiple network units / modules. Some or all of the units / modules may be selected according to actual needs to achieve the purpose of the present application. A person of ordinary skill in the art can understand and implement it without creative work.

[0096] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A vulnerability identification method, characterized in that: Applied to a network security device, the method comprises: Get the request message sent by the client to the server; When the request message includes an origin field, forwarding the request message to the server; If it is confirmed that the server responds unsuccessfully, it is determined that the server does not have a cross-origin resource sharing (CORS) vulnerability; If a response message fed back by the server is received, CORS vulnerability identification is performed according to the response header in the response message; When it is not identified whether the response message has a CORS vulnerability based on the response header, CORS vulnerability identification is performed based on the origin field.

2. The method according to claim 1, characterized in that The CORS vulnerability is identified according to the response header in the response message, including: If the response header includes Access-Control-Allow-Origin or Access-Control-Allow-Credentials, it is identified that the response message does not have a CORS vulnerability; If the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, when the value of Access-Control-Allow-Origin is a first set value, it is identified that the response message does not have a CORS vulnerability; when the value of Access-Control-Allow-Origin is a second set value, it is identified that the response message has a CORS vulnerability; If the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, when the value of the Access-Control-Allow-Credentials is not true, it is identified that the response message does not have a CORS vulnerability.

3. The method according to claim 2, characterized in that The method for determining whether the response message has a CORS vulnerability based on the response header not being identified is: If the value of Access-Control-Allow-Origin included in the response header points to a specified site or any site, or if the value of Access-Control-Allow-Credentials included in the response header is true, it is determined whether there is a CORS vulnerability in the response message that is not identified based on the response header.

4. The method according to claim 1, characterized in that: CORS vulnerability identification based on the origin field includes: When the value of the origin field does not exist or is not alive, or the value of the origin field exists and does not conform to the set format, it is determined that the request message contains CORS vulnerability detection and exploitation behavior; When the value of the origin field conforms to the set format, the value of the origin field is matched with the value of the origin field of the malicious intelligence recorded in the intelligence library; When the match succeeds, it is determined that the request message contains CORS vulnerability detection and exploitation behavior; When the match fails, feature extraction is performed on the origin field to obtain features to be detected; Based on the features to be detected and the pre-trained CORS vulnerability identification model, it is identified whether the request message contains CORS vulnerability detection and exploitation behavior.

5. The method according to claim 4, characterized in that The CORS vulnerability identification model is obtained by training a bidirectional long short-term memory model using training samples; the training samples include sample features obtained by extracting features from the origin field in each request message sample sent from the client to the server within a set time period; Based on the features to be detected and the pre-trained CORS vulnerability identification model, identifying whether the request message contains CORS vulnerability detection and exploitation behavior includes: Inputting the feature to be detected into the CORS vulnerability identification model; When the identification result output by the CORS vulnerability identification model meets the CORS vulnerability identification condition, it is identified that the request message contains CORS vulnerability detection and exploitation behavior.

6. A vulnerability identification device, characterized in that: Applied in network security equipment, the device comprises: An acquisition unit, used to acquire a request message sent from the client to the server; a forwarding unit, configured to forward the request message to the server when the request message includes an origin field; A determination unit, configured to determine that the server does not have a cross-origin resource sharing (CORS) vulnerability if it is determined that the server response is unsuccessful; The first identification unit is further configured to identify a CORS vulnerability according to a response header in the response message if a response message fed back by the server is received; The second identification unit is used to identify the CORS vulnerability based on the origin field when the first identification unit fails to identify whether the response message has a CORS vulnerability based on the response header.

7. The device according to claim 6, characterized in that The first identification unit is specifically used to identify that the response message does not have a CORS vulnerability if the response header includes Access-Control-Allow-Origin or Access-Control-Allow-Credentials; if the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, when the value of Access-Control-Allow-Origin is a first set value, it is identified that the response message does not have a CORS vulnerability; when the value of Access-Control-Allow-Origin is a second set value, it is identified that the response message has a CORS vulnerability; if the response header includes Access-Control-Allow-Origin and Access-Control-Allow-Credentials, when the value of Access-Control-Allow-Credentials is not true, it is identified that the response message does not have a CORS vulnerability.

8. The device according to claim 7, characterized in that The first identification unit is also used to determine whether there is a CORS vulnerability in the response message that is not identified based on the response header if the value of Access-Control-Allow-Origin included in the response header points to a specified site or any site, or if the value of Access-Control-Allow-Credentials included in the response header is true.

9. The device according to claim 6, characterized in that The second identification unit is specifically configured to determine that the request message contains CORS vulnerability detection and exploitation behavior when the value of the origin field does not exist or is not alive, or when the value of the origin field exists and does not conform to a set format; When the value of the origin field conforms to the set format, the value of the origin field is matched with the value of the origin field of the malicious intelligence recorded in the intelligence library; When the match is successful, it is determined that the request message contains CORS vulnerability detection and exploitation behavior; when the match is unsuccessful, feature extraction is performed on the origin field to obtain the feature to be detected; based on the feature to be detected and a pre-trained CORS vulnerability identification model, it is identified whether the request message contains CORS vulnerability detection and exploitation behavior.

10. The device according to claim 9, characterized in that The CORS vulnerability identification model is obtained by training a bidirectional long short-term memory model using training samples; the training samples include sample features obtained by extracting features from the origin field in each request message sample sent from the client to the server within a set time period; The second identification unit is specifically used to input the feature to be detected into the CORS vulnerability identification model; when the identification result output by the CORS vulnerability identification model meets the CORS vulnerability identification condition, it is identified that the request message contains CORS vulnerability detection and exploitation behavior.

Images