CN117118668A

CN117118668A - Automatic batch detection method and device for SSRF vulnerabilities, storage medium and electronic equipment

Info

Publication number: CN117118668A
Application number: CN202310912421.0A
Authority: CN
Inventors: 高文军
Original assignee: Qizhi Technology Co ltd
Current assignee: Qizhi Technology Co ltd
Priority date: 2023-07-21
Filing date: 2023-07-21
Publication date: 2023-11-24

Abstract

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

Description

Automatic batch detection method and device for SSRF vulnerabilities, storage medium and electronic equipment

Technical Field

The application relates to the technical field of vulnerability detection, in particular to an automatic batch detection method and device for SSRF vulnerabilities, a storage medium and electronic equipment.

Background

Server-side request forgery (SSRF) holes are security holes that are used by an attacker to construct a request, letting the Server initiate the request. An attacker can construct requests containing malicious uniform resource locator (Uniform Resource Locator, URL) links with the vulnerability, thereby attacking the server-side internal and external networks of the web system. In short, it is: the loopholes are utilized to send a constructed request to the intranet where the server is located to attack by using the identity of the server side and bypassing the security protection of the external network, so that the damage to the intranet service is extremely large, and therefore, the detection of the SSRF loopholes is very necessary.

At present, for the detection of SSRF vulnerabilities of a web system, because the SSRF vulnerabilities are in two types of redisplay and non-redisplay, the detection mode is mainly manual detection, but when the number of API interfaces is large, the efficiency of SSRF vulnerabilities detection is lower.

Disclosure of Invention

In order to improve the efficiency of SSRF vulnerability detection, the application provides an automatic batch detection method and device for SSRF vulnerabilities, a storage medium and electronic equipment.

In a first aspect of the present application, a method for automatically detecting SSRF vulnerabilities in batches is provided, which specifically includes: acquiring interface information of each API interface of the web system;

Determining interface requests corresponding to the API interfaces according to the interface information;

judging whether a target field exists in each interface request, if so, assigning a preset SSRF vulnerability detection link to the target field in the corresponding interface request, and performing batch package sending on each target interface request with the target field, wherein the target field is a detection field of the SSRF vulnerability;

and detecting whether the DNSLOG platform corresponding to the SSRF vulnerability detection link receives a DNS analysis request record, if so, determining that an API interface corresponding to the DNS analysis request record has an SSRF vulnerability.

By adopting the technical scheme, the interface requests corresponding to all API interfaces are determined according to the interface information, then all the interface requests are traversed, if target fields exist in the interface requests, which indicate that SSRF vulnerabilities are possible in the interface requests, SSRF vulnerability detection is needed, and preset SSRF vulnerability detection links are assigned to the target fields in the interface requests. After the assignment of the target fields is completed, each target interface request with the target fields is subjected to batch package sending, so that the corresponding API interfaces are accessed. Finally, if the DNSLOG platform receives the DNS resolution request records, which indicate that the SSRF vulnerabilities exist in the API interfaces corresponding to the target interface requests, the API interfaces corresponding to the DNS resolution request records are finally determined to be the SSRF vulnerabilities. Therefore, SSRF vulnerability detection can be carried out on a plurality of API interfaces in batches, detection is not needed manually, and SSRF vulnerability detection efficiency is improved.

Optionally, the determining, according to each piece of interface information, an interface request corresponding to each API interface specifically includes:

formatting the interface information to obtain processed information;

and calling a preset method to classify the interfaces of the processed information to obtain the packaged interface requests corresponding to the API interfaces.

By adopting the technical scheme, the interface information corresponding to each API interface is formatted to obtain the processed information, so that the subsequent packaged request can be accurately analyzed and executed. And then, carrying out interface classification on each piece of processed information by adopting a preset method to generate an interface request with a unified standard http request format and after encapsulation. Thereby facilitating subsequent screening of SSRF vulnerability detection fields in the interface request.

Optionally, after determining, according to each piece of interface information, an interface request corresponding to each API interface, the method further includes:

inquiring a body corresponding to each interface request, and screening to-be-processed fields, which are consistent with preset sensitive fields, in each body in a regular mode;

deleting a field value corresponding to the field to be processed, and reassigning the field to be processed;

Judging whether a preset general field exists in an interface request of a body which is not queried, if so, reassigning each general field according to a preset general field assignment json table;

and if not, carrying out random assignment on the field types provided by the swaggers of the web system.

