XSS vulnerability detection method, device, equipment and medium

Abstract

The present application provides a method, device, equipment and medium for detecting XSS vulnerabilities, which deletes any user attribute parameter in a first request packet, adds a corresponding request packet identifier at the original position of the deleted user attribute parameter, generates at least one second request packet and sends it to a server, receives at least one first response packet returned by the server, obtains a target first request packet corresponding to the target request packet identifier when a target request packet identifier exists in any first response packet, deletes the target request packet identifier in the target first request packet, and adds a load that can make a cross-site scripting attack XSS vulnerability attack successful in the target first request packet according to the parameter organization form in the target first request packet, generates a target request packet and sends it to a server, receives a second response packet returned by the server, controls the Web application to be detected to render the second response packet, and obtains a first detection result. The present application improves the user experience.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a method, device, equipment and medium for detecting XSS vulnerabilities. Background Art

[0002] Cross-site scripting (XSS) is a security vulnerability that attackers can exploit to inject malicious client-side code on a website. When a user (victim) logs in to the website, the client will automatically run the malicious code. The attacker can break through the website's access rights and use various attacks such as resource theft, session hijacking, and phishing to impersonate the victim. Therefore, it is crucial to detect XSS vulnerabilities in websites.

[0003] In the prior art, the XSS vulnerability in the website is detected mainly by crawling the World Wide Web (Web) page of the HyperText Transfer Protocol (HTTP) protocol, and then parsing the Web page to obtain the Document Object Model (DOM) tree corresponding to the Web page; at the same time, the embedded URL link and call parameters in the Web page are extracted, and the corresponding external JavaScript file set is retrieved according to the uniform resource locator (URL) link and call parameter transmission to obtain the script content of the relevant request information; then, the HTTP response information returned by the server is retrieved to obtain the relevant script set, and the script set in the obtained response information and the script set in the request information retrieved from the URL link are subjected to similarity detection, and whether the XSS vulnerability exists is determined by whether the similarity is detected.

[0004] However, the existing technology needs to collect URL links separately, and it is impossible to detect XSS vulnerabilities on the website without any sense when the user normally visits the website, which may result in a poor user experience. Summary of the invention

[0005] The present application provides a method, device, equipment and medium for detecting XSS vulnerabilities to solve the problem that when users normally visit the website, it is impossible to detect XSS vulnerabilities on the website without any sense, resulting in a poor user experience.

[0006] In a first aspect, an embodiment of the present application provides a method for detecting an XSS vulnerability, including:

[0007] Deleting any user attribute parameter in the first request packet, and adding a corresponding request packet identifier at the original position of the deleted user attribute parameter to generate at least one second request packet, wherein the first request packet is generated by the global wide area network Web application to be detected, and the first request packet includes at least one user attribute parameter;

[0008] Sending the at least one second request packet to a server corresponding to the Web application to be detected;

[0009] Receive at least one first response packet returned by the server, and when a target request packet identifier exists in any first response packet, obtain a target first request packet corresponding to the target request packet identifier from the first request packet, each first response packet being obtained by the server according to a second request packet;

[0010] The target request packet identifier in the target first request packet is deleted, and according to the parameter organization form in the target first request packet, a payload that can enable a cross-site scripting attack XSS vulnerability attack to succeed is added to the target first request packet to generate a target request packet;

[0011] Sending the target request packet to the server;

[0012] A second response packet returned by the server is received, and the Web application to be detected is controlled to render the second response packet to obtain a first detection result, where the first detection result includes that an XSS vulnerability exists in the server or that an XSS vulnerability does not exist in the server.

[0013] In a possible design of the first aspect, controlling the Web application to be detected to render the second response packet to obtain the first detection result includes:

[0014] Sending a rendering instruction to the terminal device where the Web application to be detected is located, wherein the rendering instruction is used to instruct the Web application to be detected to render the second response packet;

[0015] A first detection result sent by the terminal device is received, where the first detection result is obtained according to a rendering result after the Web application to be detected executes the rendering instruction.

[0016] In another possible design of the first aspect, controlling the Web application to be detected to render the second response packet to obtain the first detection result includes:

[0017] Controlling the Web application to be detected to render the second response packet;

[0018] Acquire the current data value of the Document Object Model DOM tree by using the browser plug-in pre-installed in the Web application to be detected;

[0019] When the current data value is inconsistent with the original data of the DOM tree, the first detection result is that the server has an XSS vulnerability;

[0020] When the current data value is consistent with the original data of the DOM tree, the first detection result is that there is no XSS vulnerability in the server.

[0021] Optionally, a proxy plug-in is pre-installed in the Web application to be detected, and the proxy plug-in is used to proxy the Hypertext Transfer Protocol HTTP traffic of the Web application to be detected.

[0022] In another possible design of the first aspect, after receiving at least one first response packet returned by the server, the method further includes:

[0023] When no request packet identifier exists in any first response packet, a second detection result is generated, where the second detection result is used to indicate that no XSS vulnerability exists in the server.

[0024] In another possible design of the first aspect, before traversing the user attribute parameters in the first request packet, the method further includes:

