Web form weak password detection method based on cooperation of static feature library and AI dynamic analysis

Abstract

The invention belongs to the related technical field of network security, and particularly relates to a web form weak password detection method based on cooperation of a static feature library and AI dynamic analysis, which comprises the following steps of: constructing a web form structure based on the static feature library containing various login features of various web services and a form structure tree; or identifying the field type according to the standard form, judging whether a keyword of which the language is matched with the language of the field can be found in the multi-language keyword mapping table or not when detecting that different attribute value conflicts exist in one field, if not, analyzing the framework feature layer, and if the type still cannot be analyzed, analyzing the type through the AI reasoning layer; integrating visual features, spatial relationships and context semantics which are not covered by the first two layers through a deep learning model, realizing field type inference in a complex scene, and constructing a web form structure to be detected based on each field type; and generating an HTTP (Hyper Text Transport Protocol) form request message based on the constructed web form structure.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, and more specifically, relates to a web form weak password detection method based on the collaboration of static feature library and AI dynamic analysis. Background Technology

[0002] Existing weak password detection technologies are mainly based on static rule bases or single-protocol weak password detection methods, which have significant shortcomings when dealing with modern web applications: 1. Poor compatibility with dynamic pages – Traditional detection methods can only parse static HTML page structures and cannot effectively handle JavaScript-rendered SPAs, form components based on Shadow DOM, and pages generated by frameworks such as React / Vue. <form>The dynamic forms with tags result in low recognition rates for key authentication fields in the web login interface, leading to a large number of missed detections.

[0003] 2. High rule maintenance costs – Static rule bases are difficult to adapt to rapidly iterating web front-end technologies and cannot keep up with new authentication protocols or dynamic page structure changes, requiring continuous manual investment in rule maintenance and updates.

[0004] 3. Fragmented Protocol Detection Capabilities – Existing web detection tools focus on the HTTP protocol but lack the ability to extend to non-web protocols, while network layer authentication tools cannot parse dynamic web forms. This fragmentation of protocols forces enterprises to switch between multiple detection schemes in a hybrid authentication environment, which reduces efficiency and increases the risk of missed detections at key web entry points.

[0005] Existing technologies lack the ability to uniformly parse and detect modern Web dynamic forms. Summary of the Invention

[0006] In view of the above-mentioned defects or improvement needs of existing technologies, this invention provides a web form weak password detection method based on the collaboration of static feature library and AI dynamic analysis, which aims to solve the problem of unified parsing technology for modern web dynamic forms.

[0007] To achieve the above objectives, according to one aspect of the present invention, a web form weak password detection method based on the collaboration of a static feature library and AI dynamic analysis is provided, comprising: Launch a headless browser to load the target page, execute an explicit wait to ensure that dynamic elements are rendered, traverse the DOM tree and Shadow Root in the front-end code of the target page, locate all potential input fields, and construct the form structure tree; If the web service of the target page belongs to one of the static feature libraries, a web form structure to be detected is constructed based on the pre-built static feature library containing multiple login features of various web services and the form structure tree. Otherwise, the field type is determined according to the HTML5 form specification, including detection of the autocomplete attribute value, the type attribute value, and the inputmode attribute value. When a conflict is detected between different attribute values ​​of a field, the field is marked as conflicting and transferred to the frame feature matching layer. The frame feature matching layer determines whether a keyword matching the language of the field can be found in the pre-built multilingual keyword mapping table. If so, the type corresponding to the matching keyword is determined in the mapping table. If not, the specific class attribute of the field container to which the field belongs is analyzed and detected. <label>The field type is determined by the binding relationship of the element's for attribute or the semantic association of adjacent text nodes. If the type still cannot be resolved, it is handed over to the AI ​​inference layer. Through the AI ​​inference layer, based on the form structure tree and the page rendering screenshot, the visual features, spatial relationships and contextual semantics that were not covered by the first two layers are integrated by the deep learning model to realize the field type inference in complex scenarios. A web form structure to be detected is constructed based on each field type. Based on the constructed web form structure, an HTTP form request message is generated. After adding standardized request headers to the request message, it is sent to the target URL and the response is analyzed to achieve weak password detection.

