Method and device for batch automatic detection of SSRF vulnerabilities, storage medium and electronic equipment

Abstract

The application relates to an SSRF vulnerability batch automatic detection method and device, a storage medium and electronic equipment, wherein the method comprises the following steps: acquiring interface information of each API interface of a web system; determining interface requests corresponding to each API interface according to each interface information; judging whether a target field exists in each interface request, if the target field exists, assigning a preset SSRF vulnerability detection link to the target field in the corresponding interface request, and performing batch packet sending on each target interface request with the target field, wherein the target field is a detection field of an SSRF vulnerability; detecting whether a DNSLOG platform corresponding to the SSRF vulnerability detection link receives a DNS resolution request record, if yes, determining that an API interface corresponding to the DNS resolution request record has an SSRF vulnerability. The application has the effect of improving the efficiency of SSRF vulnerability detection.

Description

Technical Field

[0001] This application relates to the field of vulnerability detection technology, specifically to a method, apparatus, storage medium, and electronic device for batch automated detection of SSRF vulnerabilities. Background Technology

[0002] Server-Side Request Forgery (SSRF) is a security vulnerability where an attacker can construct a request that forces the server to initiate the attack. This vulnerability allows an attacker to create a request containing a malicious Uniform Resource Locator (URL) link, thereby attacking both the internal and external networks of a web system's server. In short, by exploiting this vulnerability, an attacker can impersonate the server and bypass external network security measures to send a crafted request to the server's internal network, causing significant damage to internal network services. Therefore, detecting SSRF vulnerabilities is essential.

[0003] Currently, the detection of SSRF vulnerabilities in web systems mainly relies on manual detection because SSRF vulnerabilities can be either echoed or not. However, when manually detecting a large number of API interfaces, the efficiency of SSRF vulnerability detection becomes low. Summary of the Invention

[0004] To improve the efficiency of SSRF vulnerability detection, this application provides a method, apparatus, storage medium, and electronic device for batch automated SSRF vulnerability detection.

[0005] The first aspect of this application provides a method for automated batch detection of SSRF vulnerabilities, which specifically includes: obtaining interface information of each API interface of a web system; Based on the interface information, determine the interface request corresponding to each API interface; Determine whether a target field exists in each of the aforementioned interface requests. If it does, assign the preset SSRF vulnerability detection link to the target field in the corresponding interface request, and send batch packets to each target interface request that contains the target field. The target field is the detection field for the SSRF vulnerability. The system checks whether the DNSLOG platform corresponding to the SSRF vulnerability detection link has received a DNS resolution request record. If so, it determines that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

[0006] By adopting the above technical solution, the interface requests corresponding to each API interface are determined based on the interface information. Then, each interface request is iterated through. If a target field exists in the interface request, it indicates that the interface request may have an SSRF vulnerability and requires SSRF vulnerability detection. A pre-set SSRF vulnerability detection link is then assigned to the target field in this interface request. After the target field is assigned, batch packets are sent to each target interface request containing the target field, thereby accessing the corresponding API interface. Finally, if the DNSLOG platform receives a DNS resolution request record, it indicates that the API interface corresponding to each target interface request has an SSRF vulnerability. Therefore, the API interface corresponding to the DNS resolution request record is ultimately confirmed to have an SSRF vulnerability. This allows for batch SSRF vulnerability detection of multiple API interfaces without manual inspection, improving the efficiency of SSRF vulnerability detection.

[0007] Optionally, determining the interface request corresponding to each API interface based on the interface information specifically includes: The interface information is formatted to obtain the processed information. The pre-defined method is invoked to classify the processed information into interfaces, thereby obtaining the encapsulated interface requests corresponding to each API interface.

[0008] By employing the above technical solution, the interface information corresponding to each API interface is formatted to obtain processed information, which helps the subsequent encapsulated requests to be correctly parsed and executed. Then, a pre-defined method is used to classify the interfaces based on the processed information, generating encapsulated interface requests with a unified standard HTTP request format. This facilitates subsequent screening of SSRF vulnerability detection fields in the interface requests.

[0009] Optionally, after determining the interface request corresponding to each API interface based on the interface information, the method further includes: Query the body of each of the aforementioned interface requests, and filter the fields to be processed in each of the aforementioned body that are consistent with the preset sensitive fields using regular expressions; Delete the field value corresponding to the field to be processed, and reassign the field to be processed; Determine whether there are any preset common fields in the interface request where the body was not found. If they exist, assign values ​​to each of the preset common fields in the JSON table and reassign them. If it does not exist, then a random value will be assigned to the field type provided by Swagger in the web system.

[0010] By employing the above technical solution, API requests with a body are filtered out. Regular expressions are then used to identify fields in the body that match sensitive fields and are therefore designated for processing. Since these sensitive fields involve privacy information, they are reassigned to prevent privacy leaks while ensuring the API requests can still access the interface. Next, API requests without a body are filtered for common fields. Existing common fields are then reassigned according to their corresponding values ​​in the JSON table. Finally, for API requests without common fields, random values ​​are assigned to fields provided by Swagger. This process avoids privacy leaks while ensuring the API requests can still access the interface.

