Password auditing method, device, electronic device and computer-readable storage medium

Abstract

The present application provides a password auditing method, device, electronic device and computer-readable storage medium. The method includes: obtaining a request message to be processed, where the request message to be processed is a message for requesting login to a website to be audited; determining the request method adopted by the request message to be processed according to the message header of the request message to be processed; parsing the information to be audited from the request message to be processed according to the preset processing rule corresponding to the request method; and auditing the password in the information to be audited. The solution of the present application does not require engineers to perform manual reverse derivation work on information such as the login address of the website, the user name transmission field, and the password transmission field, thereby reducing the technical requirements for users during the auditing process, improving the user experience, and also improving the auditing efficiency. In addition, the solution of the present application will not impact the server where the website to be audited is located, and even if the website to be audited uses an unconventional password, it is possible to obtain and audit the password.

Description

Technical Field

[0001] This application relates to the field of information security, and more particularly, to a password auditing method, apparatus, electronic device, and computer-readable storage medium. Background Art

[0002] User authentication is the first line of defense for information systems, and the password mechanism is the most commonly used method in authentication. The strength of a password determines the complexity of a brute-force attack on the system.

[0003] Currently, the main auditing method is for information security devices to audit the password strength of websites through active scanning. Specifically, for each website to be audited, the information security device reverse-derives the login address, username transmission field, password transmission field, etc. of the website to be audited by capturing data packets or viewing the web page source code. Then, a large number of login data packets are constructed using weak password dictionaries and combinations of common usernames, and login attempts are made to the website to be audited. Subsequently, based on the feedback from the website to be audited, it is determined whether there are weak password accounts on the website.

[0004] Since the Hypertext Transfer Protocol itself does not stipulate how user authentication information such as usernames and passwords should be uploaded to the server. The designs of developers vary, and the login request page addresses, username field names, password field names, and data formats used by each website are all different. This makes it necessary for engineers to reverse-derive the login address, username transmission field, password transmission field, etc. of the website manually based on the captured data packets or web page source code when auditing the password strength of websites currently. This results in relatively high technical requirements for auditing and poor user experience. Moreover, each audit requires engineers to perform manual reverse-derivation work, which also greatly affects the audit efficiency.

[0005] In addition, since the existing auditing method audits by actively constructing a large number of login data packets and logging in to the website to be audited, it will impact the server where the website to be audited is located, and may have an adverse effect on the stability of the server. In addition, since the existing auditing method constructs a large number of login data packets using weak password dictionaries and combinations of common usernames, it only allows auditing of common passwords during the audit process. If the website to be audited uses unconventional passwords, then detection and auditing cannot be performed. Summary of the Invention

[0006] The purpose of the embodiments of this application is to provide a password auditing method, apparatus, electronic device, and computer-readable storage medium to solve the above problems.

[0007] An embodiment of the present application provides a password auditing method, including: obtaining a to-be-processed request message; the to-be-processed request message is a message for requesting to log in to the to-be-audited website; determining the request method adopted by the to-be-processed request message according to the message header of the to-be-processed request message; parsing out the to-be-audited information from the to-be-processed request message according to the preset processing rule corresponding to the request method; and auditing the password in the to-be-audited information.

[0008] The solution of the embodiment of the present application is different from the prior art that a large number of login data packets need to be actively constructed to send login requests to the to-be-audited website. In the above implementation process, by obtaining the to-be-processed request message for requesting to log in to the to-be-audited website, and then parsing the to-be-processed request message to obtain the to-be-audited information, and auditing the password in the to-be-audited information. In this way, there is no need to construct login data packets, nor to send login requests to the to-be-audited website, so that the server where the to-be-audited website is located will not be impacted, and the adverse impact on the stability of the server can be reduced. In addition, since the to-be-processed request message actually requesting to log in to the to-be-audited website is obtained for parsing, even if the to-be-audited website uses an unconventional password, the password can be obtained and then audited.

[0009] In addition, in the solution of the embodiment of the present application, by presetting corresponding processing rules for each request method, the to-be-audited information can be quickly parsed out from the to-be-processed request message according to the preset processing rule corresponding to the request method adopted by the to-be-processed request message. During the auditing process, engineers do not need to perform manual reverse derivation work on information such as the login address of the website, the user name transmission field, and the password transmission field, thereby reducing the technical requirements for users during the auditing process, improving the user experience, and also improving the auditing efficiency.

[0010] Further, determining the request method adopted by the to-be-processed request message according to the message header of the to-be-processed request message includes: identifying the request feature information included in the message header of the to-be-processed request message, and determining the request method adopted by the to-be-processed request message according to the request feature information; wherein, the request feature information is a specified field or a specified character possessed by the request method.

[0011] In the actual application process, when different request methods are adopted, different request characteristic information will be included in the request message. For example, when the Basic AUTH method is adopted, the Authenticate field will be included; when the GET request method is adopted, characteristic characters such as "GET" will be included; when the POST request method is adopted, characteristic characters such as "POST" will be included. Therefore, in the above implementation process, by identifying the request characteristic information included in the message header of the request message to be processed, it is possible to easily identify the request method adopted by the request message to be processed.

