CN112287349A - Security vulnerability detection method and server - Google Patents

Abstract

The embodiment of the invention discloses a security vulnerability detection method, a server and a storage medium, wherein the method comprises the following steps: the method comprises the steps that a server side injects a first attack code of a cross-site script attack XSS into reference data to obtain target data; the reference data comprises data to be sent to a first client by the server through a Common Gateway Interface (CGI); and the server side constructs a first return packet according to the target data and sends the first return packet to the first client side through the CGI, wherein the first return packet is used for detecting an XSS vulnerability. In the invention, the server side injects the first attack code into the data to be sent to the first client side through the CGI so as to cover all variables of the first client side which quote the CGI layer, so that the coverage rate of the XSS attack code injection in the XSS vulnerability testing process can be improved, and various XSS vulnerabilities can be tested.

Description

Security vulnerability detection method and server

Technical Field

The invention relates to the field of computer security, in particular to the technical field of XSS vulnerability detection, and particularly relates to a security vulnerability detection method and a server side.

Background

Cross Site Scripting (XSS) refers to a malicious attacker inserting malicious HyperText Markup Language (HTLM) codes into a Web page, and when a user browses the Web page, the HTLM codes embedded in the Web page are executed, thereby achieving a special purpose of the malicious user. In practical applications, a user typically clicks on a link while browsing a website, using instant messaging software, and even while reading an email. An attacker can steal user information by inserting malicious code into the link. An attacker would typically encode the link in hexadecimal (or other encoding) in order to prevent the user from doubting its legitimacy. A web site, upon receiving a request containing malicious code, creates a page containing the malicious code that appears to be a legitimate page that the web site should generate. Many popular message book and forum programs allow users to post posts that contain HTML. If the user A publishes a post containing a malicious script, the malicious script executes to steal session information of the user B when the user B browses the post.

XSS vulnerabilities are one of the most common vulnerabilities in Web applications. If a site (e.g., a Web site running a Web server) does not have a method to prevent XSS vulnerabilities, then XSS vulnerabilities exist and are difficult to defend against. At present, a Common way to detect an XSS vulnerability is to replace an input parameter value of a Common Gateway Interface (CGI), that is, to insert a malicious code into a link, and detect whether a page returned by the link has the malicious code. The CGI is physically a program running on the server that provides an interface to interact with the client HTML page. However, this approach can only detect XSS vulnerabilities injected from CGI with malicious code, and cannot accurately detect other types of XSS vulnerabilities, such as storage-type XSS vulnerabilities.

Disclosure of Invention

The embodiment of the invention provides a security vulnerability detection method and a server side, which can cover all externally introduced variables in a CGI flow and can improve the coverage rate of XSS injection in the XSS vulnerability testing process.

In a first aspect, an embodiment of the present invention provides a security vulnerability detection method, which may include: the method comprises the steps that a server side injects a first attack code of a cross-site script attack XSS into reference data to obtain target data; the reference data comprises data to be sent to a first client by the server through a Common Gateway Interface (CGI); and the server side constructs a first return packet according to the target data and sends the first return packet to the first client side through the CGI, wherein the first return packet is used for detecting an XSS vulnerability.

In the embodiment of the invention, the server side injects the first attack code into the data to be sent to the first client side through the CGI so as to cover all variables of the first client side for quoting the CGI layer, so that the coverage rate of the XSS attack code injection in the XSS vulnerability testing process can be improved, and various XSS vulnerabilities can be further tested.

In an optional implementation manner, before the server injects a first attack code of a cross-site scripting attack XSS into the reference data to obtain target data, the method further includes:

the server receives a first access request from the first client, wherein the first access request is used for acquiring the reference data;

the server side obtains the reference data aiming at the first access request from a memory or a database.

In the implementation mode, the server side obtains corresponding data from the memory or the database according to the first access request from the first client side, and the operation is simple.

In an optional implementation manner, the receiving, by the server, the first access request from the first client includes:

the CGI receives the first access request from the first client;

the server side obtaining the reference data for the first access request from a memory or a database comprises:

the CGI sends a data acquisition request to a code injection module; the data acquisition request is used for requesting the reference data;

the code injection module obtains the reference data from the memory or the database;

the step that the server side injects a first attack code of cross site scripting (XSS) into the reference data to obtain target data comprises the following steps:

the code injection module injects a first attack code into the reference data to obtain the target data.

For some reasons (such as high overhead of object creation, or requiring security control for some operations, or requiring out-of-process access, etc.), the CGI directly accesses to the memory or the database (i.e., the storage background) causes a lot of troubles, and at this time, an intermediate proxy layer can be added between the CGI and the storage background. The code injection module can inject attack codes into the reference data and can also play a role of an intermediate proxy layer (such as a proxy layer).

In this implementation, the CGI obtains reference data from the memory or the database through the code injection module, which is equivalent to adding an intermediate proxy layer between the CGI and the storage background, so that the data obtaining speed can be increased, and other problems caused by the CGI directly accessing the storage background can be avoided.

In an optional implementation manner, before the CGI sends a data acquisition request to a code injection module, the method further includes:

the CGI sends an attack code acquisition request to the code injection module, wherein the attack code acquisition request is used for requesting the first attack code;

the CGI receives the first attack code from the code injection module;

the sending, by the CGI, the data acquisition request to the code injection module includes:

and the CGI sends the data acquisition request carrying the first attack code or the identifier of the first attack code to the code injection module.

In this implementation manner, the CGI sends a data acquisition request carrying a first attack code or an identifier of the first attack code to a code injection module, the code injection module returns parameter data injected into the first attack code to the CGI, and the code injection module can accurately inject the attack code indicated by the CGI. In this implementation, after the CGI obtains the first attack code, the first attack code or the identifier of the first attack code may be carried in a plurality of data obtaining requests sent to the code injection module, and it is not necessary to obtain the attack code once each time data is obtained by the code injection module, which may reduce unnecessary operations.

In an optional implementation manner, before the code injection module injects the first attack code into the reference data to obtain the target data, the method further includes:

the code injection module acquires a reference definition from the memory or the database, wherein the reference definition is used for indicating the type of each character in the reference data;

the code injection module injecting a first attack code in the reference data to obtain the target data comprises:

and replacing data of the character string type in the reference data with the first attack code according to the reference definition to obtain the target data.

In the implementation mode, the data of each character string type in the reference data can be accurately and quickly determined according to the reference definition so as to accurately inject the attack code.

In an optional implementation manner, the first access request includes a first identifier, and the first identifier is used to indicate that the first client is a client for detecting an XSS vulnerability.

The XSS vulnerability testing task executed by the server side receives a first access request from a first client side; retrieving referenced data for the first access request from a memory or database; and constructing a first return packet according to the target data, and sending the first return packet to the first client through the CGI. The server can also execute tasks except the XSS vulnerability testing task. In practical applications, the server may interact with a part of the clients (the first client including the first identifier in the first access request) to test the XSS vulnerability, and may also process access requests of other clients (not including the first identifier) to perform other tasks. That is, the server is not limited to the XSS vulnerability testing task, and may also perform other tasks, such as other testing tasks.