[0025] The first request packet is obtained.

[0026] Optionally, obtaining the first request packet includes:

[0027] Receiving a first request packet sent by the Web application to be detected;

[0028] or,

[0029] In response to a user clicking operation on a control in the Web application to be detected, a first request packet is generated.

[0030] Optionally, the method further includes:

[0031] According to the data type of the data in the first request packet, the user attribute parameters in the first request packet are obtained.

[0032] In a second aspect, an embodiment of the present application provides a device for detecting an XSS vulnerability, including:

[0033] a processing module, configured to delete any user attribute parameter in a first request packet, and add a corresponding request packet identifier at an original position of the deleted user attribute parameter to generate at least one second request packet, wherein the first request packet is generated by a global wide area network Web application to be detected, and the first request packet includes at least one user attribute parameter;

[0034] A sending module, used to send the at least one second request packet to a server corresponding to the Web application to be detected;

[0035] an acquisition module, configured to receive at least one first response packet returned by the server, and when a target request packet identifier exists in any first response packet, acquire a target first request packet corresponding to the target request packet identifier from the first request packet, wherein each first response packet is obtained by the server according to a second request packet;

[0036] The processing module is further used to delete the target request packet identifier in the target first request packet, and add a payload that can make the cross-site scripting attack XSS vulnerability attack successful in the target first request packet according to the parameter organization form in the target first request packet, so as to generate a target request packet;

[0037] The sending module is further used to send the target request packet to the server;

[0038] The processing module is further used to receive a second response packet returned by the server, and control the Web application to be detected to render the second response packet to obtain a first detection result, wherein the first detection result includes that the server has an XSS vulnerability or that the server does not have an XSS vulnerability.

[0039] In a possible design of the second aspect, the processing module is specifically configured to:

[0040] Sending a rendering instruction to the terminal device where the Web application to be detected is located, wherein the rendering instruction is used to instruct the Web application to be detected to render the second response packet;

[0041] A first detection result sent by the terminal device is received, where the first detection result is obtained according to a rendering result after the Web application to be detected executes the rendering instruction.

[0042] In another possible design of the second aspect, the processing module is specifically configured to:

[0043] Controlling the Web application to be detected to render the second response packet;

[0044] Acquire the current data value of the Document Object Model DOM tree by using the browser plug-in pre-installed in the Web application to be detected;

[0045] When the current data value is inconsistent with the original data of the DOM tree, the first detection result is that the server has an XSS vulnerability;

[0046] When the current data value is consistent with the original data of the DOM tree, the first detection result is that there is no XSS vulnerability in the server.

[0047] Optionally, a proxy plug-in is pre-installed in the Web application to be detected, and the proxy plug-in is used to proxy the Hypertext Transfer Protocol HTTP traffic of the Web application to be detected.

[0048] In another possible design of the second aspect, after receiving at least one first response packet returned by the server, the processing module is also used to generate a second detection result when no request packet identifier exists in any first response packet, and the second detection result is used to indicate that the server does not have an XSS vulnerability.

[0049] In another possible design of the second aspect, before traversing the user attribute parameters in the first request packet, the acquisition module is also used to acquire the first request packet.

[0050] Optionally, the acquisition module is specifically used to: receive a first request packet sent by the Web application to be detected;

[0051] or,

[0052] In response to a user clicking operation on a control in the Web application to be detected, a first request packet is generated.

[0053] Optionally, the acquisition module is further used to acquire user attribute parameters in the first request packet according to a data type of the data in the first request packet.

[0054] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor, a transceiver, a memory, and computer program instructions stored in the memory and executable on the processor, wherein the processor is used to implement the first aspect and the methods provided by various possible designs when executing the computer program instructions.

[0055] In a fourth aspect, an embodiment of the present application may provide a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect and the methods provided by various possible designs.

[0056] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement the first aspect and the methods provided by various possible designs.

[0057] The detection method, device, equipment and medium of XSS vulnerability provided by the embodiment of the present application are as follows: by deleting any user attribute parameter in the first request packet, and adding the corresponding request packet identifier at the original position of the deleted user attribute parameter, generating at least one second request packet, sending at least one second request packet to the server corresponding to the Web application to be detected, receiving at least one first response packet returned by the server, obtaining the target first request packet corresponding to the target request packet identifier from the first request packet when there is a target request packet identifier in any first response packet, deleting the target request packet identifier in the target first request packet, and adding a load that can make the cross-site scripting attack XSS vulnerability attack successful in the target first request packet according to the parameter organization form in the target first request packet, generating the target request packet, sending the target request packet to the server, receiving the second response packet returned by the server, and controlling the Web application to be detected to render the second response packet, and obtaining the first detection result. It is possible to perform XSS vulnerability detection on the server corresponding to the Web application when the user uses the Web application in daily life, thereby improving the user's experience of use. At the same time, the present application also uses the second request packet to judge the possibility of the existence of XSS vulnerability in the server, and further detects it when the server may have XSS vulnerability, thereby effectively improving the efficiency of XSS vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0059] Figure 1 A schematic diagram of an application scenario of the XSS vulnerability detection method provided in an embodiment of the present application;