By adopting the technical scheme, the interface request with the body is screened out, the to-be-processed field consistent with the sensitive field in the body is screened out in a regular mode, and the sensitive field relates to the privacy information, so that the to-be-processed field is reassigned, the privacy information is prevented from being revealed, and the interface request can be ensured to normally access the interface. And screening the universal fields of the interface request without the body, and reassigning the existing universal fields according to the corresponding assignment json table of the universal fields. And finally, selecting the field type provided by the swagger to carry out random assignment on the interface request without the universal field, so that privacy information disclosure is avoided, and each interface request can be ensured to normally access the interface.

Optionally, the request type is a GET request or a POST request, and the determining whether a target field exists in each interface request specifically includes:

Determining the request type of each interface request;

judging whether the field value of the api_requestURL field of the corresponding interface request is a URL link or not under the condition that the request type is a GET request;

if the URL is linked, determining that a target field exists, and determining the api_requestURL field as the target field;

judging whether the field value of the requestData field of the corresponding interface request is a URL link or not under the condition that the request type is a POST request;

if the URL is linked, determining that a target field exists, and determining the requestData field as the target field.

By adopting the technical scheme, if the interface request is a GET request, the api_RequestURL field in the interface request is searched, and all fields do not need to be traversed, so that the vulnerability detection efficiency is improved. Then, it is determined whether there is a URL link in the api_requesturl field, and if there is a URL link, it indicates that the interface request may have an SSRF vulnerability, and it needs to be listed as a detection field, that is, a target field exists. If the interface request is a POST request, the requestData field is looked up, and if a URL link exists in the requestData field, this indicates that the interface request may have an SSRF vulnerability, i.e., a target field exists. Thereby more efficiently judging whether the target field exists in the interface request.

Optionally, before determining whether the target field exists in each interface request, the method further includes:

generating random characters, and selecting a preset number of target characters from the random characters;

and obtaining the domain name of the constructed DNSLOG platform, and generating an SSRF vulnerability detection link according to the target character and the domain name, wherein the SSRF vulnerability detection link comprises the domain name.

By adopting the technical scheme, the SSRF vulnerability detection link is generated by combining the target character and the domain name of the DNSLOG platform, namely, the URL link with a malicious structure is simulated, so that assignment is carried out to the target field of the interface request with the possible SSRF vulnerability, and the vulnerability existence condition of the corresponding API interface can be effectively detected.

Optionally, the batch sending of the target interface requests with the target fields specifically includes:

packaging the preset requests module into a preset request package function to obtain a packaged requests module;

and calling the packaged requests module to perform batch package sending on each target interface request with the target field.

By adopting the technical scheme, the requests module is packaged into the request issuing function, so that the request issuing function is conveniently and quickly invoked, each target interface request is directly uploaded to the packaged requests module, and the packaged requests module can quickly issue the target interface requests in batches, so that the request issuing speed is improved.

Optionally, the detecting whether the DNS request record is received by the DNSLOG platform corresponding to the SSRF vulnerability detection link, if yes, determining that an API interface corresponding to the DNS request record has an SSRF vulnerability, specifically includes:

calling an interface of the DNSLOG platform, and inquiring whether DNS analysis request records corresponding to package sending data requested by each target interface exist in the DNSLOG platform;

if yes, determining that the SSRF loopholes exist in the API interface corresponding to the DNS resolution request record.

By adopting the technical scheme, after each target interface request sends a package in batches, the interface of the DNSLOG platform is called, so that a DNS analysis request record received by the DNSLOG platform is obtained, if the DNS analysis request record corresponding to package sending data of the target interface request exists in the DNS analysis request record, the target interface request requests to access a corresponding SSRF vulnerability detection link, and further, the fact that the corresponding API interface has an SSRF vulnerability is explained, and therefore SSRF vulnerability detection is effectively and accurately carried out on the API interface.

In a second aspect of the present application, an automatic batch detection device for SSRF vulnerabilities is provided, which specifically includes:

the information acquisition module is used for acquiring interface information of each API interface of the web system;

The request determining module is used for determining interface requests corresponding to the API interfaces according to the interface information;

the request packet issuing module is used for judging whether a target field exists in each interface request, if so, assigning a preset SSRF vulnerability detection link to the target field in the corresponding interface request, and issuing packets in batches for each target interface request with the target field, wherein the target field is a detection field of the SSRF vulnerability;

and the vulnerability detection module is used for detecting whether the DNSLOG platform corresponding to the SSRF vulnerability detection link receives the DNS analysis request record, and if so, determining that the SSRF vulnerability exists in the API interface corresponding to the DNS analysis request record.

By adopting the technical scheme, after the information acquisition module acquires the interface information of each API interface, the request determination module determines the interface request corresponding to each API interface according to each interface information, then the request packet issuing module assigns SSRF vulnerability detection links to the target fields in each target interface request, and issues packets for each target interface request in batches, and finally the vulnerability detection module judges whether the DNSLOG platform receives the DNS analysis request record, if so, the SSRF vulnerability exists in the API interface corresponding to the DNS analysis request record.

