A web system login portal security test method and system based on behavior simulation

Abstract

The application discloses a kind of based on behavior simulation Web system login entrance security test method and system, belong to network security field.For traditional test method is carried out password guessing after constructing data packet by analyzing web page code or manual login, accuracy is low, cannot bypass encryption, signature and other protection mechanism.The application obtains login traffic by simulating artificial login process, and proposes a kind of traffic screening algorithm to filter irrelevant traffic.Finally, intelligently select two different password guessing modes, quickly guess the page with simple login logic and no anti-guessing mechanism, and successfully guess the page with complex logic and anti-explosion mechanism.The application is mainly used for automatically testing the security of login entrance in Web system, has the advantages of low false alarm rate, strong generalization ability, automation, easy to use and concealment, effectively improves the accuracy and efficiency of login entrance security test, and has positive significance and practical value for current security ecological construction.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method and system for security testing of web system login portals based on behavioral simulation. Background Technology

[0002] In recent years, as enterprises and organizations have increasingly emphasized information security, the construction of various information systems has been continuously improved. While enterprises have relatively good security measures for publicly exposed resources on the internet, their security capabilities for private resources—which are more sensitive and hidden behind login functions—are generally far weaker, relying solely on the reliability of user login passwords. Therefore, login functionality is often the first step attackers take to breach security boundaries, and it is also of great significance for security assessments.

[0003] Currently, testing of login functionality still relies primarily on manual methods. However, with the increasing prevalence of attack and defense drills and penetration testing, the drawbacks of manual login functionality testing—such as being time-consuming, labor-intensive, repetitive, and prone to errors and missed detections—are becoming more prominent. Some security researchers have open-sourced tools for automatically capturing login messages, but due to the complexity and diversity of login functionality identification, especially for dynamically rendered websites and login processes with encryption protection, existing tools cannot achieve complex login message identification and automated password guessing.

[0004] Traditional login page identification methods are based on regular expressions or rules, but once the rules are formed, they cannot be modified and lack flexibility. Traditional methods only consider partial contextual information; due to the flexibility of HTML, they cannot handle dynamically bound events in dynamically generated web pages, nor can they simulate complex login behaviors, such as encrypted logins and logins that first perform username existence checks. Therefore, traditional methods suffer from a large number of false positives and false negatives. They can only handle simple form-based logins and cannot fully trigger all login-related events. Furthermore, they lack effective methods for analyzing data packet traffic, which often contains a large amount of meaningless data, making it difficult to connect with subsequent password guessing work. Summary of the Invention

[0005] This invention proposes a web system login portal security testing method and system based on behavior simulation, which solves or at least partially solves the technical problems of low accuracy and inability to bypass encryption, signature and other protection mechanisms in the prior art.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0007] The first aspect provides a web system login portal security testing method based on behavior simulation, including:

[0008] S1: Monitor and capture browser traffic;

[0009] S2: The login process of the user is simulated twice using two different sets of pre-set usernames and passwords, and the traffic generated during the two login processes is saved. The traffic generated during the first login process constitutes the first traffic set, and the traffic generated during the second login process constitutes the second traffic set.

[0010] S3: Use a comparison-based filtering algorithm to filter the traffic in the first traffic set and the second traffic set to obtain the first login traffic set and the second login traffic set;

[0011] S4: Determine the password guessing type based on the obtained first login traffic set and second login traffic set;

[0012] S5: Based on the determined password guessing type, select the corresponding mode to guess the password.

[0013] In one implementation, step S2 includes:

[0014] The login process of a user is simulated using the first set of username and password pairs. The username input position in the first set of username and password pairs is obtained by retrieving input tags, and the password input position is obtained by retrieving password tags, thus obtaining the first traffic set.

[0015] The login process of a user is simulated using a second set of username and password pairs. The first and second sets of username and password pairs are different. The username input position in the second set of username and password pairs is obtained by retrieving the input tag, and the password input position is obtained by retrieving the password tag, thus obtaining the second traffic set.