[0012] Further, the request characteristic information includes the Authenticate field; identifying the request characteristic information included in the message header of the request message to be processed, and determining the request method adopted by the request message to be processed according to the request characteristic information includes: determining whether the message header of the request message to be processed contains the Authenticate field; if the message header of the request message to be processed contains the Authenticate field, it is determined that the request method adopted by the request message to be processed is the Basic AUTH method.

[0013] In the above implementation process, it is very easy to determine whether the request method adopted by the request message to be processed is the Basic AUTH method according to whether the Authenticate field is included in the message header.

[0014] Further, the request characteristic information includes a first specified character and a second specified character; the first specified character is the character possessed by the GET request method, and the second specified character is the character possessed by the POST request method; identifying the request characteristic information included in the message header of the request message to be processed, and determining the request method adopted by the request message to be processed according to the request characteristic information further includes: if the message header of the request message to be processed does not contain the Authenticate field, determining whether the message header of the request message to be processed contains the first specified character or the second specified character; if the message header of the request message to be processed contains the first specified character, it is determined that the request method adopted by the request message to be processed is the GET request method; if the message header of the request message to be processed contains the second specified character, it is determined that the request method adopted by the request message to be processed is the POST request method.

[0015] In practical applications, since there may also be a first specified character such as "GET" in the Authenticate field. Therefore, in the above implementation process, by first determining whether the message header contains the Authenticate field, and then further determining whether the message header contains the first specified character or the second specified character when it does not contain it, the reliability of identifying the adopted request method can be improved, and then the reliability of the parsed password can be improved.

[0016] Further, the information to be audited includes a username and a password; when the request method is a GET request method, parsing the information to be audited from the request message to be processed according to the preset processing rule corresponding to the request method includes: parsing the parameter part of the URL (Uniform Resource Locator) address corresponding to the GET request method from the request message to be processed; respectively matching the parameter part with a preset first username rule and a first password rule; when the first username rule matches the parameter part successfully and the first password rule matches the parameter part successfully, extracting the username in the parameter part according to the matching result of the first username rule and the parameter part, and extracting the password in the parameter part according to the matching result of the first password rule and the parameter part.

[0017] In the actual application process, the inventor found that when using the GET request method for a login request, the username and password are usually written in the parameter part of the URL address according to certain rules. Therefore, in the above implementation process, by pre-configuring the first username rule and the first password rule, the parameter part is respectively matched with the preset first username rule and the first password rule. In this way, if there are both a username and a password, it can be determined that the request message to be processed is a message requesting login to the website to be audited, the username can be extracted through the first username rule, and the password can be extracted through the first password rule.

[0018] Further, the information to be audited includes a username and a password; when the request method is the POST request method, parsing the information to be audited from the request message to be processed according to the preset processing rule corresponding to this request method includes: determining the data format of the request message to be processed; respectively using the second username rule and the second password rule corresponding to the data format to match the content of the message body of the request message to be processed; when the second username rule matches the content of the message body and the second password rule matches the content of the message body, extracting the user from the content of the message body according to the matching result between the second username rule and the content of the message body, and extracting the password from the content of the message body according to the matching result between the second password rule and the content of the message body.

[0019] In the actual application process, the inventor found that when using the POST request method for a login request, the username and password are written in the message body according to different rules based on different data formats. Therefore, in the above implementation process, by first determining the data format of the request message to be processed, the preset second username rule and second password rule corresponding to this data format are respectively used to match the content of the message body. In this way, if both the username and password exist, it can be determined that the request message to be processed is a message requesting login to the website to be audited, the username can be extracted through the second username rule, and the password can be extracted through the second password rule.

[0020] Further, obtaining the request message to be processed sent to the website to be audited includes: when it is detected that there is a login request message sent to the website to be audited at the traffic entrance of the website to be audited, copying the login request message to obtain the request message to be processed.

[0021] In the above implementation process, by copying the login request message at the traffic entrance of the website to be audited, the request message to be processed can be obtained for auditing in a bypass manner without affecting the normal operation of the website to be audited, thus not impacting the server where the website to be audited is located and not causing adverse effects on the stability of the server.

[0022] The embodiment of the present application further provides a password auditing device, including: an obtaining module, configured to obtain a request message to be processed; the request message to be processed is a message requesting login to the website to be audited; a determining module, configured to determine the request method used by the request message to be processed according to the message header of the request message to be processed; an analyzing module, configured to parse the information to be audited from the request message to be processed according to the preset processing rule corresponding to this request method; and an auditing module, configured to audit the password in the information to be audited.

[0023] An embodiment of the present application further provides an electronic device, including: a processor and a memory; the processor is configured to execute one or more programs stored in the memory to implement any one of the above password auditing methods.

[0024] An embodiment of the present application further provides a computer-readable storage medium storing one or more programs, and the one or more programs can be executed by one or more processors to implement any one of the above password auditing methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] To more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required to be used in the embodiments of the present application. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0026] Figure 1 It is a schematic flowchart of a password auditing method provided by an embodiment of the present application;

[0027] Figure 2 It is a schematic diagram of a configurable rule provided by an embodiment of the present application;

[0028] Figure 3 It is a schematic diagram of a rule storage structure provided by an embodiment of the present application;

