Web application unauthorized access vulnerability detection method and device and storage medium

Abstract

The invention discloses a Web application unauthorized access vulnerability detection method and device and a storage medium, and relates to the technical field of data processing, and the method comprises the steps: carrying out session removal and request playback on a session request, and determining an unauthenticated session request according to a comparison result of the similarity of response contents before and after the request playback and a preset similarity threshold; performing user sensitive information unauthorized access vulnerability detection on the unauthenticated session requests and the session-free requests based on the identity recognition parameters, and filtering the requests with user sensitive information vulnerabilities according to a detection result to obtain residual requests; performing system sensitive information unauthorized access detection on the residual requests based on a preset large model, and determining system sensitive information vulnerabilities; and if the target request has the user sensitive information vulnerability or the system sensitive information vulnerability, determining that the target request is an unauthorized access request. Detection is carried out through combination of three modes, so that the detection accuracy is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a method, device, and storage medium for detecting unauthorized access vulnerabilities in Web applications. Background Art

[0002] Unauthorized access vulnerabilities in web applications are a common security risk. This means that attackers can directly access protected resources, such as databases, management backends, API interfaces, sensitive files, etc., without going through the authentication or authorization process. Such vulnerabilities may lead to data leakage, system tampering, or service interruption, threatening the security of enterprises and users. Usually, the main method of detecting unauthorized access vulnerabilities is to remove the session identifier or token in the request and replay the request. If the response status code is 200, it is considered that an unauthorized access vulnerability exists. However, the original intention of the design of the HTTP status code is to describe the response status, not to directly reflect permission issues. When the response status code is 200, it may mean that the request is successful, but it may also return a default page or error message instead of real data due to server configuration errors. Therefore, this method of detecting unauthorized access vulnerabilities has a high false alarm rate.

[0003] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device and storage medium for detecting unauthorized access vulnerabilities in Web applications, aiming to solve the technical problem of how to improve the accuracy of unauthorized access vulnerability detection.

[0005] To address the above-mentioned problems, the present application provides a method for detecting unauthorized access vulnerabilities in web applications. The method comprises: removing sessions and replaying requests with sessions, and determining unauthorized session requests based on a comparison result of the similarity between response content before and after the request replay and a preset similarity threshold; performing unauthorized access vulnerability detection for user sensitive information on the unauthenticated session requests and non-session requests based on identity identification parameters, and filtering requests with user sensitive information vulnerabilities based on the detection results to obtain remaining requests; performing unauthorized access vulnerability detection for system sensitive information on the remaining requests based on a preset large model to determine system sensitive information vulnerabilities; and determining that the target request is an unauthorized access request if the target request has the user sensitive information vulnerability or the system sensitive information vulnerability.

[0006] In one embodiment, the step of removing the session request and requesting replay for the session request, and determining the unauthenticated session request based on a comparison result of similarity between response content before and after the request replay and a preset similarity threshold, includes:

[0007] Replay the session request to obtain a first response;

[0008] When the first response is a normal and legal response, deleting the session with the session request and replaying the request to obtain a second response;

[0009] If the second response does not indicate that the access is unauthorized, comparing the similarity between the first response and the second response;

[0010] If the similarity between the first response and the second response is greater than the similarity threshold, it is determined that the session request is the unauthenticated session request.

[0011] In one embodiment, the step of detecting an unauthorized access vulnerability to user sensitive information for unauthenticated session requests and non-session requests based on identity identification parameters includes:

[0012] Acquire a first request containing a user identifier among the unauthenticated session request and the session-free request;

[0013] Obtaining a second request from the historical message, which has the same function as the first request but different request data;

[0014] Replace the second identity identification parameter in the second request with the first identity identification parameter in the first request;

[0015] Replaying the replaced second request, and obtaining a third response corresponding to the replaced second request;

[0016] If the similarity between the third response and the response corresponding to the first request is greater than the similarity threshold, it is determined that the first request has the user sensitive information vulnerability.

[0017] In one embodiment, before the step of obtaining from the historical message a second request having the same function as the first request but different request data, the step includes:

[0018] replaying the first request and the second request, and comparing whether corresponding responses are similar;

[0019] If not, it is confirmed that the request data of the first request and the second request are different.

[0020] In one embodiment, the step of performing unauthorized access detection on the remaining requests for system sensitive information based on a preset large model to determine system sensitive information vulnerabilities includes:

[0021] Inputting the fourth responses corresponding to the remaining requests into the large model, and determining whether the remaining requests contain system sensitive information, wherein the system sensitive information includes one or more of configuration information and monitoring information;

[0022] If the system sensitive information exists and the request path of the remaining requests contains the preset keyword, it is determined that the system sensitive information vulnerability exists.

[0023] In one embodiment, the step of inputting the responses corresponding to the remaining requests into the large model and determining whether the remaining requests contain system sensitive information includes:

[0024] determining a parsing strategy according to the format of the fourth response, and parsing the fourth response based on the parsing strategy to obtain a target text;

[0025] Segmenting the target text, and mapping the lexical units obtained after the segmentation into a structured vector sequence;

[0026] Performing weighted summation on the structured vector sequence based on a self-attention mechanism to obtain a global feature vector;

[0027] The global feature vector is converted into a probability distribution. If the confidence level of the probability of containing system sensitive information in the probability distribution is greater than a preset confidence threshold, it is determined that the system sensitive information exists.

[0028] In one embodiment, before the step of performing unauthorized access detection on the remaining requests to the system sensitive information based on the preset large model to determine the system sensitive information vulnerability, the method further includes:

[0029] Replay the remaining requests, and filter the authentication requests and / or error reporting requests in the remaining requests according to the request replay results;

[0030] Obtaining the business keywords in the fifth response corresponding to the remaining requests after filtering;

[0031] If the semantic similarity between the business keyword and the preset exempted business keyword is greater than a preset semantic similarity threshold, it is confirmed that the system sensitive information vulnerability does not exist.

[0032] In one embodiment, the step of replaying the remaining requests and filtering the authentication requests and / or error reporting requests in the remaining requests according to the request replay results includes:

[0033] Replay the remaining requests to obtain the fifth responses to the remaining requests;

[0034] If the fifth response reports an error, the request corresponding to the fifth response is filtered.

[0035] In addition, to achieve the above-mentioned purpose, the present application also proposes a rights issuance device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the Web application unauthorized access vulnerability detection method as described above.

[0036] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is executed by a processor, the steps of the Web application unauthorized access vulnerability detection method as described above are implemented.