[0016] In one implementation, the username-password pair used in the first traffic set is a first username and a first password, and the username-password pair used in the second traffic set is a second username and a second password. Step S3 includes:

[0017] S3.1: Preprocess the data packets contained in the first traffic set and the second traffic set;

[0018] S3.2: Compare the number of data packets contained in the two preprocessed traffic sets. If the number of data packets contained in the two traffic sets is inconsistent, traffic capture is performed again.

[0019] S3.3: Calculate the MD5 hash of all data packets contained in the two traffic sets, and compare the MD5 hashes of the data packets contained in the first traffic set and the second traffic set in sequence. If the MD5 hashes of the data packets contained in the two sets are the same, delete the corresponding data packets in the two traffic sets. After all data packets are compared, the first login traffic set and the second login traffic set are obtained.

[0020] In one implementation, step S4 includes:

[0021] Determine whether it is a login page based on whether the number of data packets contained in the data packets of the first login traffic set or the second login traffic set is 0;

[0022] When the number of data packets in the first login traffic set is 1, delete the corresponding username and password pairs in the first login traffic set and the second login traffic set respectively. Then, compare the data packets contained in the first login traffic set and the second login traffic set again. If the contents of the contained data packets are the same, it is a quick password guessing and the flag corresponding to quick password guessing is set to 1. If the contents of the contained data packets are the same, it is a browser password guessing and the flag corresponding to browser password guessing is set to 1.

[0023] In one implementation, step S5 includes:

[0024] S5.1: Load username and password dictionaries, and generate a list of usernames and passwords to be tried;

[0025] S5.2: When the flag for quick password guessing is 1, use the data packet from the first login traffic set as a template, replace the username string in the template with the username in the list of usernames and passwords to be tried, replace the password in the template with the password in the list of usernames and passwords to be tried, replay the data packet, and determine whether the password guessing is successful. When the password guessing is successful, output the corresponding username and password pair.

[0026] S5.3: When the browser password guessing flag is 1, the username and password pairs in the list of usernames and passwords to be tried are used as input for simulated filling. The login process is repeated, and the password guessing is judged to be successful. When the password guessing is successful, the corresponding username and password pair is output.

[0027] Based on the same inventive concept, a second aspect of the present invention provides a web system login portal security testing system based on behavior simulation, comprising:

[0028] The main module is used to monitor and capture browser traffic;

[0029] The login simulation module is used to simulate the user's login process twice using two preset sets of different usernames and passwords, and save the traffic generated during the two login processes. The traffic generated during the first login process constitutes the first traffic set, and the traffic generated during the second login process constitutes the second traffic set.

[0030] The traffic filtering module is used to filter the traffic in the first traffic set and the second traffic set using a comparison-based filtering algorithm to obtain the first login traffic set and the second login traffic set.

[0031] The password guessing module is used to determine the password guessing type based on the first login traffic set and the second login traffic set; and to select the corresponding mode to guess the password based on the determined password guessing type.

[0032] In one implementation, the system further includes a storage module for storing login traffic sets and username-password pairs obtained by password guessing.

[0033] Based on the same inventive concept, a third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements the method described in the first aspect.

[0034] Based on the same inventive concept, a fourth aspect of the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect.

[0035] The present invention provides a web system login portal security testing method and system based on behavior simulation, which has at least the following technical effects:

[0036] Traditional login password guessing tools rely on static analysis of webpage forms to simulate form submissions and obtain login messages. However, with the development and updates of various front-end frameworks, many websites are dynamically built using technologies such as JavaScript and AJAX. Static analysis cannot obtain dynamically generated webpages; it can only obtain the entry point information of the front-end framework and cannot obtain login-related forms, thus failing to correctly identify messages for password guessing.