[0011] Optionally, the request type is a GET request or a POST request, and determining whether a target field exists in each of the interface requests specifically includes: Determine the request type for each of the aforementioned interfaces; If the request type is a GET request, then check whether the value of the api_requestURL field of the corresponding interface request is a URL link; If it is a URL link, then the existence of a target field is confirmed, and the api_requestURL field is determined as the target field; If the request type is a POST request, then check whether the value of the requestData field of the corresponding interface request is a URL link; If it is a URL link, then the existence of a target field is determined, and the requestData field is identified as the target field.

[0012] By adopting the above technical solution, if the interface request is a GET request, the `api_requestURL` field in the request is located, eliminating the need to traverse all fields and improving vulnerability detection efficiency. Next, it is determined whether a URL link exists in the `api_requestURL` field. If it does, the interface request may have an SSRF vulnerability and should be listed as a detection field, i.e., a target field exists. If the interface request is a POST request, the `requestData` field is located. If a URL link exists in the `requestData` field, the interface request may have an SSRF vulnerability, i.e., a target field exists. This method efficiently determines whether a target field exists in the interface request.

[0013] Optionally, before determining whether the target field exists in each of the interface requests, the method further includes: Generate random characters, and select a preset number of target characters from the random characters; Obtain the domain name of the established DNSLOG platform, and generate an SSRF vulnerability detection link based on the target characters and the domain name, wherein the SSRF vulnerability detection link includes the domain name.

[0014] By adopting the above technical solution, the target characters and the domain name of the DNSLOG platform are combined to generate an SSRF vulnerability detection link. That is, a maliciously constructed URL link is simulated and assigned to the target field of an interface request that may have an SSRF vulnerability, which can effectively detect the vulnerability of the corresponding API interface.

[0015] Optionally, the step of sending batch packets for each target interface request containing the target field specifically includes: The predefined requests module is encapsulated into a predefined request sending function to obtain the encapsulated requests module. The encapsulated requests module is invoked to send batch packets for each target interface request that contains the target field.

[0016] By adopting the above technical solution, the requests module is encapsulated into a request packet sending function, which facilitates quick request packet sending. Requests from various target interfaces are directly uploaded to the encapsulated requests module, which can then batch and quickly send packets to the target interfaces, thereby improving the speed of request packet sending.

[0017] Optionally, the step of detecting whether the DNSLOG platform corresponding to the SSRF vulnerability detection link has received a DNS resolution request record, and if so, determining that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability, specifically includes: Call the interface of the DNSLOG platform to query whether there are DNS resolution request records corresponding to the packet data of each target interface request in the DNSLOG platform; If so, then it is determined that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

[0018] By adopting the above technical solution, after each target interface requests to send packets in batches, the interface of the DNSLOG platform is called to obtain the DNS resolution request records received by the DNSLOG platform. If there is a DNS resolution request record corresponding to the packet data requested by the target interface, it means that the target interface requests access to the corresponding SSRF vulnerability detection link, which in turn indicates that the corresponding API interface has an SSRF vulnerability, thereby achieving efficient and accurate SSRF vulnerability detection of the API interface.

[0019] A second aspect of this application provides an automated batch detection device for SSRF vulnerabilities, specifically comprising: The information acquisition module is used to acquire interface information of each API interface of the web system; The request determination module is used to determine the interface request corresponding to each API interface based on the interface information. The request packet sending module is used to determine whether a target field exists in each of the interface requests. If it exists, the module assigns a preset SSRF vulnerability detection link to the target field in the corresponding interface request and sends packets in batches to each target interface request that has the target field. The target field is the detection field for SSRF vulnerabilities. The vulnerability detection module is used to detect whether the DNSLOG platform corresponding to the SSRF vulnerability detection link has received a DNS resolution request record. If so, it is determined that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

[0020] By adopting the above technical solution, after the information acquisition module obtains the interface information of each API interface, the request determination module determines the interface request corresponding to each API interface based on the interface information. Then, the request packet sending module assigns the SSRF vulnerability detection link to the target field in each target interface request and sends packets to each target interface request in batches. Finally, the vulnerability detection module determines whether the DNSLOG platform has received the DNS resolution request record. If it has, it is determined that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

[0021] In summary, this application includes at least one of the following beneficial technical effects: Based on the interface information, the corresponding interface requests for each API interface are determined. Then, each interface request is iterated through. If a target field exists in the interface request, it indicates a potential SSRF vulnerability, requiring SSRF vulnerability detection. A pre-defined SSRF vulnerability detection link is then assigned to the target field in this interface request. After the target field assignment, batch packets are sent to all target interface requests containing the target field, thereby accessing the corresponding API interfaces. Finally, if the DNSLOG platform receives a DNS resolution request record, it indicates that the API interface corresponding to each target interface request has an SSRF vulnerability. Therefore, the API interface corresponding to the DNS resolution request record is ultimately confirmed to have an SSRF vulnerability. This allows for batch SSRF vulnerability detection of multiple API interfaces without manual intervention, improving the efficiency of SSRF vulnerability detection. Attached Figure Description