[0037] This application provides a method for detecting unauthorized access vulnerabilities in Web applications, which uses three detection methods in sequence to perform unauthorized access detection. First, most authenticated requests are filtered through session authentication detection. Then, identity recognition parameters are used to detect unauthorized access vulnerabilities to user sensitive information. Finally, the remaining requests are combined with large-model semantic analysis to determine whether the response message contains system sensitive information, and unauthorized access vulnerabilities to system sensitive information are detected. By combining the three methods for analysis and detection, unauthorized access requests to sensitive information are identified, thereby improving detection accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] 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.

[0039] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0040] Figure 1 System architecture diagram of the rights issuance engine for the web application unauthorized access vulnerability detection device;

[0041] Figure 2 A schematic diagram of the overall process provided for the method of detecting unauthorized access vulnerabilities in web applications in this application;

[0042] Figure 3 Session authentication detection flow chart provided for the unauthorized access vulnerability detection method for web applications in this application;

[0043] Figure 4 A flowchart for detecting unauthorized access to user sensitive information provided by the web application unauthorized access vulnerability detection method of this application;

[0044] Figure 5 A flowchart for detecting unauthorized access to sensitive system information provided by the web application unauthorized access vulnerability detection method of this application;

[0045] Figure 6 This is a structural diagram of the hardware operating environment involved in the Web application unauthorized access vulnerability detection method in an embodiment of the present application.

[0046] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0047] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0048] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0049] To achieve the above objectives, the present application proposes a method for detecting unauthorized access vulnerabilities in Web applications. The method removes sessions and replays requests with sessions, and determines unauthorized session requests based on a comparison result of the similarity between the response content before and after the request replay and a preset similarity threshold. The unauthenticated session requests and non-session requests are detected for unauthorized access vulnerabilities of user sensitive information based on identity identification parameters, and requests with user sensitive information vulnerabilities are filtered out based on the detection results to obtain remaining requests. The remaining requests are detected for unauthorized access to system sensitive information based on a preset large model to determine system sensitive information vulnerabilities. If the target request has the user sensitive information vulnerability or the system sensitive information vulnerability, the target request is determined to be an unauthorized access request.

[0050] Unauthorized access vulnerabilities in web applications are a common security risk. This means that attackers can directly access protected resources, such as databases, management backends, API interfaces, sensitive files, etc., without going through the authentication or authorization process. Such vulnerabilities may lead to data leakage, system tampering, or service interruption, threatening the security of enterprises and users. Usually, the main method of detecting unauthorized access vulnerabilities is to remove the session identifier or token in the request and replay the request. If the response status code is 200, it is considered that an unauthorized access vulnerability exists. However, the original intention of the design of the HTTP status code is to describe the response status, not to directly reflect permission issues. When the response status code is 200, it may mean that the request is successful, but it may also return a default page or error message instead of real data due to server configuration errors. Therefore, this method of detecting unauthorized access vulnerabilities has a high false alarm rate.

[0051] This application provides a method for detecting unauthorized access vulnerabilities in Web applications, which uses three detection methods in sequence to perform unauthorized access detection. First, most authenticated requests are filtered through session authentication detection. Then, identity recognition parameters are used to detect unauthorized access vulnerabilities to user sensitive information. Finally, the remaining requests are combined with large-model semantic analysis to determine whether the response message contains system sensitive information, and unauthorized access vulnerabilities to system sensitive information are detected. By combining the three methods for analysis and detection, unauthorized access requests to sensitive information are identified, thereby improving detection accuracy.

[0052] Please refer to Figure 1 The present embodiment provides a system architecture diagram for detecting unauthorized access vulnerabilities. Using historical request messages from a business system test environment as a data source, the system first classifies messages based on whether they contain a session. Messages with a session are first removed for session authentication, filtering out authenticated requests. Unauthenticated requests and requests without a session are then checked for unauthorized access to user sensitive information. If no vulnerability is detected, unauthorized access to system sensitive information is then checked.

[0053] It should be noted that the execution subject of this embodiment can be a computing service device with network communication and program execution capabilities, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or device capable of implementing the above functions. The following uses a device for detecting unauthorized access vulnerabilities in web applications as an example to illustrate this embodiment and the following embodiments.

[0054] Based on this, the embodiment of the present application provides a method for detecting unauthorized access vulnerabilities in Web applications. Figure 2 , Figure 2 This is a flow chart of the first embodiment of the method for detecting unauthorized access vulnerabilities in Web applications of this application.

[0055] In this embodiment, the Web application unauthorized access vulnerability detection method is applied to a Web application unauthorized access vulnerability detection device, and the method includes steps S10 to S40:

[0056] Step S10: Remove the session and replay the request. According to the comparison result of the similarity between the response content before and after the request replay and the preset similarity threshold, determine whether the session request is unauthenticated.

[0057] In this embodiment, the historical request messages in the business system test environment are used as the data source. The message requests are first divided into session requests and non-session requests based on whether the message requests contain session classification. Session authentication detection is performed on session messages, and authenticated requests are filtered.

[0058] Session requests and non-session requests are distinguished based on whether the request message carries a session identifier. A session identifier is a unique credential used by the server to identify a user session. In HTTP requests, session identifiers are typically found in cookies, request headers, request parameters (such as the sessionid in the URL), and so on. For each request message, the content in these locations that may carry a session identifier is extracted. Segmentation rules are first determined using the corresponding format protocol. Structured segmentation is then performed according to these rules to extract all possible session identifier key-value pairs. The extracted key-value pairs are compared with a preset set of session identifier key names. If the extracted key is in the set, a session identifier is considered present. If the extracted key is not in the set, the key-value pair is further compared with common session identifier format characteristics, such as a length of 16-64 characters, a composition of letters, numbers, and special characters, and compliance with UUID / Base64 encoding rules. If the extracted value meets these format characteristics, it is also considered a session identifier. If a session identifier is absent from any location, the request is classified as a non-session request.

[0059] For example, when parsing an HTTP request header, the protocol stipulates that each request header consists of "key: value", separated by newlines. Therefore, the message text is split by newlines, and the key and value are separated by ":" on each line. For example, "Cookie: PHPSESSID = 123" is split into the key "Cookie" and the value "PHPSESSID = 123".

[0060] When parsing URL parameters, the protocol stipulates that the parameter portion begins with a "?", key-value pairs are separated by an &, and the key and value are connected by an "=". Therefore, first locate the "?", intercept the string following it, then use the & character to split it into multiple key-value pairs, and finally use the "=" character to separate each key-value pair.