[0037] This invention proposes a web system login portal security testing method based on behavior simulation, which obtains login traffic by simulating real user logins. It elevates the traffic capture problem to a user interface-level solution, avoiding complex issues such as encryption, dynamic binding, and how to execute JavaScript code. The core content of a login page consists of input boxes for filling in login information and login buttons for sending messages. Login tags are identified through typical feature values, and preset values ​​are entered into the obtained input box tags. Clicking the obtained button tag completes the message sending.

[0038] Furthermore, for irrelevant traffic generated during the simulated login process, this invention proposes a comparison algorithm (a comparison-based filtering algorithm) that solves the problem of traditional keyword-based filtering methods failing to generalize. This algorithm filters login-irrelevant traffic by comparing traffic generated from two different username and password pairs. Unlike traditional keyword-dependent filtering methods, this approach offers high accuracy and eliminates the need to maintain a keyword list.

[0039] Furthermore, this invention proposes two complementary password guessing methods, significantly improving the efficiency of password guessing. For the password guessing problem, there are two scenarios: single-packet plaintext login and complex logins other than single-packet plaintext login. When the username and password pair we entered explicitly appear in the message, and there are no anti-password guessing mechanisms such as checksums, timestamps, or signatures, the message is directly constructed for password guessing. This mode achieves a password guessing process in approximately milliseconds. If the login process is complex and anti-password guessing mechanisms exist, behavioral simulation can still be used for browser password guessing. This achieves excellent results, with fast password guessing for simple login pages and good handling even for complex pages. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a flowchart of the Web system login portal security testing system based on behavior simulation of the present invention.

[0042] Figure 2 This is a flowchart of the login process simulation based on behavior simulation of the present invention.

[0043] Figure 3 This is a flowchart of the comparison-based filtering algorithm of the present invention. Detailed Implementation

[0044] In view of the shortcomings of the existing technology, the technical problem to be solved by the present invention is how to solve the problem that current automated password guessing tools cannot handle scenarios such as encryption and complex login processes, and that it is necessary to clean the traffic, filter out data packets that are not related to the login function, and then guess the user's password.

[0045] To achieve the above objectives, this invention provides a web system login portal security testing method and system based on behavioral simulation. Unlike traditional methods that construct data packets, this invention uses a web crawler to manipulate browser traffic, then cleans the data packets for fully automated password guessing. Specifically, the web system login portal security testing system provided by this invention analyzes existing samples and experience to more accurately identify and locate the login page, and determine login-related input and click tags. It simulates login by calling a browser, with the complex login logic and encryption process all handled by the browser, thus overcoming the shortcomings of traditional methods.

[0046] Subsequently, in order to filter out traffic that is irrelevant to login, this invention proposes a comparison-based filtering algorithm. After filtering, two different password guessing processes can be performed based on the characteristics of the login traffic: for single data packets where the username and password are both in plaintext, the username and password in the data packet can be directly replaced for fast password guessing; for other complex cases, the browser can be called to continue password guessing.

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] Example 1

[0049] This invention provides a web system login portal security testing method based on behavior simulation, comprising:

[0050] S1: Monitor and capture browser traffic;

[0051] S2: The login process of the user is simulated twice using two different sets of pre-set usernames and passwords, and the traffic generated during the two login processes is saved. The traffic generated during the first login process constitutes the first traffic set, and the traffic generated during the second login process constitutes the second traffic set.

[0052] S3: Use a comparison-based filtering algorithm to filter the traffic in the first traffic set and the second traffic set to obtain the first login traffic set and the second login traffic set;

[0053] S4: Determine the password guessing type based on the obtained first login traffic set and second login traffic set;

[0054] S5: Based on the determined password guessing type, select the corresponding mode to guess the password.

[0055] Specifically, S1 initializes the traffic capture functionality. It performs a series of initialization tasks on the browser, opens the target webpage, and after the webpage loads, it begins to monitor and capture the browser's traffic.

