CN111404937B

CN111404937B - Method and device for detecting server vulnerability

Info

Publication number: CN111404937B
Application number: CN202010181109.5A
Authority: CN
Inventors: 林伟壕; 谢金池
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-03-16
Filing date: 2020-03-16
Publication date: 2021-12-10
Anticipated expiration: 2040-03-16
Also published as: CN111404937A

Abstract

The invention provides a method and a device for detecting server bugs, electronic equipment and a storage medium; the method comprises the following steps: sending a first network request for accessing a target address based on the identity information of the first user to a server, and receiving a first response result sent by the server in response to the first network request; modifying parameters related to both the first user and the second user in the first network request to obtain a second network request for accessing a target address based on the identity information of the second user; sending a second network request to the server, and receiving a second response result returned by the server in response to the second network request; and when the similarity between the first response result and the second response result meets the similarity condition, determining that the interface aiming at the target address in the server has a bug. According to the invention, the loopholes existing in the server can be efficiently and accurately detected.

Description

Method and device for detecting server vulnerability

Technical Field

The invention relates to the technical field of internet, in particular to a method and a device for detecting server bugs, electronic equipment and a storage medium.

Background

With the recent outbreak of various high-risk vulnerabilities, security issues for network applications have attracted increasing attention. An unauthorized vulnerability is a common security vulnerability in a background server of a World Wide WEB (WEB) application program, and means that a developer is careless and does not have strict restrictions on a certain authority or a user required for operation, so that a user who should not have the authority to operate can normally operate, and the threat lies in that one account can control all user data of a website or a server. For example, an attacker using a legal account may perform illegal operations on other account data in the server, such as querying, deleting, modifying, and other conventional database commands.

At present, detection of unauthorized vulnerabilities in the related technology is basically manual detection, and if testers perform penetration testing on a server program, manual testing takes long time and is low in efficiency.

Disclosure of Invention

The embodiment of the invention provides a method and a device for detecting server vulnerabilities, electronic equipment and a storage medium, which can efficiently and accurately detect vulnerabilities existing in a server.

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

the embodiment of the invention provides a method for detecting server bugs, which comprises the following steps:

sending a first network request for accessing a target address based on identity information of a first user to a server, and receiving a first response result sent by the server in response to the first network request;

modifying parameters related to both the first user and the second user in the first network request to obtain a second network request for accessing the target address based on the identity information of the second user;

sending the second network request to the server, and receiving a second response result returned by the server in response to the second network request;

and when the similarity between the first response result and the second response result meets a similarity condition, determining that a vulnerability exists in an interface aiming at the target address in the server.

The embodiment of the invention provides a device for detecting server bugs, which comprises:

the system comprises an override detection module, a first network access module and a second network access module, wherein the override detection module is used for sending a first network request for accessing a target address based on identity information of a first user to a server and receiving a first response result sent by the server in response to the first network request;

a preprocessing module, configured to modify parameters related to both the first user and the second user in the first network request, so as to obtain a second network request for accessing the target address based on identity information of the second user;

the unauthorized detection module is further configured to send the second network request to the server, and receive a second response result returned by the server in response to the second network request;

the unauthorized detection module is further configured to determine that an interface in the server for the target address has a bug when the similarity between the first response result and the second response result satisfies a similarity condition.

In the above solution, the device for detecting a server vulnerability further includes: the acquisition module is used for acquiring a plurality of network requests sent to the server and response results sent by the server in response to the network requests; filtering the acquired network requests according to at least one of response codes included in the response results, file extensions included in the network requests and a white list, and filtering out network requests with failed address resolution; acquiring the identity information of the user corresponding to the network request obtained after filtering; selecting two different users as the first user and the second user according to the acquired identity information, selecting a network request corresponding to the first user from the filtered network requests, and adding the identity information of the first user to the selected network request to form the first network request.

In the foregoing solution, the acquisition module is further configured to filter out, from the acquired network requests, network requests that satisfy at least one of the following conditions: the file extension name included in the network request is null; the response code included in the response result of the network request is used for representing that the server fails to receive the response code; and the response result of the network request comprises any error information in the white list.

In the above scheme, the acquisition module is further configured to determine a domain name to which the resource locator in the network request obtained after the filtering belongs and/or a login mode of the corresponding service fingerprint; configuring an account and a password of the user according with the login mode; and sending a network request for accessing the target address based on the account number and the password of the user to the server, and receiving the identity information of the user returned by the server in response to the network request.

In the foregoing solution, the preprocessing module is further configured to integrally replace the identity information of the first user in the first network request with the identity information of the second user; replacing the sensitive parameter in the identity information of the first user in the first network request with the corresponding sensitive parameter in the identity information of the second user; replacing the serial number of the first user included in the resource locator in the first network request with the serial number of the second user; wherein the resource locator in the first network request comprises the destination address and the sequence number of the first user.

In the above scheme, the override detection module is further configured to determine a similarity between the first response result and the second response result; and when the similarity exceeds a similarity threshold value, determining that a vulnerability exists in an interface aiming at the target address in the server.

In the above scheme, the override detection module is further configured to perform word segmentation on the first response result and the second response result respectively to obtain first word segmentation information and second word segmentation information; performing aggregation processing on the first word segmentation information and the second word segmentation information to obtain aggregation information; determining the word frequency of the first word segmentation information relative to the aggregation information to obtain first word frequency information; determining the word frequency of the second word segmentation information relative to the aggregation information to obtain second word frequency information; determining the cosine similarity between the first word frequency information and the second word frequency information as the similarity between the first response result and the second response result.

In the foregoing solution, the override detection module is further configured to determine that there is no vulnerability in an interface of the server for the target address when the similarity between the first response result and the second response result does not satisfy the similarity condition and the second response result includes any error information in a white list; when the similarity between the first response result and the second response result does not meet the similarity condition, the second response result does not include any error information in a white list, and includes any sensitive information in a black list, determining that a vulnerability exists in an interface of the server for the target address; and when the similarity between the first response result and the second response result does not meet the similarity condition, and the second response result does not include any error information in a white list and any sensitive information in a black list, determining that no vulnerability exists in an interface aiming at the target address in the server.

In the above solution, the device for detecting a server vulnerability further includes: and the report management module is used for recording the vulnerability existing in the server aiming at the interface of the target address in real time and generating a report comprising the interface information with the vulnerability.