[0022] Figure 1This is a flowchart illustrating a batch automated detection method for SSRF vulnerabilities provided in an embodiment of this application; Figure 2 This is a flowchart illustrating another automated batch detection method for SSRF vulnerabilities provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an automated batch detection device for SSRF vulnerabilities provided in an embodiment of this application; Figure 4 This is a schematic diagram of another automated batch detection device for SSRF vulnerabilities provided in an embodiment of this application.

[0023] Explanation of reference numerals in the attached diagram: 11. Information acquisition module; 12. Request confirmation module; 13. Request packet sending module; 14. Vulnerability detection module. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0025] In the description of the embodiments in this application, words such as "illustrative," "for example," or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "illustrative," "for example," or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "illustrative," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0026] In the description of the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, B existing alone, or A and B existing simultaneously. Furthermore, unless otherwise stated, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0027] The SSRF vulnerability batch automated detection method disclosed in this application can be understood as a specific Python script tool, the execution subject of which is a terminal, which can be an electronic device such as a mobile phone, tablet computer, e-book reader, multimedia playback device, wearable device, PC (Personal Computer).

[0028] See Figure 1 This application discloses a flowchart of a method for automated batch detection of SSRF vulnerabilities, which can be implemented using a computer program or run on an automated batch detection device for SSRF vulnerabilities based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application, specifically including: S101: Obtain the interface information of each API interface of the web system.

[0029] Specifically, an Application Programming Interface (API) allows communication and data exchange between different applications or systems. APIs are designed to enable developers to create and modify applications more quickly, while ensuring interoperability between these applications. From the perspective of the network usage environment, a web system refers to the websites we normally see when browsing the internet using a browser.

[0030] One feasible way to obtain interface information is to use a Python web crawler to crawl the Swagger library corresponding to the web system and obtain the interface information of each API interface of the web system. In this embodiment, the Python crawler can be the Python requests library or the BeautifulSoup library. In other embodiments, the Python crawler can be the urllib library. Furthermore, Swagger is a standardized and complete framework for generating, describing, invoking, and visualizing RESTful web services. Swagger can clearly describe the data transmission process and the entire interaction flow of the API interface, enabling developers to better understand and use the interface, and it primarily defines interfaces using XML or JSON format.

[0031] Furthermore, when crawling Swagger, the process first locates the Swagger URL, then sends an HTTP request to retrieve the API definitions. The API definitions are typically returned in JSON or YAML format, which is then parsed to extract the API information for each API interface. This is existing technology and will not be elaborated upon here. It should be noted that the API information is JSON data, i.e., data in JSON format.

[0032] S102: Based on the information of each interface, determine the interface request corresponding to each API interface.

[0033] In one feasible implementation, the interface information is formatted to obtain processed information; The pre-defined method is invoked to classify the processed information into interfaces, resulting in the encapsulated interface requests corresponding to each API interface.

[0034] Specifically, after obtaining the interface information for each API interface, the JSON data in the interface information is formatted using a pre-built json module in Python to obtain processed information. This clarifies the interface address, request method, parameters, and data format of each API interface, helping the encapsulated request to be correctly parsed and executed. In other embodiments, a pre-built JSON Formatter tool can also be used to format the JSON data in the interface information.

[0035] Next, the pre-defined `method` method is invoked to categorize the processed information into API types. This categorization refers to classifying APIs by request method, such as GET, POST, and PUT. GET APIs correspond to GET request methods, POST APIs to POST request methods, and PUT APIs to PUT request methods, etc. Furthermore, the `method` method pre-encapsulates GET, POST, and PUT request methods. Finally, based on the request address, request method, and request headers of each API interface, the `method` method generates a standard HTTP request format for each API interface—the encapsulated API request. A GET request is a method in the HTTP protocol used to retrieve data from the server. A POST request is used to submit data to the server.

[0036] For example, a certain interface request may take the following form: {"service":"xxx-bff-xxx","service_summary":"xxx platform","api_summary":"xxx cooperation drill-down","api_requestURL":"https: / / xxx.xxx.com / xxx-bff-xxx / demo / list","method":"post","headers": {"xxxToken":"222222222222","xxxsignature":"222222222222"},"consumes":"application / json","requestData": {"xxx_id":"","current": 1,"pagesize": 10,"xxx_list":"","province":"xx province","searchname":""}} As can be seen, the API request includes: "api_requestURL" represents the request address, "method" represents the request method (GET or POST), "headers" represents the request headers, "requestData" represents the POST request parameters, "consumes" represents the supported media types, etc.

[0037] S103: Determine whether a target field exists in each interface request. If it does, assign the pre-set SSRF vulnerability detection link to the target field in the corresponding interface request, and send batch packets to each target interface request that has a target field. The target field is the SSRF vulnerability detection field.