[0056] In step S3, the comparison-based filtering algorithm compares the data packets in the first traffic set and the second traffic set, filters out traffic that is irrelevant to login, and thus selects data packets that meet the conditions.

[0057] The main concepts of this invention include: obtaining login traffic by simulating a manual login process, proposing a traffic filtering algorithm to filter irrelevant traffic, and then intelligently selecting two different password guessing modes to quickly guess login logic on pages with simple login logic and no anti-guessing mechanisms, while also successfully guessing login logic on pages with complex login logic and anti-brute-force mechanisms. This invention is mainly used for automated security testing of login entry points in web systems, and has advantages such as low false positive rate, strong generalization ability, automation, ease of use, and stealth. It effectively improves the accuracy and efficiency of login entry security testing, and has positive significance and practical value for the current security ecosystem construction.

[0058] In one implementation, step S2 includes:

[0059] The login process of a user is simulated using the first set of username and password pairs. The username input position in the first set of username and password pairs is obtained by retrieving input tags, and the password input position is obtained by retrieving password tags, thus obtaining the first traffic set.

[0060] The login process of a user is simulated using a second set of username and password pairs. The first and second sets of username and password pairs are different. The username input position in the second set of username and password pairs is obtained by retrieving the input tag, and the password input position is obtained by retrieving the password tag, thus obtaining the second traffic set.

[0061] Please see Figure 2 This is a flowchart of the login process simulation based on behavior simulation of the present invention.

[0062] In the specific implementation process, the user login process is simulated using the first set of username and password, including the following steps:

[0063] Retrieve input tags and intelligently fill in the blanks based on username type (phone number, ID, email address, etc.).

[0064] Retrieve password tags and fill in the preset passwords.

[0065] If a label indicating agreement to the user agreement exists, select it, then locate the login-related label (login button label), and complete the login process in various ways such as clicking the login button or forcibly triggering an event, saving the traffic generated during this process.

[0066] In the second simulation, a different set of username and password credentials is used, and the above process is repeated to complete the simulation of the login process.

[0067] In one implementation, the username-password pair used in the first traffic set is a first username and a first password, and the username-password pair used in the second traffic set is a second username and a second password. Step S3 includes:

[0068] S3.1: Preprocess the data packets contained in the first traffic set and the second traffic set;

[0069] S3.2: Compare the number of data packets contained in the two preprocessed traffic sets. If the number of data packets contained in the two traffic sets is inconsistent, traffic capture is performed again.

[0070] S3.3: Calculate the MD5 hash of all data packets contained in the two traffic sets, and compare the MD5 hashes of the data packets contained in the first traffic set and the second traffic set in sequence. If the MD5 hashes of the data packets contained in the two sets are the same, delete the corresponding data packets in the two traffic sets. After all data packets are compared, the first login traffic set and the second login traffic set are obtained.

[0071] In practice, preprocessing of data packets includes decoding and deleting cookies. If the number of data packets in two traffic sets is inconsistent, the process returns to S1 for traffic capture. MD5 is the value calculated using a hash algorithm.

[0072] In one implementation, step S4 includes:

[0073] Determine whether it is a login page based on whether the number of data packets contained in the data packets of the first login traffic set or the second login traffic set is 0;

[0074] When the number of data packets in the first login traffic set is 1, delete the corresponding username and password pairs in the first login traffic set and the second login traffic set respectively. Then, compare the data packets contained in the first login traffic set and the second login traffic set again. If the contents of the contained data packets are the same, it is a quick password guessing problem, and the flag corresponding to the quick password guessing problem is set to 1. If the contents of the contained data packets are different, it is a browser password guessing problem, and the flag corresponding to the browser password guessing problem is set to 1.

[0075] Specifically, by analyzing the data packets in the first login traffic set or the second login traffic set, it is determined whether the target page is a login page, and whether a fast password guessing type based on data packet replacement or a browser password guessing type based on behavior simulation should be used.