[0060] Figure 2 A flowchart of a first embodiment of a method for detecting XSS vulnerabilities provided in an embodiment of the present application;

[0061] Figure 3 A flow chart of a second embodiment of a method for detecting XSS vulnerabilities provided in an embodiment of the present application;

[0062] Figure 4 A schematic diagram of the structure of a device for detecting XSS vulnerabilities provided in an embodiment of the present application;

[0063] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0064] The above drawings show clear embodiments of the present disclosure, which will be described in more detail below. These drawings and text descriptions are not intended to limit the scope of the present disclosure in any way, but to illustrate the concepts of the present disclosure to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0065] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0066] Before introducing the embodiments of the present application, the application background of the embodiments of the present application is first explained:

[0067] XSS is a security vulnerability that allows attackers to embed malicious script code into pages that normal users visit. When normal users visit the page, the embedded malicious script code will be executed, thereby achieving the purpose of maliciously attacking users.

[0068] Among them, XSS vulnerabilities are mainly divided into the following three categories:

[0069] Stored XSS: Stored XSS scripts are injected scripts that are permanently stored on the target server, such as in personal information or published articles. If there is no filtering or filtering is not strict, then these codes will be stored on the server. When the browser requests data, the script will be transferred from the server to the browser and executed.

[0070] Reflected XSS: The attacker prepares the attack link in advance and needs to trick the user into clicking the link to trigger the XSS code (there is no such page or content on the server). It is usually easy to appear on the search page. When the user clicks a malicious link, submits a form, or enters a malicious website, the web server will return the injected script (such as an error message, search results, etc.) to the user's browser. Since the browser believes that this response comes from a "trusted" server, the browser will execute this script.

[0071] DOM XSS: By modifying the original client code, the DOM environment in the victim's browser is changed, resulting in the execution of the payload. In other words, the page itself has not changed, but because the DOM environment has been maliciously modified, client code is included in the page and accidentally executed.

[0072] In a specific application scenario, when users browse websites, use instant messaging software, or even read emails, they usually click on links. Attackers can steal user information by inserting malicious code into the link. Attackers usually encode the link in hexadecimal (or other encoding methods) to prevent users from doubting its legitimacy. After receiving a request containing malicious code, the website will generate a page containing malicious code, and this page looks like a legitimate page that the website should generate. For example, many forum programs allow users to post posts containing HTML and javascript. If user A posts a post containing a malicious script, when user B browses this post, the malicious script will be executed, thereby stealing user B's personal information and achieving the purpose of impersonating user B.

[0073] Attackers can make users execute their predefined malicious scripts in the browser, which can cause imaginable harm, such as hijacking user sessions, inserting malicious content, redirecting users, using malware to hijack user browsers, breeding XSS worms, and even destroying websites, modifying router configuration information, etc. Therefore, it is very important to detect XSS vulnerabilities in websites.

[0074] In the prior art, XSS vulnerabilities in websites are detected mainly by crawling HTTP protocol web pages, and then parsing the web pages to obtain the DOM tree corresponding to the web pages; at the same time, the embedded URL links and call parameters in the web pages are extracted, and the corresponding external JavaScript file sets are retrieved according to the URL links and call parameter transmissions to obtain the script content of the relevant request information; thereafter, the HTTP response information returned by the server is retrieved to obtain the relevant script set, and the script set in the obtained response information and the script set in the request information retrieved from the URL link are subjected to similarity detection, and whether an XSS vulnerability exists is determined by whether similarity is detected.

[0075] However, the existing technology needs to collect URL links separately, and it is impossible to detect XSS vulnerabilities on the website without any sense when the user normally visits the website, which may result in a poor user experience.

[0076] In view of the above problems, the invention of the present application is conceived as follows: Since the prior art can only detect XSS vulnerabilities in a website when the website is tested, and users cannot access the website normally during the test, there is a problem of poor user experience. Based on this, the inventor found that when the user normally accesses the website, the corresponding request packet is obtained by proxying the http traffic, and the user attribute parameters (such as user name, mobile phone number, password, etc.) in the request packet are replaced with the request packet identifier. If the request packet identifier exists in the response packet returned by the server, it is considered that the server may have an XSS vulnerability. Further, the request packet identifier in the request packet is replaced with a load that can make the XSS vulnerability attack successful, and sent to the server. After receiving the response packet returned by the server, the Web application to be detected is controlled to render the second response packet, so that the detection result can be obtained without the user noticing, which can solve the problem of poor user experience in the prior art.

[0077] Exemplarily, the XSS vulnerability detection method provided in the embodiment of the present application can be applied to Figure 1 In a schematic diagram of an application scenario shown. Figure 1 A schematic diagram of an application scenario of the XSS vulnerability detection method provided in the embodiment of the present application is used to solve the above technical problems. Figure 1 As shown, the application scenario may include: a user terminal device 11, a proxy server 12, and a Web server 13, and the proxy server 12 is in communication connection with the user terminal device 11 and the Web server 13 respectively.

[0078] In this embodiment, the Web application to be detected is pre-installed in the user terminal device. When the user uses the Web application to be detected daily, in response to the user's click operation on the control in the Web application to be detected, a request packet is generated and sent to the proxy server 12.