In an optional implementation manner, the receiving, by the server, the first access request from the first client includes: the server receives the first access request sent by the first client through a browser; the first return package is used for displaying a target page on the browser, and the target page is used for detecting XSS vulnerabilities.

The server can receive a first access request sent by the first client through the browser through the CGI. The target page may include content, such as a pop box, that the browser has obtained by executing the XSS attack code. When the target page includes malicious content, it can be considered that an XSS vulnerability exists; in the event that the target page does not include malicious content, it may be considered that no XSS vulnerability exists. The malicious content refers to content obtained by the browser executing XSS attack codes. It can be understood that if the target page does not include malicious content, it indicates that an XSS vulnerability does not exist, that is, the browser and the server can effectively prevent XSS; otherwise, the XSS vulnerability is expressed, namely the browser and the server cannot effectively prevent XSS, and a measure for preventing XSS needs to be strengthened.

In the implementation mode, the server sends the first return packet used for displaying the target page on the browser of the first client to the first client, so that whether the XSS vulnerability is stored or not is tested, and the implementation is simple.

In an optional implementation manner, the receiving, by the server, the first access request from the first client includes: the server receives the first access request sent by the first client through a testing tool; the test tool runs on the first client and is used for detecting XSS vulnerabilities according to the first return package.

The testing tool may be an automated testing tool running on the first client that is dedicated to detecting XSS vulnerabilities. The first client sending the first access request through the testing tool may be that the testing tool simulates a user's normal user operation (corresponding to sending the first access request) of clicking a page or a link, scrolling a page, inputting a keyboard, and so on, so as to trigger a page interaction logic, i.e., an operation of interacting with the server. The test tool may scan the first return package (i.e., the page source code) for a particular code segment (i.e., the XSS attack code) in the first return package that must be processed; if such code is found to remain in the first returned package during the scan, then an XSS vulnerability is deemed to exist, otherwise, an XSS vulnerability is deemed to not exist. After the test tool detects a specific code segment, the test tool can record the current detection information, such as the detection time, the clicked link and the like; a test report may also be generated that accounts for the detected XSS. It can be understood that the test tool can automatically send the first access request to the server to trigger the page interaction logic, and scan the page source code after interaction to detect the XSS vulnerability, and the test efficiency is high and the operation is simple.

In the implementation manner, the server sends the first return packet to the first client, so that the testing tool running on the first client detects the XSS vulnerability according to the first return packet, and the testing efficiency can be effectively improved.

In an optional implementation manner, the step of injecting, by the server, a first attack code for cross-site scripting attack XSS in the reference data to obtain target data includes: and the server replaces the data of at least one character string type in the reference data with the first attack code to obtain the target data.

And the XSS replaces the data of the character string type in the data requested to be acquired by the first client side with the first attack code. In the implementation mode, any type of XSS can be simulated by replacing character string types in the reference data with attack codes, and the implementation is simple.

In an optional implementation, the method further includes: the server side injects a second attack code of XSS into the initial data to obtain intermediate data; the initial data comprises data to be sent to a second client by the server through the CGI; the second attack code is different from the first attack code; and the server side constructs a second return packet according to the intermediate data and sends the second return packet to the second client side through the CGI, wherein the second return packet is used for detecting an XSS vulnerability.

In the implementation mode, the server can inject different attack codes into data requested by different clients, so that XSS vulnerabilities of different types can be detected at the same time, and the detection efficiency is improved.

In an optional implementation manner, the first identifier is used to indicate that the first client is a client for detecting a first XSS vulnerability, and the first identifier corresponds to the first attack code; before the server injects a second attack code of XSS into the initial data to obtain intermediate data, the method further includes: the server receives a second access request from the second client, wherein the second access request is used for acquiring the initial data; the second access request comprises a second identifier, and the second identifier is used for indicating that the second client is a client for detecting a second XSS vulnerability; the second identification corresponds to the second attack code; the server side obtains the initial data aiming at the second access request from the memory or the database.

In the implementation mode, the server side injects corresponding XSS attack codes into data requested by each client side according to the identification of each client side, so that XSS vulnerabilities of different types can be detected simultaneously, the detection efficiency is improved, and the implementation is simple.

In an optional implementation manner, before the server constructs the first return packet according to the target data, the method further includes: and the server filters the content which can cause the script corresponding to the first attack code to be executed in the target data, and/or carries out HTML coding on the target data.

The server runs at least one method of filtering relevant content that would result in XSS script execution and/or at least one way of HTML coding content that is dynamically output to the page. In the method, at least one XSS defense strategy is executed before a return packet is constructed according to target data, and whether the XSS defense strategies can effectively defend XSS or not is verified.

In a second aspect, an embodiment of the present invention provides a server, where the server may include: the code injection module is used for injecting a first attack code of a cross-site scripting attack XSS into the reference data to obtain target data; the reference data comprises data to be sent to a first client by the server through a Common Gateway Interface (CGI); the CGI is used for constructing a first return packet according to the target data and sending the first return packet to the first client, and the first return packet is used for detecting an XSS vulnerability. The server may be a Web server or other type of server.

In an optional implementation manner, the server further includes: a receiving module, configured to receive a first access request from the first client, where the first access request is used to obtain the reference data; the CGI is further configured to retrieve the reference data for the first access request from a memory or a database. The interface module may be the CGI.

In an optional implementation manner, the CGI is specifically configured to receive the first access request from the first client through the CGI; sending a data acquisition request to a code injection module; the data acquisition request is used for requesting the reference data;

the code injection module is specifically configured to obtain the reference data from the memory or the database; and injecting a first attack code into the reference data to obtain the target data.

In an optional implementation manner, the CGI is further configured to send an attack code acquisition request to the code injection module, where the attack code acquisition request is used to request the first attack code; receiving the first attack code from the code injection module; and sending the data acquisition request carrying the first attack code or the identifier of the first attack code to the code injection module.

In an optional implementation manner, the code injection module is further configured to obtain a reference definition from the memory or the database, where the reference definition is used to indicate a type of each character in the reference data; and replacing data of the character string type in the reference data with the first attack code according to the reference definition to obtain the target data.

In an optional implementation manner, the first access request includes a first identifier, and the first identifier is used to indicate that the first client is a client for detecting an XSS vulnerability.

In an optional implementation manner, the receiving module is specifically configured to receive the first access request sent by the first client through a browser; the first return package is used for displaying a target page on the browser, and the target page is used for detecting XSS vulnerabilities.

In an optional implementation manner, the receiving module is specifically configured to receive the first access request sent by the first client through a testing tool; the test tool runs on the first client and is used for detecting XSS vulnerabilities according to the first return package.

In an optional implementation manner, the code injection module is specifically configured to replace data of at least one string type in the reference data with the first attack code to obtain the target data.

In an optional implementation manner, the code injection module is further configured to inject a second attack code of XSS into the initial data to obtain intermediate data; the initial data comprises data to be sent to a second client by the server through the CGI; the second attack code is different from the first attack code; the CGI is further used for constructing a second return packet according to the intermediate data and sending the second return packet to the second client through the CGI, wherein the second return packet is used for detecting XSS vulnerabilities.