[0038] Specifically, as shown in step S102, each interface request contains different fields and corresponding field values. Therefore, after the interface requests corresponding to each API interface are determined, the preset fields in all API interface requests are traversed, and it is determined whether there is a URL link in the preset fields, that is, whether the field value of the preset field is a URL link. One feasible way to determine this is to use regular expressions to determine whether there is a URL link. The preset fields are fields that may have SSRF vulnerabilities. In this embodiment, the preset fields are some or all of the fields "url", "URL", and "Url". In other embodiments, they may be some or all of the fields such as "wap", "http", "share", "link", "src", "source", "target", "display", "sourceURL", "imageURL", and "domain". It should be noted that the preset fields are more likely to contain URL links than other fields. Therefore, in this embodiment, the method of traversing the preset fields is used to make the determination of the target field more efficient. In other embodiments, each field in each interface request can also be traversed to determine whether a preset field exists.

[0039] If a pre-defined field in an API request contains a URL link, it indicates that this pre-defined field is a potential SSRF vulnerability detection field; that is, this pre-defined field could be maliciously linked by an attacker. Therefore, it is determined that this API request contains a target field, and the pre-defined field containing the URL link is the target field. Next, the pre-defined SSRF vulnerability detection link is assigned to the target field of this API request, thereby performing SSRF vulnerability detection on the corresponding API.

[0040] In summary, determining whether a target field exists in each API request involves: traversing the preset fields in the API request corresponding to each API interface, and determining whether a URL link exists in the preset fields. If it exists, the corresponding API request is determined to have a target field, and the preset field with the URL link is the target field.

[0041] The SSRF vulnerability detection link is the Proof-of-Concept (POC) data for an SSRF vulnerability, which can be used for vulnerability detection. A POC is typically an incomplete piece of code used to check if a target host has a corresponding vulnerability; it possesses randomness, universality, and determinism. By sending the POC code or data to the target, the existence of the vulnerability is determined by the specific information returned by the target. Because the POC is written based on vulnerability reproduction, the key characteristics of the vulnerability are understood through reproduction, and the conditions for vulnerability existence are determined based on these characteristics. It should be noted that the SSRF vulnerability detection link assigned to each target interface request is different; in other embodiments, the SSRF vulnerability detection link assigned to each target interface request is the same.

[0042] In one feasible implementation, batch packet sending is performed on each target interface request containing the target field, specifically including: The predefined requests module is encapsulated into a predefined request sending function to obtain the encapsulated requests module. The encapsulated requests module is invoked to send batch packets for each target interface request that contains a target field.

[0043] The `requests` module is for network access. It helps us send HTTP requests to retrieve web page content, and can send both GET and POST requests. By encapsulating the predefined `requests` module into a predefined request sending function, we obtain the encapsulated `requests` module, which is convenient for reuse and easy to call in the code. The predefined request sending function is `send_request`, but in other embodiments, it can also be `requests.get` or `requests.post`. The request sending function is typically used to send HTTP requests in batches to improve data transmission efficiency.

[0044] The API request that links to the SSRF vulnerability detection link is identified as the target API request. The encapsulated requests module is then invoked, sending the target API request to it. The encapsulated requests module then sends the corresponding HTTP request based on the request method carried in each target API request; that is, it sends packets for each target API request in batches. It should be noted that HTTP requests include GET, POST, and PUT requests, etc. When the request method is a GET request, the corresponding HTTP request is a GET request.

[0045] In another feasible implementation, before step S103, the method further includes: generating random characters and selecting a preset number of target characters from the random characters; Obtain the domain name of the established DNSLOG platform, and generate an SSRF vulnerability detection link based on the target characters and the domain name. The SSRF vulnerability detection link includes the domain name.

[0046] Specifically, random characters are generated using pre-defined Python code, which is as follows: `ssrf_character = ''.join(random.choice(string.ascii_letters + string.digits) for _in range(10)).lower()timestamp = int(time.time())`. Then, a preset number of target characters are selected from the random characters. In this embodiment, the preset number can be 6 characters, and in other embodiments, it can be 10 characters.

[0047] The DNSLOG platform is used to parse DNS log data to discover potential attack vectors. DNSLOG utilizes DNS resolution logs, which store domain name information on DNS servers, recording user access information to domains. In simple terms, an attacker registers a domain name, binds it to a server with a specific IP address, and sets up wildcard DNS. When the victim machine accesses any subdomain of this domain, the attacker's server receives the request and records the DNS resolution.

[0048] Furthermore, the DNSLOG platform setup process can be summarized as follows: purchase a domain name, such as xxx.com, and a server; then, use the domain name and server to set up the DNSLOG platform. This is existing technology and will not be elaborated further here.

[0049] Finally, based on the domain name and target characters of the DNSLOG platform, several SSRF vulnerability detection links are generated. One feasible generation method is to use the pre-installed BurpSuite tool to generate SSRF vulnerability detection links containing the domain name and target characters.