[0076] If the number of data packets in the first login traffic set is zero, it is assumed that the page does not have login-related functions, and the process terminates.

[0077] When the number of data packets in the first login traffic set is 1, the username and password pair is deleted and compared again. If the contents of the data packets contained in the two login traffic sets are the same, it means that the target webpage does not have encryption, checksum, signature and other anti-password guessing mechanisms, and the login function only needs one data packet to complete. The flag corresponding to quick password guessing can be set to 1.

[0078] If the data packets contained in two login traffic sets are identical, it indicates that the login process of the target page is complex or that there are anti-password guessing mechanisms such as encryption, verification, and signature. In this case, the browser's password guessing flag should be set to 1.

[0079] In one implementation, step S5 includes:

[0080] S5.1: Load username and password dictionaries, and generate a list of usernames and passwords to be tried;

[0081] S5.2: When the flag for quick password guessing is 1, use the data packet from the first login traffic set as a template, replace the username string in the template with the username in the list of usernames and passwords to be tried, replace the password in the template with the password in the list of usernames and passwords to be tried, replay the data packet, and determine whether the password guessing is successful. When the password guessing is successful, output the corresponding username and password pair.

[0082] S5.3: When the browser password guessing flag is 1, the username and password pairs in the list of usernames and passwords to be tried are used as input for simulated filling. The login process is repeated, and the password guessing is judged to be successful. When the password guessing is successful, the corresponding username and password pair is output.

[0083] In the specific implementation process, steps S5.2 and S5.3 can determine whether the password guessing was successful by checking the length of the response packet, whether the input tag is on the returned page, or by checking the blacklist. For example, the success of the password guessing can be determined by checking the length of the returned data packet in both successful and failed login scenarios, whether the input tag is present on the returned page when the password is successfully guessed, and whether the response packet contains firewall fingerprints or brute-force blocking prompts.

[0084] When performing password guessing, try all username-password pairs in the username-password list generated in S5.1.

[0085] Example 2

[0086] Based on the same inventive concept, this embodiment discloses a web system login portal security testing system based on behavior simulation, including:

[0087] The main module is used to monitor and capture browser traffic;

[0088] The login simulation module is used to simulate the user's login process twice using a preset username and password, and save the traffic generated during the two login processes. The traffic generated during the first login process constitutes the first traffic set, and the traffic generated during the second login process constitutes the second traffic set.

[0089] The traffic filtering module is used to filter the traffic in the first traffic set and the second traffic set using a comparison-based filtering algorithm to obtain the first login traffic set and the second login traffic set.

[0090] The password guessing module is used to determine the password guessing type based on the first login traffic set and the second login traffic set; and to select the corresponding mode to guess the password based on the determined password guessing type.

[0091] Specifically, the main module is responsible for controlling the overall process, concurrent data capture, task scheduling, and other processes.

[0092] The main module is responsible for controlling the browser's population and clicking of login-related tags on the target page, and collecting the traffic generated during the simulation.

[0093] The traffic filtering module is used to process the traffic generated by the two sets of login simulation modules through a comparison algorithm, filter out traffic that is irrelevant to login, and determine the mode to be used in password guessing.

[0094] The password guessing module analyzes data packets with concentrated login traffic to determine the password guessing type. Based on the pattern information provided by the traffic filtering module, it performs packet password guessing or browser password guessing.

[0095] In one implementation, the system further includes a storage module for storing login traffic sets and username-password pairs obtained by password guessing.

[0096] The storage module mainly stores login traffic, password guessing results, etc.

[0097] like Figure 1 As shown, the Web system login portal security testing system based on behavior simulation provided by the present invention comprises six main modules, namely, a main module, a login simulation module, a traffic filtering module, a password guessing module, and a storage module. Figure 1The flowcharts show the operation between the various modules.

[0098] The modules are described below:

[0099] The main module is used to receive one or more target pages provided by the tester at the start of automated password guessing. It performs concurrent task scheduling according to the number of processes specified by the user. In a single task, it performs initialization settings for the browser, such as traffic monitoring, page locking, and ignoring certificate errors.

[0100] The login simulation module simulates the input and click behaviors of a normal user login. It uses a preset username and password pair for simulation, checking if the values ​​of the name, id, and class in the input tags match preset rules. If they match, it fills in the input with the preset username and password and sets the tag's value attributes. Then, it uses the same preset rules to locate the login button tag, simulating a click or actively triggering the onclick event. Finally, it forwards traffic to the traffic filtering module.

[0101] The traffic filtering module compares the data packets obtained from two simulated login events to effectively determine whether the obtained data packets are truly the data packets required for login, and distinguishes between sites that can be quickly guessed and sites that require launching a browser for password guessing. Finally, all login-related traffic sets are sent to the storage module and the password guessing module.

[0102] The password guessing module analyzes the data packets contained in the login traffic set to determine whether the target page is a login page and whether to use fast password guessing at the packet replacement level or browser password guessing based on behavior simulation. This invention supports two different password guessing modes. If the target webpage does not have a password guessing prevention mechanism and the login traffic set contains only one data packet, the username-password pair in the traffic can be directly replaced with the username-password pair to be guessed from the dictionary and replayed. For complex login logic or webpages with password guessing prevention mechanisms, the login simulation module is called again for password guessing. Finally, the password guessing result is sent to the storage module.

[0103] The storage module is responsible for formatting and storing password guessing results and login traffic sets.

[0104] Figure 3 This is a flowchart illustrating the login process simulation based on behavior simulation according to the present invention. The present invention initiates two sessions on a single page, performing the same tag operations in each session. The only difference is that the username and password entered in the two sessions are different, thereby capturing two batches of traffic.

[0105] This invention applies the concept of behavioral simulation to control the browser to fill in and click, simulating a real user login process. This method differs from traditional page code analysis methods, bypassing anti-password guessing mechanisms such as traffic encryption, traffic signatures, and timestamps. It eliminates the need for reverse engineering of the code logic; traffic generation relies on capture from the browser. This method can automatically detect the presence of login functionality on any webpage and automatically guess passwords when a login page exists, improving testing efficiency and accuracy in large-scale penetration testing or security assessments. The method includes the following steps:

[0106] Step 1: Determine if it's a pop-up login. Some websites use a pop-up login page. In this case, you should first click the login button. You can determine if it's a pop-up login by checking if the current page already has a login-related button, but you don't find any input labels for username and password.

[0107] Step 2: Simulate username and password input. First, locate the tags corresponding to the username and password. Find all input tags, filtering out similar tags like "reset password" and "register." Then, check if the values ​​of the id, class, name, and placeholder attributes of all input tags contain login-related keywords. This determines whether the input tag belongs to the required input category and type (regular username, QQ number, mobile phone number, email address, password, etc.). Finally, complete the simulation using two methods: simulated filling and directly binding values ​​to the tags.

[0108] Step 3: Simulate clicking the login button. This step is initiated when smart fill ends or when attempting to trigger a pop-up login window. Implementing the login button is relatively complex. Due to the dynamic nature of HTML, it only requires dynamically binding an onclick event; any tag can serve as the login button. Since the login button is located near the input tags, its validity can be determined using this rule, the presence of an onclick event, keywords, etc. Finally, the simulation is completed by simulating a click and forcibly triggering the onclick event.

[0109] Figure 3 This is a flowchart of the traffic filtering algorithm of the present invention. The invention simulates two login processes for a single page, performing the same tagging operations in each session. The only difference is that the username and password entered in the two sessions are different, thus capturing two batches of traffic. By comparing these two traffic streams, packets with slightly different content are obtained, achieving the function of filtering login packets from the traffic. When the two traffic streams are completely identical, it can be determined that the traffic has not changed due to the change of username and password, and therefore no login packets exist. This method greatly improves the accuracy of login page identification and login packet capture, and prepares for password guessing.