[0029] Figure 4 It is a schematic diagram of the structure of a password auditing device provided by an embodiment of the present application;

[0030] Figure 5 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] The following will describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. It should be noted that, without conflict, the various embodiments provided by the present application, the various implementation manners in the embodiments, and the features can be combined with each other.

[0032] Embodiment 1:

[0033] To solve the various technical problems existing in the existing auditing methods, a new password auditing method is provided in the embodiments of the present application. It can be seen from Figure 1 shown Figure 1 It is a schematic flowchart of the password auditing method provided by an embodiment of the present application, including:

[0034] S101: Obtain a request message to be processed.

[0035] In the embodiment of the present application, the request message to be processed is a message for requesting to log in to the website to be audited.

[0036] It should be understood that the password auditing method provided by the embodiment of the present application can be applied to an electronic device (such as an information security device) independent of the server where the website to be audited is located.

[0037] In order to reduce the impact on the server where the website to be audited is located, in a feasible implementation manner of the embodiment of the present application, the acquisition of the request message to be processed can be implemented in a bypass manner.

[0038] Exemplarily, a network data packet sniffer can be set at the traffic entrance of the website to be audited (such as the mirror port of a switch), and the network data packet sniffer is used to detect whether there is a login request message sent to the website to be audited. When it is detected that there is a login request message sent to the website to be audited at the traffic entrance of the website to be audited, the login request message is copied to obtain the request message to be processed.

[0039] Certainly, in another feasible implementation manner of the embodiment of the present application, an electronic device for executing the method provided by the embodiment of the present application can also be embedded in the transmission path of the login request message to the website to be audited. Thus, when the electronic device receives the login request message, it first audits the login request message as the request message to be processed, and then sends it to the website to be audited after the auditing is completed.

[0040] It should be noted that in practical applications, a login request message usually is transmitted through multiple data streams (i.e., TCP (Transmission Control Protocol) data packets) in a session. Therefore, in order to obtain the accurate request message to be processed, in the embodiment of the present application, each TCP data packet can be reorganized to obtain an application layer message, and the application layer message is used as the request message to be processed for auditing.

[0041] Exemplarily, a session table and a flow reorganization table can be maintained in advance. Multiple table entries can be configured in the session table, and each table entry records the characteristic information of a TCP data packet (such as source IP address, destination IP address, source port number, destination port number, transport layer protocol type, etc.), the hash value calculated according to the characteristic information of the TCP data packet, and the reorganization table entry in the flow reorganization table pointed to by the table entry.

[0042] In this way, after obtaining a TCP packet that needs to be sent to the website to be audited, it is possible to query whether there is a corresponding entry in the session table through the characteristic information of the TCP packet. If it exists, the reassembly entry in the flow reassembly table it points to can be directly found, and the TCP packet is added to this reassembly entry. If there is no corresponding entry in the session table, a new entry is created in the session table, filled with the characteristic information of the TCP packet, the hash value calculated based on the characteristic information of the TCP packet, and a new reassembly entry is created, and the reassembly entry in the flow reassembly table pointed to by this entry, and then the TCP packet is added to this reassembly entry.

[0043] It should be understood that for each TCP packet that constitutes a login request message, the characteristic information such as the source IP address, destination IP address, source port number, destination port number, and transport layer protocol type is the same, so it can be mapped to and added to the same reassembly entry. When adding TCP packets, the TCP packets in the reassembly entry can be sorted in ascending order according to the sequence number of the TCP packets to ensure the correct order after the TCP packets are spliced.

[0044] After adding a TCP packet to the reassembly entry each time, it can be determined whether all the TCP packets of a login request message corresponding to this reassembly entry have arrived. After all have arrived, the data parts of the TCP packets can be spliced together to obtain an application layer message (i.e., the request message to be processed).

[0045] It should be understood that the technology for determining whether all the TCP packets of a message have arrived is a prior art and will not be elaborated in the embodiments of the present application.

[0046] S102: Determine the request method used in the request message to be processed according to the message header of the request message to be processed.

[0047] In the embodiments of the present application, the request message to be processed can be parsed to obtain the message header and message body of the request message to be processed.

[0048] Considering that in the actual application process, when using different request methods, the request message will have different request characteristic information. For example, when using the Basic AUTH method, it will have an Authenticate field; when using the GET request method, it will have characteristic characters such as "GET"; when using the POST request method, it will have characteristic characters such as "POST". Based on this, in the embodiments of the present application, the request characteristic information in the message header of the request message to be processed can be identified, and then the request method used in the request message to be processed can be determined according to the request characteristic information. Among them, the request characteristic information is the specified field or specified character of the request method.

[0049] It should be understood that the specified field or specified character can be set by the engineer. For example, it can be set to the Authenticate field, the "GET" character, and the "POST" character.

[0050] It should also be understood that in the embodiments of the present application, in addition to the Basic AUTH method, the GET request method, and the POST request method, the request message to be processed can also adopt other request methods, which are not limited in the embodiments of the present application. Correspondingly, the set request feature information can include, but is not limited to, the request feature information corresponding to the above Basic AUTH method, GET request method, and POST request method.

[0051] Exemplarily, in an alternative embodiment of the embodiments of the present application, it can be first determined whether the message header of the request message to be processed contains the Authenticate field.