[0050] For example, the final generated SSRF vulnerability detection link can be as follows: http: / / imlpxegpma168509.xxx.com / ssrf.html http: / / e7j044xmwb168509.xxx.com / ssrf.html http: / / 5vrafolvd0168509.xxx.com / ssrf.html http: / / y86eyhp1xg168509.xxx.com / ssrf.html http: / / 1a0mesual7168509.xxx.com / ssrf.html http: / / u2kuwbi8ye168509.xxx.com / ssrf.html......etc.

[0051] The domains "imlpxegpma168509.xxx.com" and "e7j044xmwb168509.xxx.com" are subdomains of the DNSLOG platform's domain. When these subdomains are accessed, they are resolved by the DNS server, and the DNSLOG platform receives DNS resolution records. Domain name resolution is the process of converting a domain name to an IP address, and this resolution is handled by the DNS server. This is existing technology and will not be elaborated upon further.

[0052] It should be noted that in other embodiments, the SSRF vulnerability detection link can also be a modified SSRF vulnerability POC data, and the final SSRF vulnerability detection link can be as follows: http: / / aaa.com@rnpaejpqhh168509.xxx.com / ssrf.html http: / / aaa.com@nhj1w5vvsr168509.xxx.com / ssrf.html http: / / aaa.com@vgufq0msks168509.xxx.com / ssrf.html http: / / hzupytrjzi168509.xxx.com?aaa.com / ssrf.html http: / / 15qvn6y7te168509.xxx.com?aaa.com / ssrf.html http: / / zik7080500168509.xxx.com?aaa.com / ssrf.html http: / / s117z3hpqr168509.aaa.com.xxx.com / ssrf.html...... S104: Check whether the DNSLOG platform corresponding to the SSRF vulnerability detection link has received a DNS resolution request record. If so, it is determined that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

[0053] In one feasible implementation, the interface of the DNSLOG platform is called to query whether there are DNS resolution request records corresponding to the packet data of each target interface request in the DNSLOG platform. If so, then the API interface corresponding to the DNS resolution request record is found to have an SSRF vulnerability.

[0054] Specifically, after sending batch packets for each target interface request, the API interface of the DNSLOG platform is called to obtain the DNS resolution request records received by the DNSLOG platform. These DNS resolution request records are system log records used to resolve domain names to IP addresses. These records contain information about the DNS query, such as the domain name address, resolution type, and request time. Next, the system checks if any DNS resolution request records exist that correspond to the packet data of each target interface request. One possible query method is: if the domain name address contained in the DNS resolution request record matches the address in the SSRF vulnerability detection link assigned in the target interface request, then it is determined that the DNSLOG platform contains a DNS resolution request record corresponding to the packet data of this target interface request.

[0055] If it exists, it means that this target interface request can request access to the SSRF vulnerability detection link (a simulated malicious URL link), thus confirming that the API interface corresponding to this target interface request has an SSRF vulnerability. This is because if this target interface request did not have an SSRF vulnerability, an attacker would not be able to exploit the SSRF vulnerability to send requests to malicious URL links.

[0056] For example, consider target API request A, whose target field contains an SSRF vulnerability detection link: http: / / imlpxegpma168509.xxx.com / ssrf.html. Target API request B contains an SSRF vulnerability detection link: http: / / e7j044xmwb168509.xxx.com / ssrf.html.

[0057] If the DNSLOG platform receives two DNS resolution request records at this time, the first one is: domain name address: imlpxegpma168509.xxx.com / ssrf.html, IP: 183.36.XX.Y, request time: 2023-06-01; The second record contains the following information: Domain name: e7j044xmwb168509.xxx.com / ssrf.html, IP address: 183.36.Xb.c, and request time: 2023-06-01. The address in the SSRF vulnerability detection link for target API request A matches the domain name address in the first DNS resolution request record. Similarly, the address in the SSRF vulnerability detection link for target API request B matches the domain name address in the second DNS resolution request record. Therefore, the API interfaces corresponding to target API requests A and B are vulnerable to SSRF attacks.

[0058] See Figure 2 This application discloses a flowchart of another automated batch detection method for SSRF vulnerabilities, which can be implemented using a computer program or run on an automated batch detection device for SSRF vulnerabilities based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application, specifically including: S201: Obtain interface information for each API interface of the web system. S202: Based on the information of each interface, determine the interface request corresponding to each API interface.

[0059] In one feasible implementation, after step S202, the method further includes: querying the body corresponding to each interface request, and filtering the fields to be processed in each body that are consistent with the preset sensitive fields using regular expressions; Delete the field value corresponding to the field to be processed, and reassign the field to be processed; Determine whether the predefined common fields exist in the interface request where the body was not found. If they exist, assign values ​​to the JSON table based on the predefined common fields and reassign the values ​​to each common field. If it does not exist, then a random value will be assigned to the field type provided by Swagger in the web system.