In summary, the present application includes at least one of the following beneficial technical effects:

and determining interface requests corresponding to all API interfaces according to the interface information, traversing all the interface requests, and if a target field exists in the interface request, indicating that the possible SSRF vulnerability in the interface request needs to be detected, assigning a preset SSRF vulnerability detection link to the target field in the interface request. After the assignment of the target fields is completed, each target interface request with the target fields is subjected to batch package sending, so that the corresponding API interfaces are accessed. Finally, if the DNSLOG platform receives the DNS resolution request records, which indicate that the SSRF vulnerabilities exist in the API interfaces corresponding to the target interface requests, the API interfaces corresponding to the DNS resolution request records are finally determined to be the SSRF vulnerabilities. Therefore, SSRF vulnerability detection can be carried out on a plurality of API interfaces in batches, detection is not needed manually, and SSRF vulnerability detection efficiency is improved.

Drawings

FIG. 1 is a schematic flow chart of an automatic batch detection method for SSRF vulnerabilities provided by an embodiment of the present application;

FIG. 2 is a schematic flow chart of another automatic batch detection method for SSRF vulnerabilities provided by an embodiment of the present application;

FIG. 3 is a schematic structural diagram of an automatic batch detection device for SSRF vulnerabilities provided in an embodiment of the present application;

fig. 4 is a schematic structural diagram of another automatic batch detection device for SSRF vulnerabilities provided in an embodiment of the present application.

Reference numerals illustrate: 11. an information acquisition module; 12. a request determination module; 13. a request packet sending module; 14. and a loophole detection module.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present application, not all embodiments.

In describing embodiments of the present application, words such as "exemplary," "such as" or "for example" are used to mean serving as examples, illustrations or explanations. Any embodiment or design described herein as "illustrative," "such as" or "for example" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "illustratively," "such as" or "for example," etc., is intended to present related concepts in a concrete fashion.

In the description of the embodiments of the present application, the term "and/or" is merely an association relationship describing an association object, and indicates that three relationships may exist, for example, a and/or B may indicate: a alone, B alone, and both A and B. In addition, unless otherwise indicated, the term "plurality" means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals. Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating an indicated technical feature. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

The application discloses an automatic batch detection method for SSRF vulnerabilities, which can be understood as a specific python script tool, wherein an execution subject of the specific python script tool is a terminal, and the terminal can be electronic equipment such as a mobile phone, a tablet computer, an electronic book reader, a multimedia playing device, a wearable device, a Personal Computer (PC) and the like.

Referring to fig. 1, an embodiment of the application discloses a flow diagram of an SSRF vulnerability batch automatic detection method, which can be implemented by a computer program or run on an SSRF vulnerability batch automatic detection device based on von neumann system. The computer program can be integrated in an application or can be run as a stand-alone tool class application, and specifically comprises:

s101: interface information of each API interface of the web system is acquired.

In particular, an application programming (Application Programming Interface, API) interface that allows communication and data exchange between different applications or systems. The design of the API interface aims to enable developers to create and modify applications faster while ensuring interoperability between these applications. From the role perspective of the network usage environment, web systems are websites that we commonly use a browser to surf the internet.

One possible way to obtain interface information is: and obtaining interface information of each API interface of the web system by crawling the corresponding swagger of the web system through the python crawler. Wherein, the python crawler can be a Requests library and a BeautiflulSoup library of python in the embodiment of the application. In other embodiments, the python crawler may be a urllib library. In addition, swagger is a canonical and complete framework for generating, describing, invoking, and visualizing Restful style Web services. Swagger can clearly describe the transmission process of data and the interactive flow of the whole API interface, so that the developer can better understand and use the interface, and it defines the interface mainly through XML or JSON format.

Further, when crawling Swagger, the URL address of Swagger is first found, then an HTTP request is sent and the interface definition is acquired. The interface definition is usually returned in JSON or YAML format, and finally parsed to extract the interface information of each API interface, which is the prior art and will not be described here again. It should be noted that, the interface information is JSON data, that is, JSON format data.

S102: and determining interface requests corresponding to the API interfaces according to the interface information.

In one implementation, formatting is performed on each interface information to obtain processed information;

and calling a preset method to classify the processed information to obtain the packaged interface request corresponding to each API interface.

Specifically, after the interface information of each API interface is obtained, the JSON data in each interface information is formatted through a JSON module preset in the Python to obtain processed information, so that the interface address, the request method, the parameters, the data format and the like of each API interface are clarified, and the packaged request can be accurately analyzed and executed. In other embodiments, the JSON data in each interface information may also be formatted by a preset JSON format tool.