[0061] When parsing a JSON request body, according to the JSON format specification, key-value pairs are wrapped in {}, strings are enclosed in double quotes and separated by commas, and the text is parsed into a set of key-value pairs. For example, "{"token":"abc"}" is converted into a mapping relationship between token and abc.

[0062] For a session request, the authenticated session request and the unauthenticated session request are determined based on the difference in responses returned by the authenticated and unauthenticated session requests. In a feasible implementation, step S10 includes steps S11 to S14:

[0063] Step S11: replay the session request to obtain a first response.

[0064] Please refer to Figure 3In this implementation, a request for an existing session is replayed, and the stored active session list is queried. If the session identifier exists in the list, has not expired, and is in a normal state, such as login authentication has been completed, the session is determined to be valid, and the request is processed normally, such as querying data and returning page content. The first response generated is a normal and legal response, such as a 200 status code. If the session is invalid, such as the identifier does not exist or has expired, an error response is generated, such as a 401 Unauthenticated.

[0065] Step S12: When the first response is a normal and legal response, the session with the session request is deleted and the request is replayed to obtain a second response.

[0066] In this embodiment, when the first response is a normal and legal response, the request is replayed after removing the session identifier to simulate access in a non-session scenario. When deleting the session identifier, the target key-value pair is removed for Cookies, and other Cookies are retained; for Authorization, the header is cleared or replaced with an invalid value; for URLs or form parameters: the target key-value pair is removed, and the request format is adjusted (such as the URL needs to be re-encoded). For example, session_id=xxx is removed from the Cookie, or the token in the Authorization header is cleared. The request after deleting the session identifier is replayed again, and other request parameters such as User-Agent, path, and request body are kept exactly the same as the original request. The only variable is the session identifier, and a second response is obtained. If the second response after deletion is consistent with the first response, it means that the session identifier is not used, and the response may be based on stateless logic or client status; if it is inconsistent, there may be a session dependency for authentication, authorization, or personalized response.

[0067] Step S13: If the second response does not indicate that the user has no access rights, the first response and the second response are compared for similarity.

[0068] Step S14: If the similarity between the first response and the second response is greater than the similarity threshold, it is determined that the session request is the unauthenticated session request.

[0069] In this embodiment, when both the first and second responses are normal, key features from the responses are extracted and a matching degree is calculated. The features extracted for comparison include: status codes, key fields in the response header, and text content in the response body, such as user data, page titles, and function button text. The extracted features are then quantitatively compared. For example, identical status codes are scored 10 points, while different ones are scored 0 points. The degree of overlap in the response body text is scored proportionally, such as 80% overlap, which is 80 points. Identical key fields in the response header are scored 10 points. The total similarity is the weighted sum of the scores for each feature, resulting in a final similarity value. Based on a preset similarity threshold, a determination is made as to whether the session request is authenticated. If the similarity exceeds the threshold, the resource content and status returned by the server in both session and non-session scenarios are nearly identical, indicating that access to the request does not rely on session authentication. The session request is therefore considered an unauthenticated session request, potentially exposing an unauthorized access vulnerability. If the similarity is less than or equal to the threshold, the content returned by the server in the non-session scenario differs significantly from that in the session scenario. Therefore, the request relies on session authentication and is not considered unauthorized access.

[0070] In a feasible implementation, authenticated session requests and unauthenticated session requests can also be distinguished based on the response status code. If the response status code is 200 OK (successful access) or 302 Found (jump to the authorized page, such as the user center), it may be authenticated; if it is 401 Unauthorized (unauthenticated) or 403 Forbidden (authentication failed / no permission), it is unauthenticated. Optionally, different response status codes can be further assigned different scores, where status code 200 and status code scores are positive values, and status codes 401 and 403 have negative scores. For example, status code 200 is 30 points, status code 302 is 10 points, and status codes 401 and 403 are -40 points.

[0071] Step S20 , performing unauthorized access vulnerability detection for user sensitive information on the unauthenticated session request and the sessionless request based on the identity identification parameter, and filtering requests with user sensitive information vulnerabilities according to the detection results to obtain remaining requests.

[0072] In this embodiment, a vulnerability in unauthorized access to user sensitive information is detected by using identity identification parameters. By modifying the identity identification parameters in the request, a test request is sent in an unauthenticated scenario to verify whether sensitive information of other users can be illegally obtained. Unauthenticated requests should only be able to access public information or the user's authorized information. If sensitive information of other users can be obtained by modifying the identity parameters, it indicates that there is a flaw in the access control logic for user identity and sensitive information.

[0073] Please refer to Figure 4 , Figure 4A detection flow chart for the vulnerability of unauthorized access to user sensitive information is provided. The request parameters generally carry parameters of user identity identification (i.e., a character string bound to user data, such as a card number, loan number, order number, etc., which can be used to query or operate the personal data of a specified user). The present invention first filters out the request A with the user identity identification parameter, and extracts the same function request B from the historical message, replays the A and B requests respectively, and compares the similarity of the two responses. If the two responses are not similar, it means that the request data of A and B are different. Then, the corresponding parameter value in the B request is replaced with the identity identification parameter value in the A request, the B request is replayed, and the similarity between the A request response and the latest B request response is compared. If the responses are similar, it means that the identity identification parameter is bound to the user sensitive data, and there is a vulnerability of unauthorized access to user sensitive information.

[0074] Step S30: performing unauthorized access detection on the remaining requests for system sensitive information based on a preset large model to determine system sensitive information vulnerabilities.

[0075] Step S40: If the target request has the user sensitive information vulnerability or the system sensitive information vulnerability, the target request is determined to be an unauthorized access request.

[0076] In this embodiment, unauthorized access is divided into unauthorized access to user sensitive information and unauthorized access to system sensitive information. For requests that are not detected as unauthorized access to user information, unauthorized access to system sensitive information is detected again, and combined with the large model analysis, it is determined whether the request contains system sensitive information.