[0079] Optionally, after receiving the request packet sent by the user terminal device, the proxy server 12 executes the program code of the XSS vulnerability detection method, and sends the processed request packet to the Web server 13. The Web server 13 receives the request packet sent by the proxy server 12, processes the request packet, generates a corresponding response packet, and sends it to the proxy server 12.

[0080] Optionally, the proxy server 12 may also control the Web application to be detected to render the response packet, thereby obtaining a detection result.

[0081] In actual applications, since the user terminal device installed with the Web application to be tested is also a processing device with data processing capabilities, the above Figure 1The proxy server in the application scenario shown can be implemented by a user terminal device. Among them, the proxy server can also be implemented by a terminal device (also referred to as a detection terminal device) that does not have the Web application to be tested installed. In the embodiments of the present application, the server, the user terminal device and the detection terminal device can be collectively referred to as an electronic device.

[0082] The technical solution of the present application is described in detail below through specific embodiments.

[0083] It should be noted that the following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0084] Figure 2 The following is a flow chart of the first embodiment of the method for detecting XSS vulnerabilities provided in the present application. Figure 2 As shown, the detection method of the XSS vulnerability may include the following steps:

[0085] S21: Delete any user attribute parameter in the first request packet, and add a corresponding request packet identifier at the original position of the deleted user attribute parameter to generate at least one second request packet.

[0086] In the embodiment of the present application, the execution subject of the embodiment is an electronic device, which can be a server, a user terminal device or a detection terminal device. The specific implementation method when the execution subject is a server, a user terminal device or a detection terminal device will be described in detail in the following steps.

[0087] It should be understood that when the execution subject is a user terminal device, the Web application to be detected needs to be pre-installed with a proxy plug-in, and the proxy plug-in is used to proxy the Hypertext Transfer Protocol HTTP traffic of the Web application to be detected.

[0088] Optionally, the user terminal device may also pre-install a self-signed certificate, and use the self-signed certificate to proxy Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) traffic of the Web application to be detected in the user terminal device.

[0089] Exemplarily, the proxy plug-in may be a burpsuite plug-in, or may be a proxy plug-in in other prior arts, and may be selected according to actual conditions, which is not limited in the embodiments of the present application.

[0090] Optionally, the web application to be detected may also proxy HTTPS and / or HTTP traffic of the web application to be detected through an existing tool or module such as mitmproxy.

[0091] In this step, the electronic device may process the pre-acquired first request packet to generate at least one second request packet, so as to subsequently utilize the at least one second request packet to obtain the possibility of an XSS vulnerability in the server.

[0092] The first request packet is generated by the Web application to be detected, and the first request packet includes at least one user attribute parameter;

[0093] Exemplarily, the user attribute parameter may be a user name, a user ID number, a phone number, a user's social account password, a bank card password, or other parameters related to user information that need to be protected. The embodiments of the present application do not impose specific restrictions on this.

[0094] Optionally, the request packet identifier may be a Universally Unique Identifier (UUID).

[0095] Exemplarily, the first request packet includes two user attributes and corresponding user attribute parameters (user name: admin; password: 123456), and the request package identifier is UUID. The electronic device will first delete admin, and add the corresponding request package identifier (UUID1) at the location of the deleted admin, so as to obtain a second request packet. The two user attributes and corresponding user attribute parameters in the second request packet are username: UUID1; password 123456. Similarly, the electronic device also needs to delete 123456, and add the corresponding request package identifier (UUID2) at the location of the deleted 123456, so as to obtain another second request packet. The two user attributes and corresponding user attribute parameters in the second request packet are username: admin; password UUID2.

[0096] S22: Send at least one second request packet to a server corresponding to the Web application to be detected.

[0097] Among them, the server corresponding to the Web application to be detected is Figure 1 Corresponding to the Web server in the embodiment.

[0098] For the server, it receives at least one second request packet sent by the electronic device, processes each second request packet to generate at least one first response packet, and sends the at least one first response packet to the electronic device.

[0099] Each first response packet is obtained by the server according to a second request packet.

[0100] S23: Receive at least one first response packet returned by the server, and when a target request packet identifier exists in any first response packet, obtain a target first request packet corresponding to the target request packet identifier from the first request packet.

[0101] In this step, the electronic device needs to retrieve the content in each first response packet to see if there is a target request packet identifier. When a target request packet identifier exists in any first response packet, it means that the first response packet may be an interface that generates an XSS vulnerability. Therefore, it is necessary to obtain the target first request packet corresponding to the target request packet identifier from the first request packet. The target request packet identifier may have an XSS vulnerability at the location of the target first request packet.

[0102] The number of first response packets is consistent with the number of second request packets.

[0103] S24: deleting the target request packet identifier in the target first request packet, and adding a payload that can enable a cross-site scripting attack (XSS) vulnerability attack to the target first request packet according to the parameter organization form in the target first request packet, to generate a target request packet;

[0104] In this step, after determining the interface where the target first request packet may generate an XSS vulnerability, it is necessary to further detect it to determine whether the server has an XSS vulnerability.