And then calling a preset method to carry out interface classification on the processed information, wherein the interface classification refers to a GET interface, a POST interface, a PUT interface and the like according to a request method, the GET interface corresponds to a GET request mode, the POST interface corresponds to a POST request mode, the PUT interface corresponds to a PUT request mode and the like. In addition, in the method, a GET request method, a POST request method, a PUT request method, and the like are packaged in advance. And finally, generating a standard http request format corresponding to each API interface, namely an encapsulated interface request by a method according to the information such as the request address, the request method, the request head and the like in the interface information corresponding to each API interface. The GET request is one method in the HTTP protocol, and is used to obtain data from a server. The POST request is used to submit data to the server.

For example, get a certain interface request form as follows:

{ "service": "xxx-bff-xxx", "service_summary": "xxx platform", "api_summary": "xxx collaboration drill down", "api_requesturl": "https:// xxx. Xxx-bff-xxx/remove/list", "method": "post", "headers": { "xxxToken": "2222222222222", "xxxsignature": "2222222222222" } "requests": "application/json", "requestData": { "xxx_id": "," current ": 1", "page": 10 ": xxx_list": "," precursor ": xx", "search name": "" "thereby is visible, and the interface request includes: "api_requesturl" indicates a request address, "method" indicates a request method (GET or POST request method), "headers" indicates a request header, "requestData" indicates a parameter of a POST request, "contacts" indicates a request to support a media type, and so on.

S103: judging whether target fields exist in each interface request, if so, assigning preset SSRF vulnerability detection links to the target fields in the corresponding interface requests, and carrying out batch package sending on each target interface request with the target fields, wherein the target fields are detection fields of SSRF vulnerabilities.

Specifically, as shown in step S102, each interface request includes different fields and corresponding field values, so after each interface request corresponding to an API interface is determined, a preset field in the interface request corresponding to all API interfaces is traversed, and whether URL links exist in the preset field, that is, whether the field value of the preset field is a URL link is determined, and one possible determining manner is that: and judging whether the URL link exists or not in a regular mode. The preset fields are fields in which SSRF vulnerabilities may exist, and in the embodiment of the present application, the preset fields are part or all of the fields of "URL", and in other embodiments, the preset fields may also be part or all of the fields of "wap", "http", "share", "link", "src", "source", "target", "display", "source URL", "imageURL", and "domain", etc. It should be noted that, compared with other fields, the preset field has a greater possibility of having URL links, so in the embodiment of the present application, a manner of traversing the preset field is adopted, so that the efficiency of determining the target field is higher. In other embodiments, each field in each interface request may be traversed to determine whether a preset field exists therein.

If the preset field of the interface request has a URL link, it is indicated that the preset field of the interface request is a detection field in which an SSRF vulnerability may exist, that is, the preset field may be maliciously linked by an attack constructor. Then it is determined that the interface request has a target field, and the default field in the interface request that has the URL link is the target field. And then, assigning a preset SSRF vulnerability detection link to a target field of the interface request, so as to perform SSRF vulnerability detection on the API interface corresponding to the interface request.

In summary, determining whether the target field exists in each interface request specifically includes: traversing preset fields in the interface requests corresponding to each API interface, judging whether URL links exist in the preset fields, if so, determining that target fields exist in the corresponding interface requests, and taking the preset fields with the URL links as the target fields.

Wherein, the SSRF vulnerability detection link is POC data of the SSRF vulnerability, and the POC data can be used for vulnerability detection. POC is typically an incomplete piece of code program for checking whether the target host has a corresponding vulnerability, which has randomness, versatility and certainty. After POC codes or data are sent to the detection target, whether the vulnerability exists actually or not is judged through the information specificity returned by the detected target. Because POC writing is based on vulnerability reproduction, important vulnerability characteristics are known through vulnerability reproduction, and vulnerability existence conditions are judged through corresponding characteristics. It should be noted that the SSRF vulnerability detection links assigned to each target interface request are different, and in other embodiments, the SSRF vulnerability detection links assigned to each target interface request are the same.

In one implementation manner, the method for sending the target interface requests with the target fields in batches specifically comprises the following steps:

and calling a packaged requests module, and performing batch package sending on each target interface request with the target field.

The requests module is a module for network access. It can help us send HTTP requests to GET web content, GET requests and POST requests. And packaging the preset requests module into a preset request package function to obtain the packaged requests module, thereby being convenient for repeated use in codes and convenient for calling. The preset request packet function is a send_request function, and in other embodiments, the preset request packet function may be a requests. The request packet sending function is generally used for sending HTTP requests in batches, so as to improve the efficiency of data transmission.

And determining the interface request with the assigned SSRF vulnerability detection link as a target interface request, calling a packaged requests module, sending the target interface request to the packaged requests module, and sending corresponding HTTP requests by the packaged requests module according to a request method carried in each target interface request, namely, sending each target interface request in batches. The HTTP request includes a GET request, a POST request, a PUT request, and the like. When the request method is a GET request method, the corresponding HTTP request is a GET request.

In another implementation manner, step S103 further includes: generating random characters, and selecting a preset number of target characters from the random characters;

and obtaining the domain name of the established DNSLOG platform, and generating an SSRF vulnerability detection link according to the target character and the domain name, wherein the SSRF vulnerability detection link comprises the domain name.

Specifically, the random character is generated by a preset python code, which is as follows: ssrf_character=', join (random. Choice (string. Aspicii_letters+string. Digits) for_in range (10)). Lower () time stamp = int (time. Time ()). Then, a preset number of target characters are selected from the random characters, wherein the preset number can be 6 in the embodiment of the application, and can be 10 in other embodiments.

The DNSLOG platform is used to parse the DNS log data to discover potential attack vectors. DNSLOG uses the DNS analysis log to store domain name information on the DNS server, and records the access information of the user to the domain name. The principle is generally understood as: the attacker registers a domain name, binds the domain name to a server of an ip and sets a generic resolution, and when the victim machine accesses any one of the sub-domains of the domain name, the attacker's server receives the request and records the DNS resolution.

Further, the dnslaog platform building process is briefly described as: purchasing domain names, such as: the xxx.com and the server are used for constructing a DNSLOG platform through the domain name and the server, which is the prior art and is not described herein.

Finally, based on the domain name and target character of DNSLOG platform, generating a plurality of SSRF vulnerability detection links, wherein one feasible generation mode is as follows: and generating an SSRF vulnerability detection link containing the domain name and the target character through a preset BurpSuite tool.

For example, the finally generated SSRF vulnerability detection links may 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:// u2 kuwbil 8ye 1688509. Xxx.com/ssrf.html.

Wherein "imlpxegpma 168409. Xxx.com", "e7j044 xmwb168409. Xxx.com" corresponds to a sub-domain name of the DNSLOG platform domain name. When accessing the sub domain names, the sub domain names are all resolved by the DNS server, and the DNSLOG platform receives the DNS resolution record. The domain name resolution is a process of converting a domain name into an IP address, and the domain name resolution is completed by a DNS server. This is the prior art and will not be described in detail here.

It should be noted that, in other embodiments, the SSRF vulnerability detection link may also be POC data of the deformed SSRF vulnerability, and the final SSRF vulnerability detection link may 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.comaaa.com/ssrf.html

http://15qvn6y7te168509.xxx.comaaa.com/ssrf.html

http://zik7080500168509.xxx.comaaa.com/ssrf.html

http://s117z3hpqr168509.aaa.com.xxx.com/ssrf.html......

S104: and detecting whether the DNSLOG platform corresponding to the SSRF vulnerability detection link receives the DNS analysis request record, and if so, determining that the SSRF vulnerability exists in the API interface corresponding to the DNS analysis request record.

In one implementation, an interface of the DNSLOG platform is called, and whether a DNS analysis request record corresponding to the package sending data requested by each target interface exists in the DNSLOG platform is queried;

Specifically, after batch unpacking is performed on each target interface request, calling an API interface of the DNSLOG platform, and obtaining a DNS analysis request record received by the DNSLOG platform, wherein the DNS analysis request record is a system log record for analyzing a domain name into an IP address. These records contain information about the DNS query, such as domain name address, resolution type, request time, etc. Then inquiring whether the DNS analysis request records corresponding to the packet sending data of each target interface request exist in all DNS analysis request records, wherein one feasible inquiring mode is as follows: if the domain name address contained in the DNS resolution request record is consistent with the address in the SSRF vulnerability detection link assigned in the target interface request, determining that the DNS resolution request record corresponding to the package sending data of the target interface request exists in the DNSLOG platform.

If so, it is determined that the SSRF vulnerability exists for the API interface to which the target interface request corresponds. Because if this target interface request does not have an SSRF vulnerability, then an attacker would not be able to exploit the SSRF vulnerability to initiate a request to a malicious URL link.

For example, there is a target interface request a whose SSRF vulnerability detection links assigned in the target field are: http:// imlpxegpm 168409. Xxx. The target interface requests B, whose SSRF vulnerability detection links assigned in the target field are: http:// e7j044 xmwb1684509. Xxx.

If the DNSLOG platform receives two DNS resolution request records at this time, the first is: domain name address: imlpxegpm 168409. Xxx. Com/ssrf. Html, IP: xx.y, request time: 2023-06-01;

the second strip is: domain name address: e7j044xmwb1684509. Xxx.com/ssrf. Html, IP: xb.c, request time: 2023-06-01. The address in the SSRF vulnerability detection link of the target interface request A is consistent with the domain name address in the first DNS resolution request record, and the address in the SSRF vulnerability detection link of the target interface request B is consistent with the domain name address in the second DNS resolution request record, so that SSRF vulnerabilities exist in the API interfaces corresponding to the target interface request A and the target interface request B.

Referring to fig. 2, an embodiment of the present application discloses a flow diagram of another SSRF vulnerability batch automation detection method, which may be implemented by a computer program or may be run on an SSRF vulnerability batch automation detection device based on von neumann system. The computer program can be integrated in an application or can be run as a stand-alone tool class application, and specifically comprises:

s201: interface information of each API interface of the web system is acquired.

S202: and determining interface requests corresponding to the API interfaces according to the interface information.

In one implementation manner, after step S202, the method further includes: inquiring body bodies corresponding to the interface requests, and screening to-be-processed fields, which are consistent with preset sensitive fields, in the body bodies in a regular mode;

judging whether a preset general field exists in the interface request of the body which is not queried, if so, reassigning each general field according to a preset general field assignment json table;

if not, carrying out random assignment on the field types provided by the swaggers of the web system.

Specifically, after determining the interface request corresponding to each API interface, inquiring whether a body exists in the interface request on the ali cloud platform through a request address in the interface request, wherein the body is composed of content, parameters, data and the like of the interface request. Additionally, GET requests typically do not require body volumes, as they are only used to acquire resources, not commit data. Whereas POST requests typically require a body for submitting data. Common body formats include JSON, XML, form data, and the like.

Screening out interface requests with body, and screening sensitive fields of the body corresponding to the interface requests, wherein the preset sensitive fields are identification card fields, related to privacy information, and in other embodiments, the preset sensitive fields can also be date of birth fields and the like. One possible screening method is: the field to be processed, which is consistent with the sensitive field, in the body is screened out in a regular mode, the field value of the field to be processed is deleted, the assignment is carried out again, the field value after the reassignment protects the privacy information, meanwhile, the normal access to the interface can be ensured, the field value after the reassignment can be selected from a preset field value table, and the field value table comprises 420117XXXXXXXXXX, 420112XXXXXXXXXX and the like. It should be noted that, the regular mode, i.e. the regular expression, is a powerful text processing tool, and may be used for field screening. This is the prior art and will not be described in detail here.

Then, whether the general fields exist in the interface request without the body is judged, the general fields are "size", "name", in other embodiments, the general fields can also be "phone", if so, the general fields are reassigned, and one possible reassigning mode is: and calling a preset universal field assignment json table, and matching field values corresponding to the universal fields from the universal field assignment json table. The universal field assignment json table includes different universal fields and corresponding field values.

For example, the general field assignment json table is as follows:

{"id": 22222,

"name":"xxxxxx",

"cityCode": 440300,

"countyCode": 440307,

"provinceCode": 440000,

"phone":"130xxxxxxxx",}

because each interface request is determined according to the interface information provided by the swagger, if the general field does not exist, the field in the interface information of the API interface provided by the swagger is selected for random assignment. For example, if the body and the general field do not exist in the interface request corresponding to the API interface M, the swagger is selected to perform random assignment on the field types "str", "int", etc. in the interface information provided by the API interface M, the "str" field is reassigned to "sss", and the "int" field is reassigned to 89.

S203: the request type of each interface request is determined.

S204: in the case that the request type is a GET request, it is determined whether the field value of the api_requesturl field of the corresponding interface request is a URL link.

S205: if the URL is linked, determining that a target field exists, and determining the api_requestURL field as the target field.

Specifically, if the field value corresponding to the "method" field in the interface request is GET, then determining that the request type of the interface request is GET request, then directly screening the field value of the "api_requesturl" field in the interface request, where the "api_requesturl" field indicates the request address, and if the field value is URL link, it is indicated that there may be an SSRF vulnerability in the field, so that the "api_requesturl" field is determined as the target field, thereby facilitating the subsequent SSRF vulnerability detection of the API interface corresponding to the interface request. Otherwise, if the URL is not linked, the judgment of the next interface request is continued.

S206: in the case that the request type is a POST request, it is determined whether the field value of the requestData field of the corresponding interface request is a URL link.

S207: if the URL is linked, determining that a target field exists, and determining the requestData field as the target field.

Specifically, if the field value corresponding to the "method" field in the interface request is POST, determining that the request type of the interface request is POST request, directly screening the field value of the "requestData" field in the interface request, wherein the "requestData" field represents the parameters of the POST request, and if the field value is URL link, it is indicated that the field may have SSRF vulnerability, so that the "requestData" field is determined as the target field, thereby facilitating subsequent SSRF vulnerability detection of the API interface corresponding to the interface request.

S208: if so, assigning the preset SSRF vulnerability detection link to a target field in the corresponding interface request, and performing batch package issuing on each target interface request with the target field.

S209: and detecting whether the DNSLOG platform corresponding to the SSRF vulnerability detection link receives the DNS analysis request record, and if so, determining that the SSRF vulnerability exists in the API interface corresponding to the DNS analysis request record.

Specifically, reference may be made to steps S103-S104, which are not described herein.

In another implementation manner, after determining that an API interface with an SSRF vulnerability exists, a corresponding SSRF vulnerability detection report is generated, where one possible generation manner is: generating an SSRF vulnerability detection report in an HTML format, wherein the written fields in the SSRF vulnerability detection report comprise: address specification of API interface with SSRF vulnerability, SSRF vulnerability description, "URL" field, "Request" field, preset SSRF vulnerability repair suggestion and POC data of corresponding SRF vulnerability.

The implementation principle of the SSRF vulnerability batch automatic detection method provided by the embodiment of the application is as follows: and determining interface requests corresponding to all API interfaces according to the interface information, traversing all the interface requests, and if a target field exists in the interface request, indicating that the possible SSRF vulnerability in the interface request needs to be detected, assigning a preset SSRF vulnerability detection link to the target field in the interface request. After the assignment of the target fields is completed, each target interface request with the target fields is subjected to batch package sending, so that the corresponding API interfaces are accessed. Finally, if the DNSLOG platform receives the DNS resolution request records, which indicate that the SSRF vulnerabilities exist in the API interfaces corresponding to the target interface requests, the API interfaces corresponding to the DNS resolution request records are finally determined to be the SSRF vulnerabilities. Therefore, SSRF vulnerability detection can be carried out on a plurality of API interfaces in batches, detection is not needed manually, and SSRF vulnerability detection efficiency is improved.

The following are examples of the apparatus of the present application that may be used to perform the method embodiments of the present application. For details not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the method of the present application.

Referring to fig. 3, a schematic structural diagram of an SSRF vulnerability batch automatic detection apparatus according to an embodiment of the present application is shown. The batch automation detection device applied to the SSRF vulnerabilities can be realized into all or part of the device through software, hardware or a combination of the software and the hardware. The device 1 comprises an information acquisition module 11, a request determination module 12, a request package issuing module 13 and a vulnerability detection module 14.

An information obtaining module 11, configured to obtain interface information of each API interface of the web system;

the request determining module 12 is configured to determine, according to each interface information, an interface request corresponding to each API interface;

the request packet sending module 13 is configured to determine whether a target field exists in each interface request, if so, assign a preset SSRF vulnerability detection link to the target field in the corresponding interface request, and perform batch packet sending on each target interface request with the target field, where the target field is a detection field of the SSRF vulnerability;

the vulnerability detection module 14 is configured to detect whether the DNS log platform corresponding to the SSRF vulnerability detection link receives the DNS resolution request record, and if so, determine that the API interface corresponding to the DNS resolution request record has an SSRF vulnerability.

Optionally, the request determining module 12 is specifically configured to:

formatting the interface information to obtain processed information;

Optionally, as shown in fig. 4, the apparatus 1 further includes a reassignment module 15, specifically configured to:

inquiring body bodies corresponding to the interface requests, and screening to-be-processed fields, which are consistent with preset sensitive fields, in the body bodies in a regular mode;

Optionally, the request issuing module 13 is specifically configured to:

determining the request type of each interface request;

judging whether the field value of the api_requestURL field of the corresponding interface request is a URL link or not under the condition that the request type is get request;

Optionally, the apparatus 1 further comprises a link generation module 16, specifically configured to:

Optionally, the request issuing module 13 is specifically further configured to:

Optionally, the vulnerability detection module 14 is specifically configured to:

calling an interface of the DNSLOG platform, and inquiring whether a DNS analysis request record corresponding to the package sending data requested by each target interface exists in the DNSLOG platform;

It should be noted that, when executing the SSRF vulnerability batch automatic detection method, the SSRF vulnerability batch automatic detection device provided in the foregoing embodiment is only exemplified by the division of the foregoing functional modules, in practical application, the foregoing functional allocation may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the device and the method for automatically detecting the SSRF vulnerabilities in batches provided in the foregoing embodiments belong to the same concept, which embody detailed implementation procedures in the method embodiments, and are not described herein again.

The embodiment of the application also discloses a computer readable storage medium, and the computer readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the SSRF vulnerability batch automatic detection method of the embodiment is adopted.

The computer program may be stored in a computer readable medium, where the computer program includes computer program code, where the computer program code may be in a source code form, an object code form, an executable file form, or some middleware form, etc., and the computer readable medium includes any entity or device capable of carrying the computer program code, a recording medium, a usb disk, a removable hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a Random Access Memory (RAM), an electrical carrier signal, a telecommunication signal, a software distribution medium, etc., where the computer readable medium includes, but is not limited to, the above components.

The method for automatically detecting the SSRF vulnerabilities in batches is stored in the computer-readable storage medium through the computer-readable storage medium, and is loaded and executed on a processor so as to facilitate the storage and application of the method.

The embodiment of the application also discloses electronic equipment, wherein a computer program is stored in a computer readable storage medium, and when the computer program is loaded and executed by a processor, the SSRF vulnerability batch automatic detection method is adopted.

The electronic device may be an electronic device such as a desktop computer, a notebook 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 further include an input/output device, a network access device, a bus, and the like.

The processor may be a Central Processing Unit (CPU), or of course, according to actual use, other general purpose processors, digital Signal Processors (DSP), application Specific Integrated Circuits (ASIC), ready-made programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., and the general purpose processor may be a microprocessor or any conventional processor, etc., which is not limited in this respect.

The memory may be an internal storage unit of the electronic device, for example, a hard disk or a memory of the electronic device, or may be an external storage device of the electronic device, for example, a plug-in hard disk, a Smart Memory Card (SMC), a secure digital card (SD), or a flash memory card (FC) provided on the electronic device, or the like, and may be a combination of the internal storage unit of the electronic device and the external storage device, where the memory is used to store a computer program and other programs and data required by the electronic device, and the memory may be used to temporarily store data that has been output or is to be output, which is not limited by the present application.

The SSRF vulnerability batch automatic detection method of the embodiment is stored in the memory of the electronic device through the electronic device, and is loaded and executed on the processor of the electronic device, so that the SSRF vulnerability batch automatic detection method is convenient to use.

The foregoing is merely exemplary embodiments of the present disclosure and is not intended to limit the scope of the present disclosure. That is, equivalent changes and modifications are contemplated by the teachings of this disclosure, which fall within the scope of the present disclosure. Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a scope and spirit of the disclosure being indicated by the claims.

Claims

1. An SSRF vulnerability batch automation detection method, which is characterized by comprising the following steps:

acquiring interface information of each API interface of the web system;

2. The method for automatically detecting SSRF vulnerabilities in batch according to claim 1, wherein determining the interface request corresponding to each API interface according to each interface information comprises:

formatting the interface information to obtain processed information;

3. The method for automatically detecting SSRF vulnerabilities in batch according to claim 1, wherein after determining the interface request corresponding to each API interface according to each interface information, further comprising:

4. The method for automatically detecting SSRF vulnerabilities in batch according to claim 1, wherein the request type is a GET request or a POST request, and the determining whether a target field exists in each interface request specifically comprises:

determining the request type of each interface request;

5. The method for batch automation detection of SSRF vulnerabilities of claim 1, further comprising, prior to determining whether a target field exists in each of the interface requests:

6. The method for automatically detecting SSRF vulnerabilities in batch according to claim 1, wherein the step of issuing a batch package for each target interface request having the target field comprises the steps of:

7. The method for automatically detecting SSRF vulnerabilities in batch according to claim 1, wherein the detecting whether the DNS log 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, specifically includes:

8. An SSRF vulnerability batch automation detection apparatus, comprising:

the information acquisition module (11) is used for acquiring interface information of each API interface of the web system;

a request determining module (12) for determining an interface request corresponding to each API interface according to each interface information;

the request packet issuing module (13) is used for judging whether a target field exists in each interface request, if so, assigning a preset SSRF vulnerability detection link to the target field in the corresponding interface request, and issuing packets in batches for each target interface request with the target field, wherein the target field is the detection field of the SSRF vulnerability;

and the vulnerability detection module (14) is used for detecting whether the DNSLOG platform corresponding to the SSRF vulnerability detection link receives the DNS analysis request record, and if so, determining that the SSRF vulnerability exists in the API interface corresponding to the DNS analysis request record.

9. A computer readable storage medium having a computer program stored therein, characterized in that the method according to any of claims 1-7 is employed when the computer program is loaded and executed by a processor.

10. 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 the method according to any of claims 1-7 is used when the computer program is loaded and executed by the processor.