[0077] System sensitive information refers to confidential information related to web applications, servers, databases, and other system-level information. Its characteristics include, but are not limited to: system configuration information, such as the server IP address (192.168.1.1), operating system version (Windows Server 2019), and middleware configuration (Tomcat 9.0.50); ​​database information, such as database connection strings (e.g., jdbc:mysql: / / localhost:3306 / db?user=root&password=123); table structures, such as users(id, password), and database accounts and passwords; keys and credentials, such as the API key api_key=abcdef123456; encryption keys; and code and log information. Automatic identification of system sensitive information is achieved using a pre-defined large-scale model, such as a large-scale language model based on text classification. During training, the large-scale model is fine-tuned using labeled samples of system sensitive information and non-sensitive information to ensure that it understands the semantic and format characteristics of system sensitive information. The large-scale model receives response text as input and outputs a determination of whether system sensitive information is contained, along with a confidence level. A confidence threshold is preset based on the model accuracy. When the confidence of the model output is greater than or equal to the threshold, it is determined that system sensitive information exists in the response.

[0078] A target request is considered an unauthorized access request if it meets any of the following conditions: the request has been previously detected as having an unauthorized access vulnerability to user sensitive information; the request has been detected as having an unauthorized access vulnerability to system sensitive information.

[0079] In this embodiment, three detection methods are used sequentially to detect unauthorized access. First, session authentication is used to filter out most authenticated requests. Next, identity recognition parameters are used to detect vulnerabilities related to unauthorized access to user sensitive information. Finally, the remaining requests are analyzed using a large model semantic analysis to determine whether the response message contains system-sensitive information, thereby detecting vulnerabilities related to unauthorized access to system-sensitive information. This combined analysis and detection of these three methods identifies unauthorized access requests to sensitive information, thereby improving detection accuracy.

[0080] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction and will not be repeated hereafter. On this basis, step S20 can include steps S21 to S25:

[0081] Step S21: obtaining the first request containing the user identifier among the unauthenticated session request and the non-session request.

[0082] In this embodiment, identity parameters used to specify the target user are identified from unauthenticated session requests and sessionless requests. The semantic features of the identity parameters contain user identification-related semantics, such as uid (user ID), user_id, username (username), email (email address), phone (phone number), and id (the default user ID associated with the service). These parameters often appear in URL parameters (e.g., / user / info?uid=123), form data (e.g., user_id=456), or JSON request bodies (e.g., {"id":789}), and are used to specify "which user's information is being accessed." The value feature is typically a number (e.g., uid=123), a string (e.g., username=testuser), or a unique identifier (e.g., a user UUID). The URL parameters, request bodies, and other locations of unauthenticated session requests and sessionless requests are parsed, and all possible identity parameters are filtered based on the aforementioned features. For example, uid=123 is extracted as the identity parameter from the request " / api / user?uid=123&page=1." The extracted parameters are compared with the preset user identity parameter feature library. If the extracted parameters are the same as those in the parameter feature library, it means that the request has a user identifier.

[0083] Step S22: Obtain from the historical message a second request having the same function as the first user request but different request data.

[0084] In this embodiment, the same functional request refers to consistent paths and methods, consistent non-identity parameters, and consistent protocols and versions. Path and method consistency refers to the same request URL path (e.g., / api / order / info) and HTTP method (GET / POST). Non-identity parameter consistency refers to the fact that, except for the user identity parameter, the keys and values ​​of other key parameters, such as action=query and type=detail, are exactly the same to ensure consistent functional scenarios, such as querying order details. Protocol and version consistency refers to the same HTTP protocol version to avoid changes in the response format due to protocol differences.

[0085] Traverse the historical messages and filter out the second request that matches the first request's path and method, non-identity parameters, and protocol and version. This filtered request contains the same user ID key as the first request, but a different user ID value, to ensure that both requests target the same identity type (i.e., the same order number but belonging to different users). Save the complete information of the filtered second request B, including the request method, URL path, parameters, and request headers.

[0086] Specifically, the step of determining whether the request data of the first request and the second request are the same includes: replaying the first request and the second request, and comparing whether the corresponding responses are similar; if not, confirming that the request data of the first request and the second request are different.

[0087] Replay the first request and the second request, obtain the responses of both, and verify whether the connected request data is the same through similarity comparison. In the same network environment, replay the first request and the second request respectively, and obtain the corresponding first response and second response. Extract the features for comparison from the two responses, including: structural features, content features, status code and response header. Among them, structural features refer to the format of the response body (HTML, JSON, XML, etc.), core tags (such as HTML <div class＝"order-detail">) or a key set of JSON; content features refer to fixed field values ​​related to user sensitive data in the response body, such as the name corresponding to user_name, the amount corresponding to amount, and the card number fragment corresponding to card_no; status code and response header refer to whether key response headers such as the HTTP status code and Content-Type are consistent.

[0088] Calculate the similarity between the first response and the second response, assign different weights to the structural feature share, content feature share, and status code share, and calculate the similarity. If the similarity is less than or equal to the preset threshold, the responses are determined to be dissimilar, and the request data corresponding to the first request and the second request are different; if the similarity is greater than the threshold, it means that the request data are the same.

[0089] Step S23: Replace the second identity identification parameter in the second request with the first identity identification parameter in the first request.

[0090] Step S24: replay the replaced second request and obtain a third response corresponding to the replaced second request.

[0091] Step S25: If the similarity between the third response and the response corresponding to the first request is greater than the similarity threshold, it is determined that the first request has the user sensitive information vulnerability.

[0092] In this embodiment, the identity parameter values ​​of the first request are used to replace the corresponding parameters of the second request, while the other parameters, request header, method, and path of the request remain unchanged. A new request is generated and replayed to determine similarity with the response to the first request. This determination is based on the same method as described above and will not be repeated here. If the similarity is greater than a preset threshold, the replaced identity parameter means that the replaced second request has obtained the user data corresponding to the first request, creating a vulnerability in which unauthorized access to sensitive user information is possible.

[0093] Through the identity parameter replacement test under the same function, it is verified whether the identity identification parameter is the only access credential for the user's sensitive data. Under normal circumstances, even if the identity parameter is replaced, the unauthenticated request should not be able to obtain the corresponding data. If a response that is highly consistent with the original request can be obtained after the replacement, it means that the identity identification parameter is directly bound to the user's sensitive data and has not been verified for permissions. That is, it is not verified whether the requester has the right to access the user data corresponding to the identity identification, and there is an unauthorized access vulnerability.