[0105] For example, the two user attributes and corresponding user attribute parameters in the first target request packet are username: UUID1 and password: 123456. In the first target request packet, the user attribute is the username, which may contain an interface that generates an XSS vulnerability. The electronic device deletes UUID1 and writes the code<svg / onload="alert(1)"> (that is, the payload) is added to the target first request packet to obtain the target request packet. The user attributes and corresponding user attribute parameters in the target request packet are the user names:<svg / onload="alert(1)"> ; Password: 123456.

[0106] Exemplarily, the load (English: payload) can be determined according to the parameter organization form (English: Content-Type) in the target first request packet. The specific implementation process can refer to the implementation method existing in the prior art, which will not be repeated here.

[0107] Exemplarily, after determining the load, the target first request packet may also be processed so as to subsequently add the load to the target first request packet. The following are five examples of processing the target first request packet.

[0108] 1) If the parameter organization format of the target first request packet is js, and the target request packet identifier is contained in double quotes or single quote variables, try to close the quotes and inject the xss payload into js.

[0109] 2) If the parameter organization format of the target first request packet is js, and the target request packet identifier is contained in a multi-line comment, the comment is closed in reverse and the xss payload is injected into js.

[0110] 3) The parameter organization form of the target first request packet is js, and the target request packet identifier is directly included in js, and the xss payload is injected into js.

[0111] 4) If the parameter organization form of the target first request packet is HTML, and the target request packet identifier is directly contained in the body tag, then the XSS payload in the form of a tag in HTML is injected. For example, the XSS payload can be as follows:<svg / onload="alert(1)"> , <img src＝x onerror＝alert(1)> , <script>alert(1)；< / script> wait.

[0112] 5) The parameter organization format of the target first request packet is html, and the target request packet identifier is included in the attributes of any tag. The target request packet identifier is included in double quotes or single quotes variables, then the quotes are closed and the xss payload of the tag attributes is injected. For example, the xss payload can be "onmouseover="alert(1)".

[0113] S25: Send the target request packet to the server;

[0114] For the server, it receives the target request packet sent by the electronic device, processes the target request packet to generate a second response packet, and sends the second response packet to the electronic device.

[0115] S26: receiving a second response packet returned by the server, and controlling the Web application to be detected to render the second response packet to obtain a first detection result.

[0116] In this step, the electronic device needs to receive the second response packet sent by the server in order to control the Web application to be detected to render the second response packet, thereby verifying whether there is an XSS vulnerability in the server.

[0117] The first detection result includes whether the server has an XSS vulnerability or the server does not have an XSS vulnerability.

[0118] A specific description is given by taking the execution subject as a server or a detection terminal device as an example. The server or detection terminal device sends a rendering instruction to the user terminal device where the Web application to be detected is located, and the rendering instruction is used to instruct the Web application to be detected to render the second response packet. At the same time, for the user terminal device where the Web application to be detected is located, the Web application to be detected is rendered using the second response packet according to the rendering instruction, and a first detection result is obtained according to the rendering result, and the first detection result is sent to the server or detection terminal device. The server or detection terminal device receives the first detection result sent by the user terminal device.

[0119] Take the user terminal device as an example for explanation. The user terminal device controls the web application to be detected to render the second response packet, and uses the browser plug-in pre-installed in the web application to be detected to obtain the current data value of the DOM tree. When the current data value is inconsistent with the original data of the DOM tree, the first detection result is that the server has an XSS vulnerability. When the current data value is consistent with the original data of the DOM tree, the first detection result is that the server does not have an XSS vulnerability.

[0120] The browser plug-in can be a plug-in developed by the user or a plug-in existing in the prior art, which can be determined according to actual needs, and the embodiments of the present application do not specifically limit this. The browser plug-in is mainly used to add js code on each page of the web application to be detected to enhance the usability of the web application to be detected, and monitor the data in the DOM tree.

[0121] The XSS vulnerability detection method provided by the embodiment of the present application is to delete any user attribute parameter in the first request packet, add a corresponding request packet identifier at the original position of the deleted user attribute parameter, generate at least one second request packet, send at least one second request packet to the server corresponding to the Web application to be detected, receive at least one first response packet returned by the server, and when there is a target request packet identifier in any first response packet, obtain the target first request packet corresponding to the target request packet identifier from the first request packet, delete the target request packet identifier in the target first request packet, and add a load that can make the cross-site scripting attack XSS vulnerability attack successful in the target first request packet according to the parameter organization form in the target first request packet, generate a target request packet, send the target request packet to the server, receive the second response packet returned by the server, and control the Web application to be detected to render the second response packet to obtain the first detection result. This solution can detect XSS vulnerabilities on the server corresponding to the Web application to be detected when the user uses the Web application to be detected in daily life, which improves the user's experience. At the same time, the present application also uses the second request packet to judge the possibility of the server having an XSS vulnerability, and further detects it when the server may have an XSS vulnerability, effectively improving the efficiency of XSS vulnerability detection.

