File deletion vulnerability defense method, system and computer device
By establishing a file operation request table in the HTTP request of the Web server, identifying and storing the delete operation request, and using table matching to block malicious requests, the problem of inability to identify file deletion vulnerabilities in the existing technology is solved, and the security and stability of the Web server are improved.
Patent Information
- Application Number
- CN202111127570.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-09-26
- Publication Date
- 2025-08-12
- Estimated Expiration
- 2041-09-26
AI Technical Summary
The existing technology cannot identify and block file deletion vulnerabilities in a timely and accurate manner, which affects the security and stability of the Web server.
By extracting file operation request information from the HTTP request of the Web server, establishing a file operation request table, identifying and storing the delete operation request, using the delete operation request table to match subsequent requests, blocking malicious deletion requests that meet preset conditions.
It realizes timely and accurate identification and blocking of file deletion vulnerabilities, and improves the security and stability of the Web server.
Smart Images

Figure CN114116619B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of Web server security technology, and in particular to a method, system, and computer device for defending against file deletion vulnerabilities. Background Art
[0002] Web applications are applications based on a web browser / server architecture that access web pages from a web server or execute server-side web page programs through HTTP requests. Because they provide users with a graphical, easy-to-access, and intuitive interface for searching and browsing information on the internet, they are easy to use, require only a browser and minimal storage space, and are cross-platform. These advantages have led to their widespread adoption, and their variety and number are increasing. However, the widespread use of web applications has also led to the emergence of web security threats. Hackers exploit vulnerabilities in web applications to gain control of web servers, tamper with web page content, steal important data, and insert malicious code. For example, functions within web applications involving file deletion operations can expose file deletion vulnerabilities if the file name is controlled by a malicious user. This vulnerability allows attackers to arbitrarily delete any file on the server, impacting the secure and stable operation of business systems and servers, and even causing significant losses to service providers.
[0003] For file deletion vulnerabilities, the main discovery methods in existing technologies are white-box source code auditing and black-box manual testing. White-box source code auditing requires security personnel to use professional knowledge and special tools for source code analysis and debugging. On the basis of clarifying the internal structure and code details of the software, they gradually check statements, conditions, code paths, data flows, and various valid or invalid inputs to conduct security tests on the code of the entire site or program and discover program code vulnerabilities. However, this method is very time-consuming and requires testers to have strong professionalism. During the black-box testing process, since testers often cannot know the files outside the Web path, they can generally only perform verification tests on accessible Web front-end resource files such as JS, CSS, etc., and file deletion tests will affect the integrity of the program, making it impossible to achieve harmless detection. In addition, in the actual operating environment, existing technologies cannot promptly and accurately identify and block attacks against file deletion vulnerabilities.
[0004] Existing technologies are unable to promptly and accurately identify and block attacks based on file deletion vulnerabilities, and no effective solution has yet been proposed. Summary of the Invention
[0005] In this embodiment, a method, system, and computer device for defending against a file deletion vulnerability are provided to solve the problem in related technologies that attacks against the file deletion vulnerability cannot be identified and blocked in a timely and accurate manner.
[0006] First, in this embodiment, a method for defending against a file deletion vulnerability is provided, the method comprising:
[0007] Extracting a first file operation request from an HTTP request for accessing a Web server, and storing information of the first file operation request in a file operation request table in a time sequence of requests for accessing the Web server, wherein the information of the first file operation request includes at least: a file information parameter name, a file information parameter value, and a URL;
[0008] determining, based on the file operation request table, whether each of the first file operation requests is a delete operation request in the order of a time when the Web server is accessed, obtaining information about a first delete operation request in the file operation request table, and deleting information about the first file operation request preceding the first delete operation request;
[0009] storing the first deletion operation request information in the deletion operation request table; and deleting the deletion operation request information from the file operation request table;
[0010] For the second file operation request located after the first deletion operation request in the first file operation request, match it with the deletion operation request table in sequence based on the file information parameter name and URL; block the third file operation request that meets the preset conditions in the successfully matched file operation request.
[0011] In some embodiments, for a second file operation request that follows the first delete operation request in the first file operation request, after sequentially matching the file information parameter name and URL with the delete operation request table, the method further includes:
[0012] If the second file operation request fails to match the deletion operation request table, determining whether the second file operation request is a deletion operation request;
[0013] If the second file operation request is a delete operation request, storing information about the second file operation request in a delete operation request table, and deleting the information about the second file operation request from the file operation request table;
[0014] If the second file operation request is not a delete operation request, delete the information of the second file operation request from the file operation request table.
[0015] In some embodiments, determining, based on the file operation request table and in order of time of accessing the Web server, whether each of the first file operation requests is a delete operation request includes:
[0016] Accessing the Web server based on the file information parameter value in the information of the first file operation request stored in the file operation request table to obtain first return information and a corresponding Web address;
[0017] Sending the first file operation request to the Web server according to the first returned information;
[0018] Accessing the Web server based on the Web address to obtain second return information;
[0019] When the second returned information indicates access failure, the first file operation request is determined to be a deletion operation request.
[0020] In some embodiments, for a second file operation request in the first file operation request that follows the first deletion operation request, matching the second file operation request in the first file operation request with the deletion operation request table based on the file information parameter name and the URL in sequence includes:
[0021] If the file information parameter name and URL of the second file operation request information are consistent with the file information parameter name and URL of any deletion operation request information in the deletion operation request table, the match is successful.
[0022] In some embodiments, extracting the first file operation request from the HTTP request for accessing the Web server includes:
[0023] The first file operation request is obtained from the HTTP request for accessing the Web server through regular expression condition screening.
[0024] In some embodiments, accessing the Web server based on the file information parameter value in the information of the first file operation request stored in the file operation request table to obtain the first return information and the corresponding Web address includes:
[0025] Obtaining a first address based on a file information parameter value in the information of the first file operation request, accessing a corresponding file of the Web server according to the first address, and obtaining third return information;
[0026] When the third return information indicates that the access failed, obtaining multiple traversal addresses based on the directory information of the Web server, and accessing the file based on the traversal addresses until a fourth return information indicating that the access was successful is obtained;
[0027] The third or fourth return information of a successful access is set as the first return information; and the address of a successful access is set as the Web address corresponding to the file information parameter value.
[0028] In some embodiments, the file information parameter name is a parameter name including file name and path information; the file information parameter value is the file name and path information corresponding to the file information parameter name.
[0029] In some embodiments, the preset conditions include:
[0030] The file name of the file information parameter value of the second file operation request includes a preset file type; or
[0031] The path information of the file information parameter value of the second file operation request is a preset path.
[0032] In a second aspect, a file deletion vulnerability defense system is provided in this embodiment, the system comprising: a user terminal, a web server, and a web reverse proxy server; wherein the user terminal is connected to the web reverse proxy server via the Internet, and the web reverse proxy server is connected to the web server;
[0033] The user terminal is installed with a browser, which accesses the Web reverse proxy server by sending an HTTP request;
[0034] The Web reverse proxy server is used to execute any of the above-mentioned defense methods for file deletion vulnerabilities.
[0035] In a third aspect, a computer device is provided in this embodiment, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute any of the above-mentioned file deletion vulnerability defense methods.
[0036] Compared with related technologies, the file deletion vulnerability defense method provided in this embodiment extracts the file information parameters and URL of the HTTP request by screening and analyzing the HTTP request, and identifies the deletion operation by executing the request; by matching the characteristics with the deletion operation request, it determines whether other requests are malicious deletion requests and blocks the malicious requests, which solves the problem in related technologies that attacks against arbitrary file deletion vulnerabilities cannot be identified and blocked in a timely and accurate manner, and improves the security and stability of business system and server operations.
[0037] The details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:
[0039] Figure 1 It is a schematic diagram of the application system of the file deletion vulnerability defense method of the embodiment of the present application.
[0040] Figure 2 This is a flowchart of a method for defending against a file deletion vulnerability according to an embodiment of the present application.
[0041] Figure 3 This is a flowchart of a request information processing method when the second file operation request of an embodiment of the present application fails to match the deletion operation request table.
[0042] Figure 4 This is a flow chart of a method for determining whether a first file operation request is a deletion operation request according to an embodiment of the present application.
[0043] Figure 5 This is a flow chart of a method for accessing a Web server and obtaining first return information and a corresponding Web address according to an embodiment of the present application.
[0044] Figure 6 It is a flowchart of the method for defending against file deletion vulnerabilities in a preferred embodiment of the present application. DETAILED DESCRIPTION
[0045] In order to more clearly understand the purpose, technical solutions and advantages of the present application, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments.
[0046] Unless otherwise defined, the technical terms or scientific terms involved in this application should have the general meaning understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "an", "a", "the", "these" and the like in this application do not indicate quantitative restrictions, and they can be singular or plural. The terms "include", "comprise", "have" and any variants thereof involved in this application are intended to cover non-exclusive inclusions; for example, a process, method and system, product or device comprising a series of steps or modules (units) is not limited to the listed steps or modules (units), but may include unlisted steps or modules (units), or may include other steps or modules (units) inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "plurality" involved in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, and B exists alone. Generally, the character " / " indicates that the related objects are in an "or" relationship. The terms "first," "second," "third," etc. used in this application are only used to distinguish similar objects and do not represent a specific ordering of the objects.
[0047] A common way to access the Internet is for a user terminal to access a website through a browser. The access process is the process of sending an HTTP request to a web server and obtaining a response.
[0048] An HTTP request message consists of four parts: a request line, a request header, a blank line, and request data. The request line is divided into three parts: the request method, the URL, and the HTTP protocol version. A URL is a Uniform Resource Locator, an abstract unique identification method for a resource location, and consists of four parts: the protocol, the host, the port, and the path. The request header adds some additional information to the request message and consists of "name / value" pairs. The request data is optional; for example, a GET request does not have request data. The request data part is also called the body, and any other data can be added.
[0049] An HTTP response message consists of four parts: a status line, a response header, a blank line, and the response data. The status line consists of three parts: protocol version, status code, and status code description. The protocol version is the same as the request message. The status code is a three-digit code that indicates the status of the web server's Hypertext Transfer Protocol response. The first digit represents one of five response states: message, success, redirect, request error, and server error. The status code description is a brief description of the status code. The response data is used to store the data to be returned to the client.
[0050] The method provided in the embodiment of the present application can be executed in a computer device serving as a Web reverse proxy server. Figure 1 Schematic diagram of the application system of the method for defending against file deletion vulnerability of this embodiment. Figure 1 Only one server is shown in the figure), and the reverse proxy server 104 can deploy security measures such as firewalls. The reverse proxy server 104 may include one or more processors and a memory for storing data, wherein the processor may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA. The memory can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for defending against file deletion vulnerabilities in the present embodiment. The processor executes various functional applications and data processing by running the computer program stored in the memory, thereby implementing the above method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely located relative to the processor.
[0051] The user terminal 106 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above terminal. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.
[0052] In this embodiment, a method for defending against file deletion vulnerabilities is provided. Figure 2 This is a flowchart of the method for defending against file deletion vulnerabilities in this embodiment. This embodiment is a process in which a web reverse proxy server, after receiving an access request to a web server, filters and determines malicious file deletion requests from the request and blocks them. Figure 2As shown, the process includes the following steps:
[0053] Step S201: extract a first file operation request from an HTTP request for accessing a Web server, and store information of the first file operation request into a file operation request table in the chronological order of the request to access the Web server, wherein the information of the first file operation request includes at least: a file information parameter name, a file information parameter value, and a URL.
[0054] When a user accesses a Web site through a browser, the HTTP request sent by the user's browser will first be intercepted by the Web reverse proxy server due to the connection method between the Web reverse proxy server and the Web server. The embodiment of the present application determines whether the request is a file operation request based on whether the request data part of the HTTP request includes the file information parameter name and the file information parameter value. If the request is a file operation request, it is set as the first file operation request, and the file information parameter name, file information parameter value and URL of the first file operation request are stored in the file operation request table in the order of the time of accessing the Web server. The content of the file operation request table is a real-time judgment and addition of the HTTP request of the user to access the Web site.
[0055] Step S202: Based on the file operation request table, determine whether each first file operation request is a deletion operation request in the order of the time when the Web server is accessed, obtain the information of the first deletion operation request in the file operation request table, and delete the information of the first file operation request before the first deletion operation request.
[0056] The file operation type of the first file operation request may include operations such as adding, deleting, modifying, and querying files. In this embodiment of the present application, based on the chronological order of access to the Web server, the information of each first file operation request in the file operation request table is used to determine whether the request is a deletion operation request. When the first deletion operation request is found, the information of all first file operation requests preceding the first deletion operation request in the file operation request table can be deleted. In other words, if no deletion operation request is found, as long as it is determined that a first file operation request is not a deletion operation request, the information of the request can be deleted from the file operation request table.
[0057] Step S203: Store the information of the first deletion operation request into the deletion operation request table; and delete the information of the deletion operation request from the file operation request table.
[0058] After the first delete operation request is found, the information of the delete operation request is stored in the delete operation request table, and then the information of the delete operation request is deleted from the file operation request table. In this way, the file operation request table only includes the information of the second file operation request after the first delete operation request.
[0059] Step S204: For the second file operation request that follows the first deletion operation request in the first file operation request, match it with the deletion operation request table in sequence based on the file information parameter name and URL; and block the third file operation request that meets the preset conditions in the successfully matched file operation request.
[0060] For the second file operation request, the file information parameter name and URL of the request are matched against the file information parameter name and URL of each deletion operation request in the deletion operation request table, in the chronological order of the web server accesses. If a match is found with any deletion operation request, the second file operation request is considered to have a deletion function. If the file information parameter values of the second file operation request also meet the preset conditions, the second file operation request is considered to have malicious deletion intent. The request is then designated as a third file operation request and blocked.
[0061] Through the above steps S201 to S204, the HTTP requests for accessing the website are first screened to obtain requests carrying file information parameters, and the information of these requests is stored in the file operation request table. The file operation request table is then screened a second time to obtain the first deletion operation request. The information of this deletion operation request is stored in the deletion operation request table. The deletion operation request table matches subsequent requests in the file operation request table with the deletion operation request table. If the match is successful and the file information parameter value of the request also meets the preset conditions, it indicates that the request has a malicious deletion intention and is blocked. This embodiment solves the problem in the related art that attacks against arbitrary file deletion vulnerabilities cannot be identified and blocked in a timely and accurate manner, thereby improving the security and stability of business system and server operations.
[0062] In some of these embodiments, Figure 3 Flowchart of the request information processing method when the second file operation request fails to match the deletion operation request table, as shown in FIG. Figure 3 As shown, the method includes the following steps:
[0063] Step S301: If the second file operation request fails to match the deletion operation request table, determine whether the second file operation request is a deletion operation request.
[0064] If the information matching of any deletion operation request in the second file operation request and deletion operation request table is unsuccessful, it means that the resource or operation type required by the request is different from that of the existing deletion operation request. It is necessary to re-determine whether the request is a new deletion operation request. The judgment method is the same as that in step S202.
[0065] Step S302: If the second file operation request is a delete operation request, store the information of the second file operation request in a delete operation request table, and delete the information of the second file operation request from the file operation request table.
[0066] If it is determined that the second file operation request is a deletion operation request, the information of the deletion operation request is stored in the deletion operation request table, and then the information of the deletion operation request is deleted from the file operation request table.
[0067] Step S303: If the second file operation request is not a delete operation request, delete the information of the second file operation request from the file operation request table.
[0068] If it is determined that the second file operation request is not a deletion operation request, then there is no risk of malicious deletion for the request, and the request is allowed to access the Web server normally.
[0069] Through the above steps S301 to S303, when the information of the second file operation request fails to match the deletion operation request table, the information of the second file operation request is transferred to the deletion operation request table or deleted, ensuring real-time updating of the file operation request table, so that only the file operation requests to be determined are retained in the file operation request table; at the same time, it is ensured that the deletion operation request table saves all deletion operation request information that cannot match each other, providing a judgment basis for subsequent blocking.
[0070] Optionally, in some embodiments, Figure 4 A flow chart of a method for determining whether a first file operation request is a delete operation request. Figure 4 As shown, the method includes the following steps:
[0071] Step S401: Access the Web server based on the file information parameter value in the information of the first file operation request stored in the file operation request table to obtain first return information and a corresponding Web address.
[0072] The file operation request table stores information about each first file operation request, including the file information parameter name, file information parameter value, and URL of the request. This embodiment uses the file information parameter value of the first file operation request to obtain the file name and file path to be operated, accesses the Web server based on the file name and file path, and obtains first return information and the Web address corresponding to the file. The purpose of this access is to confirm whether the file exists on the Web server. The first return information of this embodiment is a response status code. When the first digit of the status code is 2, it indicates a successful access. When the first digit of the status code is a number other than 2, it indicates an access failure. The Web address corresponding to the file is the Web address when the access is successful.
[0073] Step S402: Send the first file operation request to the Web server according to the first returned information.
[0074] If the returned information is a status code indicating successful access, indicating that the file exists on the Web server, the first file operation request is completely sent to the Web server for execution.
[0075] Step S403: Access the Web server based on the Web address to obtain second return information.
[0076] The Web server is accessed again according to the Web address obtained in step S401 to confirm whether the file still exists on the Web server. The second returned information in this embodiment is a response status code.
[0077] Step S404: When the second returned information indicates access failure, the first file operation request is determined to be a deletion operation request.
[0078] If the returned information is a status code indicating successful access, indicating that the file still exists on the Web server, then it is determined that the first file operation request is not a delete operation request. If the returned information is a status code indicating failed access, indicating that the file no longer exists on the Web server, then it is determined that the first file operation request is a delete operation request.
[0079] Through steps S401 to S404, it is possible to determine whether the first file operation request is a delete operation request based on the first file operation request information stored in the file operation request table by actually executing the request. Since the first delete instruction in a malicious deletion attack is usually a normal file deletion operation and does not pose a security risk to the system, this embodiment uses this method to filter out delete operation requests from the first file operation request, providing a basis for subsequent blocking operations.
[0080] In some embodiments, the specific process of matching the first file operation request with the deletion operation request table is involved. Optionally, in S204, matching the second file operation request with the deletion operation request table based on the file information parameter name and URL in sequence includes:
[0081] If the file information parameter name and URL of the information of the second file operation request are consistent with the file information parameter name and URL of any deletion operation request information in the deletion operation request table, the match is successful.
[0082] The information of the second file operation request stored in the file operation request table includes: file information parameter name, file information parameter value and URL. The information used in the matching process is the file information parameter name and URL. Since the URL of the file operation request corresponds to the back-end processing logic of the request, if the URL and file information parameter name of the two file operation requests are consistent, it can be considered that the operation type and operation method of the two requests are consistent. Since one of the requests has been determined to be a deletion operation request in the previous step, the other request that is successfully matched can also be confirmed as a deletion operation request.
[0083] The matching method of this embodiment can more accurately identify a deletion operation request without performing an actual deletion operation and without affecting program integrity.
[0084] In some embodiments, the specific process of extracting the first file operation request from the HTTP request is involved. Optionally, the extracting the first file operation request from the HTTP request for accessing the Web server in S201 includes:
[0085] The first file operation request is obtained from the HTTP request for accessing the Web server through regular expression condition screening.
[0086] The format of HTTP requests is fixed. To extract file information parameter names, file information parameter values, and URL information from HTTP requests, you can use regular expressions. Regular expressions describe a string matching pattern that can be used to check whether a string contains a certain substring, replace a matching substring, or extract a substring that meets a certain condition from a string. The embodiments of the present application set the string to be matched according to the HTTP request format, extract the URL of the request from the request line, and extract the file information parameter name and file information parameter value from the request data. Among them, the file information parameter name can be filename and / or path. The file information parameter value can be the parameter value assigned to filename and / or path.
[0087] The method for obtaining the first file operation request in this embodiment can accurately screen a large number of HTTP requests in real time based on regular expressions to obtain the URL and file information parameters of the first file operation request.
[0088] Optionally, in some embodiments, Figure 5 A flowchart of a method for accessing a Web server based on a file information parameter value of a first file operation request and obtaining first return information and a corresponding Web address. Figure 5 As shown, the method includes the following steps:
[0089] Step S501: obtaining a first address based on a file information parameter value in the information of the first file operation request, accessing a corresponding file of the Web server according to the first address, and obtaining third return information.
[0090] The file name and file path to be operated are obtained based on the file information parameter value of the first file operation request, such as filename = / uploads / file / test.zip or path = / uploads / file / &file = test.zip. The file information parameter value includes the path and specific file name information. This information is then concatenated with the URL of the first file operation request to form a new web address, referred to as the first address, such as http: / / domain name / uploads / file / test.zip. The web server is accessed based on the first address to obtain the third return information. If the third return information is 2xx, it means that the file can be accessed normally.
[0091] Step S502: When the third return information indicates that the access failed, multiple traversal addresses are obtained based on the directory information of the Web server, and the file is accessed based on the traversal addresses until the fourth return information indicating that the access was successful is obtained.
[0092] If the third return message is not 2xx, the access failed. Since the file path in the file information parameter value may be a relative path, and the parent directory information of this relative path is not included in the parameter, it is necessary to obtain the web server's directory dictionary set as a possible file URL path, and confirm the access by traversal. If the fourth return message indicating successful access is finally obtained, it means that the file exists on the web server. If access is still unsuccessful, the file does not exist, the first file operation request is invalid, and no further actions on the request will be performed.
[0093] Step S503: The third or fourth return information of successful access is set as the first return information; and the address of successful access is set as the Web address corresponding to the parameter value of the file information.
[0094] If the third or fourth return information indicates a successful access, that information is set as the first return information; the address of the successful access is set as the web address corresponding to the parameter value of the file information. This web address serves as the final address for verifying whether the file exists.
[0095] Through the above steps S501 to S503, it is accurately determined whether the file exists on the Web server based on the file information parameter value of the first file operation request. If so, the accurate Web address of the file is obtained to facilitate subsequent access and operation.
[0096] In an embodiment of the present application, the file information parameter name is a parameter name containing a file name and / or path information; the file information parameter value is the file name and path information corresponding to the file information parameter name.
[0097] This embodiment clarifies the composition of file information parameters and clarifies the information type and specific data filtered from HTTP requests.
[0098] In some embodiments, a third file operation request that satisfies a preset condition among the successfully matched file operation requests is blocked, where the preset condition includes:
[0099] The file name of the file information parameter value of the second file operation request includes a preset file type; or the path information of the file information parameter value of the second file operation request is a preset path.
[0100] Preset file types include script files such as ASP / ASPX / PHP / JSP files, web application configuration files such as web.config / web.xml / datasource.xml, and front-end resource files such as JS / CSS. The default path is outside the attachment directory or the web root directory. Malicious users often use the .. / or ..\ characters to control directories. The detection module uses these matching characteristics to determine whether blocking is necessary.
[0101] By setting the preset conditions in this embodiment, the file information parameter values of the deletion operation request are restricted. According to the preset conditions, malicious deletion requests can be more accurately determined and effectively blocked.
[0102] The present embodiment is described and illustrated below through preferred embodiments.
[0103] Figure 6 This is a flowchart of the method for defending against file deletion vulnerabilities in this preferred embodiment. Figure 6 As shown, the method includes the following steps:
[0104] Step S601, filter the request line and request data of the HTTP request for accessing the Web server using a regular expression to obtain a first file operation request; store the parameter name, parameter value, and URL of the first file operation request including the file name and path information in a file operation request table in the chronological order of accessing the Web server.
[0105] Step S602: executing the first file operation request in the file operation request table in sequence according to the time sequence of accessing the Web server: determining whether there is a deletion operation request in the deletion operation request table.
[0106] Step S603: If there is a deletion operation request in the deletion operation request table, the parameter name and URL including the file name and path information of the first file operation request are matched with the parameter name and URL including the file name and path information of any deletion operation request in the deletion operation request table. If the parameter name and URL are consistent, it indicates a successful match.
[0107] Step S604, if the match is successful, then determine whether the file name of the file operation request contains a script file such as an ASP / ASPX / PHP / JSP file, a Web application configuration file such as web.config / web.xml / datasource.xml, a front-end resource file JS / CSS, or whether the path information is outside the attachment directory or the WEB root directory. If the file name or path information of the file operation request meets the above conditions, then the request is determined to be a malicious deletion request and the file operation request is blocked. If the match is successful, but the file name or path information does not meet the above conditions, it means that the request is a normal deletion request, and the request is allowed to be sent to the Web server and deleted from the file operation request table.
[0108] Step S605: If the match fails, determine whether the first file operation request is a delete operation request. The specific operation is: obtain the first address according to the file name and path information in the first file operation request parameter value, access the corresponding file on the Web server according to the first address, and obtain third return information.
[0109] Step S606: If the third returned information is status code 2xx, it indicates that the access is successful; if the returned information is not 2xx, it indicates that the access fails.
[0110] In step S607, if the third response indicates an access failure, multiple traversal addresses are obtained based on the Web server's directory information, and the file is accessed based on the traversal addresses until a fourth response indicating a successful access is obtained. If the access is unsuccessful, indicating that the file does not exist, the operation on the request is terminated and the file is deleted from the file operation request table.
[0111] Step S608: Set the third or fourth return information of successful access as the first return information; and set the address of successful access as the Web address corresponding to the file.
[0112] Step S609: Send a first file operation request to the Web server according to the first return information.
[0113] Step S610: Access the Web server based on the Web address to obtain second return information.
[0114] Step S611, when the second return information indicates access failure, the first file operation request is determined to be a deletion operation request; when the second return information indicates access success, the first file operation request is determined to be a non-deletion operation request, the operation on the request is terminated, and it is deleted from the file operation request table.
[0115] Step S612: After determining that the first file operation request is a deletion operation request, the parameter name, parameter value and URL of the deletion operation request including the file name and path information are stored in the deletion operation request table; and the information of the deletion operation request is deleted from the file operation request table.
[0116] Through the above steps S601 to S612, malicious file deletion requests can be accurately and timely identified from HTTP requests and blocked, and this identification and blocking method will not affect the integrity and security of the Web application, ensuring the safe and stable operation of the Web server.
[0117] It should be noted that the steps shown in the above process or the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.
[0118] In some embodiments, the present application also provides a file deletion vulnerability defense system, which includes a user terminal, a web server, and a web reverse proxy server. The user terminal is connected to the web reverse proxy server via the Internet, and the web reverse proxy server is connected to the web server. The user terminal is installed with a browser, which accesses the web reverse proxy server by sending an HTTP request.
[0119] The web reverse proxy server uses regular expressions to filter file operation requests in HTTP requests, determines whether the file operation request is a deletion request based on the requested file information parameters, and determines whether the deletion request is malicious by pre-setting conditions on the file name and path information. Requests confirmed to be malicious are blocked, while normal deletion requests and other file operation requests are not interfered with, allowing them to access the web server normally. The system in this embodiment can accurately and promptly identify and block malicious file deletion requests from HTTP requests, and this identification and blocking method does not affect the integrity and security of the web application, ensuring the safe and stable operation of the web server.
[0120] This embodiment further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.
[0121] Optionally, the computer device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.
[0122] It should be noted that, for specific examples in this embodiment, reference may be made to the examples described in the above embodiments and optional implementation modes, and will not be repeated in this embodiment.
[0123] It should be understood that the specific embodiments described herein are only used to explain this application and are not used to limit it. Based on the embodiments provided in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0124] Obviously, the accompanying drawings are merely examples or embodiments of the present application. A person skilled in the art can also apply the present application to other similar situations based on these drawings without inventive effort. Furthermore, it is understandable that, although the work involved in this development process may be complex and lengthy, certain design, manufacturing, or production changes based on the technical content disclosed in this application are merely routine technical means for a person skilled in the art and should not be considered to constitute a deficiency in the disclosure of the present application.
[0125] The term "embodiment" as used in this application refers to specific features, structures, or characteristics described in conjunction with the embodiment that can be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily mean that the embodiment is the same, nor does it mean that it is mutually exclusive with other embodiments and is independent or optional. It is understood, either explicitly or implicitly, by those skilled in the art that the embodiments described in this application can be combined with other embodiments when there is no conflict.
[0126] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.
Claims
1. A method for defending against file deletion vulnerabilities, characterized in that include: Extracting a first file operation request from an HTTP request for accessing a Web server, and storing information of the first file operation request in a file operation request table in a time sequence of requests for accessing the Web server, wherein the information of the first file operation request includes at least: a file information parameter name, a file information parameter value, and a URL; determining, based on the file operation request table, whether each of the first file operation requests is a delete operation request in the order of a time when the Web server is accessed, obtaining information about a first delete operation request in the file operation request table, and deleting information about the first file operation request preceding the first delete operation request; storing the first deletion operation request information in the deletion operation request table; and deleting the deletion operation request information from the file operation request table; For a second file operation request that follows the first delete operation request in the first file operation request, matching the second file operation request with the delete operation request table based on the file information parameter name and URL in sequence; and blocking a third file operation request that satisfies a preset condition in the successfully matched second file operation request; For a second file operation request that follows the first deletion operation request in the first file operation request, after sequentially matching the file information parameter name and URL with the deletion operation request table, the method further includes: If the second file operation request fails to match the deletion operation request table, determining whether the second file operation request is a deletion operation request; If the second file operation request is a delete operation request, storing information about the second file operation request in a delete operation request table, and deleting the information about the second file operation request from the file operation request table; If the second file operation request is not a delete operation request, delete the information of the second file operation request from the file operation request table.
2. The method according to claim 1, characterized in that Determining, based on the file operation request table and in order of time of accessing the Web server, whether each of the first file operation requests is a delete operation request includes: Accessing the Web server based on the file information parameter value in the information of the first file operation request stored in the file operation request table to obtain first return information and a corresponding Web address; Sending the first file operation request to the Web server according to the first returned information; Accessing the Web server based on the Web address to obtain second return information; When the second returned information indicates access failure, the first file operation request is determined to be a deletion operation request.
3. The method according to claim 1, characterized in that For a second file operation request located after the first deletion operation request in the first file operation request, matching the second file operation request in sequence with the deletion operation request table based on the file information parameter name and the URL includes: If the file information parameter name and URL of the second file operation request information are consistent with the file information parameter name and URL of any deletion operation request information in the deletion operation request table, the match is successful.
4. The method according to claim 1, wherein Extracting the first file operation request from the HTTP request for accessing the Web server includes: The first file operation request is obtained from the HTTP request for accessing the Web server through regular expression condition screening.
5. The method according to claim 2, characterized in that Accessing the Web server based on the file information parameter value in the information of the first file operation request stored in the file operation request table to obtain first return information and a corresponding Web address includes: Obtaining a first address based on a file information parameter value in the information of the first file operation request, accessing a corresponding file of the Web server according to the first address, and obtaining third return information; When the third return information indicates that the access failed, obtaining multiple traversal addresses based on the directory information of the Web server, and accessing the file based on the traversal addresses until a fourth return information indicating that the access was successful is obtained; The third or fourth return information of a successful access is set as the first return information; and the address of a successful access is set as the Web address corresponding to the file information parameter value.
6. The method according to any one of claims 1 to 5, characterized in that The file information parameter name is a parameter name including file name and path information; the file information parameter value is the file name and path information corresponding to the file information parameter name.
7. The method according to claim 6, characterized in that The preset conditions include: The file name of the file information parameter value of the second file operation request includes a preset file type; or The path information of the file information parameter value of the second file operation request is a preset path.
8. A file deletion vulnerability defense system, characterized in that include: User terminal, Web server, Web reverse proxy server; wherein, the user terminal is connected to the Web reverse proxy server via the Internet, and the Web reverse proxy server is connected to the Web server; The user terminal is installed with a browser, which accesses the Web reverse proxy server by sending an HTTP request; The Web reverse proxy server is used to execute the file deletion vulnerability defense method according to any one of claims 1 to 7.
9. A computer device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute the method for defending against a file deletion vulnerability according to any one of claims 1 to 7.
Citation Information
Patent Citations
File processing method and related device
CN108681594A