In the above solution, the device for detecting a server vulnerability further includes: the rule management module is used for responding to white list configuration operation and updating error information submitted by the white list configuration operation into a white list; and responding to the blacklist configuration operation, and updating the sensitive information submitted by the white list configuration operation into a blacklist.

An embodiment of the present invention provides an electronic device, including:

a memory for storing executable instructions;

and the processor is used for realizing the server vulnerability detection method provided by the embodiment of the invention when the executable instructions stored in the memory are executed.

The embodiment of the invention provides a storage medium, which stores executable instructions and is used for causing a processor to execute so as to realize the server vulnerability detection method provided by the embodiment of the invention.

The embodiment of the invention has the following beneficial effects:

by modifying parameters related to all users in the network request, the response of the server to the user change is detected, and whether the interface of the server has the ability to sense the user difference or not can be accurately judged through the similarity of response results, so that the difference response is made, and whether a bug exists in the interface of the server can be accurately and quickly detected.

Drawings

Fig. 1 is a schematic architecture diagram of a server vulnerability detection system 100 according to an embodiment of the present invention;

fig. 2 is a schematic structural diagram of an electronic device 500 according to an embodiment of the present invention;

fig. 3A is a schematic flowchart of a method for detecting a server vulnerability according to an embodiment of the present invention;

FIG. 3B is a block diagram of a network request according to an embodiment of the present invention;

FIG. 3C is a structural diagram of response results provided by an embodiment of the present invention;

fig. 3D is a schematic flowchart of determining a similarity between a first response result and a second response result according to an embodiment of the present invention;

FIG. 3E is a schematic diagram of the calculation of the cosine theorem according to the embodiment of the present invention;

fig. 4 is a schematic flowchart of a method for detecting a server vulnerability according to an embodiment of the present invention;

fig. 5A is a schematic flowchart of a method for detecting a server vulnerability, provided by an embodiment of the present invention;

FIG. 5B is a diagram illustrating the reporting of interface information provided by an embodiment of the present invention;

FIG. 5C is a schematic diagram of a configuration interface of a blacklist according to an embodiment of the present invention;

fig. 6 is a schematic structural diagram of a server vulnerability detection apparatus according to an embodiment of the present invention;

fig. 7 is a schematic flowchart of a method for detecting a server vulnerability according to an embodiment of the present invention;

fig. 8 is a schematic flowchart of a method for detecting a server vulnerability according to an embodiment of the present invention;

fig. 9 is a schematic flowchart of a method for detecting a server vulnerability, provided by an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail with reference to the accompanying drawings, the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.

Before further detailed description of the embodiments of the present invention, terms and expressions mentioned in the embodiments of the present invention are explained, and the terms and expressions mentioned in the embodiments of the present invention are applied to the following explanations.

1) The network request, also called request message, is a means for the client to obtain data response from the server. The structure of the network request includes: request methods (e.g., GET request and POST request), interface/network address, fields for indicating the resource (e.g., web page data) to be fetched, protocol version, and request body (i.e., entity body/data body).

2) The network response, also referred to as a response message, a response result, a response or a return result, refers to a response returned by the server to the client according to the network request, and the returned message entity body carries the resource requested by the client.

3) The POST request is one of request methods used by the network request, and specifies that data submitted by the network request must be placed in the entity body.

4) An interface, corresponding to a network address of a server, is a way for the server to identify, locate and process a Resource (e.g., a web page) requested by a client, the server may expose a plurality of interfaces to the client for access, each interface corresponding to a Resource of the server, and the Resource may be represented by a Uniform Resource Locator (URL).

5) The unauthorized process means that the server is too trusting to a network request (such as a data operation request) of a user through a client, and the determination on the user identity and the operation authority of the client is ignored, so that the user of a common client has the authority of an administrator user or other common users, such as functions of adding, deleting, changing, or checking and the like.

6) Parallel override refers to acquiring the authority in a mode of 'the authority type is unchanged and the user identity is changed'. For example: the client of a common user (not having administrator authority) sends out the identity information in the network request, and the identity information is replaced by the identity information of other users (having the same type of authority in the server), but the network request can still obtain the data of other users from the server.

7) The blacklist is a set of sensitive information, and records related to information security of the user, such as a mobile phone number, a bank account number, an address, and the like, are stored in a background database of the network application. Sensitive information is information that can be marked with emphasis; if the returned result after the (reconstructed) network request sent to the server in the detection process is matched with the blacklist, the unauthorized vulnerability exists.

8) And the white list is a collection of error information, and the network application returns a record of a response result including the error information to the client. If the result returned after the (reconstructed) network request sent to the server in the detection process matches the white list (i.e., includes error information in the white list), the network address in the network request (among all the network addresses of the server to be detected whether a bug exists) will be filtered (because the access of the network address does not have a bug), and no further detection processing is performed.

9) Identity information, also called authentication information or login state information, is data that is stored on the client by the server after the client logs in and establishes a session with the server, and is temporarily or permanently stored by the client in order for the server to recognize the user identity of the client to track the session, and for example, typical user information is implemented in the form of data (cookie) stored on the local terminal of the user, and includes: user ID, session ID (sid), and session key (skey), etc.

10) The parameter is data related to the identity, authority, and the like of the user in the network request, for example, a URL, a cookie (located in a header field of the network request), and data related to the user in a data body (i.e., the above message entity body), and is also referred to as a sensitive parameter because it is related to the user.

11) A login state, that is, the background of the network user is in a login state in the background of the network application, and in the login state, the client can use the authority associated with the user identity information, such as adding, deleting, modifying; as a way to achieve the login state, the client may request to log in again by means of the cookie issued by the server when logging in the server before, so that the user does not need to repeatedly input the user name and password.

12) Traffic, the client sends a network request to the server to request the server to return the behavior of a response.

13) Traffic collection, also known as traffic recording, records network requests sent by clients to servers.

14) Traffic replay, also known as traffic replay, resends the collected network requests to the server to be tested to detect the presence of a vulnerability based on the response returned by the server.

15) And (4) carrying out flow deduplication, and removing repeated requests recorded in the collected flow.

16) And (3) removing the dirty flow from the flow, and removing the dirty flow from the collected flow. Where "dirty" traffic attracts user-initiated network requests to the background through illicit means (e.g., through illegal information such as yellow gambling viruses to attract user clicks).