[0052] If the message header of the request message to be processed contains the Authenticate field, it is determined that the request method adopted by the request message to be processed is the Basic AUTH method.

[0053] If the message header of the request message to be processed does not contain the Authenticate field, it is then determined whether the message header of the request message to be processed contains the first specified character or the second specified character.

[0054] If the message header of the request message to be processed contains the first specified character, it is determined that the request method adopted by the request message to be processed is the GET request method; if the message header of the request message to be processed contains the second specified character, it is determined that the request method adopted by the request message to be processed is the POST request method.

[0055] It should be noted that in the embodiments of the present application, when the message header of the request message to be processed does not contain the Authenticate field, it can be first determined whether the message header of the request message to be processed contains the first specified character, and then when the first specified character is not included, it can be further determined whether the second specified character is included. In addition, it can also be that when the message header of the request message to be processed does not contain the Authenticate field, it is first determined whether the message header of the request message to be processed contains the second specified character, and then when the second specified character is not included, it is further determined whether the first specified character is included.

[0056] It should be understood that the above first specified character may be the "GET" character, but this is not a limitation. As long as it can identify that the method adopted is the GET request method. Similarly, the above second specified character may be the "POST" character, but this is not a limitation. As long as it can identify that the method adopted is the POST request method.

[0057] It should also be noted that in the above optional implementation, it is first determined whether the Authenticate field is included in the message header, and then when it is not included, it is further determined whether the first specified character or the second specified character is included in the message header. This is because in actual applications, the Authenticate field may also contain the first specified character such as "GET", so through the above optional implementation, the recognition reliability of the request method adopted can be improved, and then the reliability of the parsed password can be improved.

[0058] Of course, in the actual application process, it is also possible not to first determine whether the Authenticate field is included in the message header, but to first perform the determination of the first specified character or the second specified character. The determination order among the Authenticate field, the first specified character, and the second specified character is not limited in the embodiments of the present application.

[0059] It should be noted that if the first specified character is the "GET" character, and the determination of whether the first specified character is included in the message header is performed first, and then the determination of whether the Authenticate field is included in the message header is performed. Then at this time, the original Basic AUTH method may be misidentified as the GET request method. For this reason, in the embodiments of the present application, when parsing the information to be audited according to the preset processing rule corresponding to the recognized request method, it can be determined whether the information to be audited (including the username and password) can be successfully parsed. If not, it indicates that the request method is misidentified, and thus the recognition of the request method continues. In this way, the accuracy of the request method recognition can be improved to a certain extent.

[0060] S103: Parse the information to be audited from the request message to be processed according to the preset processing rule corresponding to the request method.

[0061] It should be understood that the information to be audited includes the username and password. If only the username or only the password is parsed from the request message to be processed, it indicates that the request message to be processed may not be a message for requesting login to the website to be audited. At this time, the processing flow of the request message to be processed can be ended. When both the username and the password are parsed from the request message to be processed, the subsequent step S104 is continued.

[0062] In an embodiment of the present application, if the determined request method is the Basic AUTH method, the content corresponding to the Authenticate field can be parsed to extract the username and password. Specifically, the keyword "basic" in the Authenticate field can be directly recognized, or the keyword "Authorization" in the Authenticate field can be recognized first, and then the keyword "basic" can be recognized from the content described by the keyword "Authorization", and then the string after the keyword "basic" can be decoded to obtain the username and password.

[0063] Exemplarily, assume an Authenticate field is as follows:

[0064] GET / favicon.ico HTTP / 1.1

[0065] Host:192.168.88.1

[0066] User-Agent:Mozilla / 5.0 (X11;Ubuntu;Linux x86_64;rv:98.0) Gecko / 20100101 Firefox / 98.0

[0067] Accept:image / avif, image / webp, * / *

[0068] Accept-Language:en-US, en;q=0.5

[0069] Accept-Encoding:gzip, deflate

[0070] Authorization:Basic YWRtaW46YWRtaW4=

[0071] Connection:keep-alive

[0072] Referer:http: / / 192.168.88.1 /

[0073] Cookie:HFS_SID_=0.00187900336459279

[0074] Then, the string "YWRtaW46YWRtaW4=" after the keyword "basic" can be recognized. This string is the username and password encoded by base64. After decoding "YWRtaW46YWRtaW4=" by base64, the plaintext "admin:admin" can be obtained, that is, the username is admin and the password is admin.

[0075] In the embodiment of the present application, the first username rule and the first password rule corresponding to the GET request method can be pre-configured, and the second username rule and the second password rule corresponding to the POST request method can be pre-configured.

[0076] It should be noted that the first username rule and the second username rule are used to match the username in the message to be processed, and the first password rule and the second password rule are used to match the password in the message to be processed.

[0077] It should also be noted that the Hypertext Transfer Protocol does not specify the specific format for transmitting the username and password. In actual usage scenarios, json, xml or URL encoded formats are often used to transmit the message to be processed.

[0078] For the POST request method, in different data formats, there will be certain differences in the configuration rules of the username and password. Therefore, for the POST request method, it is necessary to pre-configure the second username rule and the second password rule corresponding to each data format for different data formats. Exemplarily, the rules pre-configured in the embodiment of the present application may include but are not limited to Figure 2 the rules shown.