[0110] Step 1: After obtaining the two sets of traffic, first compare the number of data packets in the two sets of traffic.

[0111] Step 2: Since both packet transmissions trigger the same click event, this comparison can detect whether the network is stable. If the two data packet formats are inconsistent, a retry should be considered.

[0112] Step 3: For ease of comparison, calculate the MD5 hash of each data packet in the traffic set.

[0113] Step 4: Compare all data packets in the traffic set in order. Since the username and password sent twice are different, when the corresponding MD5 values ​​are different, it can be determined that it is related to login. The other packets with the same MD5 are directly filtered out, and two login traffic sets can be obtained.

[0114] Step 5: Determine the number of data packets in the login traffic cluster.

[0115] Step 6: If the number of data packets in the login traffic cluster is 0, it means that there is no login packet on the site and it is not a login page.

[0116] Step 7: If the number of data packets in the traffic cluster is 1, delete the corresponding username and password pair.

[0117] Step 8: Compare whether the unique packets in the two traffic sets are equal.

[0118] Step 9: If the results are the same, it means that the website has no other parameters related to login and the username and password are transmitted in plaintext. In this case, the quick password guessing function should be called and the quick password guessing flag should be set to 1.

[0119] Step 10: If the login traffic cluster contains multiple data packets, it is considered that the login logic is complex. If the traffic cluster contains only a single data packet, but the messages are inconsistent after deleting the username and password pair, it indicates that there are anti-password guessing mechanisms such as checksum, timestamp, traffic encryption, and signature. Set the browser password guessing flag to 1.

[0120] Since the system described in Embodiment 2 of this invention is the same system used to implement the web system login portal security testing method based on behavior simulation in Embodiment 1 of this invention, those skilled in the art can understand the specific structure and variations of this system based on the method described in Embodiment 1 of this invention, and therefore will not be repeated here. All systems used in the method of Embodiment 1 of this invention fall within the scope of protection of this invention.

[0121] Example 3

[0122] Based on the same inventive concept, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements the method described in Embodiment 1.

[0123] Since the computer-readable storage medium described in Embodiment 3 of this invention is the same computer-readable storage medium used in implementing the web system login portal security testing method based on behavior simulation in Embodiment 1 of this invention, those skilled in the art can understand the specific structure and variations of this computer-readable storage medium based on the method described in Embodiment 1 of this invention, and therefore will not be repeated here. All computer-readable storage media used in the method of Embodiment 1 of this invention fall within the scope of protection of this invention.

[0124] Example 4

[0125] Based on the same inventive concept, this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method in Embodiment 1.

[0126] Since the computer device described in Embodiment 4 of this invention is the same computer device used to implement the web system login portal security testing method based on behavior simulation in Embodiment 1 of this invention, those skilled in the art can understand the specific structure and variations of this computer device based on the method described in Embodiment 1 of this invention, and therefore will not be repeated here. All computer devices used in the method of Embodiment 1 of this invention fall within the scope of protection of this invention.

[0127] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0128] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0129] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention. Clearly, those skilled in the art can make various modifications and variations to the embodiments of the invention without departing from the spirit and scope of the invention. Thus, if these modifications and variations of the embodiments of the invention fall within the scope of the claims of the invention and their equivalents, the invention also intends to include these modifications and variations.

Claims