[0008] Furthermore, before sending the request message to the target URL, if token verification exists, the token value is extracted from the front-end code of the target page, appended to the HTTP form request message, and then sent.

[0009] Furthermore, the method for generating HTTP form request messages based on the constructed web form structure is as follows: Generate a request body and a request header for each username / password combination. The request body consists of key-value pairs containing the username, password, and all hidden fields, encoded in x-www-form-urlencoded format.

[0010] Furthermore, the method also includes a dynamic anti-detection mechanism, specifically including: rotating the request source IP through a proxy IP pool; when a CAPTCHA is detected, calling the CAPTCHA recognition module to automatically parse and fill the CAPTCHA field to avoid the interception of the protection mechanism.

[0011] According to another aspect of the present invention, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0012] According to another aspect of the invention, a computer-readable storage medium is provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed by a processor, it controls the device where the storage medium is located to perform the steps of the method described above.

[0013] According to another aspect of the present invention, a computer program product is provided, comprising a computer program; when the computer program is executed by a processor, it implements the method described above.

[0014] In summary, compared with the prior art, the technical solutions conceived by this invention have the following main advantages: 1. This invention proposes a web form weak password detection method based on the collaboration of a static feature library and dynamic AI analysis. It is an adaptive multi-protocol weak password detection scheme with a dual-engine architecture of "static feature library + dynamic AI semantic analysis". First, it determines whether the web service of the target page belongs to one of the static feature libraries. If so, the static feature library is used directly to determine the type of each field without configuration. Otherwise, a three-layer mechanism (standard form, non-standard form, AI inference) is used to identify the type of each field. This method can dynamically render the page in real time and intelligently classify form fields. This scheme significantly improves the detection coverage and accuracy of modern web applications and solves the problem of unified parsing of modern web dynamic forms.

[0015] 2. The present invention further proposes that, before sending a request message to the target URL, if token verification exists, the token value is extracted from the front-end code of the target page, appended to the HTTP form request message, and then sent. This can automatically bypass the security mechanism and effectively ensure the implementation of weak password detection. Attached Figure Description

[0016] Figure 1 A flowchart of a web form weak password detection method based on the collaboration of static feature library and AI dynamic analysis is provided for an embodiment of the present invention. Figure 2 This is an example diagram of the data structure for network entity form recognition results provided in an embodiment of the present invention; Figure 3 A flowchart of a Web form field recognition and acquisition method provided in an embodiment of the present invention; Figure 4 A flowchart illustrating the overall process of weak password detection for integrated protocols and forms provided in this embodiment of the invention; Figure 5 A flowchart illustrating the integrated protocol and forms provided in this embodiment of the invention; Figure 6 This is a diagram illustrating the architecture of a network asset detection system provided in an embodiment of the present invention. Figure 7 A block diagram of a network asset detection system provided in an embodiment of the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0018] Example 1 A web form weak password detection method based on the collaboration of a static feature library and AI dynamic analysis, such as... Figure 1 As shown, it includes: Launch a headless browser to load the target page, execute an explicit wait to ensure that dynamic elements are rendered, traverse the DOM tree and Shadow Root in the front-end code of the target page, locate all potential input fields, and construct the form structure tree; If the web service of the target page belongs to one of the static feature libraries, a web form structure to be detected is constructed based on the pre-built static feature library containing multiple login features of various web services and the form structure tree. Otherwise, the field type is determined according to the HTML5 form specification, including detection of the autocomplete attribute value, the type attribute value, and the inputmode attribute value. When a conflict is detected between different attribute values ​​of a field, the field is marked as conflicting and transferred to the frame feature matching layer. The frame feature matching layer determines whether a keyword matching the language of the field can be found in the pre-built multilingual keyword mapping table. If so, the type corresponding to the matching keyword is determined in the mapping table. If not, the specific class attribute of the field container to which the field belongs is analyzed and detected. <label>The field type is determined by the binding relationship of the element's for attribute or the semantic association of adjacent text nodes. If the type still cannot be resolved, it is handed over to the AI ​​inference layer. Through the AI ​​inference layer, based on the form structure tree and the page rendering screenshot, the visual features, spatial relationships and contextual semantics that were not covered by the first two layers are integrated by the deep learning model to realize the field type inference in complex scenarios. A web form structure to be detected is constructed based on each field type. Based on the constructed web form structure, an HTTP form request message is generated. After adding standardized request headers to the request message, it is sent to the target URL and the response is analyzed to achieve weak password detection.