[0079] It should also be noted that in the embodiment of the present application, the first username rule, the first password rule, the second username rule and the second password rule can all be configured in the following form:

[0080] String pattern Extracted substring number Applicable format passwrd=([^&]*) 1 URL encoded

[0081] Among them, the first line represents each component of each rule, and the second line is an example of a rule. Among them, the string pattern is a pattern matching rule based on regular expressions, which contains at least one substring for matching. Taking passwrd=([^&]*) as an example, when matching, it is judged whether the string "[^&]*" exists. The extracted substring number represents the position of the content to be extracted after the match. Taking "1" in the second line as an example, it means that after the match, the first substring after the string "[^&]*" is the content to be extracted. The applicable format represents the data format applicable to this rule. Taking the second line in the above table as an example, it means that this rule is applicable to the URL encoded data format.

[0082] In the embodiments of the present application, after the above rules are configured, they can be implemented through a regular expression matching engine (such as the hyperscan engine).

[0083] It should also be noted that in the embodiments of the present application, after the engineer configures each first username rule, first password rule, second username rule, and second password rule, the configured rules can be saved through, such as, plain text files, databases, binary files, etc. And for the convenience of differentiating between rules, the files storing each rule can also be divided into two sections, respectively used to store password rules and username rules, for example Figure 3 as shown (including two sections of password and username, respectively used to store password rules and username rules).

[0084] When the determined request method is the GET request method, the parameter part of the URL address corresponding to the GET request method can be parsed from the to-be-processed request message, and then the preset first username rule and first password rule are respectively used to match the parameter part.

[0085] When the first username rule matches the parameter part successfully and the first password rule matches the parameter part successfully: According to the matching result of the first username rule and the parameter part, the username in the parameter part can be extracted. When extracting, it can be extracted according to the substring serial number extracted in the first username rule. According to the matching result of the first password rule and the parameter part, the password in the parameter part is extracted. When extracting, it can be extracted according to the substring serial number extracted in the first password rule.

[0086] If any one of the first username rule and the first password rule fails to match, the processing flow of the to-be-processed request message is ended.

[0087] It should be noted that the method of parsing the parameter part of the URL address corresponding to the GET request method from the to-be-processed request message can be: identifying the character "GET" in the to-be-processed request message, and the string after the character "GET" is the URL address corresponding to the GET request method. Then, identifying the character "?" in the URL address, and the string after the character "?" is the parameter part of the URL address.

[0088] Exemplarily, assume that the to-be-processed request message includes the following content:

[0089] GET / dursta.js?action=login&username=admin&paswword=332%40&uri=&ref=&uid=&HTTP / 2

[0090] Host: stadig.ifeng.com

[0091] User-Agent: Mozilla / 5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko / 20100101 Firefox / 99.0

[0092] Accept: image / avif, image / webp, * / *

[0093] Accept-Language: zh-CN, zh;q=0.8, zh-TW;q=0.7, zh-HK;q=0.5, en-US;q=0.3, en;q=0.2

[0094] Accept-Encoding: gzip, deflate, br

[0095] Referer: https: / / www.ifeng.com /

[0096] Connection: keep-alive

[0097] Cookie: userid=1644543720818_joke064196; if_prov=cn024; if_city=024; prov=cn024; city=024; weather_city=ln_sy; region_ip=61.161.238.x; region_ver=1.2; UM_distinctid=17ee671f0282aa-0f91c9ff0dbf448-4c3e237c-100200-17ee671f029a07

[0098] Then the URL address corresponding to the GET request method can be parsed as: " / dursta.js?action=login&username=admin&paswword=332&uri=&ref=&uid=&". The parameter part of this URL address is the part after "?", that is, "action=login&username=admin&paswword=332&uri=&ref=&uid=&".

[0099] The parameter part of the URL address is respectively matched with the first username rule and the first password rule. If the parameter part of the URL address is successfully matched with both the first username rule and the first password rule, it is considered that the parameter part of the URL address contains both the username and password information, and then this request message is a user login request. Then, the username and password are extracted according to the first username rule and the first password rule. In the above example, in this example, the extracted username is "admin" and the password is "332%40".

[0100] Since there may be cases of escaping special characters when encoding the URL according to the Hypertext Transfer Protocol. For example, in the above example, "332%40" is the result after escaping. Therefore, in order to obtain the real username and password, it is also necessary to unescape the extracted username and password. In this example, after unescaping the extracted username and password, the actual username and password obtained finally are "admin" and "332@" respectively.

[0101] When the determined request method is the POST request method, the data format of the request message to be processed can be determined first, and then the second username rule and the second password rule corresponding to this data format are respectively used to match the content of the message body of the request message to be processed.

[0102] When the second username rule corresponding to this data format is successfully matched with the content of the message body, and the second password rule corresponding to this data format is also successfully matched with the content of the message body: According to the matching result of the second username rule corresponding to this data format and the content of the message body, the username in the content of the message body is extracted. When extracting, it can be extracted according to the substring serial number extracted in this second username rule. According to the matching result of the second password rule corresponding to this data format and the content of the message body, the password in the content of the message body is extracted. When extracting, it can be extracted according to the substring serial number extracted in the second password rule.