1. A web system login portal security testing method based on behavior simulation, characterized in that, include: S1: Monitor and capture browser traffic; S2: The login process of the user is simulated twice using two different sets of pre-set usernames and passwords, and the traffic generated during the two login processes is saved. The traffic generated during the first login process constitutes the first traffic set, and the traffic generated during the second login process constitutes the second traffic set. S3: Use a comparison-based filtering algorithm to filter the traffic in the first traffic set and the second traffic set to obtain the first login traffic set and the second login traffic set; S4: Determine the password guessing type based on the obtained first login traffic set and second login traffic set; S5: Based on the determined password guessing type, select the corresponding mode to guess the password; Wherein, the username and password pair used in the first traffic aggregation is the first username and the first password, and the username and password pair used in the second traffic aggregation is the second username and the second password. Step S3 includes: S3.1: Preprocess the data packets contained in the first traffic set and the second traffic set; S3.2: Compare the number of data packets contained in the two preprocessed traffic sets. If the number of data packets contained in the two traffic sets is inconsistent, traffic capture is performed again. S3.3: Calculate the MD5 of all data packets contained in the two traffic sets, and compare the MD5 of the data packets contained in the first traffic set and the second traffic set in order. If the MD5 of the data packets contained in the two sets are the same, delete the corresponding data packets in the two traffic sets. After all data packets are compared, the first login traffic set and the second login traffic set are obtained. Step S4 includes: Determine whether it is a login page based on whether the number of data packets contained in the data packets of the first login traffic set or the second login traffic set is 0; When the number of data packets in the first login traffic set is 1, delete the corresponding username and password pairs in the first login traffic set and the second login traffic set respectively. Then, compare the data packets contained in the first login traffic set and the second login traffic set again. If the contents of the contained data packets are the same, it is a quick password guessing and the flag corresponding to quick password guessing is set to 1. If the contents of the contained data packets are different, it is a browser password guessing and the flag corresponding to browser password guessing is set to 1.

2. The web system login portal security testing method based on behavior simulation as described in claim 1, characterized in that, Step S2 includes: The login process of a user is simulated using the first set of username and password pairs. The username input position in the first set of username and password pairs is obtained by retrieving input tags, and the password input position is obtained by retrieving password tags, thus obtaining the first traffic set. The login process of a user is simulated using a second set of username and password pairs. The first and second sets of username and password pairs are different. The username input position in the second set of username and password pairs is obtained by retrieving the input tag, and the password input position is obtained by retrieving the password tag, thus obtaining the second traffic set.

3. The web system login portal security testing method based on behavior simulation as described in claim 1, characterized in that, Step S5 includes: S5.1: Load username and password dictionaries, and generate a list of usernames and passwords to be tried; S5.2: When the flag for quick password guessing is 1, use the data packet from the first login traffic set as a template, replace the username string in the template with the username in the list of usernames and passwords to be tried, replace the password in the template with the password in the list of usernames and passwords to be tried, replay the data packet, and determine whether the password guessing is successful. When the password guessing is successful, output the corresponding username and password pair. S5.3: When the browser password guessing flag is 1, the username and password pairs in the list of usernames and passwords to be tried are used as input for simulated filling. The login process is repeated, and the password guessing is judged to be successful. When the password guessing is successful, the corresponding username and password pair is output.

4. A web system login portal security testing system based on behavior simulation, characterized in that, Based on the method described in claim 1, it includes: The main module is used to listen for and capture browser traffic; The login simulation module is used to simulate the user's login process twice using two preset sets of different usernames and passwords, and save the traffic generated during the two login processes. The traffic generated during the first login process constitutes the first traffic set, and the traffic generated during the second login process constitutes the second traffic set. The traffic filtering module is used to filter the traffic in the first traffic set and the second traffic set using a comparison-based filtering algorithm to obtain the first login traffic set and the second login traffic set. The password guessing module is used to determine the password guessing type based on the first login traffic set and the second login traffic set; and to select the corresponding mode to guess the password based on the determined password guessing type.

5. The web system login portal security testing system based on behavior simulation as described in claim 4, characterized in that, The system also includes a storage module for storing login traffic sets and username / password pairs obtained through password guessing.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed, it implements the method as described in any one of claims 1 to 3.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 3.

Images