[0094] In another optional implementation, multiple sets of test requests can be constructed based on the extracted identification parameters, simulating scenarios where different user information can be accessed. By modifying the parameter values, the test is conducted to determine whether unauthorized requests can unauthorizedly access other user data. At least three sets of parameter values ​​are generated for the extracted identification parameters, including: a baseline value (e.g., uid=123) used as a comparison baseline; other user values ​​(e.g., uid=124, uid=125), which may exist (e.g., uid=124, uid=125, which can be generated by enumerating numbers, guessing common usernames, etc.); and an invalid value (e.g., uid=999999), which is used to verify that "invalid users return empty data" and eliminate false positives. The remaining parts of the original request, such as the request method, path, non-identity parameters, and no-session / unauthenticated session status, remain unchanged. Only the identification parameter values ​​are replaced with the test values ​​to generate multiple sets of test requests. For example: Original request: / api / user?uid=123 (no-session request); Test request 1: / api / user? uid=124 (replace with other user value); Test request 2: / api / user?uid=999999 (replace with invalid value).

[0095] Collect all responses and check whether they contain user sensitive information. Parse the response of each test request and match it with the feature library to see if there is sensitive information. For example, if the response body contains "mobile phone number: 13800138000", it is determined to contain sensitive information by regular matching of 11 digits; by comparing the response results of different test requests, determine whether unauthenticated requests can obtain sensitive information of other users beyond their authority. When all the following conditions are met, it is determined that there is a vulnerability: the response of the original request (baseline value, such as uid=123) contains user sensitive information (which conforms to the feature library); test requests with other user values ​​(such as uid=123) contain user sensitive information (which conforms to the feature library); id=124) also contains sensitive information, and this information does not belong to the base user of the original request (for example, the response to uid=124 contains "Li Si's mobile phone number", which is different from "Zhang San's mobile phone number" for uid=123); the response to the test request with an invalid value (such as uid=999999) does not contain sensitive information (or prompts "user does not exist"), eliminating the misjudgment of "fixed sensitive information is returned for any value"; all test requests are in an unauthenticated state (no session or unauthenticated session), that is, access rights are not obtained through the legal login process.

[0096] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 3 , before step S30, steps A10 to A30 may also be included:

[0097] Step A10: replay the remaining requests, and filter the authentication requests and / or error reporting requests in the remaining requests according to the request replay result.

[0098] In this embodiment, before the remaining requests are finally analyzed using the large model semantics to determine whether the response message contains system-sensitive information, the fertility request is replayed to filter out authenticated requests and / or error requests. This step is identical to step S10 and will not be further described here. This secondary verification prevents missed detections.

[0099] Step A20: Obtain the business keywords in the fifth response corresponding to the remaining requests after filtering.

[0100] In step A30 , if the semantic similarity between the service keyword and the preset exempted service keyword is greater than a preset semantic similarity threshold, it is confirmed that there is no system sensitive information vulnerability.

[0101] In this embodiment, when detecting unauthorized access to sensitive system information, business exemption requests are first analyzed and filtered. Then, non-business exemption requests are analyzed in conjunction with the large-scale model to determine whether they contain sensitive system information. Business exemption functions are those that directly participate in business processing but require exemptions from certain standard business processes or rules due to business strategies, customer customization requirements, or special business scenarios. Examples include exempting key customers from contract terms such as payment cycles and service level agreements; exempting order refund time limits during promotional events; and exempting high-credit users from certain anti-fraud verification steps to expedite the transaction process. Non-business exemption functions are those that are not directly related to core business logic but require exemptions from certain restrictions or rules under specific conditions due to technical, security, compliance, or user experience requirements. Functions not directly involved in business processing, such as order processing, payment processing, and user data operations, are typically exempted due to system stability, security policies, and legal compliance requirements. For example, a log debugging interface in a development environment may require exemptions from security restrictions in a production environment; allowing administrators to temporarily modify accounts in an emergency, bypassing password complexity requirements; and a test account feature in a financial app may be exempt from real-name authentication during the development phase, but mandatory authentication is required in production.

[0102] In this embodiment, natural language processing (NLP) technology is used to analyze the semantic features of request and response messages and match them with a preset library of exempt business scenarios to determine whether the request belongs to a public business scenario that does not require authentication, thereby eliminating the misjudgment of unauthorized access vulnerabilities. Data for public business scenarios that do not require authentication is pre-stored as a benchmark for semantic comparison, such as public product introductions and public policy descriptions. NLP pre-processing is performed on each exempt scenario to generate a feature vector that can be used for semantic comparison. For the description text of each exempt scenario, such as Fund Product A is a low-risk product with an annualized yield of a%, and a minimum purchase amount of X yuan, a word segmentation tool, such as a dictionary-based mechanical word segmentation or a statistical word segmentation model, is used to extract core words such as fund product, annualized yield, low risk, and purchase amount. Meaningless stop words are removed, and the keywords are standardized. The keywords are converted into computer-computable vectors, such as by using a bag-of-words model to count the frequency of keyword occurrences; or by using a pre-trained word vector model to map each keyword to a fixed-dimensional vector. The overall vector of the scenario is then average-weighted and stored in the exempt business scenario library.

[0103] When receiving a request to be tested and its corresponding response, the business semantic text must be extracted as input for NLP analysis. Specifically, the request URL path, request parameters, and request body are parsed to extract text related to the business scenario. For example, extracting "fund" and "intro" from the URL path / public / fund / intro?fund_id=1001 to obtain the product introduction. Parsing the response body to extract the business description text, for example, extracting the HTML response body from the HTML response body. <div class＝"product-desc"> Insurance X covers A, B... Extract "Insurance X", "Coverage", "A", and "B" from the query. Clean the extracted response text to remove HTML tags and special symbols, such as & and numbers, retaining only strings relevant to the business semantics. Also, unify the capitalization to ensure consistency in subsequent analysis.

[0104] Perform keyword extraction and feature vector conversion on the preprocessed request and response texts to generate semantic features comparable to the exemption scenario library. Use the same NLP tools as those used when building the exemption scenario library to segment the request and response texts and filter out stop words and non-business words. Use the same vector conversion method as the exemption scenario library to convert the extracted keywords into feature vectors. Optionally, use the bag-of-words model to count the frequency of occurrence of request and response keywords to generate a frequency vector. For example, if "insurance" appears twice and "premium" appears once, the vector is [2, 1, ...]); based on the word vector model, map each keyword to a vector and calculate the overall feature vector through average calculation. Compare the feature vectors of the request and response with the feature vectors of all scenarios in the exemption scenario library, calculate the semantic similarity, and determine whether it belongs to the exemption scenario. The vector similarity algorithm can be cosine similarity, which calculates the cosine value of the angle between the request and response feature vectors and the feature vector of each exemption scenario. If the maximum similarity between the request and response and the exemption scenario library is greater than or equal to the preset threshold, the request is determined to belong to an exemption business scenario, that is, the scenario allows anonymous access without authentication; if the similarity is less than the threshold, it is determined not to belong to an exemption scenario.