[0122] Optionally, in some embodiments, after the electronic device receives at least one first response packet returned by the server, the method for detecting the XSS vulnerability also includes generating a second detection result when no request packet identifier exists in any first response packet, and the second detection result is used to indicate that no XSS vulnerability exists on the server.

[0123] Optionally, in some embodiments, before S21, the method for detecting the XSS vulnerability also includes obtaining a first request packet.

[0124] Taking the execution subject as a server or a detection terminal device as an example for specific description, the server or the detection terminal device receives a first request packet sent by the Web application to be detected, thereby obtaining the first request packet.

[0125] Taking the execution subject as a user terminal device as an example, the user terminal device generates a first request packet in response to a user clicking operation on a control in the Web application to be detected.

[0126] Optionally, in some embodiments, after obtaining the first request packet, the electronic device may also obtain user attribute parameters in the first request packet according to the data type of the data in the first request packet.

[0127] Exemplarily, the user attribute parameters can be GET type parameters or POST type parameters. Taking POST type parameters as an example, the electronic device can use the MIME header to determine the parameter organization format of the POST body. The parameter organization format can be json or xml, etc., and obtain the corresponding user attribute parameters according to the parameter organization format.

[0128] In this embodiment, the data in the request packet can be represented by code. If the request packet contains two user attributes and the corresponding user attribute parameters are username: admin; password: 123456, it can be represented by the code username=admin&password=123456. It should be understood that the electronic device can also represent the data in the request packet by other code forms, and the embodiment of the present application does not specifically limit this.

[0129] Figure 3 The following is a flow chart of the second embodiment of the method for detecting XSS vulnerabilities provided in the present application. Figure 3 As shown, the detection method of the XSS vulnerability may include the following steps:

[0130] S31: In response to a user clicking operation on a control in a Web application to be detected, a first request packet is generated and sent to a proxy server.

[0131] For the proxy server, the first request sent by the user terminal device is received.

[0132] S32: Delete any user attribute parameter in the first request packet, add a corresponding request packet identifier at the original position of the deleted user attribute parameter, generate at least one second request packet, and send the second request packet to the Web server.

[0133] For the Web server, it receives at least one second request packet sent by the proxy server, generates at least one first response packet according to the at least one second request packet, and sends the first response packet to the proxy server.

[0134] S32: Receive at least one first response packet returned by the Web server, and determine whether the first response packet contains the target request packet identifier. If not, generate a second detection result, which is used to indicate that the server does not have an XSS vulnerability; if yes, execute S33.

[0135] S33: Determine the first response packet with the target request packet identifier as the target first request packet, delete the target request packet identifier in the target first request packet, and add a payload that can successfully attack the cross-site scripting (XSS) vulnerability to the target first request packet according to the parameter organization form in the target first request packet, generate a target request packet, and send the target request packet to the Web server.

[0136] For the Web server, it receives the target request packet sent by the proxy server, generates a second response packet according to the target request packet, and sends it to the proxy server.

[0137] S34: Receive a second response packet sent by the Web server, and send a rendering instruction to the user terminal device.

[0138] The rendering instruction is used to instruct the Web application to be detected to render the second response packet.

[0139] For the user terminal device, the rendering instruction sent by the proxy server is received.

[0140] S35: The Web application to be detected uses the pre-installed browser plug-in to render the second response packet according to the rendering instruction and obtains a rendering result.

[0141] S36: Send the rendering result to the proxy server.

[0142] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0143] Figure 4 A schematic diagram of the structure of the XSS vulnerability detection device provided in the embodiment of the present application. Figure 4 As shown, the detection device for the XSS vulnerability includes:

[0144] The processing module 41 is used to delete any user attribute parameter in the first request packet, and add a corresponding request packet identifier at the original position of the deleted user attribute parameter to generate at least one second request packet, wherein the first request packet is generated by the global wide area network Web application to be detected, and the first request packet includes at least one user attribute parameter;

[0145] A sending module 42, configured to send at least one second request packet to a server corresponding to the Web application to be detected;

[0146] The acquisition module 43 is used to receive at least one first response packet returned by the server, and when there is a target request packet identifier in any first response packet, acquire the target first request packet corresponding to the target request packet identifier from the first request packet, and each first response packet is obtained by the server according to a second request packet;

[0147] The processing module 41 is further used to delete the target request packet identifier in the target first request packet, and add a payload that can make the cross-site scripting attack XSS vulnerability attack successful in the target first request packet according to the parameter organization form in the target first request packet, so as to generate a target request packet;

[0148] The sending module 42 is also used to send the target request packet to the server;

[0149] The processing module 41 is further used to receive a second response packet returned by the server, and control the Web application to be detected to render the second response packet to obtain a first detection result, wherein the first detection result includes whether an XSS vulnerability exists in the server or whether an XSS vulnerability does not exist in the server.

[0150] In a possible design of an embodiment of the present application, the processing module 41 is specifically configured to:

[0151] Sending a rendering instruction to the terminal device where the Web application to be detected is located, where the rendering instruction is used to instruct the Web application to be detected to render the second response packet;

[0152] A first detection result sent by a terminal device is received, where the first detection result is obtained according to a rendering result after the Web application to be detected executes a rendering instruction.