[0060] Specifically, after determining the corresponding API request for each API interface, the system checks the Alibaba Cloud platform for the existence of a request body using the request URL in the request. The request body consists of the content, parameters, and data of the API request. Furthermore, GET requests typically do not require a body because they are only used to retrieve resources, not to submit data. POST requests, on the other hand, usually require a body to submit data. Common body formats include JSON, XML, and form data.

[0061] The process involves filtering out API requests with body fields and then filtering the corresponding body fields for sensitive fields. A preset sensitive field is the ID card field, which involves privacy information. In other embodiments, it could also be a birth date field, etc. One feasible filtering method is to use regular expressions to filter out fields in the body that match the sensitive fields, delete the field values, and reassign them. The reassigned field values ​​protect privacy information while ensuring normal API access. The reassigned field values ​​can be selected from a preset field value table, including values ​​such as 420117XXXXXXXXXXXX, 420112XXXXXXXXXXXX, etc. It should be noted that regular expressions are a powerful text processing tool that can be used for field filtering. This is existing technology and will not be elaborated further.

[0062] Next, it checks whether the interface request without a body contains common fields. These common fields are "size" and "name" (in other embodiments, "phone" could also be used). If they exist, these common fields are reassigned. One possible reassignment method is to call a preset common field assignment JSON table and match the corresponding field values ​​from the table. The common field assignment JSON table includes different common fields and their corresponding values.

[0063] For example, the general field assignments to the JSON table are as follows: {"id": 22222, "name":"xxxxxx", "cityCode": 440300, "countyCode": 440307, "provinceCode": 440000, "phone":"130xxxxxxxx",} Since each API request is determined based on the API information provided by Swagger, if no common fields exist, then fields from the API information provided by Swagger for that API are randomly assigned values. For example, if the API request for API M does not have a body and also does not have common fields, then fields of type "str" ​​and "int" from the API information provided by Swagger for API M are randomly assigned values. The "str" ​​field is reassigned to "sss", and the "int" field is reassigned to 89.

[0064] S203: Determine the request type for each interface request.

[0065] S204: If the request type is a GET request, then determine whether the value of the api_requestURL field of the corresponding interface request is a URL link.

[0066] S205: If it is a URL link, then the existence of a target field is confirmed, and the api_requestURL field is determined as the target field.

[0067] Specifically, if the "method" field in the API request is valued as GET, then the request type is determined to be a GET request. The "api_requestURL" field, representing the request address, is then directly examined. If the value is a URL, it indicates a potential SSRF vulnerability, and this "api_requestURL" field is identified as the target field for subsequent SSRF vulnerability detection of the corresponding API. Conversely, if it is not a URL, the process continues to the next API request.

[0068] S206: If the request type is a POST request, then determine whether the value of the requestData field of the corresponding interface request is a URL link.

[0069] S207: If it is a URL link, then the existence of a target field is confirmed, and the requestData field is identified as the target field.

[0070] Specifically, if the value of the "method" field in the interface request is POST, then the request type of this interface request is determined to be a POST request. Then, the value of the "requestData" field in this interface request is directly filtered out. The "requestData" field represents the parameters of the POST request. If the field value is a URL link, it means that this field may have an SSRF vulnerability. Therefore, this "requestData" field is identified as the target field, which facilitates the subsequent SSRF vulnerability detection of the API interface corresponding to this interface request.

[0071] S208: If it exists, the pre-set SSRF vulnerability detection link will be assigned to the target field in the corresponding interface request, and batch packets will be sent to each target interface request that has the target field.

[0072] S209: Check whether the DNSLOG platform corresponding to the SSRF vulnerability detection link has received a DNS resolution request record. If so, determine that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

[0073] For details, please refer to steps S103-S104, which will not be repeated here.

[0074] In another feasible implementation, after identifying the API interface with the SSRF vulnerability, a corresponding SSRF vulnerability detection report is generated. One feasible generation method is to generate the SSRF vulnerability detection report in HTML format. The fields written in the SSRF vulnerability detection report include: the address description of the API interface with the SSRF vulnerability, the SSRF vulnerability description, the "URL" field, the "Request" field, the pre-set SSRF vulnerability remediation suggestions, and the corresponding SRF vulnerability POC data.

[0075] The implementation principle of the automated batch SSRF vulnerability detection method in this application is as follows: Based on the interface information, determine the interface requests corresponding to each API interface. Then, iterate through each interface request. If a target field exists in the interface request, it indicates that the interface request may have an SSRF vulnerability and requires SSRF vulnerability detection. In this case, assign a pre-set SSRF vulnerability detection link to the target field in the interface request. After the target field is assigned, batch packets are sent to each target interface request containing the target field, thereby accessing the corresponding API interface. Finally, if the DNSLOG platform receives a DNS resolution request record, it indicates that the API interface corresponding to each target interface request has an SSRF vulnerability. Therefore, the API interface corresponding to the DNS resolution request record is ultimately determined to have an SSRF vulnerability. This allows for batch SSRF vulnerability detection of multiple API interfaces without manual detection, improving the efficiency of SSRF vulnerability detection.