[0105] Based on the first embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction and will not be repeated hereafter. On this basis, step S30 can include steps S31 to S32:

[0106] Step S31: input the fourth response corresponding to the remaining request into the large model to determine whether there is system sensitive information in the remaining request, wherein the system sensitive information includes one or more of configuration information and monitoring information.

[0107] In this embodiment, the non-business exemption function calls the large model to analyze whether the response message contains system sensitive information such as configuration information and monitoring information, and comprehensively judges whether there is an unauthorized access vulnerability based on whether the request path contains words such as monitor and conf.

[0108] Select pre-trained large models that support text classification, such as BERT, RoBERTa, etc., and fine-tune them to adapt to the task of identifying system sensitive information. Before fine-tuning, extract text containing system sensitive information from historical vulnerability reports, error logs, and configuration file fragments, and collect public business texts that do not contain system sensitive information. Label all samples, and the labeling content includes: whether it contains system sensitive information, where label 1 indicates that it contains system sensitive information, and 0 indicates that it does not contain system sensitive information. Pre-process the collected data to remove garbled characters, special symbols such as HTML tags, and redundant spaces in the text, and unify the case; use word segmentation tools (such as Jieba) for Chinese text, segment English text by space, split long text into word sequences, and perform format conversion to convert the text and labels into a format acceptable to the model.

[0109] The preprocessed text is converted into tokens for model input, and special symbols are added, such as [CLS] for sentence start and [SEP] for sentence end in BERT. The underlying model parameters are first frozen to preserve the general semantic knowledge learned during pre-training. The top classification layer is then trained to map the model output to labels indicating whether or not sensitive information is present. Later in training, some underlying parameters are unfrozen, such as the last two or three Transformer layers. Backpropagation is used to adjust the parameters, allowing the model to learn the specific characteristics of sensitive system information, such as the strong association between words like "monitor" and "conf" and monitoring and configuration information. Finally, a cross-entropy loss function is used to calculate the difference between the model's predicted labels and the true labels. Using the Adam optimizer, the learning rate is adjusted to minimize the loss function, making the model's predictions more accurate, resulting in a fine-tuned large model.

[0110] Optionally, accuracy, precision, and recall can be used as evaluation metrics. Accuracy is the percentage of correctly predicted samples, precision is the percentage of samples containing sensitive information that actually contain sensitive information, and recall is the percentage of correctly predicted samples containing sensitive information. The goal is to ensure that both precision and recall are greater than or equal to preset thresholds to evaluate the model. If the recall rate for surveillance information recognition is low, retrain the model with more surveillance-related samples. If the false positive rate is high, increase the proportion of easily confused text in non-sensitive samples to strengthen the model's distinguishing ability. The confidence distribution of the model output is analyzed using a validation set. When the confidence level of the model's prediction of sensitive information is greater than or equal to the preset confidence threshold, the result is considered valid.

[0111] In a feasible implementation, step S31 may include steps S311 to S314:

[0112] Step S311: determining a parsing strategy according to the format of the fourth response, and parsing the fourth response based on the parsing strategy to obtain a target text.

[0113] In this embodiment, a differentiated parsing strategy is adopted according to the format of the fourth response, and the format of the fourth response is determined based on Content-Type. If it is in JSON or JSONP format, a JSON parser is used, such as a parsing tool based on a syntax tree, to convert the response body into a nested key-value pair structure, identify the field names and field values ​​of all levels, concatenate all field names and field values ​​into strings, and retain the hierarchical relationship. If the field value is an array or a complex object, filter the unstructured value and only extract the field name and simple value to obtain the target text. If it is in HTML or XML format, an HTML / XML parser is used, such as a parsing tool based on a DOM tree to traverse the tag structure and identify <title>、< / title> 、 etc. Text labels, ignored <script>、<style>等非内容标签；提取标签内的纯文本，保留标签的class / id属性，如"class＝config:数据库地址：10.0.0.5"，去除HTML实体、注释、空行，合并连续空格，得到目标文本。纯文本格式则直接提取完整文本，过滤不可见字符，如换行符、制表符，得到目标文本。

[0114] 可选地，还可以通过规则匹配和模式识别，去除与系统敏感信息无关的动态内容。例如，对于动态时间戳，识别符合时间格式的字符串，如，yyyy-MM-dd HH：mm：ss、timestamp＝1626500000，通过正则表达式\d{4}-\d{2}-\d{2}\d{2}:\d{2}:\d{2}匹配并删除。对于随机数或者会话ID，识别无语义的长字符串，通过"长度≥16且由字母+数字组成”的特征匹配并删除；多余重复冗余内容，去除连续重复的无意义词汇。

[0115] 步骤S312，对所述目标文本进行分词，将分词后得到的词法单元映射为结构化向量序列。

[0116] 本实施方式中，将预处理后的文本输入大模型，将非结构化文本转换为模型可计算的结构化向量序列，保留词汇语义和位置信息。按语言规则，英文空格分词、中文Jieba分词拆分文本，并对未登录词(如db_host)进行子词拆分，输出字符串序列，包含文本中所有有意义的词汇及符号，例如：["[CLS]"，"system","conf"，"："，"db"，"_host"，"＝"，"10.0.0.1"，"；"，"monitor"，"："，"cpu"，"＝"，"70％"，"[SEP]"]。其中，[CLS]是模型预定义的"句子级特征标记”，[SEP]是句子结束标记。对字符串序列的每个Token，通过模型预训练的词向量表、位置向量表和段向量表”分别映射为向量，再叠加为最终的Token向量。一个Token向量序列的形状为[序列长度,向量维度]，每个向量包含：反映词汇本身语义的词向量，标记Token在序列中位置的位置向量，以及若文本是单句，所有Token的段向量相同，仅在长文本拆分时用于区分不同段落的段向量。

[0117] 步骤S313，基于自注意力机制对所述结构化向量序列进行加权求和，得到全局特征向量。

[0118] 本实施方式中，将词汇编码输出的结构化向量序列作为Transformer层的输入，进入多层注意力机制处理，通过多层注意力机制捕捉Token间的语义关联，生成融合上下文信息的高阶特征向量。对每个Token的向量生成三个矩阵：Query(查询)、Key(键)、Value(值)；计算Query与所有Key的相似度，得到注意力权重，权重越高，说明两个Token的语义关联越强；按权重对Value向量加权求和，得到该融合了相关词汇的语义上下文感知向量。经过Transformer处理后，取文本首个Token([CLS]，模型预定义的句子级特征标记)的向量作为整个文本的全局语义特征向量，该向量融合了所有词汇的上下文关联信息。