The embodiment of the invention provides a method and a device for detecting server loopholes, electronic equipment and a storage medium, which can efficiently and accurately detect unauthorized loopholes existing in a server. An exemplary application of the server vulnerability detection method provided by the embodiment of the present invention is described below, and the server vulnerability detection method provided by the embodiment of the present invention may be implemented by a server, for example, may be implemented by a single server, may be implemented by a plurality of servers in a cooperative manner, and may of course be implemented by a terminal (for example, a computer, a smart phone with an artificial intelligence core, and the like).

Next, an embodiment of the present invention is described by taking a single server as an example, referring to fig. 1, fig. 1 is a schematic structural diagram of a server vulnerability detection system 100 provided in the embodiment of the present invention. The server vulnerability detection system 100 includes: the detection server 200, the terminal 300 and the client 310 in the terminal 300, the background server 400 of the client 310.

The server vulnerability detection method provided by the embodiment of the invention can be realized through the following processes: firstly, the detection server 200 collects a plurality of network requests sent by the client to the background server 400, and filters the plurality of network requests to obtain a first network request; then, the detection server 200 sends a first network request to the backend server 400, and receives a first response result sent by the backend server 400 in response to the first network request; modifying parameters related to both the first user and the second user in the first network request to obtain a second network request; finally, the detection server 200 sends a second network request to the backend server 400, and receives a second response result returned by the backend server 400 in response to the second network request; the detection server 200 determines whether the bug exists in the background server 400 according to the first response result and the second response result.

Next, a structure of an electronic device provided in an embodiment of the present invention is described, where the electronic device provided in an embodiment of the present invention may be the detection server 200 shown in fig. 1. Referring to fig. 2, fig. 2 is a schematic structural diagram of an electronic device 500 according to an embodiment of the present invention, where the electronic device 500 shown in fig. 2 includes: at least one processor 510, memory 550, at least one network interface 520, and a user interface 530. The various components in the electronic device 500 are coupled together by a bus system 540. It is understood that the bus system 540 is used to enable communications among the components. The bus system 540 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 540 in fig. 2.

The Processor 510 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.

The user interface 530 includes one or more output devices 531 enabling presentation of media content, including one or more speakers and/or one or more visual display screens. The user interface 530 also includes one or more input devices 532, including user interface components to facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

The memory 550 may comprise volatile memory or nonvolatile memory, and may also comprise both volatile and nonvolatile memory. The non-volatile Memory may be a Read Only Memory (ROM), and the volatile Memory may be a Random Access Memory (RAM). The memory 550 described in connection with embodiments of the invention is intended to comprise any suitable type of memory. Memory 550 optionally includes one or more storage devices physically located remote from processor 510.

In some embodiments, memory 550 can store data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

An operating system 551 including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

a network communication module 552 for communicating to other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;

a display module 553 for enabling presentation of information (e.g., a user interface for operating peripherals and displaying content and information) via one or more output devices 531 (e.g., a display screen, speakers, etc.) associated with the user interface 530;

an input processing module 554 to detect one or more user inputs or interactions from one of the one or more input devices 532 and to translate the detected inputs or interactions.

In some embodiments, the server vulnerability detection apparatus provided by the embodiments of the present invention may be implemented in a software manner, and fig. 2 shows a server vulnerability detection apparatus 555 stored in a memory 550, which may be software in the form of programs and plug-ins, and includes the following software modules: an override detection module 5551 and a pre-processing module 5552. These modules may be logical functional modules and thus may be arbitrarily combined or further divided according to the functions implemented. The functions of the respective modules will be explained below.

In other embodiments, the Device for detecting a server bug according to embodiments of the present invention may be implemented by combining hardware and software, and as an example, the Device according to embodiments of the present invention may be a processor in the form of a hardware decoding processor, which is programmed to execute the method for detecting a server bug according to embodiments of the present invention, for example, the processor in the form of the hardware decoding processor may be one or more Application Specific Integrated Circuits (ASICs), DSPs, Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), Field Programmable Gate Arrays (FPGAs), or other electronic components.

The following describes an embodiment of the present invention by taking an example in which the detection server 200 in fig. 1 implements the method for detecting a server vulnerability provided in the embodiment of the present invention. Referring to fig. 3A, fig. 3A is a schematic flowchart of a method for detecting a server vulnerability according to an embodiment of the present invention, and the steps shown in fig. 3A will be described.

In step S101, the detection server sends a first network request for accessing a target address based on the identity information of the first user to the background server.

Referring to fig. 3B, fig. 3B is a schematic structural diagram of a network request according to an embodiment of the present invention. In fig. 3B, the network request consists of three parts, a request line, a request header and a request body. The request line comprises a request method, a URL and a protocol version; the request header (or header) consists of a "name/value" pair, one pair per line, with colon separation between the name and value, and includes the user's identity information (e.g., cookie).

In some embodiments, the URL in the request line of the first network request includes the destination address, and the request header of the first network request includes the identity information of the first user.

For example, the first network request may carry the following information: URL: www.example.com/task, phpid 1& token aaa, identity information of the first user (cookie): "skey ═ abc; sid is 3 ".

In step S102, the detection server receives a first response result sent by the background server in response to the first network request.

Referring to fig. 3C, fig. 3C is a schematic structural diagram of a response result provided by the embodiment of the present invention. In fig. 3C, the response result is composed of three parts, namely a status line, a response header and a response body, wherein the status line includes three parts, namely a protocol version, a status code (or called response code) and a status code description; the response header consists of a "name/value" pair, one for each row, with colon separation between the name and value.

Here, the status code is 3 digits, the status codes of 200-299 indicate that the server (i.e. the server) successfully receives, the status codes of 300-399 indicate resource redirection, the status codes of 400-499 indicate client request errors, and the status codes of 500-599 indicate server side errors.

In step S103, the detection server modifies the parameters related to both the first user and the second user in the first network request to obtain a second network request for accessing the destination address based on the identity information of the second user.

Here, the parameter for detecting the modification of the server is a parameter related to the identity or authority of the user, etc. in the first network request. Since the modification of the parameters in the first network request is associated with both the first user and the second user, the second network request carries part or all of the identity information of the second user as long as any one of the parameters is modified, even if not all of the parameters are associated with both the first user and the second user.

In some embodiments, the detection server replaces the identity information of the first user in the first network request with the identity information of the second user in whole to obtain a second network request for accessing the target address based on the identity information of the second user.