[0153] In another possible design of the embodiment of the present application, the processing module 41 is specifically configured to:

[0154] Control the web application to be detected to render the second response packet;

[0155] Utilize the browser plug-in pre-installed in the web application to be detected to obtain the current data value of the DOM tree;

[0156] When the current data value is inconsistent with the original data of the DOM tree, the first detection result is that the server has an XSS vulnerability;

[0157] When the current data value is consistent with the original data of the DOM tree, the first detection result is that there is no XSS vulnerability in the server.

[0158] Optionally, a proxy plug-in is pre-installed in the Web application to be detected, and the proxy plug-in is used to proxy the Hypertext Transfer Protocol HTTP traffic of the Web application to be detected.

[0159] In another possible design of an embodiment of the present application, after receiving at least one first response packet returned by the server, the processing module 41 is also used to generate a second detection result when no request packet identifier exists in any first response packet, and the second detection result is used to indicate that there is no XSS vulnerability in the server.

[0160] In another possible design of the embodiment of the present application, before traversing the user attribute parameters in the first request packet, the acquisition module 43 is also used to acquire the first request packet.

[0161] Optionally, the acquisition module 43 is specifically used to: receive a first request packet sent by the Web application to be detected;

[0162] or,

[0163] In response to a user clicking operation on a control in the Web application to be detected, a first request packet is generated.

[0164] Optionally, the acquisition module 43 is further configured to acquire user attribute parameters in the first request packet according to a data type of the data in the first request packet.

[0165] The XSS vulnerability detection device provided in the embodiment of the present application can be used to execute the XSS vulnerability detection method in any of the above embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0166] It should be noted that it should be understood that the division of the various modules of the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. And these modules can all be implemented in the form of software calling through processing elements; they can also be all implemented in the form of hardware; some modules can also be implemented in the form of software calling through processing elements, and some modules can be implemented in the form of hardware. In addition, all or part of these modules can be integrated together, or they can be implemented independently. The processing element described here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in the processor element or instructions in the form of software.

[0167] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 5 As shown, the electronic device may include: a processor 51, a transceiver 52, a memory 53, and computer program instructions stored in the memory 53 and executable on the processor 51. When the processor 51 executes the computer program instructions, the XSS vulnerability detection method provided in any of the aforementioned embodiments is implemented.

[0168] Optionally, the electronic device may further include an interface for interacting with other devices.

[0169] Optionally, the above-mentioned components of the electronic device may be connected via a system bus.

[0170] Optionally, the transceiver 52 is used to communicate with other computers, and the transceiver 52 constitutes a communication interface.

[0171] Optionally, in hardware implementation, the above Figure 4 In the embodiment shown: the sending module 42 and the obtaining module 43 correspond to the transceiver 52 in this embodiment. Figure 4 The processing module 41 in the illustrated embodiment corresponds to the processor 51 in this embodiment.

[0172] The memory 53 may be a separate storage unit or a storage unit integrated in a processor. The number of processors is one or more.

[0173] It should be understood that the processor 51 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0174] The system bus may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

[0175] All or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid state drive, magnetic tape, floppy disk, optical disc and any combination thereof.

[0176] The electronic device provided in the embodiment of the present application can be used to execute the XSS vulnerability detection method provided in any of the above method embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0177] An embodiment of the present application provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are executed on a computer, the computer executes the above-mentioned XSS vulnerability detection method.

[0178] The computer-readable storage medium mentioned above can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory, electrically erasable programmable read-only memory, erasable programmable read-only memory, programmable read-only memory, read-only memory, magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0179] Optionally, a readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0180] An embodiment of the present application also provides a computer program product, which includes a computer program. The computer program is stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, the above-mentioned XSS vulnerability detection method can be implemented.

[0181] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for detecting XSS vulnerabilities, characterized in that: include: Deleting any user attribute parameter in the first request packet, and adding a corresponding request packet identifier at the original position of the deleted user attribute parameter to generate at least one second request packet, wherein the first request packet is generated by the global wide area network Web application to be detected, and the first request packet includes at least one user attribute parameter; Sending the at least one second request packet to a server corresponding to the Web application to be detected; Receive at least one first response packet returned by the server, and when a target request packet identifier exists in any first response packet, obtain a target first request packet corresponding to the target request packet identifier from the first request packet, each first response packet being obtained by the server according to a second request packet; The target request packet identifier in the target first request packet is deleted, and according to the parameter organization form in the target first request packet, a payload that can enable a cross-site scripting attack (XSS) vulnerability attack to succeed is added to the target first request packet to generate a target request packet; Sending the target request packet to the server; A second response packet returned by the server is received, and the Web application to be detected is controlled to render the second response packet to obtain a first detection result, where the first detection result includes that an XSS vulnerability exists in the server or that an XSS vulnerability does not exist in the server.

2. The method according to claim 1, characterized in that The controlling the Web application to be detected to render the second response packet to obtain a first detection result includes: Sending a rendering instruction to the terminal device where the Web application to be detected is located, wherein the rendering instruction is used to instruct the Web application to be detected to render the second response packet; A first detection result sent by the terminal device is received, where the first detection result is obtained according to a rendering result after the Web application to be detected executes the rendering instruction.