[0119] 步骤S314，将所述全局特征向量转换为概率分布，若所述概率分布中含系统敏感信息概率的置信度大于预设置信度阈值，则确定存在所述系统敏感信息。

[0120] 本实施方式中，将全局特征向量输入全连接层，通过softmax函数将向量转换为概率分布，输出两个类别概率：P(含敏感信息)和P(不含敏感信息)，同时输出敏感信息类型的概率分布(如P(配置信息)＝0.85、P(监控信息)＝0.07)。提取分类层输出的概率值，将含敏感信息概率作为该判定的置信度，表示模型对含敏感信息这一结论的可信程度。若置信度大于等于预设的置信度阈值，则判定响应报文包含系统敏感信息；否则判定不包含。

[0121] 步骤S32，若存在所述系统敏感信息，且所述剩余请求的请求路径中包含预设的关键词，则确定存在所述系统敏感信息漏洞。

[0122] 本实施例中，解析请求的URL路径，提取其中的关键单词，判断是否包含与系统敏感功能强关联的词。预设敏感路径关键词库，例如，["monitor"，"conf"，"config"，"system"，"admin"，"database"，"log"，"status"]等通常对应监控、配置、系统状态等敏感功能的关键词。若请求路径中包含上述任一关键词，则标记为路径含敏感关键词。当大模型判定第四响应包含系统敏感信息，且请求路径包含敏感关键词库中的单词时，该请求处于未鉴权状态，判定存在系统敏感信息未授权访问漏洞。当仅路径含敏感词但响应无敏感信息，如 / monitor返回"请登录”，无实际监控数据，则判定为不存在漏洞；若响应有敏感信息但路径不含敏感词，则进一步人工确认，避免漏判。

[0123] 请参照图5，图5提供了一种系统敏感信息未授权访问检测流程图，系统敏感信息检测前，先重放请求过滤鉴权或报错请求。然后进行业务豁免功能分析，即基于自然语言处理提取请求和响应报文中的关键词，然后与提前收集的系统豁免业务场景，如基金产品介绍、保险产品介绍等进行语义比较，如果相近则不存在未授权访问漏洞。非业务豁免功能则调用大模型分析响应报文是否包含系统敏感信息如配置信息、监控信息，结合请求路径是否包含monitor、conf等单词综合判断是否存在未授权访问漏洞。

[0124] 本实施例中，大模型解决响应文本中系统敏感信息的精准识别问题，路径关键词进行功能场景的敏感属性判断，两者结合在未鉴权场景下验证是否能非法获取系统敏感信息，实现对未授权访问漏洞的准确判定。

[0125] 本申请提供一种Web应用未授权访问漏洞检测设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述实施例一中的Web应用未授权访问漏洞检测方法。

[0126] 下面参考图6，其示出了适于用来实现本申请实施例的Web应用未授权访问漏洞检测设备的结构示意图。本申请实施例中的Web应用未授权访问漏洞检测设备可以包括但不限于诸如移动电话、笔记本电脑、个人数字助理(PDA，Personal DigitalAssistant)、平板电脑(PAD，portable android device)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图6示出的Web应用未授权访问漏洞检测设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

[0127] 如图6所示，Web应用未授权访问漏洞检测设备可以包括处理装置1001(例如中央处理器、图形处理器等)，其可以根据存储在只读存储器(ROM，Read Only Memory)1002中的程序或者从存储装置1003加载到随机访问存储器(RAM，Random Access Memory)1004中的程序而执行各种适当的动作和处理。在随机访问存储器1004中，还存储Web应用未授权访问漏洞检测设备操作所需的各种程序和数据。处理装置1001、只读存储器1002以及随机访问存储器1004通过总线1005彼此相连。输入 / 输出(I / O)接口1006也连接至总线。通常，以下系统可以连接至I / O接口1006：包括例如触摸屏、触摸板、键盘、鼠标、图像传感器、麦克风、加速度计、陀螺仪等的输入装置1007；包括例如液晶显示器(LCD，Liquid Crystal Display)、扬声器、振动器等的输出装置1008；包括例如磁带、硬盘等的存储装置1003；以及通信装置1009。通信装置1009可以允许Web应用未授权访问漏洞检测设备与其他设备进行无线或有线通信以交换数据。虽然图中示出了具有各种系统的Web应用未授权访问漏洞检测设备，但是应理解的是，并不要求实施或具备所有示出的系统。可以替代地实施或具备更多或更少的系统。

[0128] 特别地，根据本申请公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置从网络上被下载和安装，或者从存储装置1003被安装，或者从只读存储器1002被安装。在该计算机程序被处理装置1001执行时，执行本申请公开实施例的方法中限定的上述功能。

[0129] 本申请提供的Web应用未授权访问漏洞检测设备，采用上述实施例中的Web应用未授权访问漏洞检测方法，能解决如何提高未授权访问漏洞检测的准确性的技术问题。与现有技术相比，本申请提供的Web应用未授权访问漏洞检测设备的有益效果与上述实施例提供的Web应用未授权访问漏洞检测方法的有益效果相同，且该Web应用未授权访问漏洞检测设备中的其他技术特征与上一实施例方法公开的特征相同，在此不做赘述。

[0130] 应当理解，本申请公开的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式的描述中，具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

[0131] 以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

[0132] 本申请提供一种计算机可读存储介质，具有存储在其上的计算机可读程序指令(即计算机程序)，计算机可读程序指令用于执行上述实施例中的Web应用未授权访问漏洞检测方法。

[0133] 本申请提供的计算机可读存储介质例如可以是U盘，但不限于电、磁、光、电磁、红外线、或半导体的系统或器件，或者任意以上的组合。计算机可读存储介质的更具体地例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM，Random Access Memory)、只读存储器(ROM，Read Only Memory)、可擦式可编程只读存储器(EPROM，Erasable Programmable Read Only Memory或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM，CD-Read Only Memory)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统或者器件使用或者与其结合使用。计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、射频(RF，RadioFrequency)等等，或者上述的任意合适的组合。

[0134] 上述计算机可读存储介质可以是Web应用未授权访问漏洞检测设备中所包含的；也可以是单独存在，而未装配入Web应用未授权访问漏洞检测设备中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被Web应用未授权访问漏洞检测设备执行时，使得Web应用未授权访问漏洞检测设备：对有会话请求进行会话移除和请求重放，根据请求重放前后响应内容的相似度与预设相似度阈值的比较结果，确定未鉴权会话请求；