The following information is carried with the first network request: URL: www.example.com/task, phpid 1& token aaa, identity information of the first user (cookie): skey ═ abc; sid is 3 and the identity information cookie of the second user is skey bcd; taking sid 4 as an example, the identity information of the first user in the first network request is entirely replaced by the identity information of the second user, and the obtained second network request carries the following information: URL: www.example.com/task, phpid 1& token aaa, identity information of the second user (cookie): skey is bcd; and sid is 4 (namely, the cookie of the first user is replaced by the cookie of the second user in the whole).

In some embodiments, the detection server replaces the sensitive parameter in the identity information of the first user in the first network request with the corresponding sensitive parameter in the identity information of the second user to obtain a second network request for accessing the target address based on the identity information of the second user.

Here, the sensitive parameter in the identity information may be any parameter related to the user identity, for example, a user ID in a cookie, a session ID (sid), a session key (skey), and the like.

The following information is carried with the first network request: URL: www.example.com/task, phpid 1& token aaa, identity information of the first user (cookie): skey ═ abc; sid is 3 and the identity information cookie of the second user is skey bcd; taking sid 4 as an example, replacing the sensitive parameter in the identity information of the first user in the first network request with the corresponding sensitive parameter in the identity information of the second user, and then obtaining a second network request carrying the following information: URL: www.example.com/task, phpid 1& token aaa, identity information of the second user (cookie): skey is bcd; sid ═ 3 (i.e., replace the skey in the first user's cookie with the skey in the second user's cookie).

In some embodiments, the detection server modifies a parameter in a request body of the first network request, which is related to both the identity information of the first user and the identity information of the second user, to obtain a second network request for accessing the destination address based on the identity information of the second user.

In some embodiments, the detection server replaces the serial number of the first user included in the resource locator (i.e., URL) in the first network request with the serial number of the second user to obtain a second network request to access the destination address based on the identity information of the second user.

Here, the resource locator in the first network request includes the destination address and the sequence number of the first user. For example: when the URL in the first network request is www.example.com/task, phpid 1& token aaa, the first user's serial number (id) is 1.

The following information is carried with the first network request: URL: www.example.com/task, phpid 1& token aaa, identity information of the first user (cookie): skey ═ abc; taking sid as 3 and URL requested by the second user as www.example.com/task, phpid as 2& token as bbb, replacing the serial number of the first user included in the resource locator in the first network request with the serial number of the second user, and obtaining the second network request carrying the following information: URL: www.example.com/task, phpid 2& token aaa, identity information of the second user (cookie): skey ═ abc; and sid is 3 (namely, the serial number id of the first user in the URL requested by the first user is replaced by 1 and the serial number id of the second user is replaced by 2).

The embodiment of the invention not only can modify the identity information of the user in the network request, but also can modify the parameters which are related to the identity information of the user except the identity information of the user in the network request, thereby improving the comprehensiveness of detecting the vulnerability and reducing the false alarm rate.

In step S104, the detection server sends a second network request to the backend server.

In some embodiments, the URL in the request line of the second network request includes the destination address, wherein the sequence number of the user included in the URL may be the sequence number of the second user, and the identity information of the user included in the request header of the second network request may be the modified identity information of the first user.

For example, the second network request may carry the following information: URL: www.example.com/task, phpid 1& token aaa, modified identity information cookie: skey is bcd; and (4) replacing the whole cookie of the first user with the cookie of the second user.

In step S105, the detection server receives a second response result sent by the background server in response to the second network request.

In some embodiments, referring to fig. 3C, the second response result is comprised of three parts, a status line, a response header, and a response body, wherein the status line includes three parts, a protocol version, a status code, and a status code description.

When the subsequent detection server performs unauthorized vulnerability detection, whether the vulnerability exists in the interface of the background server for the target address can be determined according to the state code of the response header in the second response result and the field included in the response text.

In step S106, the detection server determines whether there is a vulnerability in the interface for the target address in the background server according to the first response result and the second response result.

In some embodiments, when the similarity between the first response result and the second response result satisfies the similarity condition, the detection server determines that a vulnerability exists in an interface of the background server for the target address.

As an example, the detection server determines a similarity between the first response result and the second response result; and when the similarity exceeds a similarity threshold value, determining that the interface aiming at the target address in the background server has a bug.

As an example, the detection server determines a similarity between the first response result and the second response result; and when the similarity does not exceed the similarity threshold, determining that no loophole exists in the interface aiming at the target address in the background server.

Here, the similarity threshold may be any constant between 0 and 1, and is set to 0.7 herein.

Referring to fig. 3D, fig. 3D is a schematic flowchart of determining a similarity between a first response result and a second response result according to an embodiment of the present invention. In fig. 3D, the process of determining the similarity between the first response result and the second response result specifically includes: step S301, performing word segmentation processing on the first response result and the second response result respectively to obtain first word segmentation information and second word segmentation information; step S302, carrying out aggregation processing on the first participle information and the second participle information to obtain aggregated information; step S303, determining the word frequency of the first word segmentation information relative to the aggregation information to obtain first word frequency information; determining the word frequency of the second word segmentation information relative to the aggregation information to obtain second word frequency information; step S304, vectorizing the first word frequency information and the second word frequency information; step S305, determining a cosine similarity between the vectorized first word frequency information and the vectorized second word frequency information as a similarity between the first response result and the second response result.

Here, the rules of the word segmentation process are: when the response result contains Chinese sentences, semantic analysis methods can be introduced to carry out word segmentation, for example, the Chinese sentences are divided into a plurality of words.