3. The method according to claim 1, characterized in that The controlling the Web application to be detected to render the second response packet to obtain a first detection result includes: Controlling the Web application to be detected to render the second response packet; Obtaining the current data value of the Document Object Model DOM tree by using the browser plug-in pre-installed in the Web application to be detected; When the current data value is inconsistent with the original data of the DOM tree, the first detection result is that the server has an XSS vulnerability; When the current data value is consistent with the original data of the DOM tree, the first detection result is that there is no XSS vulnerability in the server.

4. The method according to claim 3, characterized in that A proxy plug-in is pre-installed in the Web application to be detected, and the proxy plug-in is used to proxy the Hypertext Transfer Protocol HTTP traffic of the Web application to be detected.

5. The method according to claim 1, characterized in that After receiving at least one first response packet returned by the server, the method further includes: When no request packet identifier exists in any first response packet, a second detection result is generated, where the second detection result is used to indicate that no XSS vulnerability exists in the server.

6. The method according to claim 1, characterized in that Before deleting any user attribute parameter in the first request packet and adding a corresponding request packet identifier at the original position of the deleted user attribute parameter to generate at least one second request packet, the method further includes: The first request packet is obtained.

7. The method according to claim 6, characterized in that The obtaining of the first request packet comprises: Receiving a first request packet sent by the Web application to be detected; or, In response to a user clicking operation on a control in the Web application to be detected, a first request packet is generated.

8. The method according to claim 6, characterized in that The method further comprises: According to the data type of the data in the first request packet, the user attribute parameters in the first request packet are obtained.

9. A device for detecting XSS vulnerabilities, characterized in that: include: a processing module, configured to delete any user attribute parameter in a first request packet, and add a corresponding request packet identifier at an original position of the deleted user attribute parameter to generate at least one second request packet, wherein the first request packet is generated by a global wide area network Web application to be detected, and the first request packet includes at least one user attribute parameter; A sending module, used to send the at least one second request packet to a server corresponding to the Web application to be detected; an acquisition module, configured to receive at least one first response packet returned by the server, and when a target request packet identifier exists in any first response packet, acquire a target first request packet corresponding to the target request packet identifier from the first request packet, wherein each first response packet is obtained by the server according to a second request packet; The processing module is further used to delete the target request packet identifier in the target first request packet, and add a payload that can make the cross-site scripting attack XSS vulnerability attack successful in the target first request packet according to the parameter organization form in the target first request packet, so as to generate a target request packet; The sending module is further used to send the target request packet to the server; The processing module is further used to receive a second response packet returned by the server, and control the Web application to be detected to render the second response packet to obtain a first detection result, wherein the first detection result includes that the server has an XSS vulnerability or that the server does not have an XSS vulnerability.

10. The device according to claim 9, characterized in that The processing module is specifically used for: Sending a rendering instruction to the terminal device where the Web application to be detected is located, wherein the rendering instruction is used to instruct the Web application to be detected to render the second response packet; A first detection result sent by the terminal device is received, where the first detection result is obtained according to a rendering result after the Web application to be detected executes the rendering instruction.

11. The device according to claim 9, characterized in that The processing module is specifically used for: Controlling the Web application to be detected to render the second response packet; Obtaining the current data value of the Document Object Model DOM tree by using the browser plug-in pre-installed in the Web application to be detected; When the current data value is inconsistent with the original data of the DOM tree, the first detection result is that the server has an XSS vulnerability; When the current data value is consistent with the original data of the DOM tree, the first detection result is that there is no XSS vulnerability in the server.

12. The device according to claim 11, characterized in that A proxy plug-in is pre-installed in the Web application to be detected, and the proxy plug-in is used to proxy the Hypertext Transfer Protocol HTTP traffic of the Web application to be detected.

13. The device according to claim 9, characterized in that After receiving at least one first response packet returned by the server, the processing module is further used to generate a second detection result when no request packet identifier exists in any first response packet, and the second detection result is used to indicate that there is no XSS vulnerability in the server.

14. The device according to claim 9, characterized in that Before deleting any user attribute parameter in the first request packet and adding a corresponding request packet identifier at the original position of the deleted user attribute parameter to generate at least one second request packet, the acquisition module is also used to acquire the first request packet.

15. The device according to claim 14, characterized in that The acquisition module is specifically used to: receive a first request packet sent by the Web application to be detected; or, In response to a user clicking operation on a control in the Web application to be detected, a first request packet is generated.

16. The device according to claim 14, characterized in that The acquisition module is further used to acquire the user attribute parameters in the first request packet according to the data type of the data in the first request packet.

17. An electronic device comprising: A processor, a transceiver, a memory, and computer program instructions stored in the memory and executable on the processor, wherein the processor is used to implement the XSS vulnerability detection method as described in any one of claims 1 to 8 when executing the computer program instructions.

18. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the XSS vulnerability detection method as described in any one of claims 1 to 8.

19. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, it is used to implement the XSS vulnerability detection method as described in any one of claims 1 to 8.

Images