[0135] 基于身份识别参数对所述未鉴权会话请求和无会话请求，进行用户敏感信息未授权访问漏洞检测，并根据检测结果过滤存在用户敏感信息漏洞的请求，得到剩余请求；基于预设的大模型对所述剩余请求进行系统敏感信息未授权访问检测，确定系统敏感信息漏洞；若目标请求存在所述用户敏感信息漏洞，或者所述系统敏感信息漏洞，则确定所述目标请求为未授权访问请求。

[0136] 可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如"C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN，LocalArea Network)或广域网(WAN，Wide Area Network)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

[0137] 附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和 / 或流程图中的每个方框、以及框图和 / 或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

[0138] 描述于本申请实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块的名称在某种情况下并不构成对该单元本身的限定。

[0139] 本申请提供的可读存储介质为计算机可读存储介质，所述计算机可读存储介质存储有用于执行上述Web应用未授权访问漏洞检测方法的计算机可读程序指令(即计算机程序)，能够解决如何提高未授权访问漏洞检测的准确性的技术问题。与现有技术相比，本申请提供的计算机可读存储介质的有益效果与上述实施例提供的Web应用未授权访问漏洞检测方法的有益效果相同，在此不做赘述。

[0140] 以上所述仅为本申请的部分实施例，并非因此限制本申请的专利范围，凡是在本申请的技术构思下，利用本申请说明书及附图内容所作的等效结构变换，或直接 / 间接运用在其他相关的技术领域均包括在本申请的专利保护范围内。< / script>

Claims

1. A method for detecting unauthorized access vulnerabilities in Web applications, characterized in that: The method for detecting unauthorized access vulnerabilities in Web applications includes: Remove and replay existing session requests, and determine unauthenticated session requests based on the comparison of the similarity between the response content before and after the request replay and the preset similarity threshold; Performing a vulnerability detection for unauthorized access to user sensitive information on the unauthenticated session request and the sessionless request based on the identity identification parameter, and filtering requests with user sensitive information vulnerabilities based on the detection results to obtain remaining requests; Based on the preset large model, the remaining requests are tested for unauthorized access to system sensitive information to determine system sensitive information vulnerabilities; If the target request has the user sensitive information vulnerability or the system sensitive information vulnerability, the target request is determined to be an unauthorized access request.

2. The method for detecting unauthorized access vulnerabilities in Web applications according to claim 1, wherein: The step of removing the session and replaying the request for the session, and determining the unauthenticated session request based on the comparison result of the similarity between the response content before and after the request replay and the preset similarity threshold, includes: Replay the session request to obtain a first response; When the first response is a normal and legal response, deleting the session with the session request and replaying the request to obtain a second response; If the second response does not indicate that the access is unauthorized, comparing the similarity between the first response and the second response; If the similarity between the first response and the second response is greater than the similarity threshold, it is determined that the session request is the unauthenticated session request.

3. The method for detecting unauthorized access vulnerabilities in Web applications according to claim 1, wherein: The step of detecting the vulnerability of unauthorized access to user sensitive information for unauthenticated session requests and non-session requests based on identity identification parameters includes: Acquire a first request containing a user identifier among the unauthenticated session request and the session-free request; Obtaining a second request from the historical message, which has the same function as the first request but different request data; Replace the second identity identification parameter in the second request with the first identity identification parameter in the first request; Replaying the replaced second request, and obtaining a third response corresponding to the replaced second request; If the similarity between the third response and the response corresponding to the first request is greater than the similarity threshold, it is determined that the first request has the user sensitive information vulnerability.

4. The method for detecting unauthorized access vulnerabilities in Web applications according to claim 3, wherein: The step of obtaining a second request having the same function as the first request but different request data from the historical message includes: replaying the first request and the second request, and comparing whether corresponding responses are similar; If not, it is confirmed that the request data of the first request and the second request are different.

5. The method for detecting unauthorized access vulnerabilities in Web applications according to claim 1, wherein: The step of performing unauthorized access detection on the remaining requests for system sensitive information based on the preset large model to determine system sensitive information vulnerabilities includes: Inputting the fourth responses corresponding to the remaining requests into the large model, and determining whether the remaining requests contain system sensitive information, wherein the system sensitive information includes one or more of configuration information and monitoring information; If the system sensitive information exists and the request path of the remaining requests contains the preset keyword, it is determined that the system sensitive information vulnerability exists.

6. The method for detecting unauthorized access vulnerabilities in Web applications according to claim 5, wherein: The step of inputting the responses corresponding to the remaining requests into the large model and determining whether the remaining requests contain system sensitive information comprises: determining a parsing strategy according to the format of the fourth response, and parsing the fourth response based on the parsing strategy to obtain a target text; Segmenting the target text, and mapping the lexical units obtained after the segmentation into a structured vector sequence; Performing weighted summation on the structured vector sequence based on a self-attention mechanism to obtain a global feature vector; The global feature vector is converted into a probability distribution. If the confidence level of the probability of containing system sensitive information in the probability distribution is greater than a preset confidence threshold, it is determined that the system sensitive information exists.

7. The method for detecting unauthorized access vulnerabilities in Web applications according to claim 1, wherein: Before the step of performing unauthorized access detection on the remaining requests for system sensitive information based on the preset large model to determine system sensitive information vulnerabilities, the following step is also included: Replay the remaining requests, and filter the authentication requests and / or error reporting requests in the remaining requests according to the request replay results; Obtaining the business keywords in the fifth response corresponding to the remaining requests after filtering; If the semantic similarity between the business keyword and the preset exempted business keyword is greater than a preset semantic similarity threshold, it is confirmed that the system sensitive information vulnerability does not exist.

8. The method for detecting unauthorized access vulnerabilities in Web applications according to claim 7, wherein: The step of replaying the remaining requests and filtering the authentication requests and / or error reporting requests in the remaining requests according to the request replay results includes: Replay the remaining requests to obtain the fifth responses to the remaining requests; If the fifth response reports an error, the request corresponding to the fifth response is filtered.

9. A web application unauthorized access vulnerability detection device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the method for detecting unauthorized access vulnerabilities of Web applications according to any one of claims 1 to 8.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the method for detecting unauthorized access vulnerabilities in Web applications according to any one of claims 1 to 8 are implemented.

Images