In an optional implementation manner, the first identifier is used to indicate that the first client is a client for detecting a first XSS vulnerability, and the first identifier corresponds to the first attack code; the receiving unit is further configured to receive a second access request from the second client, where the second access request is used to obtain the initial data; the second access request comprises a second identifier, and the second identifier is used for indicating that the second client is a client for detecting a second XSS vulnerability; the second identification corresponds to the second attack code; the CGI is further configured to retrieve the initial data for the second access request from the memory or the database.

In an optional implementation manner, the server further includes: and the processing unit is used for filtering the content which can cause the script corresponding to the first attack code to be executed in the target data, and/or performing HTML coding on the target data.

In a third aspect, an embodiment of the present invention provides another server, where the server includes a receiver and a transmitter, and further includes: a processor adapted to implement one or more instructions; and a computer storage medium storing one or more instructions adapted to be loaded by the processor and to perform the method according to the first aspect as well as the optional implementations of the first aspect.

In a fourth aspect, embodiments of the present invention provide a computer storage medium storing one or more instructions adapted to be loaded by a processor and to perform the method according to the first aspect and the optional implementation manner in the first aspect.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a schematic diagram of a network architecture according to an embodiment of the present invention;

fig. 2A is a schematic diagram of a manual test scenario provided in an embodiment of the present invention;

fig. 2B is a schematic diagram of an automatic test scenario according to an embodiment of the present invention;

fig. 3 is a flowchart of a security vulnerability detection method according to an embodiment of the present invention;

fig. 4 is a flowchart of another security vulnerability detection method provided in the embodiment of the present invention;

fig. 5 is a flowchart illustrating an interaction between a server and a client in an XSS vulnerability detection process according to an embodiment of the present invention;

FIG. 6 is a schematic view of a browser interface according to an embodiment of the present invention;

FIGS. 7A and 7B are schematic diagrams illustrating page comparisons according to an embodiment of the present invention;

fig. 8 is a flowchart of another interaction between a server and a client in the XSS vulnerability detection process according to an embodiment of the present invention;

fig. 9 is another flowchart of interaction between a server and a client in an XSS vulnerability detection process according to an embodiment of the present invention;

fig. 10 is a schematic structural diagram of a server according to another embodiment of the present invention;

fig. 11 is a schematic structural diagram of another server provided in the embodiment of the present invention;

fig. 12 is a schematic structural diagram of a client according to an embodiment of the present invention.

Detailed Description

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

The terms "comprises" and "comprising," and any variations thereof, in the present description and claims, are intended to cover a non-exclusive inclusion, such as a list of steps or elements. A method, system, article, or apparatus is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, system, article, or apparatus.

The embodiment of the invention provides a security vulnerability detection method, namely a method for detecting XSS vulnerability, and aims to more clearly describe the scheme of the invention. Some of the knowledge associated with XSS is described below.

XSS attack: cross Site Scripting (Cross Site Scripting) is not to be confused with the abbreviations of Cascading Style Sheets (CSS), and is therefore abbreviated as XSS. The cross-site scripting attack is a common vulnerability in a Web program, and the XSS belongs to a passive attack mode used for a client, so that the hazard of the XSS is easily ignored. The principle is that an attacker embeds malicious codes in a webpage, and when other users browse the website, the codes can be automatically executed, so that the purpose of attack is achieved. XSS is not limited to visible page entries, but may be hidden form fields, get request parameters, and the like. The essence of XSS is: the malicious codes are not filtered and mixed with the normal codes of the website; the browser cannot tell which scripts are authentic, causing malicious scripts to be executed. It can be appreciated that if the server does not properly filter the text entered by the user, it is inserted into the HTML in a trade, which can easily cause injection holes. An attacker can construct a malicious code instruction by utilizing the bugs, and further, the data security is damaged by utilizing the malicious code.

Root cause of XSS existence: the parameters in the URL are not filtered sufficiently for the content that the user enters and submits to the Web server. If we can filter the parameters in the URL submitted by the user and all the submitted content sufficiently in the Web program to filter out all the illegal parameters and input content, then we will not cause "execute the script customized by the attacker in the browser of the user". However, sufficient and complete filtration is not practically possible. Because attackers have a variety of curiosity, you simply cannot imagine ways to bypass server-side filtering, most typically by variously encoding URLs and parameters to bypass XSS filtering.

XSS classification: XSS attacks can be classified into storage type, reflection type, and DOM (document Object model) type, depending on the source of the attack.

The attack steps of the storage-type XSS are as follows: (1) an attacker submits the malicious codes to a database of a target website; (2) when a user opens a target website, the website server side takes out the malicious codes from the database, splices the malicious codes in HTML and returns the HTML to the browser; (3) and after the user browser receives the response, analyzing and executing the response, and executing the malicious code mixed in the response. Such attacks are often found in web functions with user saved data, such as forum posts, merchandise comments, user private letters, and the like.

The attack procedure for reflection XSS is as follows: (1) an attacker constructs a special Uniform Resource Locator (URL), which contains malicious code; (2) when a user opens a URL with malicious codes, the website server takes out the malicious codes from the URL, splices the malicious codes in HTML and returns the HTML to the browser; (3) and after the user browser receives the response, analyzing and executing the response, and executing the malicious code mixed in the response. Reflection XSS differs from storage XSS by: malicious code of the storage type XSS is stored in a database, and malicious code of the reflection type XSS is stored in a URL. Reflective XSS vulnerabilities are common to functions that pass parameters through URLs, such as web site searches, jumps, and the like. Since the malicious URL needs to be actively opened by the user to take effect, the attacker often induces the user to click through a plurality of means.

The attack steps of DOM type XSS are as follows: (1) an attacker constructs a special URL, wherein the special URL comprises malicious codes; (2) a user opens a URL with malicious code; (3) and after receiving the response, the user browser analyzes and executes the response, and the front-end JavaScript extracts the malicious codes in the URL and executes the malicious codes. DOM-type XSS is distinguished from two XSS types: in the DOM XSS attack, malicious codes are taken out and executed by the browser end, the malicious codes belong to the security loopholes of front-end JavaScript, and the other two XSSs belong to the security loopholes of the server end.

Compromise of XSS attack: stealing data (namely Cookie) stored on a local terminal of a user, destroying a page structure, navigating to a malicious website, acquiring browser information, carrying trojans, illegally transferring accounts, forcibly sending emails, controlling a victim machine to attack other websites, stealing various user accounts and the like.

Prevention of XSS attack: both the storage type XSS and the reflection type XSS are inserted into response HTML after malicious codes are taken out by a server, and data which is intentionally written by an attacker is embedded into the code and is executed by a browser. There are two common approaches to preventing these two vulnerabilities: 1. pure front-end rendering is instead used to separate code and data. 2. The HTML is fully escaped. Pure front-end rendering process: (1) the browser loads a static HTML which does not contain any data related to the service; (2) the browser executes JavaScript in the HTML; (3) the JavaScript loads the service data through Ajax and calls a DOM Application Programming Interface (API) to update the service data on the page. Among them, Ajax, which is "asynchronous JavaScript and XML" (asynchronous JavaScript and XML), refers to a web page development technology for creating interactive web page applications. If splicing HTML is necessary, a suitable escape library is employed to fully escape the insertion points of the HTML template. The sufficient escaping of the HTML can comprise HTML coding when the untrusted data is put into an HTML tag, HTML Attribute coding when the untrusted data is put into an HTML Attribute, URL coding when the untrusted data is used as a URL parameter value, and the like. The above-mentioned untrusted data refers to input data of the user. At any time the user's input is untrusted, the output of the untrusted data is encoded accordingly. The above lists only a few common ways of preventing XSS, and other methods can be used to prevent XSS in practical applications.