[0076] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0077] Please see Figure 3 This is a schematic diagram of the structure of the automated batch detection device for SSRF vulnerabilities provided in this application embodiment. This automated batch detection device for SSRF vulnerabilities can be implemented as all or part of the device through software, hardware, or a combination of both. The device 1 includes an information acquisition module 11, a request determination module 12, a request packet sending module 13, and a vulnerability detection module 14.

[0078] Information acquisition module 11 is used to acquire interface information of each API interface of the web system; The request determination module 12 is used to determine the interface request corresponding to each API interface based on the interface information. The request packet sending module 13 is used to determine whether there is a target field in each interface request. If there is, the preset SSRF vulnerability detection link is assigned to the target field in the corresponding interface request, and batch packets are sent to each target interface request that has a target field. The target field is the SSRF vulnerability detection field. The vulnerability detection module 14 is used to detect whether the DNSLOG platform corresponding to the SSRF vulnerability detection link has received a DNS resolution request record. If so, it is determined that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

[0079] Optionally, request confirmation module 12, specifically used for: The information from each interface is formatted to obtain the processed information; The pre-defined method is invoked to classify the processed information into interfaces, resulting in the encapsulated interface requests corresponding to each API interface.

[0080] Optional, such as Figure 4 As shown, device 1 also includes a reassignment module 15, specifically used for: Query the body of each interface request and filter the fields in each body that match the preset sensitive fields using regular expressions. Delete the field value corresponding to the field to be processed, and reassign the field to be processed; Determine whether the predefined common fields exist in the interface request where the body was not found. If they exist, assign values ​​to the JSON table based on the predefined common fields and reassign the values ​​to each common field. If it does not exist, then a random value will be assigned to the field type provided by Swagger in the web system.

[0081] Optionally, request packet sending module 13, specifically used for: Determine the request type for each interface request; If the request type is a GET request, then check whether the value of the api_requestURL field of the corresponding interface request is a URL link; If it is a URL link, then the existence of a target field is confirmed, and the api_requestURL field is determined as the target field; If the request type is a POST request, then check whether the value of the requestData field of the corresponding interface request is a URL link; If it is a URL link, then the target field is determined to exist, and the requestData field is identified as the target field.

[0082] Optionally, device 1 also includes a link generation module 16, specifically used for: Generate random characters, and select a preset number of target characters from the random characters; Obtain the domain name of the established DNSLOG platform, and generate an SSRF vulnerability detection link based on the target characters and the domain name. The SSRF vulnerability detection link includes the domain name.

[0083] Optionally, the request packet sending module 13 is also used for: The predefined requests module is encapsulated into a predefined request sending function to obtain the encapsulated requests module. The encapsulated requests module is invoked to send batch packets for each target interface request that contains a target field.

[0084] Optional, vulnerability detection module 14, specifically used for: Call the DNSLOG platform's interface to query whether there are DNS resolution request records in the DNSLOG platform corresponding to the packet data of each target interface request; If so, then the API interface corresponding to the DNS resolution request record is found to have an SSRF vulnerability.

[0085] It should be noted that the above-described automated batch detection device for SSRF vulnerabilities, when executing the automated batch detection method for SSRF vulnerabilities, is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the automated batch detection device for SSRF vulnerabilities and the automated batch detection method embodiment provided above belong to the same concept, and their implementation process is detailed in the method embodiment, which will not be repeated here.

[0086] This application also discloses a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it employs a batch automated detection method for SSRF vulnerabilities as described in the above embodiments.

[0087] The computer program can be stored in a computer-readable medium. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or certain middleware. The computer-readable medium includes any entity or device capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the computer-readable medium includes, but is not limited to, the above-mentioned components.

[0088] The above-described SSRF vulnerability batch automated detection method is stored in the computer-readable storage medium and loaded and executed on the processor to facilitate the storage and application of the method.

[0089] This application also discloses an electronic device in which a computer program is stored in a computer-readable storage medium. When the computer program is loaded and executed by a processor, the above-mentioned automated batch detection method for SSRF vulnerabilities is used.

[0090] The electronic device can be a desktop computer, a laptop computer, or a cloud server, and the electronic device includes, but is not limited to, a processor and a memory. For example, the electronic device may also include input / output devices, network access devices, and buses.

[0091] The processor can be a central processing unit (CPU). Of course, depending on the actual use, it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc., and this application does not limit it.

[0092] The memory can be an internal storage unit of an electronic device, such as a hard disk or RAM, or an external storage device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD), or flash memory card (FC) equipped on the electronic device. Furthermore, the memory can be a combination of an internal storage unit and an external storage device. The memory is used to store computer programs and other programs and data required by the electronic device. The memory can also be used to temporarily store data that has been output or will be output. This application does not limit this.

[0093] In this electronic device, the SSRF vulnerability batch automated detection method of the above embodiment is stored in the memory of the electronic device and loaded and executed on the processor of the electronic device for convenient use.