[0019] This embodiment uses a three-level identification mechanism to locate key fields: 1) Prioritize matching HTML5 standard attributes (autocomplete / type, etc.); 2) Secondary priority matching of password field naming rules (predefined username / password keyword regular expressions); 3) For authentication request fields that cannot be extracted and recognized from the page, invoke the AI ​​semantic model based on association. <label>Inference and recognition are performed on text / placeholder content.

[0020] During weak password detection: For web page authentication, construct an authentication request containing username, password, and hidden fields, attach randomized request headers and proxy information, analyze the response (status code, redirect, keywords, cookies, etc.), and determine whether the login authentication was successful.

[0021] Results recording and feedback: The target address, username, password, protocol type, timestamp, and other information of successful authentication will be stored in the database for subsequent analysis and report generation.

[0022] In practical implementation, the following are specific examples illustrating dynamic page analysis and form parsing: (1) Page rendering based on Selenium headless browser engine Use Selenium WebDriver to launch a headless browser (Headless Chrome / Firefox) to simulate real user behavior and load a JavaScript-rendered page; Explicit waiting (WebDriverWait) or polling ensures that dynamic elements on the page are rendered.

[0023] (2) Layered form positioning strategy For traditional HTML page request forms: identify all tags and extract action, method, input name / id / type, etc.; For iframe-nested forms: automatically switch to the corresponding <iframe>and repeat the parsing process;For Shadow DOM components: switch to shadowRoot and extract the internal input field;For dynamic forms without the <form> tag (such as React / Vue rendered containers): traverse all <input>, <button>, <label>, etc. elements and construct a pseudo-form structure.

[0024] (3) Password field intelligent recognition based on static feature library and AI inferenceHTML5 attribute priority matching: judge autocomplete="username", autocomplete="current-password", type="password", type="email", etc. standard attributes;Authentication field naming rule feature matching: fuzzy match the name and id attributes of the input box with keywords such as user|username|email|login|pass|password|pwd|token|string, etc.Conflict scenario: when HTML5 attributes conflict with associated text labels, prioritize HTML5 attributes; if there is still ambiguity, further parse the page visual layout relationship (such as the DOM level of the field and the <label> CSS style position) for secondary verificationHidden field extraction: identify CSRF tokens in type="hidden" input boxes and automatically fill them in subsequent weak password detection requestsDeep learning natural language processing AI model inferenceFeature hashing and cache check: first, generate a feature hash value based on multiple attributes of the field. These attributes include label type, input type, placeholder, name attribute, id attribute, text content, class name, autocomplete attribute, etc. Then check if this feature hash value exists in the cache. If it exists, directly get the field type from the cache and return it, which can avoid repeated AI inference

[0025] Feature information collection: if the feature hash value does not exist in the cache, collect a series of feature information related to the field;Build prompt words and call AI model: combine the collected feature information into a prompt word, and include the field screenshot data in the request so that the model can combine visual information for judgment. Then request the AI model to judge the type of the field. Here, the AI model is required to return only the field type, which may be username, password, captcha, submit button, or others.The system will obtain the results returned by the model, and then use a preset mapping table to standardize the results, converting them into the type identifiers used internally by the system. If the results returned by the model are not in the mapping table, they will be marked as "unknown". The field recognition results are shown in Figure 2.

[0026] In specific implementation, regarding the weak password detection link of the Web form, the following is a specific example:Use the action path, method, and fields (username field, password field, hidden field name) information returned by the dynamic analysis module; for each group of username / password: construct a POST request, fill in the corresponding parameters with the username, password, CSRF token, and other hidden field values; send the request and determine whether the login is successful based on the response status code (such as 200, 302 redirect) and whether the response body contains success keywords (such as "Welcome", "Dashboard", "token"); record the log for the failure case and continue with the next group combination; if successful, record information such as the target IP, port, username, password, protocol type, verification time, successful response header / body, etc.