In practical applications, some way of preventing XSS attacks is usually adopted to reduce XSS vulnerabilities. However, in practical applications, even if the server or the client uses some measures for preventing XSS attacks, XSS vulnerabilities may still exist. In order to reduce XSS vulnerabilities of a server or a client, the XSS vulnerabilities existing in the server or the client need to be found out in a test mode, and then a corresponding strategy is adopted to defend XSS. In addition, before a certain website is formally put into use, XSS vulnerabilities also need to be detected, and then corresponding preventive measures are taken. Currently, XSS vulnerabilities are typically manually detected using a generic XSS attack string. Specifically, the method for manually detecting the XSS vulnerability may be to input these test scripts in an input box (Textbox) in a web page or other places where data can be input, and see that a dialog box cannot be popped up, which indicates that the XSS vulnerability exists; it is also possible to see in the URL that there are variables that pass values through the URL to the Web server, replace the values of these variables with test scripts (i.e., replace the CGI input parameter values), and then see if the test scripts can execute. However, this way of manually detecting XSS vulnerabilities can only detect XSS vulnerabilities injected from CGI with malicious code, and cannot well detect storage-type XSS vulnerabilities and other forms of XSS vulnerabilities. That is, this test method cannot well simulate the storage-type XSS vulnerability and other forms of XSS vulnerability, i.e., the XSS has low attack code injection rate coverage, i.e., the XSS defense capability cannot be fully tested. In addition, the injection of XSS attack code in these methods for detecting XSS vulnerabilities usually needs to rely on existing URL rules, and has lack of timeliness and variability. Therefore, it is necessary to research an XSS vulnerability detection method with higher implantation coverage rate of XSS attack codes.

The XSS vulnerability detection method provided by the embodiment of the invention is mainly applied to two test scenes, namely a manual test scene and an automatic test scene. Fig. 1 is a schematic diagram of a network architecture according to an embodiment of the present invention. As shown in fig. 1, the network architecture may include a server and a cluster of clients; the client cluster may include a plurality of clients. As shown in fig. 1, the client cluster includes aclient terminal 1, clients 2, …, and a client N; as shown in fig. 1, the client terminal 2, …, and the client N may respectively perform a network connection with the server to interact with the server and log in a corresponding web page. In order to better understand the present solution, in the embodiment of the present invention, a client is selected as an example in the client cluster to describe a data interaction relationship between the client and the server.

Fig. 2A is a schematic diagram of a manual test scenario provided in an embodiment of the present invention. As shown in fig. 2A, the client sends an access request to the server through the browser; the server side acquires reference data aiming at the access request from a storage background (a database or a memory) through the CGI, injects an XSS attack code into the reference data through a code injection module, constructs a first return packet according to the reference data and sends the first return packet to the client side through the CGI; and the browser of the client displays a corresponding page according to the first return packet. In this test scenario, a user may determine whether an XSS vulnerability exists from a page displayed by a browser. In the case that the page includes malicious content, an XSS vulnerability may be considered to exist; in the case where the page does not include malicious content, it may be considered that no XSS vulnerability exists. The malicious content refers to content obtained by the browser executing XSS attack codes. It can be understood that if the page does not include malicious content, it indicates that an XSS vulnerability does not exist, that is, the browser and the server can effectively prevent XSS; otherwise, the XSS vulnerability is expressed, namely the browser and the server cannot effectively prevent XSS, and a measure for preventing XSS needs to be strengthened.

Fig. 2B is a schematic diagram of an automatic test scenario according to an embodiment of the present invention. As shown in fig. 2B, the test tool on the client sends an access request to the server; the server side acquires reference data aiming at the access request from a storage background (a database or a memory) through the CGI, injects an XSS attack code into the reference data through a code injection module, constructs a first return packet according to the reference data and sends the first return packet to the client side through the CGI; the testing tool scans the page source code corresponding to the first return packet; and if the specific code end (namely the tested attack code) is found to be remained in the page source code in the scanning process, considering that the XSS vulnerability exists, and otherwise, considering that the XSS vulnerability does not exist. The test tool comprises a scanning tool, and the scanning tool is used for scanning the page source code corresponding to the first return packet.

In order to improve the coverage rate of XSS attack code injection in the process of detecting XSS vulnerabilities and detect various XSS vulnerabilities, the data to be sent to the client by the server through the CGI are injected into the XSS attack codes, and therefore all variables of the client referring to the CGI layer are covered. It can be understood that, by increasing the injection route of the XSS attack code in this way, all externally-introduced variables in the CGI flow can be covered, and finally, the injection coverage rate of the XSS attack code in the XSS vulnerability detection is improved. The operations performed by the server will be described with reference to the drawings.

Fig. 3 is a flowchart of a security vulnerability detection method according to an embodiment of the present invention. As shown in fig. 3, the method may include:

301. and the server side injects a first attack code of the cross-site scripting attack XSS into the reference data to obtain target data.

The reference data comprises data to be sent to the first client by the server through a Common Gateway Interface (CGI). The server may be a Web server or other server. The server may be the server in fig. 2A and 2B. It is understood that the server may inject a first attack code of XSS in the reference data before sending the reference data to the first client through the CGI, so that the attack code of XSS can cover all variables of the first client that refer to the CGI layer. The first attack code of XSS can be set according to the test requirement. For example, a browser of a first client executes the first attack code to cause the first client to pop up a certain window. And for example, the browser of the first client executes the first attack code to be navigated to the malicious website. The first attack code may be used for detecting XSS vulnerability, such as a code that causes a tag of a client to be forcibly closed, "a" > < script > < alert (1) < ", a code that causes the client to trigger resource loading," < img src ═ alert (1) >, and the like, and embodiments of the present invention are not limited.

The step of injecting a first attack code for cross-site scripting to attack XSS into the reference data by the server to obtain target data may be: and the server replaces the data of at least one character string type in the reference data with the first attack code to obtain the target data. The XSS replaces the data of the character string type in the data requested to be acquired by the client side with the attack code. Therefore, by replacing the character string type data in the reference data with the attack code, any type of XSS can be simulated, and the implementation is simple. In the actual test process, the server can replace one section of codes at a time; and after the whole function test is finished, replacing a code and retesting. The XSS attack code can be used by the client (scan tool, or browser) to decide which kind. Optionally, before the server executes 301, the server receives a target instruction from the client, where the target instruction is used to instruct the server to inject a first attack code into data to be sent by the server to the first client through a common gateway interface CGI. It will be appreciated that the client may send instructions to the server to cause the server to inject the attack code indicated by the instructions. Thus, different attack codes can be conveniently tested.