For example, when the first response result is { "ret": 0, "content": 12345} and the second response result is { "ret": 0, "content": 12345678), performing participle processing on the first response result and the second response result to obtain first participle information [ "ret", 0, "content", 12345]Second participle information [ "ret", 0, "content", 12345678](ii) a Performing aggregation processing on the first participle information and the second participle information to obtain aggregation information [ "ret", 0, "content", 12345, 12345678](ii) a Calculating first word frequency information { "ret" { "of the first word-dividing information relative to the aggregation information: 1,0: 1, "content": 1,12345: 1,12345678: 0, calculating second word frequency information { "ret" { "of the second participle information relative to the aggregation information: 1,0: 1, "content": 1,12345: 0,12345678: 1 }; vectorizing first word frequency information to [1, 1, 1, 1, 0]The first word frequency information vector is quantized to [1, 1, 1, 0, 1](ii) a Referring to fig. 3E, fig. 3E is a schematic diagram of a calculation of the cosine theorem according to an embodiment of the present invention, which can be obtained according to fig. 3E and a formula of the cosine theorem

Calculating cosine similarity between the vectorized first word frequency information and the vectorized second word frequency information as follows:

therefore, the similarity between the first response result and the second response result can be determined to be 0.75 and exceeds the similarity threshold value of 0.7, and the similarity between the first response result and the second response result meets the similarity condition, so that the vulnerability of the interface aiming at the target address in the background server can be determined.

According to the embodiment of the invention, whether the interface aiming at the target address in the server has the bug or not is determined according to the similarity between the first response result and the second response result by the cosine similarity theorem, so that the rate of detecting the bug is improved, and the accuracy of detecting the bug is also improved.

After the similarity detection is performed, in order to further improve the detection accuracy, a white list detection process may be added, specifically: in some embodiments, when the similarity between the first response result and the second response result satisfies the similarity condition and the second response result includes any error information in the white list, the detection server determines that there is no vulnerability in the interface for the target address in the background server.

Here, the error information is a known error keyword such as "fail", or "registration required".

As an example, when the similarity between the first response result and the second response result exceeds a similarity threshold and the second response result includes any error information in the white list, the detection server determines that there is no vulnerability in the interface for the target address in the background server.

For example, if a result returned after detecting the reconstructed network request sent by the server to the background server matches the white list (that is, includes any error information in the white list) in the detection process, it indicates that the resource in the background server cannot be acquired by using the reconstructed network request, and therefore, it may be determined that there is no vulnerability in the interface for the target address in the background server.

After white list detection is performed, in order to further improve the detection accuracy, a black list detection process may be added, specifically: in some embodiments, when the similarity between the first response result and the second response result satisfies the similarity condition and the second response result does not include any error information in the white list, whether a vulnerability exists in an interface to the target address in the background server may be determined by determining whether the second response result includes any sensitive information in the black list.

Here, the sensitive information refers to records related to information security of the user, such as a mobile phone number, a bank account number, an address, and the like.

As an example, when the similarity between the first response result and the second response result exceeds a similarity threshold, the second response result does not include any error information in a white list, and includes any sensitive information in a black list, it is determined that a vulnerability exists in an interface of the server for the target address.

As another example, when the similarity between the first response result and the second response result exceeds a similarity threshold, the second response result does not include any error information in a white list, and does not include any sensitive information in a black list, it is determined that there is no vulnerability in the interface for the target address in the server.

For example, if a result returned after detecting the reconstructed network request sent by the server to the background server in the detection process matches the blacklist (that is, includes any sensitive information in the blacklist), it indicates that the privacy resource related to the user in the background server can be obtained by using the reconstructed network request, and therefore it may be determined that an unauthorized vulnerability exists in the background server for the interface of the target address.

According to the embodiment of the invention, the black-and-white list rule is introduced in the process of judging whether the unauthorized vulnerability exists, so that the vulnerability detection rate is further improved, and the vulnerability detection accuracy is also improved.

Referring to fig. 4, fig. 4 is a schematic flowchart of a method for detecting a server vulnerability, which is provided by the embodiment of the present invention, and based on fig. 3A, the method may include steps S107 to S111 before step S101.

In step S107, the detection server collects a plurality of network requests sent by the client to the backend server, and response results sent by the backend server to the client in response to the plurality of network requests.

In some embodiments, the detection server may collect all network requests sent by the client to the background server; all network requests sent by the client to the background server in any time period can be collected; or collecting all network requests sent by the clients meeting the preset condition to the background server, for example, using the client whose accumulated time exceeds the preset accumulated time threshold. And after the detection server determines the acquired network request, acquiring a corresponding response result.

In step S108, the detection server filters the acquired network request according to at least one of the response code included in the response result, the file extension included in the network request, and the white list, and filters out the network request with failed address resolution.

Here, the rule of filtering the network request may be an arbitrary selection network request; or may be a traversal select network request.

In some embodiments, the detection server filters out the collected network requests that satisfy at least one of the following conditions: the file extension included in the network request is null (or invalid); response codes included in the response results of the network requests represent that the background server fails to receive the response codes; the response result of the network request comprises any error information in the white list.

When the response code included in the response result is 40x (e.g. 401) or 50x (e.g. 501), it is characterized that the background server does not successfully receive the network request. The white list may be the same as the error information included in the white list (i.e., the white list used to detect the unauthorized vulnerability) or may be different according to user definition.

For example, if the returned result of the network request matches the white list (i.e. includes any error information in the white list) during the filtering process, it indicates that the network address in the network request may have expired or that there is no vulnerability in the access of the network address, and therefore, no further detection process is required.

In step S109, the detection server obtains the filtered identity information of the user corresponding to the network request.

In some embodiments, the detection server determines a domain name to which the resource locator in the network request obtained after filtering belongs and/or a login mode of a corresponding service fingerprint; configuring an account and a password of a user according with a login mode; and sending a network request for accessing the target address based on the account number and the password of the user to the background server, and receiving the identity information of the user returned by the background server in response to the network request.

For example, according to the login mode used for the service identification of the domain name belonging to the network request and the account and the password of the pre-configured user, the network request based on the account and the password of the user is sent to the background server to obtain the identity information (cookie) of the user.

In step S110, the detection server selects two different users as the first user and the second user according to the acquired identity information.

Here, the detection server extracts the identity information (cookie) of the user corresponding to the filtered remaining network request from the filtered remaining network request, and selects any two users with different identity information as the first user and the second user.

In step S111, the detection server selects a network request corresponding to the first user from the filtered network requests, and adds the identity information of the first user to a header of the selected network request to form the first network request.

The process of acquiring the identity information of the first user comprises the following steps: the detection server sends a network request for accessing the target address based on the account and the password of the first user to the background server, so that the identity information of the first user returned by the background server in response to the network request is obtained.

It has been explained in detail above that the request header of the network request includes the identity information of the user, so that the detection server may add the obtained identity information of the first user in the request header of the selected network request to form the first network request.

The embodiment of the invention filters and discards expired or invalid network requests through the filtering rules, and then performs vulnerability detection processing on the filtered network requests, thereby avoiding subsequent flow playback and further wasting detection resources of a detection server.

Referring to fig. 5A, fig. 5A is a schematic flowchart of a method for detecting a server vulnerability, which is provided by the embodiment of the present invention, and based on fig. 3A, step S112 may be included after step S106.

In step S112, the detection server records, in real time, the vulnerability existing in the interface for the target address in the background server, and generates a report including the interface information in which the vulnerability exists.

In some embodiments, the detection server may send a report and/or a notification including the interface information with the vulnerability to the detection person (in the interactive interface of the detection person), so that the detection person performs secondary verification (or detection) on the interface of the target address according to the report and/or the notification including the interface information with the vulnerability.

For example, referring to fig. 5B, fig. 5B is a schematic diagram of a report of interface information provided in the embodiment of the present invention, and in fig. 5B, the report of interface information shows the time when a vulnerability is detected (i.e., the warehousing time), the user identity information (id), the vulnerability/risk type, and the URL where the vulnerability exists is scanned out.

According to the embodiment of the invention, the scanning vulnerability detection report is provided for the user, so that the user can carry out secondary detection according to the returned result, and the vulnerability detection accuracy is further improved.

In some embodiments, the black list and the white list support user (detector) autonomous configuration, and the specific process of configuring the white list is as follows: and the detection server responds to the white list configuration operation and updates the error information submitted by the white list configuration operation into the white list. The specific process of configuring the blacklist is as follows: and the detection server responds to the blacklist configuration operation and updates the sensitive information submitted by the white list configuration operation into the blacklist.

For example, referring to fig. 5C, fig. 5C is a schematic view of a configuration interface of a blacklist according to an embodiment of the present invention, and in fig. 5C, a user may update, for example, delete or add sensitive information included in the blacklist through the configuration interface of the blacklist.

The configuration interface for detecting the white list and the configuration interface for filtering the white list used by the URL are both similar to the configuration interface for the black list, and will not be described herein again.

The embodiment of the invention provides a perfect filtering rule and detection rule management background, and supports the self-service configuration of the filtering rule and the detection rule by a user, thereby further improving the accuracy of detecting the vulnerability.

Continuing with fig. 2, an exemplary structure of the server vulnerability detection apparatus 555 provided by the embodiment of the present invention implemented as a software module is described below, and in some embodiments, as shown in fig. 2, the software module stored in the server vulnerability detection apparatus 555 of the memory 550 may include: an override detection module 5551 and a pre-processing module 5552.

The unauthorized detection module 5551 is configured to send a first network request for accessing a destination address based on the identity information of the first user to the server, and receive a first response result sent by the server in response to the first network request;

a preprocessing module 5552, configured to modify a parameter related to both the first user and the second user in the first network request, so as to obtain a second network request for accessing the destination address based on the identity information of the second user;

the unauthorized detection module 5551 is further configured to send a second network request to the server, and receive a second response result returned by the server in response to the second network request;

the override detection module 5551 is further configured to determine that there is a vulnerability in the interface of the server for the target address when the similarity between the first response result and the second response result satisfies the similarity condition.

In some embodiments, the server vulnerability detection apparatus 555 further includes: an acquiring module 5553, configured to acquire a plurality of network requests sent to the server and response results sent by the server in response to the plurality of network requests; filtering the acquired network requests according to at least one of response codes included in the response results, file extensions included in the network requests and a white list, and filtering out network requests with failed address resolution; acquiring the identity information of the user corresponding to the network request obtained after filtering; and selecting two different users as a first user and a second user according to the acquired identity information, selecting a network request corresponding to the first user from the filtered network requests, and adding the identity information of the first user to the selected network request to form a first network request.

In some embodiments, the collecting module 5553 is further configured to filter out the collected network requests, which satisfy at least one of the following conditions: the file extension included in the network request is null; the response code included in the response result of the network request represents that the server fails to receive the response code; the response result of the network request comprises any error information in the white list.

In some embodiments, the acquiring module 5553 is further configured to determine a domain name to which the resource locator in the network request obtained after filtering belongs and/or a login manner of the corresponding service fingerprint; configuring an account and a password of a user according with a login mode; and sending a network request for accessing the target address based on the account number and the password of the user to the server, and receiving the identity information of the user returned by the server in response to the network request.

In some embodiments, the preprocessing module 5552 is further configured to replace the identity information of the first user in the first network request with the identity information of the second user in its entirety; replacing the sensitive parameter in the identity information of the first user in the first network request with the corresponding sensitive parameter in the identity information of the second user; replacing the serial number of the first user included in the resource locator in the first network request with the serial number of the second user; the resource locator in the first network request comprises a target address and a serial number of the first user.

In some embodiments, the override detection module 5551 is further configured to determine a similarity between the first response result and the second response result; and when the similarity exceeds a similarity threshold value, determining that the interface aiming at the target address in the server has a bug.

In some embodiments, the override detection module 5551 is further configured to perform word segmentation on the first response result and the second response result, respectively, to obtain first word segmentation information and second word segmentation information; performing aggregation processing on the first word segmentation information and the second word segmentation information to obtain aggregation information; determining the word frequency of the first word segmentation information relative to the aggregation information to obtain first word frequency information; determining the word frequency of the second word segmentation information relative to the aggregation information to obtain second word frequency information; and determining the cosine similarity between the first word frequency information and the second word frequency information as the similarity between the first response result and the second response result.

In some embodiments, the override detection module 5551 is further configured to determine that there is no vulnerability in the interface of the server for the target address when the similarity between the first response result and the second response result satisfies the similarity condition and the second response result includes any error information in the white list; when the similarity between the first response result and the second response result meets the similarity condition, the second response result does not include any error information in the white list and includes any sensitive information in the black list, determining that a vulnerability exists in an interface aiming at a target address in the server; and when the similarity between the first response result and the second response result meets the similarity condition, the second response result does not include any error information in the white list and does not include any sensitive information in the black list, determining that no vulnerability exists in the interface aiming at the target address in the server.

In some embodiments, the server vulnerability detection apparatus 555 further includes: and the report management module 5554 is used for recording the vulnerability existing in the interface of the target address in the server in real time and generating a report comprising the interface information of the vulnerability.

In some embodiments, the server vulnerability detection apparatus 555 further includes: the rule management module 5555 is configured to, in response to the white list configuration operation, update the error information submitted by the white list configuration operation into the white list; and responding to the blacklist configuration operation, and updating the sensitive information submitted by the white list configuration operation into the blacklist.

Embodiments of the present invention provide a storage medium storing executable instructions, where the executable instructions are stored, and when executed by a processor, will cause the processor to execute a method for detecting a server vulnerability, provided by embodiments of the present invention, for example, a method for detecting a server vulnerability as shown in fig. 3A, fig. 3D, fig. 4 or fig. 5A.

In some embodiments, the storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

In some embodiments, executable instructions may be written in any form of programming language (including compiled or interpreted languages), in the form of programs, software modules, scripts or code, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions can correspond, but do not necessarily correspond, to files in a file system, and can be stored in a portion of a file that holds other programs or data, e.g., in one or more scripts stored in a hypertext markup language document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

In the following, an exemplary application of the embodiments of the present invention in a practical application scenario will be described.

In the implementation process of the embodiment of the invention, the following problems are found in the related art:

(1) in the related technology, the response result is obtained by modifying the parameter of the URL in the network request, and the detection result has many false alarms and low result availability, which is not beneficial to vulnerability analysis. On one hand, because the network requests are various and the parameters of the URL used for requesting resources from the server have no uniform standard, the parameters of the URL are complex and various, so that the parameters of the URL related to the user identity or the authority in the network requests are not clear; on the other hand, the response of the network request may contain dynamic data such as recommendations, advertisements or timestamps, which are irrelevant to the authority, so that misjudgment is easy to occur.

(2) In the related technology, detection points which are possibly unauthorized are not covered sufficiently, only the parameters of the URL in the network request are considered, the parameters which need to be detected in the URL cannot be flexibly defined, and the detection of the parameters in the cookie is ignored.

(3) Basic identity authentication in the related art mostly adopts a mode of directly configuring cookie information, and login logic cannot be automatically adapted according to a WEB application page interface or specific services.

(4) The related art can only be used as a manual test method or a semi-automatic test method because of high false alarm, is limited to the operation of a tester, and cannot be used as an automatic test scheme.

In view of the above problems, an embodiment of the present invention provides a method for detecting a server unauthorized vulnerability. The embodiment of the invention not only can modify the identity information of the user in the network request, but also can modify the parameters except the identity information of the user in the network request, thereby improving the comprehensiveness of detecting the vulnerability and reducing the false alarm rate; by judging the similarity between the first response result and the second response result, the vulnerability detection rate is improved, and the vulnerability detection accuracy is also improved.

The implementation scheme of the embodiment of the invention is as follows:

referring to fig. 6, fig. 6 is a schematic structural diagram of a detection apparatus for a server unauthorized vulnerability, provided by an embodiment of the present invention, in fig. 6, the detection apparatus for a server unauthorized vulnerability is composed of seven parts, including: the system comprises a task issuing module, a URL acquisition module, a user login state management module, a URL preprocessing module, an override detection module, a rule management module and a report management module, which are specifically explained below.

(1) A task issuing module: the system is composed of a WEB system entry and a command line entry, and a detection person can define URLs (or called detection) required to be scanned and post request data bodies.

The task issuing module can configure parameters needing to be scanned, and the scanned parameters can include any one or more of a URL (uniform resource locator), a data body (the number/type of the parameters included in the data body depends on a developer of the network application and can include one or more parameters);

(2) the user login state management module: identifying a user identity based on domain name asset attribution and a service fingerprint, thereby constructing a login request and saving identity information for a specific user such as user A and user B;

the domain name asset attribution means that different domain names in the network are registered under the names of different users (which can be individuals, organizations, companies, etc.) and services; when a client sends a network request, a corresponding IP address can be inquired according to a domain name of the network request (the IP address and the domain name are in one-to-one or one-to-many relationship), a user to which the domain name belongs can be inquired (in a domain name registration database), and identity information of the user is stored, or a service to which the domain name belongs is inquired (in a service belonging database), and an identity authentication mode used by the service is stored.

The service fingerprint refers to that the website displays the service type and service content provided by the website when providing service to the outside, for example, the website indicates that the website provides social service, video service or news consultation service on a webpage, the identification can be performed according to the webpage return information, and then the identity authentication mode used by the website can be inquired in the identity authentication relation database.

(3) The URL acquisition module: the flow can be collected by installing an agent on a WEB application server or installing a plug-in on a user browser, and the duplicate removal and the dirty removal are completed.

(4) The URL preprocessing module is responsible for: requesting a URL by using a pre-configured user account and a password to obtain a response comprising a cookie of a user; filtering known URLs which do not need to be processed; and reconstructing the network request including the URL information.

(5) A rule management module: and the module is responsible for managing black and white list filtering rules of the scanned URL, URL parameters and returned results (the black and white list can be modified by the operation and maintenance personnel to change the filtering rules).

(6) The override detection module: and (4) carrying out flow replay based on the existing rule and the existing algorithm, and judging whether the override exists or not after the result of comparing multiple requests is verified by the cosine similarity algorithm and the black and white list.

(7) A report management module: the system is responsible for displaying the detection result and providing the request return result to confirm whether the override exists or not, can visually confirm whether the false alarm exists or not, and can directly inform the service attribution party to process without manual confirmation when the strict return result white list verification is started.

Referring to fig. 7, fig. 7 is a schematic flowchart of a method for detecting a server unauthorized vulnerability according to an embodiment of the present invention.

Firstly, collecting a plurality of requests carrying URLs, and respectively recording a return result res0 and a hypertext Transfer Protocol (HTTP) response code 0;

secondly, filtering URLs according to HTTP response codes, file extension names and white list rules of returned results, and deleting URLs with failed domain name resolution;

thirdly, acquiring user identity information cookie _ a and cookie _ B according to a login mode used for service identification of a domain name to which the URL belongs and account passwords of a user A and a user B which are pre-configured;

fourthly, requesting URL with the identity information of the user A, and recording a return result res _ a0 and an HTTP status code _ a 0;

fifthly, reconstructing the URL or post body information of the request according to the known sensitive parameters (for example, replacing the user id of the user A with the user id of the user B), and recording a return result res _ a1 and an HTTP status code _ a 1;

and sixthly, determining whether the interface forms the override or not through cosine similarity algorithm verification and black/white list verification.

Referring to fig. 8, fig. 8 is a schematic flowchart of a method for detecting a server unauthorized vulnerability according to an embodiment of the present invention.

Firstly, collecting a plurality of requests carrying URLs, and respectively recording a return result res0 and an HTTP response code 0;

fourthly, recording a return result res _ a2 and an HTTP status code _ a2 of the URL requested by the user A;

fifthly, re-requesting the same URL by using the identity information of the user B and recording return results res _ B2 and code _ B2;

Referring to fig. 9, fig. 9 is a schematic flowchart of a method for detecting a server unauthorized vulnerability according to an embodiment of the present invention.

fourthly, modifying the sensitive parameters in the identity information cookie _ a of the user A into the corresponding parameters of the user B (the user id of the user A is replaced by the user id of the user B), and recording a return result res _ a3 and an HTTP status code _ a 3;

and fifthly, determining whether the interface forms an override or not through cosine similarity algorithm verification and black/white list verification.

In summary, the embodiments of the present invention have the following beneficial effects:

(1) the detection accuracy of the unauthorized vulnerability is improved, and 100% accuracy can be achieved under the condition that a strict blacklist verification mechanism is started and rule configuration is completed.

(2) The automation degree of the unauthorized loophole is improved, the suspicious return result is collected to the management platform to realize loophole trackability, the detection cost is reduced, and the closed loop of the detection flow is realized.

The above description is only an example of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present invention are included in the protection scope of the present invention.

Claims

1. A method for detecting server vulnerabilities, the method comprising:

when the similarity between the first response result and the second response result meets a similarity condition, determining that a vulnerability exists in an interface of the server aiming at the target address;

when the similarity between the first response result and the second response result meets the similarity condition and the second response result comprises any error information in a white list, determining that no vulnerability exists in an interface aiming at the target address in the server;

and when the similarity between the first response result and the second response result meets the similarity condition and the second response result does not include any error information in the white list, determining whether the interface aiming at the target address in the server has a bug or not by judging whether the second response result includes any sensitive information in the black list or not.

2. The method of claim 1, wherein prior to sending the first network request to the server to access the destination address based on the identity information of the first user, the method further comprises:

collecting a plurality of network requests sent to the server and response results sent by the server in response to the network requests;

filtering the acquired network requests according to at least one of response codes included in the response results, file extensions included in the network requests and the white list, and filtering out network requests with failed address resolution;

acquiring the identity information of the user corresponding to the network request obtained after filtering;

selecting two different users as the first user and the second user according to the acquired identity information, selecting a network request corresponding to the first user from the filtered network requests, and adding the identity information of the first user to the selected network request to form the first network request.

3. The method of claim 2, wherein the filtering the collected network requests according to at least one of a response code included in the response result, a file extension included in the network request, and the white list comprises:

filtering out network requests meeting at least one of the following conditions from the collected network requests:

the file extension name included in the network request is null;

the response code included in the response result of the network request is used for representing that the server fails to receive the response code;

and the response result of the network request comprises any error information in the white list.

4. The method of claim 2, wherein the obtaining the filtered identity information of the user corresponding to the network request comprises:

determining the domain name of the resource locator in the network request obtained after filtering and/or the login mode of the corresponding service fingerprint;

configuring an account and a password of the user according with the login mode;

and sending a network request for accessing the target address based on the account and the password of the user to the server, and receiving the identity information of the user returned by the server in response to the network request for accessing the target address based on the account and the password of the user.

5. The method of claim 1, wherein modifying the parameter associated with both the first user and the second user in the first network request comprises at least one of:

replacing the identity information of the first user in the first network request with the identity information of the second user integrally;

replacing the sensitive parameter in the identity information of the first user in the first network request with the corresponding sensitive parameter in the identity information of the second user;

replacing the serial number of the first user included in the resource locator in the first network request with the serial number of the second user;

wherein the resource locator in the first network request comprises the destination address and the sequence number of the first user.

6. The method according to claim 1, wherein the determining that the interface for the target address in the server has a bug when the similarity between the first response result and the second response result satisfies a similarity condition comprises:

determining a similarity between the first response result and the second response result;

and when the similarity exceeds a similarity threshold value, determining that a vulnerability exists in an interface aiming at the target address in the server.

7. The method of claim 6, wherein determining the similarity between the first response result and the second response result comprises:

performing word segmentation processing on the first response result and the second response result respectively to obtain first word segmentation information and second word segmentation information;

performing aggregation processing on the first word segmentation information and the second word segmentation information to obtain aggregation information;

determining the word frequency of the first word segmentation information relative to the aggregation information to obtain first word frequency information;

determining the word frequency of the second word segmentation information relative to the aggregation information to obtain second word frequency information;

determining the cosine similarity between the first word frequency information and the second word frequency information as the similarity between the first response result and the second response result.

8. The method of claim 1, wherein when the similarity between the first response result and the second response result satisfies the similarity condition, and the second response result does not include any error information in the white list, determining whether there is a vulnerability in an interface of the server for the target address by determining whether the second response result includes any sensitive information in a black list includes:

when the similarity between the first response result and the second response result meets the similarity condition, the second response result does not include any error information in the white list, and includes any sensitive information in the black list, determining that a vulnerability exists in an interface aiming at the target address in the server;

and when the similarity between the first response result and the second response result meets the similarity condition, and the second response result does not include any error information in the white list and does not include any sensitive information in the black list, determining that no vulnerability exists in an interface aiming at the target address in the server.

9. The method according to any one of claims 1 to 8,

after the determining that the interface in the server for the target address has a bug, the method further comprises:

recording the vulnerability existing in the server for the interface of the target address in real time, and generating a report comprising the interface information with the vulnerability;

the method further comprises the following steps:

responding to a white list configuration operation, and updating the error information submitted by the white list configuration operation into the white list;

and responding to a blacklist configuration operation, and updating the sensitive information submitted by the white list configuration operation into the blacklist.

10. An apparatus for detecting server vulnerabilities, the apparatus comprising:

the unauthorized detection module is further configured to determine that a vulnerability exists in an interface of the server for the target address when the similarity between the first response result and the second response result meets a similarity condition;

the unauthorized detection module is further configured to determine that no vulnerability exists in an interface of the server for the target address when the similarity between the first response result and the second response result meets the similarity condition and the second response result includes any error information in a white list;

and when the similarity between the first response result and the second response result meets the similarity condition and the second response result does not include any error information in the white list, judging whether the second response result includes any sensitive information in a black list or not, and determining whether a vulnerability exists in an interface aiming at the target address in the server or not.

11. A computer-readable storage medium having stored thereon a computer program, wherein the computer program, when executed by a processor, implements the method for detecting a server vulnerability of any one of claims 1 to 9.

12. A terminal comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor is configured to implement the method for detecting a server vulnerability of any one of claims 1 to 9 when executing the computer program.