[0027] As a preferred implementation, before sending the request message to the target URL, if there is token verification, extract the token value from the front-end code of the target page and append it to the HTTP form request message before sending. This belongs to the anti-automation bypass mechanism.

[0028] In the entire detection method, in addition to adding the token value, the anti-automation bypass mechanism also includes: for the password detection protection mechanism in the Web page, adopting methods such as automatically extracting and filling the CSRF field, randomizing the request header field, and accessing the proxy pool rotation strategy. For example, if there is token verification, extract the token value from the front-end code of the target page in advance and automatically append it to the HTTP form request message; add standardized request headers (User-Agent, Referer) to the HTTP form request message to achieve request disguise, and support proxy rotation during sending to avoid IP blocking.

[0029] Among them, for captcha processing: determine whether a captcha exists through image feature analysis (pixel complexity, character distortion, color distribution); call the captcha recognition engine to recognize the captcha and fill in the recognition results in the corresponding fields.

[0030] CSRF token and hidden fields: During dynamic rendering, all hidden input field values ​​(including CSRF token, timestamp, digital signature, etc.) are automatically extracted; during weak password detection, these hidden field values ​​are filled into the POST request along with the username / password to ensure legality.

[0031] Request header and proxy IP rotation: randomize HTTP request headers: User-Agent, Referer, Accept-Language, X-Forwarded-For, etc.; maintain a proxy IP pool, obtain available proxies through the interface, and randomly switch the access IP address for each weak password detection.