302. The server side constructs a first return packet according to the target data and sends the first return packet to the first client side through the CGI.

The first return packet is used to detect XSS vulnerabilities. The client can be a mobile phone, a tablet computer, a notebook computer, a desktop computer and other devices capable of browsing webpages. And the first attack code injected by the server side in the reference data acts on the service assembly return packet logic.

One idea of XSS defense is: the input (and URL parameters) are filtered and the output is encoded. Namely, filtering all contents submitted by a client (namely, a user), and filtering parameters in the URL to filter out related contents which can cause the XSS script to be executed; then, the content dynamically output to the page is HTML-coded, so that XSS scripts cannot be executed in the browser. Although filtering the input can be bypassed, a significant portion of XSS attacks are also intercepted. The XSS vulnerability detection scheme provided by the embodiment of the invention can be used for detecting whether the service end can filter out related contents which can cause the XSS script to be executed, and/or reasonably performing HTML coding on the contents dynamically output to the page, so that the XSS script cannot be executed in the browser. It will be appreciated that the server side is run with at least one method of filtering relevant content that would result in XSS script execution and/or at least one way of HTML coding content that is dynamically output to the page. The related content may be "<", ">", "&", carriage return, space, and the like. For example, the code that filters "<" may be replace (str, "<", "<"). The server side can inject attack codes into data to be sent to the client side through the CGI, so as to verify the HTML coding mode of the content dynamically output to the page by the server side, and/or a strategy for filtering the relevant content which can cause XSS script to execute. It will be appreciated that the server may filter relevant content in the target data that causes the XSS script to execute prior toexecution 302, and/or HTML code the content for dynamic output to the page prior to building the return package.

For example, the HTML coding performed by the server includes "< turn to < > "and" > are converted into > "," is converted into & "," turn to " "," transitions to & # 39; before constructing a return packet according to target data, the server side can replace character strings in the target data with XSS attack codes, and construct the return packet according to the coded target data after executing HTML coding; and the client analyzes the return packet and executes the page source code obtained by analyzing the return packet, thereby testing whether the HTML coding mode executed by the server is effective. If the page source code displayed by the client does not contain the complete XSS attack code, the HTML coding mode executed by the server is effective; otherwise, the HTML coding mode executed by the server side is invalid. The definition of the complete XSS attack code is: the XSS attack code is not HTML coded and is consistent with the alternate XSS attack code.

In the embodiment of the invention, the server side injects the data to be sent to the client side through the CGI into the attack codes of the XSS so as to cover all variables of the client side which quote the CGI layer, so that the coverage rate of XSS injection in the process of testing XSS vulnerabilities can be improved, and further various XSS vulnerabilities can be tested.

In an optional implementation manner, before performingstep 301 and step 302, the server may further perform the following operations:

303. the server receives a first access request from a first client.

The first access request is used to obtain the reference data. Optionally, the first access request includes a first identifier, where the first identifier is used to indicate that the first client is a client for detecting an XSS vulnerability. In practical applications, the server may interact with a part of the clients (the clients including the first identifier in the access request) to detect XSS vulnerabilities, or may process access requests of other clients (not including the first identifier) to perform other tasks. That is, the service end is not limited to execute the XSS vulnerability detection task, and may also execute other tasks, such as other testing tasks, at the same time. Optionally, the first identifier is used to indicate that the first client is a client for detecting a first XSS vulnerability, and the first identifier corresponds to the first attack code.

As shown in fig. 2A, the receiving, by the server, the access request from the first client may be that the server receives the access request sent by the first client through a browser; the first return package is used for displaying a target page on the browser, and the target page is used for detecting XSS vulnerabilities. The target page may include content, such as a pop box, that the browser has obtained by executing the XSS attack code. When the target page includes malicious content, it can be considered that an XSS vulnerability exists; in the event that the target page does not include malicious content, it may be considered that no XSS vulnerability exists. It can be understood that if the target page does not include malicious content, it indicates that an XSS vulnerability does not exist, that is, the browser and the server can effectively prevent XSS; otherwise, the XSS vulnerability is expressed, namely the browser and the server cannot effectively prevent XSS, and a measure for preventing XSS needs to be strengthened.

The server receiving the access request from the first client may be that the server receiving the access request sent by the client through a test tool; the test tool runs on the first client and is used for detecting XSS vulnerabilities according to the first return package. The testing tool may be an automated testing tool running on the first client that is dedicated to detecting XSS vulnerabilities. The first client sending the access request through the testing tool may be that the testing tool simulates a conventional user operation (corresponding to sending the access request) of clicking a page or a link, scrolling the page, inputting a keyboard, and the like, so as to trigger a page interaction logic, that is, an operation of interacting with the server. The test tool may scan the first return package (i.e., the page source code) for a particular code segment (i.e., the XSS attack code) in the first return package that must be processed; if such code is found to remain in the first returned package during the scan, then an XSS vulnerability is deemed to exist, otherwise, an XSS vulnerability is deemed to not exist. The test tool may include a scan tool for scanning the page source code. After the test tool detects a specific code segment, the test tool can record the current detection information, such as the detection time, the clicked link and the like; a test report may also be generated indicating the detected XSS condition. The test report may include one or more of the following: task number, test starting time, test ending time and test duration; service information: the used account information, the accessed server information, the number of pages covered and which injection codes are executed; problematic page information: executing time, recording screens before and after operation, page codes with problems, code segments with specific problems, screenshots with problems and vulnerability security rating; and (3) processing aiming at the problems: process results (person, time, conclusion), create work order button, etc.

304. The server side obtains the reference data aiming at the first access request from a memory or a database.

The memory or database corresponds to the storage backend in fig. 2A and 2B.

In the implementation mode, the server acquires corresponding data from the memory or the database according to the first access request from the first client, and the operation is simple.

The first attack code in FIG. 3 may be attack code for testing a first XSS vulnerability. The first attack code may be a window popped up after being executed by the browser of the first client, or may be a malicious website navigated to a page currently displayed by the browser, or may be other malicious behaviors. In the actual test process, the capability of filtering attack codes of various XSSs by the service end and the client end is often required to be tested, and the capability of filtering the attack codes of a certain XSS by the service end and the client end is not only required to be tested. This requires the server to inject different attack codes into the data to be sent to the client through the CGI. For example, the server side injects a first attack code into data which the first client side requests to access, and then tests whether the server side and the first client side can filter the first attack code; and the server side injects the second attack code into the data which the second client side requests to access, so that the second attack code can be filtered out by the test server side and the second client side. The first attack code may pop up a window after being executed by the browser of the first client, and the second attack code may navigate a page currently displayed by the browser to a malicious website after being executed by the browser of the second client. It can be understood that, in order to detect XSS vulnerabilities more comprehensively, the server is required to inject different attack codes into data to be sent to the client through the CGI.

In order to improve the testing efficiency, the embodiment of the invention can simultaneously use a plurality of clients to detect XSS vulnerabilities caused by different attack codes. The following describes how to detect XSS vulnerabilities caused by multiple attack codes at the same time by taking the first client and the second client as an example. Fig. 4 is a flowchart of another security vulnerability detection method according to an embodiment of the present invention. In the process of executing 301 to 304, the server may further execute the vulnerability detection method flow in fig. 4. As shown in fig. 4, the method may include:

401. the server receives a second access request from a second client.

The second access request comprises a second identifier, and the second identifier is used for indicating that the second client is a client for detecting a second XSS vulnerability; the second identification corresponds to the second attack code. It can be understood that, if the server detects an access request including the second identifier, the server injects a second attack code into data requested by the access request; and if the server detects the access request comprising the first identifier, injecting a first attack code into the data requested by the access request.

402. The server obtains initial data for the second access request from a memory or a database.

403. And the server side injects a second attack code of XSS into the initial data to obtain intermediate data.

The initial data comprises data to be sent to a second client by the server through the CGI; the second attack code is different from the first attack code. The implementation of 403 may be the same as or different from the implementation of 301.

404. And the server side constructs a second return packet according to the intermediate data and sends the second return packet to the second client side through the CGI.

The second return packet is used for detecting XSS vulnerabilities. 404 are implemented in the same manner as 302.

In the embodiment of the invention, the server side injects different attack codes into the data requested by the access request according to the identification carried by the access request, can simultaneously detect XSS vulnerabilities caused by the different attack codes, and has high test efficiency.

The process of detecting the XSS vulnerability is further described below with reference to an interaction flow diagram between the server and the client in the process of detecting the XSS vulnerability. Fig. 5 is a flowchart illustrating interaction between a server and a client in an XSS vulnerability detection process according to an embodiment of the present invention. The process of detecting XSS vulnerabilities in FIG. 5 corresponds to the manual test scenario in FIG. 2A. As shown in fig. 5, the service end and the client end together complete XSS vulnerability detection, and the specific process of detecting the XSS vulnerability is as follows:

501. and the client sends an access request to the server through the browser.

The client can be a mobile phone, a tablet computer, a notebook computer, a desktop computer and other devices capable of browsing webpages. The browser may be a browser running on the client, such as a QQ browser. A client sends an access request to a server through a browser, so that a user can input a website or search information through an input box of the browser; it is also possible that the user triggers the page interaction logic by input operations such as clicking, action gestures, sliding, etc., e.g. clicking a link in a page, etc. Fig. 6 is a schematic view of a browser interface according to an embodiment of the present invention. Fig. 6 is a browser interface displayed by a client (i.e., a mobile phone). As shown in fig. 6, the browser interface includes an input box (see the uppermost dotted line box in fig. 6) through which a user can input search information or a web page address to open a corresponding web page; the browser interface includes a plurality of link addresses (one for each dashed box in fig. 6), and the user clicks one of the link addresses to open the corresponding web page. In the test process, a tester inputs a webpage address or search information through an input box, and clicks a link address of a browser interface, namely, an access request is sent to a server through a browser.

502. And the server side acquires reference data aiming at the access request from the storage background.

As shown in fig. 5, the server includes a CGI, a storage backend, and a code injection module. The storage background can be a memory of the server or a database associated with the server. And the code injection module is used for injecting the attack codes of the XSS into the reference data to obtain target data.

503. And the server side injects an XSS attack code into the reference data to obtain target data.

The step of the server injecting the XSS attack code into the reference data to obtain the target data may be that the server calls a code injection module to inject the XSS attack code into the reference data to obtain the target data.

504. And the server side constructs a return packet according to the target data.

505. And the server side sends a return packet to the client side through the CGI.

506. And the client executes the page source code corresponding to the return packet to display the target page.

The client executes the page source code corresponding to the return packet to display the target page may be that the client parses the return packet to obtain the page source code and executes the page source code to display the target page. The target page may include content, such as a pop box, that the browser has obtained by executing the XSS attack code. When the target page includes malicious content, it can be considered that an XSS vulnerability exists; in the event that the target page does not include malicious content, it may be considered that no XSS vulnerability exists. It can be understood that if the target page does not include malicious content, it indicates that an XSS vulnerability does not exist, that is, the browser and the server can effectively prevent XSS; otherwise, the XSS vulnerability is expressed, namely the browser and the server cannot effectively prevent XSS, and a measure for preventing XSS needs to be strengthened. Fig. 7A and fig. 7B are schematic diagrams illustrating page comparison according to an embodiment of the present invention. Fig. 7A shows a page (i.e., a normal page) displayed by a return packet from a server when the server does not inject an XSS attack code into data requested by the client. Fig. 7B shows a page displayed by a return packet parsed by the server when the server injects an attack code of XSS into data requested by the client. Comparing fig. 7A and fig. 7B, it can be seen that, when the server injects an XSS attack code into the data requested by the client, the page displayed by the client appears with an attack script, i.e., the content in the dashed box in fig. 7B.

In the embodiment of the invention, a client sends an access request to a server through a browser, and determines whether an XSS vulnerability exists through a page displayed by the browser; the method can simulate the actual application scene, and can conveniently and visually detect the XSS vulnerability.

Fig. 8 is another flowchart of interaction between a server and a client in the XSS vulnerability detection process according to an embodiment of the present invention. As shown in fig. 8, the service end and the client end together complete XSS vulnerability detection, and the specific process of detecting the XSS vulnerability is as follows:

801. and the client sends an access request to the server through the browser.

The implementation ofstep 801 may be the same as the implementation ofstep 501.

802. The CGI sends an attack code acquisition request to the code injection module.

As shown in fig. 8, the server includes a CGI, a storage backend, and a code injection module. The storage background can be a memory of the server or a database associated with the server. The attack code acquisition request is used for requesting a first attack code. The access request may carry an identification of the client. Optionally, before performingstep 802, the CGI determines, according to the identifier of the client carried in the access request, a first attack code to be acquired; and generating an attack code acquisition request, wherein the attack code acquisition request is used for requesting the first attack code. The CGI may store a correspondence between the client identifier and the attack code, and may determine the attack code corresponding to the client identifier, that is, the attack code to be acquired, according to the correspondence. Optionally, before performingstep 802, the CGI generates an attack code acquisition request, where the attack code acquisition request is used to request a first attack code. The first attack code is an attack code to be tested at the server side currently.

803. The code injection module obtains a first attack code.

The code injection module is associated with a memory that stores at least one attack code. Optionally, the code injection module obtains the first attack code requested by the attack code obtaining request from its associated memory.

804. The code injection module sends a first attack code to the CGI.

805. The CGI sends a data acquisition request to the code injection module.

The data acquisition request carries the first attack code and is used for requesting reference data.

806. And the code injection module acquires the reference data from the storage background.

The reference data is the data requested by the data acquisition request. The code injection module may determine the data to be obtained from the storage backend and the definition of the data to be obtained by parsing the data obtaining request.

807. The code injection module retrieves the reference definition from the storage backend.

The reference definition is used to indicate the type of characters in the reference data. It will be appreciated that the data for each string type in the reference data can be accurately determined from the reference definition.

808. And the code injection module replaces the data of the character string type in the reference data with the first attack code according to the reference definition to obtain target data.