[0094] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for automated batch detection of SSRF vulnerabilities, characterized in that, The method includes: Obtain the interface information of each API interface of the web system; the API interface is an application programming interface. Based on the interface information, determine the interface request corresponding to each API interface; Determining whether a target field exists in each of the aforementioned interface requests includes: traversing the preset fields in the interface request corresponding to each API interface, and determining whether a URL link exists in the preset fields. If it exists, the preset field with the URL link is taken as the target field; assigning a preset SSRF vulnerability detection link to the target field in the corresponding interface request, and sending batch packets to each target interface request containing the target field, wherein the target field is the SSRF vulnerability detection field; and the SSRF vulnerability is a server-side request forgery vulnerability. The process of detecting whether the DNSLOG platform corresponding to the SSRF vulnerability detection link has received a DNS resolution request record includes: calling the interface of the DNSLOG platform to obtain the DNS resolution request record received by the DNSLOG platform; when the domain name address contained in the DNS resolution request record is consistent with the address in the SSRF vulnerability detection link, it is determined that there is a corresponding DNS resolution request record in the DNSLOG platform; if so, it is determined that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability; the DNS resolution request record is a system log record used to resolve domain names to IP addresses, and the DNSLOG platform is used to parse DNS log data to discover potential attack vectors.

2. The SSRF vulnerability batch automated detection method according to claim 1, characterized in that, The step of determining the interface request corresponding to each API interface based on the interface information specifically includes: The interface information is formatted to obtain the processed information. The pre-defined method is invoked to classify the processed information into interfaces, thereby obtaining the encapsulated interface requests corresponding to each API interface.

3. The SSRF vulnerability batch automated detection method according to claim 1, characterized in that, After determining the interface request corresponding to each API interface based on the interface information, the method further includes: Query the body of each of the aforementioned interface requests, and filter the fields to be processed in each of the aforementioned body that are consistent with the preset sensitive fields using regular expressions; Delete the field value corresponding to the field to be processed, and reassign the field to be processed; Determine whether there are any preset common fields in the interface request where the body was not found. If they exist, assign values ​​to each of the preset common fields in the JSON table and reassign them. If it does not exist, a random value will be assigned to the field type provided by Swagger for the web system; Swagger is a specification and complete framework for generating, describing, calling and visualizing RESTful web services.

4. The SSRF vulnerability batch automated detection method according to claim 1, characterized in that, The request type of the interface request is either a GET request or a POST request. The determination of whether a target field exists in each of the interface requests specifically includes: Determine the request type for each of the aforementioned interfaces; If the request type is a GET request, then check whether the value of the api_requestURL field of the corresponding interface request is a URL link; If it is a URL link, then the existence of a target field is confirmed, and the api_requestURL field is determined as the target field; If the request type is a POST request, then check whether the value of the requestData field of the corresponding interface request is a URL link; If it is a URL link, then the existence of a target field is determined, and the requestData field is identified as the target field.

5. The SSRF vulnerability batch automated detection method according to claim 1, characterized in that, Before determining whether the target field exists in each of the interface requests, the method further includes: Generate random characters, and select a preset number of target characters from the random characters; Obtain the domain name of the established DNSLOG platform, and generate an SSRF vulnerability detection link based on the target characters and the domain name, wherein the SSRF vulnerability detection link includes the domain name.

6. The SSRF vulnerability batch automated detection method according to claim 1, characterized in that, The step of sending batch packets for each target interface request containing the target field specifically includes: The predefined requests module is encapsulated into a predefined request sending function to obtain the encapsulated requests module; the requests module is a module used for network access. The encapsulated requests module is invoked to send batch packets for each target interface request that contains the target field.

7. A batch automated detection device for SSRF vulnerabilities, used to implement the batch automated detection method for SSRF vulnerabilities according to any one of claims 1 to 6, characterized in that, The automated batch detection device for SSRF vulnerabilities includes: The information acquisition module (11) is used to acquire the interface information of each API interface of the web system; the API interface is an application programming interface. The request determination module (12) is connected to the information acquisition module (11) and is used to determine the interface request corresponding to each API interface based on the interface information. The request packet sending module (13), connected to the request determination module (12), is used to traverse the preset fields in the interface request corresponding to each API interface and determine whether there is a URL link in the preset fields. The preset fields with URL links are used as target fields. The preset SSRF vulnerability detection link is assigned to the target field in the corresponding interface request, and the target interface requests with the target field are sent in batches. The target field is the detection field of the SSRF vulnerability. The SSRF vulnerability is a server-side request forgery vulnerability. The vulnerability detection module (14) is connected to the request packet sending module (13) and is used to call the interface of the DNSLOG platform to obtain the DNS resolution request record received by the DNSLOG platform. When the domain name address contained in the DNS resolution request record is consistent with the address in the SSRF vulnerability detection link, it is determined that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is loaded and executed by the processor, the SSRF vulnerability batch automated detection method as described in any one of claims 1-6 is employed.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, When the processor loads and executes the computer program, it employs the SSRF vulnerability batch automated detection method as described in any one of claims 1-6.

Images