[0103] If any one of the second username rule and the second password rule corresponding to this data format fails to match, the processing flow of this request message to be processed is ended.

[0104] In the embodiment of the present application, in order to determine the data format of the request message to be processed, the content type field (Content-Type field) of the message header of this request message to be processed can be parsed, so as to determine the data format of the request message to be processed according to the content in the content type field.

[0105] Exemplarily, if the content in the content type field is "application / x-www-form-URLencoded", it is determined that the data format of the request message to be processed is the form in URL encoded format. If the content in the content type field is "application / json", it is determined that the data format of the request message to be processed is the json format. If the content in the content type field is "application / xml", it is determined that the data format of the request message to be processed is the xml format.

[0106] Similarly, after extracting the username and password, the extracted username and password can be unescaped to obtain the actual username and password.

[0107] In the embodiment of the present application, corresponding methods can be adopted for unescaping according to the different ways of obtaining the username and password. For example, if the username and password are extracted from the message body content in json format, the username and password are unescaped according to the unescaping rules of json format. It should be understood that the unescaping rules corresponding to various data formats are prior art and will not be elaborated in the embodiment of the present application.

[0108] S104: Audit the password in the information to be audited.

[0109] In the embodiment of the present application, password strength rules can be preset, and information such as the length of the password, the number of letters, the number of special characters, and the number of digits included in the password are specified in the password strength rules.

[0110] In addition, in the embodiment of the present application, two common password dictionaries can also be preconfigured. One is a preset common password dictionary, and the other is a user-defined common password dictionary. The preset common password dictionary is a dictionary built in when the device (referring to the electronic device that executes the method provided in the embodiment of the present application) leaves the factory, and it includes passwords that users often use; the user-defined common password dictionary is a dictionary set by the device user through the human-machine interface. The common password dictionary and the user-defined common password dictionary are loaded into the memory during device initialization and can be initialized in the form of a hash table. There are multiple hash table entries in the hash table, and each hash table entry corresponds to a common password in the common password dictionary and the user-defined common password dictionary, and records the hash value corresponding to the common password.

[0111] When auditing, first, the password in the information to be audited can be traversed character by character to obtain the length of the password, the number of letters, the number of special characters, and the number of digits, and it is judged whether it conforms to the preset password strength rules. If not, it means that the password strength is non-compliant.

[0112] Then, the hash value of the password in the information to be audited can be calculated, and it is checked whether there is a hash table entry with the same hash value in the hash table. If the corresponding hash table entry is found, it indicates that the password in the information to be audited hits the common password dictionary or the user-defined common password dictionary. According to the found hash table entry, record the reason for the failed audit (the reasons include: hitting the user-defined common password dictionary, hitting the preset common password dictionary, hitting both the user-defined common password dictionary and the preset common password dictionary, etc.).

[0113] If the password strength is non-compliant or hits the user-defined common password dictionary and / or the preset common password dictionary, it indicates that the password strength does not meet the information security requirements, and an alarm is issued. The alarm content includes the source IP, destination IP, source port, destination port, transport layer protocol, application layer protocol, user name, password, non-compliance reason, time, etc.

[0114] It should also be noted that in the embodiment of the present application, in the password strength rule, according to the length of the password, the number of letters, special characters, and numbers included in the password, etc., three levels of password strength, namely high, medium, and low, can be defined. Then, after obtaining the password length and the number of letters, special characters, and numbers of the password in the information to be audited, according to the preset password strength rule, the password strength of the password in the information to be audited is determined.

[0115] The password auditing method provided by the embodiment of the present application is different from the prior art that needs to actively construct a large number of login data packets to send login requests to the website to be audited. In the above implementation process, by obtaining the to-be-processed request message for logging in to the website to be audited, and then parsing the to-be-processed request message to obtain the information to be audited, the password in the information to be audited is audited. In this way, there is no need to construct login data packets, nor to send login requests to the website to be audited, thus not causing an impact on the server where the website to be audited is located, and the adverse impact on the stability of the server can be reduced. In addition, since it is the to-be-processed request message for actually logging in to the website to be audited that is obtained for parsing, even if the website to be audited uses an unconventional password, the password can be obtained and then audited.

[0116] In addition, the solution of the embodiment of the present application, by presetting corresponding processing rules for each request method, can quickly parse the information to be audited from the to-be-processed request message according to the preset processing rules corresponding to the request method used by the to-be-processed request message. During the auditing process, engineers do not need to perform manual reverse derivation work on information such as the login address of the website, the user name transmission field, and the password transmission field, thus reducing the technical requirements for users during the auditing process, improving the user experience, and also improving the auditing efficiency.

[0117] Embodiment 2:

[0118] Based on the same inventive concept, the present application also provides a password auditing device 400. Figure 4 As shown, Figure 4 Shows the use of Figure 1 The password auditing device of the method shown. It should be understood that the specific functions of the device 400 can be referred to the description above, and the detailed description is appropriately omitted here to avoid repetition. The device 400 includes at least one software function module that can be stored in a memory in the form of software or firmware or fixed in the operating system of the device 400. Specifically:

[0119] See also Figure 4 As shown, the apparatus 400 includes: an acquisition module 401, a determination module 402, a parsing module 403 and an audit module 404. Among them:

[0120] The acquisition module 401 is used to acquire a request message to be processed; the request message to be processed is a message requesting to log in to the website to be audited;

[0121] A determination module 402, configured to determine a request method used by the request message to be processed according to a message header of the request message to be processed;

[0122] The parsing module 403 is used to parse the to-be-audited information from the to-be-processed request message according to the preset processing rules corresponding to the request method;

[0123] The audit module 404 is used to audit the passwords in the information to be audited.

[0124] In a feasible implementation of an embodiment of the present application, the determination module 402 is specifically used to identify the request characteristic information in the message header of the request message to be processed, and determine the request method adopted by the request message to be processed based on the request characteristic information; wherein the request characteristic information is a specified field or specified character of the request method.

[0125] In the above-mentioned feasible implementation mode, the request characteristic information includes an Authenticate field; the determination module 402 is specifically used to determine whether the message header of the request message to be processed contains an Authenticate field; if the message header of the request message to be processed contains an Authenticate field, it is determined that the request method adopted by the request message to be processed is the Basic AUTH method.

[0126] In the above feasible implementation manner, the requested feature information includes a first specified character and a second specified character; the first specified character is a character possessed by the GET request method, and the second specified character is a character possessed by the POST request method; the determining module 402 is further specifically configured to, if the message header of the to-be-processed request message does not include an Authenticate field, determine whether the message header of the to-be-processed request message includes the first specified character or the second specified character; if the message header of the to-be-processed request message includes the first specified character, determine that the request method adopted by the to-be-processed request message is the GET request method; if the message header of the to-be-processed request message includes the second specified character, determine that the request method adopted by the to-be-processed request message is the POST request method.

[0127] In an embodiment of the present application, the password in the to-be-audited information includes a username and a password; when the request method is the GET request method, the parsing module 403 is specifically configured to parse the parameter part of the URL address corresponding to the GET request method from the to-be-processed request message, and respectively match the parameter part by using a preset first username rule and a first password rule; when the first username rule matches the parameter part successfully and the first password rule matches the parameter part successfully, extract the username in the parameter part according to the matching result between the first username rule and the parameter part, and extract the password in the parameter part according to the matching result between the first password rule and the parameter part.

[0128] In an embodiment of the present application, the password in the to-be-audited information includes a username and a password; when the request method is the POST request method, the parsing module 403 is specifically configured to determine the data format of the to-be-processed request message, and respectively match the content of the message body of the to-be-processed request message by using a second username rule and a second password rule corresponding to the data format; when the second username rule matches the content of the message body successfully and the second password rule matches the content of the message body successfully, extract the username in the content of the message body according to the matching result between the second username rule and the content of the message body, and extract the password in the content of the message body according to the matching result between the second password rule and the content of the message body.

[0129] In an embodiment of the present application, the obtaining module 401 is specifically configured to, when detecting a login request message sent to the to-be-audited website at the traffic entrance of the to-be-audited website, copy the login request message to obtain the to-be-processed request message.

[0130] It should be understood that, for the sake of concise description, the content described in some of the first embodiments will not be repeated in this embodiment.

[0131] Embodiment 3:

[0132] This embodiment provides an electronic device. As shown in Figure 5 the figure, it includes a processor 501 and a memory 502. Among them:

[0133] The processor 501 is used to execute one or more programs stored in the memory 502 to implement the password auditing method in the above-mentioned first embodiment.

[0134] It can be understood that Figure 5 the structure shown in the figure is only schematic. The electronic device may further include more or fewer components than those shown in Figure 5 the figure, or have a different configuration from that shown in Figure 5 the figure.

[0135] Exemplarily, the electronic device may further include a communication bus, so as to realize the connection and communication between the processor 501 and the memory 502 through the communication bus.

[0136] In the embodiments of the present application, the electronic device may be a device with data processing capabilities such as a mobile phone, a computer, a server, etc.

[0137] This embodiment also provides a computer-readable storage medium, such as a floppy disk, an optical disc, a hard disk, a flash memory, a USB flash drive, an SD (Secure Digital Memory Card) card, an MMC (Multimedia Card) card, etc. One or more programs for implementing the above-mentioned various steps are stored in the computer-readable storage medium. These one or more programs can be executed by one or more processors to implement the password auditing method in the above-mentioned first embodiment. Details are not described herein again.

[0138] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the communication connections shown or discussed with each other can be realized through some communication interfaces.

[0139] In each embodiment of the present application, the functional modules can be integrated together to form an independent part, or each module can exist alone, or two or more modules can be integrated to form an independent part.

[0140] In this document, relational terms such as first and second are used solely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0141] In this document, "a plurality of" means two or more.