Optionally, the code injection module may replace, according to the reference definition, data of each string type that is not marked in the reference data with the first attack code to obtain the target data. That is, the data of the string type noted in the reference data is not replaced with the first attack code. In order to ensure that the reference data sent to the client meets the service requirement, the server marks data of some character string types in the reference data, so that the code injection module does not replace the data with the first attack code.

809. The CGI constructs a return packet according to the target data.

810. The CGI sends a return packet to the client.

811. And the client executes the page source code corresponding to the return packet to display the target page.

The implementation ofsteps 808 to 811 can refer tosteps 504 to 506 in fig. 5.

In the embodiment of the application, the CGI obtains the reference data from the memory or the database through the code injection module, which is equivalent to adding an intermediate proxy layer between the CGI and the storage background, so that the data obtaining speed can be increased, and other problems caused by the fact that the CGI directly accesses the storage background can be avoided.

Fig. 9 is another flowchart of interaction between a server and a client in the XSS vulnerability detection process according to an embodiment of the present invention. The process of detecting XSS vulnerabilities in FIG. 9 corresponds to the automatic test scenario in FIG. 2B. As shown in fig. 9, the service end and the client end together complete XSS vulnerability detection, and the specific process of detecting the XSS vulnerability is as follows:

901. the client sends an access request to the server through the scanning tool.

901 is similar to 501 in figure 5. The scan tool may be part of an automated test tool running on the client that is dedicated to detecting XSS vulnerabilities. The client sends the access request through the scanning tool, and the scanning tool simulates conventional user operations of clicking a page or a link, scrolling the page, inputting a keyboard and the like by a user so as to trigger page interaction logic, namely, interaction operation with the server.

902. And the server side acquires reference data aiming at the access request from the storage background.

As shown in fig. 9, the server includes a CGI, a storage backend, and a code injection module. The storage background can be a memory of the server or a database associated with the server. And the code injection module is used for injecting the attack codes of the XSS into the reference data to obtain target data.

903. And the server side injects an XSS attack code into the reference data to obtain target data.

904. The service side executes an XSS defense strategy to process the target data.

The XSS defense policy executed by the server to process the target data may be: and the server filters the content which can cause the script execution corresponding to the attack code of the XSS in the target data, and/or carries out HTML coding on the target data. The server may also execute other XSS defense policies to process the target data, which is not limited in the embodiment of the present invention. It is understood that whether the XSS defense policy currently executed by the server can effectively defend XSS can be tested by the method in fig. 9. If the XSS defense strategy currently executed by the server side cannot effectively defend XSS, the XSS defense strategy needs to be further perfected, and the XSS defense strategy is one purpose of testing.

905. And the server side constructs a return packet according to the processed target data.

906. The service traffic sends a return packet to the client through the CGI.

905 to 906 may correspond in turn to 504 to 505 in fig. 5.

907. And the client scans the page source code obtained by analyzing the return packet through a scanning tool so as to determine the existence condition of the XSS vulnerability.

The client scans the page source code obtained by analyzing the return packet through the scanning tool to determine the existence condition of the XSS vulnerability, namely the page source code obtained by analyzing the return packet through the scanning tool and scanning the page source code to search a specific code segment (namely an XSS attack code); and if such codes are found to be remained on the page source codes in the scanning, determining that the XSS vulnerability exists, and otherwise, determining that the XSS vulnerability does not exist.

Optionally, after detecting a specific code segment (i.e., an attack code of the XSS), the test tool may record the detection information of this time, for example, the detection time, a clicked link, and the like; a test report may also be generated that accounts for the detected XSS. It can be understood that the test tool can automatically send the first access request to the server to trigger the page interaction logic, and scan the page source code after interaction to detect the XSS vulnerability, and the test efficiency is high and the operation is simple.

Optionally, the client may further execute the page source code corresponding to the return packet through the browser to display the target page. Therefore, whether the attack codes are executed by the browser or not and the attack scripts generated after the attack codes are executed can be tested.

In the embodiment of the invention, the server injects the attack code into the data requested by the client and sends the return packet to the client, so that a test tool running on the client can detect the XSS vulnerability according to the return packet, and the test efficiency can be effectively improved.

Based on the description of the embodiment of the security vulnerability detection method, the embodiment of the invention also discloses a server, and the server can run a computer program (comprising a program code). The server may perform the methods performed by the server in fig. 3-6 and fig. 9. Referring to fig. 10, the server may run the following modules:

acode injection module 1001, configured to inject a first attack code for a cross-site scripting attack XSS into reference data to obtain target data; the reference data comprises data to be sent to a first client by the server through a Common Gateway Interface (CGI);

the CGI1002 is configured to construct a first return packet according to the target data, and send the first return packet to the first client, where the first return packet is used to detect an XSS vulnerability.

In one embodiment, the server further includes: a receivingmodule 1003, configured to receive a first access request from the first client, where the first access request is used to obtain the reference data;

a CGI1002 further configured to retrieve said reference data for said first access request from a memory or a database.

In another embodiment, the first access request includes a first identifier, and the first identifier is used to indicate that the first client is a client for detecting XSS vulnerabilities.

In another embodiment, thereceiving module 1003 is specifically configured to receive the first access request sent by the first client through a browser; the first return package is used for displaying a target page on the browser, and the target page is used for detecting XSS vulnerabilities.

In another embodiment, thereceiving module 1003 is specifically configured to receive the first access request sent by the first client through a testing tool; the test tool runs on the first client and is used for detecting XSS vulnerabilities according to the first return package.

In another embodiment, thecode injection module 1001 is specifically configured to replace data of at least one string type in the reference data with the first attack code to obtain the target data.

In another embodiment, thecode injection module 1001 is further configured to inject a second attack code of XSS into the initial data to obtain intermediate data; the initial data comprises data to be sent to a second client by the server through the CGI; the second attack code is different from the first attack code;

the CGI1002 is further configured to construct a second return packet according to the intermediate data, and send the second return packet to the second client through the CGI, where the second return packet is used to detect an XSS vulnerability.

In another embodiment, the first identifier is used to indicate that the first client is a client for detecting a first vulnerability, and the first identifier corresponds to the first attack code;

the receiving unit is further configured to receive a second access request from the second client, where the second access request is used to obtain the initial data; the second access request comprises a second identifier, and the second identifier is used for indicating that the second client is a client for detecting a second XSS vulnerability; the second identification corresponds to the second attack code;

a CGI1002 further configured to retrieve the initial data for the second access request from the memory or the database.

According to the embodiment of the present invention, each step involved in the method executed by the server in fig. 3 to 6 and fig. 8 to 9 may be executed by each unit in the server shown in fig. 10. For example, 301 shown in fig. 3 is performed bycode injection module 1001 shown in fig. 10, 302 is performed by CGI1002 in fig. 10; as another example, 401 shown in fig. 4 may be performed by receivingmodule 1003 shown in fig. 10, 403 may be performed by CGI1002 in fig. 10, 403 may be performed bycode injection module 1002, 404 may be performed byCGI 1002.