[0032] The aforementioned static feature library stores login features of mainstream Web services (Tomcat, Jenkins, WordPress, etc.), including: Default login path (e.g., Tomcat's / manager / html); Form field naming rules (e.g., JBoss's j_username / j_password); Successful login indicator (e.g., WebLogic Server Console in WebLogic). Port mapping relationship (e.g., Grafana's default port is 3000).

[0033] The feature library is stored in JSON format and includes key fields such as Web service name, default port (port mapping relationship), default login path, field mapping relationship, login success identifier, and form field naming rules. O(1) complexity matching is achieved through an in-memory hash table.

[0034] In addition, when the web service of the target page does not belong to one of the static feature libraries, the target page form is equivalent to a dynamic Form. To parse and classify the fields of the dynamic Form, it is necessary to first follow the HTML5 form specification to determine the field type. If the recognition cannot be completed, then recognize the non-standard form (for example, in the form dynamically generated by React / Vue, the container may store non-standard expressions): (1) Field semantic analysis: Based on the predefined keyword list (USERNAME_KEYWORDS / PASSWORD_KEYWORDS) (preset), according to the field name, id attribute and associated <label> text of each field, match keywords from the keyword list to identify the field name; if the type of the field cannot be recognized, then identify the field name through the "logic" of type inference (the code snippet is as follows):def is_username_field(name, label_text):return any(keyword in name for keyword in ['user', 'login']) or \any(keyword in label_text for keyword in ['用户名'])Automatically identify the username and password fields in the form through text keyword matching. Adopt the strategy of combining the predefined keyword list with multi-attribute matching to achieve a preliminary judgment of the field semantics, and thus construct a form structure to be detected.

[0035] Regarding the field type recognition, as shown in Figure 3, use the hierarchical rule (HTML5 attribute → framework feature → AI inference) to recognize the username field and password field.

[0036] The first layer: HTML5 standard field type parsing layerFirst, follow the HTML5 form specification to determine the field type, detect the autocomplete value (attribute) (for example, "username" identifies the username field, "current-password" identifies the password field); detect the type value (attribute) (for example, the "password" type is directly determined as a password input box, and the "email" type is determined as a username candidate field); assist in judgment with the inputmode value (attribute) (for example, the "numeric" mode may indicate a verification code field).It enables zero-configuration, accurate identification of modern forms that conform to Web standards. When a conflict is detected in the attribute values ​​of a field (such as the simultaneous existence of autocomplete="username" and type="password"), a conflict flag is activated (marked as a conflict state) and the field type is transferred to the next level for resolution. The second layer, the framework feature matching layer, constructs a feature fingerprint library (pre-defined) based on the naming conventions of mainstream development frameworks. It establishes a multilingual keyword mapping table (e.g., "user" / "login" / "account" maps to the username field, and "pass" / "secret" / "password" maps to the password field). It checks whether a matching text can be found in the multilingual keyword mapping table. If so, it determines the type of the matching field in the mapping table. If not, it analyzes the specific class attribute of the field container (e.g., v-text-field in Vue framework, MuiInputBase-root in React) and detects <label>the binding relationship of the element's for attribute or the semantic relationship of adjacent text nodes to determine the field type. If it still cannot be parsed, it proceeds to the third layer.

[0037] The third layer: The AI ​​inference layer inputs the form structure tree and page rendering screenshots into the AI ​​inference layer. Through deep learning models (such as deepseek, etc.), it integrates the visual features, spatial relationships and contextual semantics that the first two levels (analyzing the front-end code) failed to cover (such as the form title "User Login" to strengthen account password recognition) to achieve field type inference in complex scenarios.

[0038] After field type recognition is completed, scan the hidden input items and extract the CSRF token value: # Extracting from hidden fields hidden_fields = driver.find_elements(By.XPATH, " / / input[@type='hidden']") # Filter for high-probability CSRF fields (names containing token / session / csrf, etc.) csrf_candidates = [f for f in hidden_fields if re.search(r'(csrf|token|session)', f.get_attribute("name"))] Regular CAPTCHAs are identified by named fields, while complex CAPTCHAs are identified by machine learning (AI inference layer) using visual features to assist in identifying the token value.

[0039] Next, we enter the weak password detection stage: using a preset dictionary to initiate batch attempts; Result verification: Monitor login response (redirect path, cookie settings) or protocol-specific success indicators.< / label>

[0040] As a preferred implementation, the method for generating an HTTP form request message based on the constructed web form structure is as follows: Generate a request body and a request header for each username / password combination. Among them, the request body is a key-value pair organized by the username, password, and all hidden fields, and the encoding format of the key-value pair is in the x-www-form-urlencoded format.

[0041] The method of this embodiment can also integrate protocol weak password detection. As shown in Figure 4 and Figure 5, first, perform protocol judgment and initialization to determine the protocol and method used for network authentication, specifically including: (1) Web form authentication protocol (HTTP / HTTPS form login or basic authentication); (2) Database connection protocol (such as MySQL, Redis, etc.); (3) Network service protocol (such as SSH, FTP, Telnet, SMTP, POP3, etc.). The method of judgment and initialization is: input the target address (URL / IP / domain name), and according to the target-related information, determine to obtain the weak password detection configuration information from the database, including whether to enable weak password detection, whether to use a proxy, the dictionary file path, the number of concurrent threads, etc.

[0042] (1) Weak password detection for HTTP basic authentication For HTTP / HTTPS services that support the three authentication methods of Basic, Digest, and NTLM, construct the corresponding Auth objects in sequence: Basic: HTTPBasicAuth(username, password); Digest: HTTPDigestAuth(username, password); NTLM: HttpNtlmAuth(username, password) (supports Windows domain accounts).

[0043] After constructing the corresponding Auth object, initiate a concurrent GET request. If the returned status code is 200, it is considered a successful login.

[0044] Specifically, the inputs are: target URL, weak password dictionary, authentication type (Basic, Digest, NTLM) (encryption algorithm). Processing: Concurrently adapt the authentication type protocol for each (username, password) combination in the weak password dictionary to obtain a standardized message. If the authentication type is Basic, the protocol adaptation function is requests.auth.HTTPBasicAuth(username, password); if it is Digest, the protocol adaptation function is requests.auth.HTTPDigestAuth(username, password); if it is NTLM, the protocol adaptation function is requests_ntlm.HttpNtlmAuth(username, password). Set the values ​​of the parameters proxies, headers, and timeout in the standardized message, and send the standardized message to the target URL via a GET request. If a status code of 200 is returned, success is recorded.

[0045] (2) Database protocol weak password detection for MySQL: Use the libmysqlclient client or pymysql to try to connect with the specified username / password. If the handshake returns OK_Packet, then it is successful; For Redis: Use the redis-py client and try logging in with the AUTH command. If it returns +OK, then it was successful. For MSSQL, PostgreSQL, and similar databases, a similar method is used to determine successful login based on the respective database client library.

[0046] Specifically, the inputs are: target IP and port, database application (program, service) type (MySQL, Redis, PostgreSQL, MSSQL, etc.), and weak password dictionary; Processing: Concurrently send each (username, password) combination from the weak password dictionary to the target IP and port for password detection. MySQL: Call the connect function in the pymysql or MySQLdb function library to initiate a connection with connect(host, user=username, password=password, port=port). If the connection is successful and returns OK_Packet, record the success. Redis: Call the StrictRedis function in the redis-py function library to send a ping() to the target IP and port using StrictRedis(host, port, password=password). If the target returns PONG, then record success. (3) SSH / FTP / Telnet weak password detection SSH (ssh_brute): Uses Paramiko SSHClient, supports socks proxy, attempts to log in via client.connect(), succeeds if no exception occurs; FTP (ftp_brute): Using ftplib or a socket proxy based on socks, call ftp.connect() and ftp.login(). If the return code starts with "2", it is successful. Telnet (telnet_brute): Uses telnetlib to read the shell prompt (such as "$" or "#") using telnet.read_until("login") and write(username / password) to determine success; Concurrent execution: Use ThreadPool or Celery asynchronous tasks to perform weak password detection in parallel for each protocol; during the detection process, if a difference is found between the target protocol version and the static feature database record (such as the encryption authentication mechanism added in MySQL 8.0), the AI ​​inference module can generate a detection strategy compatible with the version in real time based on the version number and extended fields in the response, and adjust the authentication method or parameters attempted for the weak password.

[0047] Specifically, for SSH: Input: target IP, port, weak password dictionary, timeout; If a proxy is enabled: obtain proxy information, use the function socks.socksocket() to create a proxy environment and proxy socket, and then pass the proxy socket to the client connection function client.connect(sock=proxy_sock) in the Paramiko library; If there is no proxy: client.connect(host, port, username, password, timeout, banner_timeout); If the connection is successful and no error is returned, the verification is considered successful, and the result is recorded. For FTP: Input: target IP, port, weak password dictionary, timeout; If a proxy is enabled: create a proxy environment using the function socks.socksocket(), use the ftp function library to call the function ftp.connect(host, port, timeout) to connect, and use the function ftp.login(username, password) to authenticate for login after connection; If there is no proxy: directly use the ftp function library to call the function ftp.connect() to connect, and after connecting, use the function ftp.login(username, password) to log in and authenticate; If the response code begins with "2", then success is recorded; For Telnet: Input: target IP, port, weak password dictionary, timeout; The program determines whether to enable a proxy based on the input parameters. If enabled, it establishes a Telnet connection with the target server's specified IP address and port using the specified proxy object `proxyObj`; otherwise, it directly connects to the target. The entire connection process completes within the set timeout period. After a successful connection, the program continuously reads the information returned by the server until it encounters a prompt with the keyword "login," indicating that the server is ready to receive a username. Upon detecting the "login" prompt, the program selects a username from the given weak password dictionary and sends it to the server using the `write` method. After the username is entered, the program continues to read the server's response until it encounters a prompt with the keyword "word," indicating that the server is waiting for a password. Upon detecting the "word" prompt, the program selects the password corresponding to the current username from the same weak password dictionary and sends it to the server using the `write` method, completing the submission of authentication credentials.After submitting the password, the program immediately reads and captures all currently available server return information. By parsing the response result, it can be determined whether the weak password attempt is successful.

[0048] If the returned content contains "$" or "#", record it as successful.

[0049] All successful login information (target address, protocol type, username, password, authentication time, etc.) is uniformly stored in the database for management; through the collaborative work of the above modules, the solution of this embodiment can adapt to modern complex protocol environments and achieve the weak password detection ability with wide coverage, high accuracy, and low false positives.

[0050] It should be noted that the method of this embodiment can be built around the core logic of multi-protocol adaptive weak password detection relying on the network target vulnerability situation monitoring scenario. As shown in Figure 6, each module collaborates to implement the complete process from asset detection (IP, domain name, node) to weak password detection and result control, which is briefly described as follows: (I) Core function modules 1. Asset detection module Function: Execute asset detection and parsing operations, corresponding to the process of "receiving the asset detection range, obtaining network entity response information, and identifying live hosts / open ports / running services".

[0051] Implementation logic: Receive the asset detection range (IP address, IP address segment, domain name) input by the user, call the multi-protocol detection component, collect network entity response information, parse it to identify asset information such as live hosts, open ports, and running services, and store it in the asset database (associated with the Mongo database).

[0052] 2. Multi-protocol weak password detection module Function: Execute multi-protocol adaptive weak password detection operations that integrate static feature libraries and dynamic AI reasoning, corresponding to the process of "screening weak password risk services, multi-protocol adaptive detection, weak password dictionary call, and login attempt" in Embodiment 1.

[0053] Implementation logic: Static feature library driven: Relying on a pre-built multi-protocol static feature library (storing protocol default authentication fields, weak password high-frequency combinations, service fingerprint rules), it quickly matches basic detection strategies (such as SSH default port 22 authentication process, FTPBasic authentication field format); Enhanced Dynamic AI Inference: Introducing an AI inference component to analyze response anomalies during the detection process in real time (such as CAPTCHA triggering, login frequency restrictions), and dynamically adjusting the detection strategy (CAPTCHA recognition and autofill, adaptive control of detection frequency, and intelligent switching of proxy IPs). Weak password attempts and result determination: Retrieve combinations from the weak password dictionary, use multi-threading technology to attempt logins in parallel, determine weak password vulnerabilities based on the response results (status code, login success indicator), and record the detection results.

[0054] 3. Weak password dictionary management module function: Performs management operations of weak password dictionary library, corresponding to the "user imports custom dictionary, system format verification and deduplication" process in Embodiment 1.

[0055] Implementation logic: Provide a dictionary import interface to support users to upload custom weak password dictionary files; perform format verification (such as text encoding, entry separation compliance) and deduplication (based on hash algorithm or string matching) on ​​the imported dictionary; maintain a standardized weak password dictionary library (associated with Redis cache + Mongo) to provide dynamically updated dictionary resources for the detection module.

[0056] (II) Supporting Management Module 1. Target Management Module Functions: Enables full lifecycle management of target information, corresponding to the "target information display, query, filtering, adding, editing, deleting, and result viewing" functions in the invention content.

[0057] Implementation logic: Construct a target information database (storing name, organization, domain name, type, etc.), provide a Web interface / API interface, support users to visualize the operation of target assets, associate weak password detection tasks and results, and realize the dynamic maintenance of target assets.

[0058] 2. Task management module function: realizes the scheduling and control of weak password detection tasks, corresponding to the "task information display, query, filter, create, pause, start, edit and delete" functions in the invention content.

[0059] Implementation logic: Relying on a task scheduling engine (such as Celery + Redis queue), it supports users to create weak password detection tasks (configuring parameters such as detection scope, dictionary, concurrency, frequency limit, etc.); monitors the task status in real time (creating, executing, completed, paused), and provides the ability to dynamically intervene in the task execution process (pause / start / terminate) to ensure that tasks are executed as needed.

[0060] 3. Proxy pool management moduleFunction: Realize the dynamic management of proxy IPs, corresponding to the requirements of "proxy information display, query, filtering, addition, editing, deletion" in the invention content and "IP proxy pool switching" for weak password detection.

[0061] Implementation logic: Maintain a proxy IP resource library (store IP address, port, type, availability status), provide the ability to dynamically call proxy IPs for the weak password detection module; monitor the availability of proxies in real time, automatically remove invalid proxies, and supplement valid proxies to ensure the flexibility and continuity of IP switching during the detection process.

[0062] II. System working processTaking "weak password detection task execution" as an example, the following fully presents the system process as shown in Figure 7:1. Task creation and distributionThe system administrator / user 100 issues a weak password detection task 220 (specifying parameters such as asset detection scope, dictionary, concurrency, etc.) through the main node 200 application interface module 210; the main node task scheduling module disassembles the task and distributes it to the slave nodes 400 through the transaction cache database; the slave node task scheduling unit receives the task 410 and triggers the probe scanning unit to execute asset detection 420. Collect network entity response information, parse the live hosts, open ports, and running services, and store them in the result storage database (MongoDB).

[0063] 2. Weak password detection executionThe slave node weak password detection unit 440 loads the multi-protocol weak password detection module, screens high-risk services (SSH, RDP, FTP, etc.), retrieves the protocol default detection strategy, uses the dynamic AI inference layer to assist in identifying the web login form, obtains the dictionary combination from the weak password dictionary management module to analyze the response in real time, calls the proxy pool management module to switch IPs and adjust the detection frequency; tries to log in in parallel with multiple threads and records the results: if successful, mark the vulnerability and store it in the vulnerability management module; if failed, continue to traverse the dictionary.

[0064] 3. Results summary and display: The detection results are summarized by the result processing unit of node 400 and then stored in database 320 and synchronized to master node 200; users can query the visualization results (asset distribution, vulnerabilities) through the target management module and export the data.

[0065] Embodiment 2 This application also relates to an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0066] The electronic device can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The memory can be used to store computer programs and / or modules. The processor performs various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by calling data stored in the memory.