[0142] The above description is only for the embodiments of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. A password auditing method, characterized in that, Including: Obtain a request message to be processed; The request message to be processed is a message for requesting to log in to the website to be audited; Determine the request method adopted by the request message to be processed according to the message header of the request message to be processed; Parse the information to be audited from the request message to be processed according to the preset processing rule corresponding to the request method; The information to be audited includes a username and a password; Audit the password in the information to be audited; Determine the request method adopted by the request message to be processed according to the message header of the request message to be processed, including: Identify the request feature information in the message header of the request message to be processed, and determine the request method adopted by the request message to be processed according to the request feature information; Wherein, the request feature information is a specified field or a specified character possessed by the request method; The request feature information includes an Authenticate field; Identify the request feature information in the message header of the request message to be processed, and determine the request method adopted by the request message to be processed according to the request feature information, including: Judge whether the message header of the request message to be processed contains an Authenticate field; If the message header of the request message to be processed contains an Authenticate field, determine that the request method adopted by the request message to be processed is the Basic AUTH method; The request feature information includes a first specified character and a second specified character; the first specified character is a character possessed by the GET request method, and the second specified character is a character possessed by the POST request method; Identify the request feature information in the message header of the request message to be processed, and determine the request method adopted by the request message to be processed, further including: If the message header of the request message to be processed does not contain an Authenticate field, judge whether the message header of the request message to be processed contains the first specified character or the second specified character; If the message header of the request message to be processed contains the first specified character, determine that the request method adopted by the request message to be processed is the GET request method; If the message header of the request message to be processed contains the second specified character, determine that the request method adopted by the request message to be processed is the POST request method; When the request method is the GET request method, parsing the information to be audited from the request message to be processed according to the preset processing rule corresponding to the request method includes: Parse the parameter part of the URL address corresponding to the GET request method from the request message to be processed; Match the parameter part respectively using a preset first username rule and a first password rule; When the first user name rule matches the parameter part successfully and the first password rule matches the parameter part successfully, extract the user name in the parameter part according to the matching result between the first user name rule and the parameter part, and extract the password in the parameter part according to the matching result between the first password rule and the parameter part; When the request method is the POST request method, parse the information to be audited from the request message to be processed according to the preset processing rules corresponding to this request method, including: Determine the data format of the request message to be processed; Respectively use the second user name rule and the second password rule corresponding to the data format to match the content of the message body of the request message to be processed; When the second user name rule matches the content of the message body successfully and the second password rule matches the content of the message body successfully, extract the user name in the content of the message body according to the matching result between the second user name rule and the content of the message body, and extract the password in the content of the message body according to the matching result between the second password rule and the content of the message body.

2. The method according to claim 1, wherein Obtain the request message to be processed sent to the website to be audited, including: When it is detected that there is a login request message sent to the website to be audited at the traffic entrance of the website to be audited, copy the login request message to obtain the request message to be processed.

3. A password auditing device, characterized in that, Include: An acquisition module, configured to acquire a request message to be processed; The request message to be processed is a message for requesting login to the website to be audited; A determination module, configured to determine the request method adopted by the request message to be processed according to the message header of the request message to be processed; An analysis module, configured to parse the information to be audited from the request message to be processed according to the preset processing rules corresponding to this request method; The information to be audited includes a user name and a password; An audit module, configured to audit the password in the information to be audited; The determination module is specifically configured to identify the request feature information included in the message header of the request message to be processed, and determine the request method adopted by the request message to be processed according to the request feature information; wherein, the request feature information is a specified field or a specified character possessed by the request method; The request feature information includes the Authenticate field; the determination module is specifically configured to determine whether the message header of the request message to be processed contains the Authenticate field; if the message header of the request message to be processed contains the Authenticate field, determine that the request method adopted by the request message to be processed is the Basic AUTH method; The described requested feature information includes a first specified character and a second specified character; the first specified character is a character possessed by the GET request method, and the second specified character is a character possessed by the POST request method; the determining module is further specifically configured to, if the message header of the to-be-processed request message does not include an Authenticate field, determine whether the message header of the to-be-processed request message includes the first specified character or the second specified character; if the message header of the to-be-processed request message includes the first specified character, determine that the request method adopted by the to-be-processed request message is the GET request method; if the message header of the to-be-processed request message includes the second specified character, determine that the request method adopted by the to-be-processed request message is the POST request method. The password in the to-be-audited information includes a username and a password; when the request method is the GET request method, the parsing module 403 is specifically configured to parse out the parameter part of the URL address corresponding to the GET request method from the to-be-processed request message, and respectively match the parameter part with a preset first username rule and a first password rule; when the first username rule matches the parameter part successfully and the first password rule matches the parameter part successfully, extract the username in the parameter part according to the matching result between the first username rule and the parameter part, and extract the password in the parameter part according to the matching result between the first password rule and the parameter part. When the request method is the POST request method, the parsing module is specifically configured to determine the data format of the to-be-processed request message, and respectively match the content of the message body of the to-be-processed request message with a second username rule and a second password rule corresponding to the data format; when the second username rule matches the content of the message body successfully and the second password rule matches the content of the message body successfully, extract the username in the content of the message body according to the matching result between the second username rule and the content of the message body, and extract the password in the content of the message body according to the matching result between the second password rule and the content of the message body.

4. An electronic device, characterized in that, Comprising: A processor and a memory; The processor is used to execute one or more programs stored in the memory to implement the method according to any one of claims 1-2.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, and when the one or more programs are executed by one or more processors, the processors are caused to execute the method according to any one of claims 1-2.

Images