According to the embodiment of the present invention, the units in the server shown in fig. 10 may be respectively or entirely combined into one or several other units to form a structure, or some unit(s) therein may be further split into multiple functionally smaller units to form a structure, which may achieve the same operation without affecting the implementation of the technical effects of the embodiment of the present invention. The units are divided based on logic functions, and in practical application, the functions of one unit can be realized by a plurality of units, or the functions of a plurality of units can be realized by one unit. In other embodiments of the present invention, the server-based terminal may also include other units, and in practical applications, these functions may also be implemented by being assisted by other units, and may be implemented by cooperation of multiple units.

According to another embodiment of the present invention, the server as shown in fig. 10 may be constructed by running a computer program (including program codes) capable of executing the steps involved in the respective methods as shown in fig. 3 to 6 and fig. 8 on a general-purpose computing device such as a computer including a processing element such as a Central Processing Unit (CPU), a random access storage medium (RAM), a read-only storage medium (ROM), and a storage element, and the security vulnerability detection method of the embodiment of the present invention may be implemented. The computer program may be recorded on a computer-readable recording medium, for example, and loaded and executed in the server via the computer-readable recording medium.

Based on the above description of the method embodiment and the apparatus embodiment, the embodiment of the present invention further provides a schematic structural diagram of a server, where theserver 1100 may generate relatively large differences due to different configurations or performances, and may include one or more Central Processing Units (CPUs) 1122 (e.g., one or more processors) and amemory 1132, and one or more storage media 1130 (e.g., one or more mass storage devices) storing anapplication program 1142 ordata 1144.Memory 1132 andstorage media 1130 may be, among other things, transient storage or persistent storage. The program stored on thestorage medium 1130 may include one or more modules (not shown), each of which may include a series of instruction operations for the server. Still further, thecentral processor 1122 may be provided in communication with thestorage medium 1130 to execute a series of instruction operations in thestorage medium 1130 on theserver 1100. Theserver 1100 may be a server provided by the present invention.

Theserver 1100 may also include one ormore power supplies 1126, one or more wired orwireless network interfaces 1150, one or more input-output interfaces 1158, and/or one ormore operating systems 1141, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, and so forth.

The steps performed by the server in the above embodiment may be based on the server structure shown in fig. 11. Specifically, thecentral processing unit 1122 can implement the functions of thecode injection module 1001 and theCGI 1002; the input/output interface 1158 may implement the function of thereceiving module 1003.

Further, please refer to fig. 12, which is a schematic structural diagram of a client according to an embodiment of the present invention. As shown in fig. 12, the client 1210 corresponds to the client in the above embodiments, and the client 1210 may include: at least oneprocessor 1201, e.g., a CPU, at least onenetwork interface 1204, auser interface 1203, amemory 1205, at least onecommunication bus 1202. Wherein acommunication bus 1202 is used to enable connective communication between these components. Theuser interface 1203 may include a Display screen (Display) and a Keyboard (Keyboard), and optionally, theuser interface 1203 may also include a standard wired interface and a standard wireless interface. Thenetwork interface 1204 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). Thememory 1205 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. Thememory 1205 may also optionally be at least one storage device located remotely from theprocessor 1201 described previously. As shown in fig. 12, thememory 1205, which is a computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

In theclient 1200 shown in fig. 12, thenetwork interface 1204 is mainly used to connect the client and the server; anduser interface 1203 is primarily an interface for providing input to a user; and theprocessor 1201 may be configured to invoke a device control application stored in thememory 1205 to implement: sending an access request to a server; receiving a return packet from a server; and analyzing the return packet to obtain a page source code and executing the page source code to display a target page, or analyzing the return packet to obtain a page source code and scanning the page source code to detect an XSS attack code.

It should be understood that theclient 1200 may perform the operations performed by the client in the foregoing embodiments, such as the operations performed by the client in fig. 5 and 8.

Further, here, it is to be noted that: an embodiment of the present invention further provides a computer storage medium, where the computer storage medium stores the aforementioned computer program executed by the server, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the security vulnerability detection method in the embodiment corresponding to fig. 3 to 6 or 8 can be executed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in the embodiments of the computer storage medium to which the present invention relates, reference is made to the description of the method embodiments of the present invention.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present invention, and it is therefore to be understood that the invention is not limited by the scope of the appended claims.

Claims (10)

1. A security vulnerability detection method is characterized by comprising the following steps:

the method comprises the steps that a server side injects a first attack code of a cross-site script attack XSS into reference data to obtain target data; the reference data comprises data to be sent to a first client by the server through a Common Gateway Interface (CGI);

and the server side constructs a first return packet according to the target data and sends the first return packet to the first client side through the CGI, wherein the first return packet is used for detecting an XSS vulnerability.

2. The method according to claim 1, wherein before the server injects a first attack code of a cross site scripting attack XSS into the reference data to obtain target data, the method further comprises:

the server receives a first access request from the first client, wherein the first access request is used for acquiring the reference data;

the server side obtains the reference data aiming at the first access request from a memory or a database.

3. The method of claim 2, wherein the first access request comprises a first identifier indicating that the first client is a client for detecting XSS vulnerabilities.

4. The method of claim 2, wherein the server receiving the first access request from the first client comprises:

the server receives the first access request sent by the first client through a browser; the first return package is used for displaying a target page on the browser, and the target page is used for detecting XSS vulnerabilities.

5. The method of claim 2, wherein the server receiving the first access request from the first client comprises:

the server receives the first access request sent by the first client through a testing tool; the test tool runs on the first client and is used for detecting XSS vulnerabilities according to the first return package.

6. The method according to any one of claims 2 to 5, wherein the server side injects a first attack code of cross site scripting attack XSS into the reference data to obtain target data, and the method comprises the following steps:

and the server replaces the data of at least one character string type in the reference data with the first attack code to obtain the target data.

7. The method of claim 6, further comprising:

the server side injects a second attack code of XSS into the initial data to obtain intermediate data; the initial data comprises data to be sent to a second client by the server through the CGI; the second attack code is different from the first attack code;

and the server side constructs a second return packet according to the intermediate data and sends the second return packet to the second client side through the CGI, wherein the second return packet is used for detecting an XSS vulnerability.

8. The method of claim 7, wherein the first identifier is used to indicate that the first client is a client for detecting a first XSS vulnerability, and wherein the first identifier corresponds to the first attack code; before the server injects a second attack code of XSS into the initial data to obtain intermediate data, the method further includes:

the server receives a second access request from the second client, wherein the second access request is used for acquiring the initial data; the second access request comprises a second identifier, and the second identifier is used for indicating that the second client is a client for detecting a second XSS vulnerability; the second identification corresponds to the second attack code;

the server side obtains the initial data aiming at the second access request from the memory or the database.

9. A server, comprising:

the code injection module is used for injecting a first attack code of a cross-site scripting attack XSS into the reference data to obtain target data; the reference data comprises data to be sent to a first client by the server through a Common Gateway Interface (CGI);

the CGI is used for constructing a first return packet according to the target data and sending the first return packet to the first client, and the first return packet is used for detecting an XSS vulnerability.

10. The server according to claim 9, wherein the server further comprises:

a receiving module, configured to receive a first access request from the first client, where the first access request is used to obtain the reference data;

the CGI is further configured to retrieve the reference data for the first access request from a memory or a database.

Images