[0067] The relevant technical solutions are the same as above, and will not be repeated here.

[0068] Embodiment 3 This application also relates to a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0069] Specifically, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0070] The relevant technical solutions are the same as above, and will not be repeated here.

[0071] Embodiment 4 This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of the method described in the above embodiments of this application.

[0072] The relevant technical solutions are the same as above, and will not be repeated here.

[0073] Those skilled in the art will readily understand that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / iframe> < / label> < / label> < / label> < / form>

Claims

1. A web form weak password detection method based on the collaboration of a static feature library and AI dynamic analysis, characterized in that, include: Launch a headless browser to load the target page, execute an explicit wait to ensure that dynamic elements are rendered, traverse the DOM tree and Shadow Root in the front-end code of the target page, locate all potential input fields, and construct the form structure tree; If the web service of the target page belongs to one of the static feature libraries, a web form structure to be detected is constructed based on the pre-built static feature library containing multiple login features of various web services and the form structure tree. Otherwise, the field type is determined according to the HTML5 form specification, including detection of the autocomplete attribute value, the type attribute value, and the inputmode attribute value. When a conflict is detected between different attribute values ​​of a field, the field is marked as conflicting and transferred to the frame feature matching layer. The frame feature matching layer determines whether a keyword matching the language of the field can be found in the pre-built multilingual keyword mapping table. If so, the type corresponding to the matching keyword is determined in the mapping table. If not, the specific class attribute of the field container to which the field belongs is analyzed and detected. <label> The field type is determined by the binding relationship of the element's for attribute or the semantic association of adjacent text nodes. If the type still cannot be resolved, it is handed over to the AI ​​inference layer. Through the AI ​​inference layer, based on the form structure tree and the page rendering screenshot, the visual features, spatial relationships and contextual semantics that were not covered by the first two layers are integrated by the deep learning model to realize the field type inference in complex scenarios. A web form structure to be detected is constructed based on each field type.< / label> Based on the constructed web form structure, an HTTP form request message is generated. After adding standardized request headers to the request message, it is sent to the target URL and the response is analyzed to achieve weak password detection.

2. The web form weak password detection method as described in claim 1, characterized in that, Before sending the request message to the target URL, if token verification exists, extract the token value from the front-end code of the target page, append it to the HTTP form request message, and then send it.

3. The web form weak password detection method as described in claim 1, characterized in that, The method for generating HTTP form request messages based on the constructed web form structure is as follows: Generate a request body and a request header for each username / password combination. The request body consists of key-value pairs containing the username, password, and all identified hidden fields, encoded in x-www-form-urlencoded format.

4. The web form weak password detection method as described in claim 1, characterized in that, The method also includes a dynamic anti-detection mechanism, specifically including: rotating the source IP of the packet request through a proxy IP pool; when a verification code is detected, calling the verification code recognition module to automatically parse and fill the verification code field to avoid the interception of the protection mechanism.

5. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 4.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein the computer program, when executed by a processor, controls the device on which the storage medium is located to perform the steps of the method as described in any one of claims 1 to 4.

7. A computer program product, characterized in that, Includes a computer program; when the computer program is executed by a processor, it implements the method of any one of claims 1 to 4.

Images