CN112702334B - 静态特征与动态页面特征结合的web弱口令检测方法 - Google Patents

Abstract

本发明涉及一种静态特征与动态页面特征结合的WEB弱口令检测方法，属于信息安全领域。本发明发送至少两次错误的密码判断是否产生动态返回值并获取EL；当返回页面中存在黑名单列表的关键字时，则说明口令错误；若不存在则进入下一步判断；判断用户名和密码的键名是否存在于跳转后的页面中，若存在说明本组口令错误，继续进行下一次判断；若不存在，则进行下一步判断；将返回页面的总长度与EL相比较，若相等，则认为本组口令为错误口令，否则将进入下一步判断；依次发送一个错误的密码e1，和从上一步得到的待检测口令s，若返回页面长度相等则认为本组密码错误，若不相等则本组密码正确。本发明可用于WEB系统的弱口令以及万能密码检测，准确率高。

Description

静态特征与动态页面特征结合的WEB弱口令检测方法

技术领域

本发明属于信息安全领域，具体涉及一种静态特征与动态页面特征结合的WEB弱口令检测方法。

背景技术

如今，WEB已成为互联网信息传播贡献的最便捷的技术。与此同时也带来了一系列的安全问题。由于WEB后台常常包含大量的用户或企业的隐私数据，一直是黑客的重点攻击对象，其中弱口令攻击是一个最直接有效的攻击方式。

2007年，Dinei等人用三个月的时间研究了50万用户的密码口令习惯，发现近七成用户都在使用较弱的口令作为密码。2011年，Cui等人利用nmap对全球的HTTP以及Telnet服务主机进行了一次弱口令探测，发现了110万存在弱口令的设备。2015年，Patton等人在实验中，利用Shodan搜索引擎搜索多种型号的物联网设备并进行弱口令探测，发现了部分型号设备弱口令漏洞率达到百分之四十。如此众多的弱口令给互联网带来了巨大的安全隐患，所以如何检测WEB系统中存在的弱口令就变得尤为重要。

设置复杂口令的WEB管理系统就一定安全吗？其实不然。除了弱口令以外，后台万能密码漏洞也是安全工作者注重的一个方面。其漏洞原因是因为登录后台没有对接受的参数进行SQL关键词的转义，导致可以进行SQL注入。攻击者利用"or"a"＝"a、a'or'1＝1--等注入语句就可以不需要密码进入管理后台，使得口令系统形同虚设。

然而，由于WEB系统的多样性：不同系统的页面元素不同，提交内容不同，返回信息的特征值也不相同。难以用指定的有限的静态特征值来判断登录情况。所以目前的安全人员大多只能通过繁琐的人工测试来进行弱口令的检测。在待测目标较少的情况下，利用人工分析的弊端还不太明显。然而随着资产的增加，管理员常常会面临需要批量检测弱口令的问题。此时若采用人工分析，就会导致效率极其低下且耗时耗力。此时，设计一种通用的弱口令检测算法来代替人工就显得尤为必要。这就是本文所要解决的问题。

此前学术界也有相关的一些研究工作。2016年，田峥等人提出了基于网页静态分析的Web弱口令检测方法，支持批量化WEB弱口令检测。2017年，陈春玲等在对于XSS漏洞自动化探测中，面对只有登录后才能进行进一步测试的情况，提出了利用模拟登录来检测XSS的方法。2018年，徐顺超等人设计出针对物联网WEB弱口令探测系统AWKD，同时支持对物联网设备的自动化抓取与检测。2019年，TideSec安全团队在github发布开源项目web_pwd_common_crack，其名称为通用web弱口令破解脚本，可以检测没有验证码的后台是否存在弱口令。

前人的工作为实现弱口令自动化探测做出了一定的贡献，但是也存在很明显的不足。田峥等人提出的检测算法中缺少对如何判断正确的细节描述，也没有检验最后的结果是否真正有效。虽然物联网设备的WEB系统与普通的WEB系统有一定的关联，但是普通WEB系统的样式更多，更为复杂。所以徐顺超等人设计的系统对于普通WEB系统来说并不一定适用。而web_pwd_common_crack工具虽然使用简单，并且开源，但是经过实验后发现其结果误报较高，并且检测率较低。另外以上系统或模型均无法检测万能密码漏洞，并且不能支持用户自定义爆破规则，程序缺乏拓展性。

发明内容

(一)要解决的技术问题

本发明要解决的技术问题是如何提供一种静态特征与动态页面特征结合的WEB弱口令检测方法，以解决现有的弱口令自动化探测中，人工分析效率极其低下且耗时耗力，自动化监测复杂或误报较高，并且检测率较低等问题。

(二)技术方案

为了解决上述技术问题，本发明提出一种静态特征与动态页面特征结合的WEB弱口令检测方法，该方法包括如下步骤：

S1、预处理：发送至少两次错误的密码判断是否产生动态返回值并获取返回值长度EL(Error Length)；

S2、关键字黑名单检测：当返回页面中存在黑名单列表的关键字时，则说明口令错误，进行下一组口令尝试；若不存在则进入下一步判断；

S3、判断用户名和密码的键名是否存在于跳转后的页面中，若存在说明本组口令错误，继续进行下一次判断；若不存在，则进行下一步判断；

S4、与EL比较：将返回页面的总长度与EL相比较，若相等，则认为本组口令为错误口令，否则将进入下一步判断；

S5、Recheck环节：依次发送一个错误的密码e1，和从上一步得到的待检测口令s，比较两者的返回页面长度，若相等则认为本组密码错误，若不相等则本组密码正确。

进一步地，所述步骤S1具体包括：发送至少两次错误的密码来判断页面的稳定性，若返回页面的长度相等则认为其页面为稳定的，并记录下此时页面的返回值长度EL；若不稳定则退出爆破；返回值长度为返回页面的body值长度加上headers头部长度。

进一步地，在步骤S1和步骤S5中发送密码或口令前还包括预请求的过程，具体包括：先请求一次后台页面，保存系统在第一次请求时分配的cookie值。

进一步地，所述步骤S2中的黑名单列表的关键字包括提示密码错误的关键字、超过最大尝试次数的关键字和被防火墙拦截的关键字。

进一步地，所述口令包括错误口令、正确口令和万能密码；其中，可以正常登录后台的万能密码，我们认为其属于正确口令部分，不引起防火墙拦截的但无法登陆的万能密码属于错误口令部分，否则属于万能密码部分。

进一步地，发送密码或口令还包括：识别登录页面，识别出提交路径，识别提交参数，直接向目标地址提交数据而不经过页面渲染。

进一步地，所述识别登录页面的过程包括：判断是否存在Form表单，若不存在则系统退出，若存在则利用关键字特征进一步判断是否为搜索页面，如果是搜索页面则系统退出，如果否则接着会判断是否存在登录页面常见的关键字，若不存在则认为此页面不是登录页面，系统退出，如果存在则认为是登录页面。

进一步地，所述识别提交路径的过程如下：利用BeautifulSoup模块分析提取Form表单，然后检测action字段的值；当action的值为绝对URL地址则直接将action的值作为提交路径地址，当以“/”开头，则将其与web根地址拼接，当以“.”开头，则为相对路径，将其与当前目录的路径拼接，最后返回提交路径的地址。

进一步地，每次发包之前都会产生一组随机的User-Agent，X-Forwarded-For，以及Client-IP字段来绕过WAF与CMS的防护限制。

进一步地，所述密码使用常规字典、动态字典或万能密码字典生成，所述常规字典根据当前要爆破的用户名生成对应的字典，所述动态字典根据域名生成不同的动态字典，所述万能密码字典为根据常见的密码生成的字典。

(三)有益效果

本发明提出一种静态特征与动态页面特征结合的WEB弱口令检测方法，将传统的静态特征关键字与目标的页面长度变化、登录框键名、关键字等动态页面特征信息相结合，经过大量实际统计信息，实现了WEB弱口令以及万能密码的自动化检测。本文基于此方法实现了一个可用于后台弱口令以及万能密码检测的检测系统模型——WebCrack，并增加了随机headers头部、动态密码生成、自定义爆破规则拓展等模块，减少了被防火墙拦截的概率，提高了识别率。实验表明，此方法可用于各类WEB系统的弱口令以及万能密码检测，准确率达到了93.75％，为用户的口令设置提供了直接有益的参考，具有较好的实用性。

附图说明

图1为本发明DBKER算法总体流程；

图2为本发明预处理流程；

图3为本发明Recheck环节流程；

图4为本发明WebCrack整体框架；

图5为本发明登录页面识别流程。

具体实施方式

为使本发明的目的、内容和优点更加清楚，下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。

针对以上问题，本文基于提出了一套静态特征与动态特征相结合的检测方法——DBKER(Dynamic，Blacklist，Login Key，Error Length，Recheck)法，并基于此算法实现了一个可用于后台弱口令以及万能密码检测的系统模型——WebCrack。

DBKER算法

算法描述

对于某指定类型的WEB系统的弱口令识别而言，我们只需提取其口令正确时返回页面的静态特征码，然后判断返回信息中是否存在该特征码即可。但是作为通用爆破算法来说，面对各种各样的网站，我们不可能去找到所有的口令正确登录页面的特征，即无法简单的通过“白名单”的方式来判断登录情况。

虽然口令正确的页面我们不容易得到，但是口令失败的页面我们是容易获取的，只需发送一组错误的口令即可。我们就可以记录下此时的页面特征，作为筛除错误口令的判断条件，这也是DBKER算法的核心思想。但是在实际中，并不是仅仅只有“登录成功”，与“登录失败”两种情况，往往还混杂着其他的干扰页面。这时候，我们就需要根据目标的动态页面特征进行综合判断，从而找出正确的口令页面。算法总体流程如图1所示。

1.1事件分类

为了便于下文中讨论，结合实验数据，我们将事件分类如下：

(1)从口令种类上，可分为错误口令，正确口令，万能密码。其中，可以正常登录后台的万能密码，我们认为其属于正确口令部分。不引起防火墙拦截的但无法登陆的万能密码属于错误口令部分，否则属于万能密码部分。

(2)从返回页面302跳转后的最终位置，我们将其分为原页面跟新页面。

(3)从页面内容，我们将其分为口令错误提示页面，口令正确提示页面，超过口令错误最大次数提示页面，防火墙拦截页面，后台页面。

经实验统计，共归类为以下情形，分别记为事件1-9。我们将其他不符合此通用规则的情况，例如错误定位登录框，网页间歇性不稳定等情况归为“其他”类。其中事件1-7为干扰事件，事件8,9为我们需要筛选出来的登录成功事件。

1.输入错误密码，原页面，无提示

2.输入错误密码，原页面，提示口令错误页面

3.输入错误密码，原页面，提示超过口令错误最大次数页面

4.输入错误密码，新页面，提示口令错误页面

5.输入错误密码，新页面，提示超过口令错误最大次数页面

6.输入万能密码，新页面，提示防火墙拦截页面

7.其他

8.输入正确密码，新页面，提示口令正确。

9.输入正确密码，新页面，进入后台。

1.2预处理：发送至少两次错误的密码判断是否产生动态返回值并获取ErrorLength——EL

此处提出一个“页面稳定性”概念：当一个页面对同一数据包的返回结果是相同的，那么我们即可称此页面为稳定的。若页面稳定说明此页面对于错误口令的返回结果是一致的，就可以作为我们判断的特征；若返回结果不一致则说明此页面具有不稳定性，会产生动态返回结果。此时系统无法进行判断，退出爆破。

系统首先会发送至少两次错误的密码来判断页面的稳定性。若两次返回页面的长度相等则认为其页面为稳定的，并记录下此时页面的返回值长度Error Length(下文中通称为EL)，作为第三步判断的基准。若不稳定则退出爆破。其中，返回值长度为返回页面的body值长度加上headers头部长度。

另外由于部分管理系统会在第一次请求时分配一个cookie来记录用户的登录次数，所以系统会先请求一次后台页面，我们称为预请求，来保存此cookie值，以免由于响应头中的set-cookie干扰长度判断。预处理流程如图2所示：

1.3第一步：关键字黑名单检测

黑名单检测属于静态特征检测方法，通过搜集整理常见的登录失败关键字，可以过滤掉大部分口令错误页面。其中主要包含三个方面的关键字：

(1)提示密码错误的关键字。如果检测到返回页面中含有“密码错误”，“登录失败”等关键字，则认为本组口令为错误口令，进行下一组口令的尝试。

(2)超过最大尝试次数的关键字。某些WEB系统为了防止攻击者对于后台密码的破解，会设置最大尝试次数。当尝试次数用尽时则会弹出提示并隐藏登录框，阻止进一步口令尝试。由于此行为常常会引起页面返回值变化，从而被系统误认为是登录成功。所以黑名单中增加“尝试次数过多”，“已被锁定”等关键字来减少误报。

(3)被防火墙拦截的关键字。由于引入了万能密码检测模块，发送数据后经常会被防火墙所拦截。由于防火墙拦截会造成页面长度返回值变化，并且返回页面不包含登录框关键字，从而容易造成误报。所以黑名单中也增加了如“创宇盾”、“百度云加速”、“黑客攻击”等防火墙特征码。

仅通过黑名单关键字的检测并不能保证口令就一直正确，因为(1)我们不可能收集到所有的错误关键字，(2)关键字中大多只是英文跟中文关键字，面对其他外文网站此步骤无法生效。

当返回页面中存在黑名单列表的关键字时，则说明口令错误，进行下一组口令尝试。若不存在则进入下一步判断。此步骤可以过滤干扰事件2,3,4,5,6。其过滤能力取决于黑名单关键字是否完整。

1.4第二步：判断用户名跟密码的键名是否存在于跳转后的页面中

在事件1,2,3的情况下，如果输入的密码错误，WEB系统的登录框会继续存在，让用户重新输入密码；如果口令正确，则会进入管理后台，此时登录框消失。利用这一点我们就可以根据登录框是否继续存在作为我们判断的标准。在识别参数时我们会提取到所有登录框内的参数，包括需要爆破的账号与密码的键名。此时我们将其键名标志出来，记为user_key与pass_key(下文中统称为key)，并且与返回后的页面相比对。若存在说明本组口令错误，继续进行下一次判断。若不存在，则进行下一步判断。

此时就涉及到一个问题，是与302跳转时的页面比对还是302跳转后的页面比对？因为跳转方式有多种，提示的信息也有很多种，不过最终还是要落到返回的最终信息上。所以302跳转时的页面内容并不能作为判断的依据。所以我们只需要关注302跳转后的页面中是否存在记录的key关键字。若未特别说明，本文均默认关注的是302跳转后的页面内容。

1.5第三步：与EL比较

在预处理中，我们通过发送一组错误口令来记录EL的数值。在此步骤会将返回页面的总长度与EL相比较。若相等，则我们有理由认为这一组口令为错误口令，否则将进入下一步判断。此步骤可以过滤掉干扰事件1，2，4。

1.6第四步：Recheck环节

通过上面的三步，我们得出一组待检测口令s。为了保证结果的准确性，系统还会进行一次重新发包的检测，本文中称为Recheck环节。

在此环节中，系统会在一次预请求之后，依次发送一个错误的密码e1，和从上一步得到的一组待检测口令s。比较两者的返回页面长度。若相等，则说明可能已经因为尝试次数过多而被系统所屏蔽，此时正确密码和错误密码对于系统来说均不接受，所以返回值的长度才会相同，认为本组密码错误。利用此步骤可以过滤掉干扰事件3和5。若不等，则本组密码正确。Recheck环节流程如图3所示。

1.7检测能力表和误报率计算

设S为所有探测中出现的事件集合，且有S＝M+N。M为检测到正确口令页面的事件,P(M)为其概率。N为其余的干扰事件的事件集合，P(N)为其概率，其中子事件记为Ni，i为事件标号。

设R为检测算法所能排除的事件，Q(R)为其排除概率。Ri为能排除的干扰子事件i，则有误报率公式：

P(mistake)＝∑(i＝1；i<＝max)P(Ni)(1-Q(Ri))

除预处理之外，设算法步骤1-4能识别到的干扰事件概率分别为Q(A),Q(B),Q(C),Q(D)。其中子事件概率为Q(Ki),K∈{A,B,C,D}。i为事件编号，i∈{1,2,3,4,5,6,7}。

在本算法中各步骤对于事件的检测能力如表1所示。

表1各步骤检测能力范围

算法中各步骤对于事件的拦截能力有相重叠的部分，可以增大最后的准确率。

得出各个干扰事件被排除的概率为：

Q(R1)＝Q(B1∪C1)

Q(R2)＝Q(A2∪B2∪C2)

Q(R3)＝Q(A3∪B3∪D3)

Q(R4)＝Q(A4∪C4)

Q(R5)＝Q(A5∪D5)

Q(R6)＝Q(A6)

在本算法中，理想情况下有

Q(B1),Q(C1),Q(B2),Q(B3),Q(C2),Q(C4),Q(D3),Q(D5)＝1

故有

Q(R1),Q(R2),Q(R3),Q(R4),Q(R5)＝1

所以最后的误报公式为

P(mistake)＝P(N6)(1-Q(R6))+P(N7)

由于P(N7)为不可控情况，所以在DBKER算法中，影响误报率的决定因素为R6。也就是说对于万能密码防火墙拦截页面的黑名单关键字将直接决定最后误报率的高低。

2WebCrack检测系统

基于此算法我们实现了一个基础系统模型——WebCrack。系统整体框架如图4:

2.1页面分析模块

WebCrack采用了静态页面分析方法。在识别出提交路径后，直接向目标地址提交数据而不经过页面渲染。因为一些网站会在前端验证用户的输入是否含有非法字符，以此防止万能密码或者后台注入攻击。而WebCrack不渲染页面执行Javascript脚本，可以绕过此类防护。

2.1.1登录页面识别

此步骤主要有两个作用:

(1)验证是否为真正的后台登录页面。系统会判断是否存在Form表单，若存在则利用关键字特征进一步判断是否为搜索页面。接着会判断是否存在登录页面常见的关键字，如“登录”，“login”，“user”，“pass”等。若不存在则认为此页面不是登录页面。

(2)剔除存在验证码的页面。由于本系统仅为验证DBKER算法的实用性，并未实现对验证码识别，所以当遇到含有验证码的页面时系统会自动退出。

登录页面识别流程如图5所示。

2.1.2提交路径识别

想要实现自动化检测，首先要模拟人工来识别登录框与提交的参数。一般来说，WEB系统最常见的认证方式有基于Form表单或者Ajax两种方式。由于大多数CMS采用了Form表单的方式，所以本工具实现了Form表单中的路径与参数识别。

此处方法与田峥等人的方法大体相同。首先利用BeautifulSoup模块分析提取Form表单，然后检测action字段的值，分以下情况讨论。

(1)当action的值为绝对URL地址。则直接将action的值作为提交路径地址。

(2)当以“/”开头，则将其与web根地址拼接。

(3)当以“.”开头，则为相对路径，将其与当前目录的路径拼接。

最后返回提交路径的地址。

2.1.3提交参数识别

提取form表单之后，我们需要找出对应的用户名，密码输入框和登录按钮。对于用户名和密码输入框的获取主要依靠的是关键字对比。如果input标签中的name值包含'user','name','zhanghao','yonghu','email','account'等关键字则标记此处为用户名输入框。同理，如果标签中包含'pass','pw','mima'等关键字则标记为密码字段。

一些网站为了防止CSRF攻击，常常会增加隐藏的token字段来进行验证。所以系统会遍历提取form表单中所有含有value的键值对来发送，以绕过CSRF防护系统的检测。

除此之外，一些网站会设置reset按钮，当此键含有值的时候会将表单初始化，而忽略发送的账号密码。所以系统在遍历到reset字段时，会将其从字典中移除。

2.2随机headers模块

为了防止黑客对于后台口令进行猜解，很多WAF以及WEB管理系统设置了对于同一IP一段时间内的提交次数限制，当超过一定次数后系统就会锁定无法继续登录。但是由于某些开发者采用了请求头中的X_FORWARDED_FOR字段来获取目标IP，而此字段可以伪造，所以只需要加入一个随机函数即可绕过限制。在WebCrack中，每次发包之前都会产生一组随机的User-Agent，X-Forwarded-For，以及Client-IP字段来绕过WAF与CMS的防护限制。

2.3字典生成模块

字典生成模块由三部分子字典组成，分别是常规字典，动态字典，万能密码字典。

2.3.1常规字典

常规字典除了123456,qwe123之外，还可以根据当前要爆破的用户名生成对应的字典。例如当爆破的用户名为admin时，就会自动生成与之关联的密码，如admin123,admin888，admin123456等。

2.3.2动态字典

WebCrack增加了根据域名生成不同的动态字典的功能。很多管理员为了方便，会根据域名设置自己的管理密码，同样会被黑客猜到，造成弱口令隐患。假如系统检测的目标为一个域名，举例为webcrack.yzddmr6.com，那么就会生成以下动态字典列表，其中后缀可以由用户自行配置。假如正则匹配到目标是一个IP而不是域名则不会产生动态字典。

2.3.3万能密码字典

WebCrack的一大特点就是可以支持万能密码的检测。其中内置了一些常见的检测万能密码的payload，如：admin'or'a'＝'a、'or'＝'or'、admin'or'1'＝'1'or 1＝1、')or('a'＝'a等。系统首先进行传统字典尝试，若未找出正确口令就会启用万能密码探测模块。

因为大多数成熟的管理系统并不存在此漏洞。若对所有的目标均开启会导致不必要的发包，甚至触发防火墙机制。所以自定义爆破规则的优势就显现出来。在面对未知CMS时会默认开启万能密码探测；在遇到已知CMS时可以通过自定义规则设置是否开启此项。

2.4自定义判断算法模块

有了通用弱口令判定算法后，系统虽然可以爆破大部分网站后台，但是总会有一些开发不规范或者不符合通用爆破规则的特殊网站。基于此，本系统增加了自定义爆破规则模块，使用者可以根据自己的需要自定义爆破规则。

配置文件参数说明：

以discuz论坛系统为例：

此配置项的意思是：如果检测到登录页面有“admin_questionid”关键字则识别为“discuz”管理系统。此管理系统默认没有验证码，并且根据exp_able字段看出此，管理系统是不存在万能密码漏洞的，所以在爆破时不会加入万能密码检测的payload，防止触发WAF拦截。如果返回信息中包含”admin.php？action＝logout”则说明已经成功进入后台，爆破成功。若返回信息中包含"密码错误次数过多"关键字，则说明已经触发了此系统的最大密码错误数，就会直接退出爆破。“alert”的值为0，说明不会打印“note”字段中的内容。

3总结

弱口令以及万能密码这类漏洞较为低级，并且不需要很高的技术水平就可以利用，却往往会被人们忽略。被不法分子利用之后，可能导致个人信息泄漏，甚至服务器权限丢失。会给政府，企业，个人造成不同程度的损失。本文在前人的基础上完成了一套切实有效的WEB弱口令以及万能密码自动检测算法，并实现了具体的系统。实现了导入后台地址即可进行批量化检测的功能，并且在准确率和检测率上超过市面上的同类系统。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变形，这些改进和变形也应视为本发明的保护范围。

Claims (6)

1.一种静态特征与动态页面特征结合的WEB弱口令检测方法，其特征在于，该方法包括如下步骤：

S1、预处理：发送至少两次错误的口令判断是否产生动态返回值并获取返回值长度EL（Error Length）；

S2、关键字黑名单检测：当返回页面中存在黑名单列表的关键字时，则说明口令错误，进行下一组口令尝试；若不存在则进入下一步判断；

S3、判断用户名和口令的键名是否存在于跳转后的页面中，若存在说明本组口令错误，继续进行下一次判断；若不存在，则进行下一步判断；

S4、与EL比较：将返回页面的总长度与EL相比较，若相等，则认为本组口令为错误口令，否则将本组口令作为待检测口令s进入下一步判断；

S5、Recheck环节：依次发送一个错误的口令e1，和从上一步得到的待检测口令s，比较两者的返回页面长度，若相等则认为本组口令错误，若不相等则本组口令正确；

所述步骤S1具体包括：发送至少两次错误的口令来判断页面的稳定性，若返回页面的长度相等则认为其页面为稳定的，并记录下此时页面的返回值长度EL；若不稳定则退出爆破；返回值长度为返回页面的body值长度加上headers头部长度；

在步骤S1和步骤S5中发送口令前还包括预请求的过程，具体包括：先请求一次后台页面，保存系统在第一次请求时分配的cookie值；

发送口令还包括：识别登录页面，识别出提交路径，识别提交参数，直接向目标地址提交数据而不经过页面渲染。

2.如权利要求1所述的WEB弱口令检测方法，其特征在于，所述步骤S2中的黑名单列表的关键字包括提示口令错误的关键字、超过最大尝试次数的关键字和被防火墙拦截的关键字。

3.如权利要求1所述的WEB弱口令检测方法，其特征在于，所述口令包括错误口令、正确口令和万能口令；其中，可以正常登录后台的万能口令，我们认为其属于正确口令部分，不引起防火墙拦截的但无法登陆的万能口令属于错误口令部分，否则属于万能口令部分。

4.如权利要求1所述的WEB弱口令检测方法，其特征在于，所述识别登录页面的过程包括：判断是否存在Form表单，若不存在则系统退出，若存在则利用关键字特征进一步判断是否为搜索页面，如果是搜索页面则系统退出，否则接着会判断是否存在登录页面常见的关键字，若不存在则认为此页面不是登录页面，系统退出，如果存在则认为是登录页面。

5.如权利要求1所述的WEB弱口令检测方法，其特征在于，所述识别提交路径的过程如下：利用BeautifulSoup模块分析提取Form表单，然后检测action字段的值；当action的值为绝对URL地址则直接将action的值作为提交路径地址，当以“/”开头，则将其与web根地址拼接，当以“.”开头，则为相对路径，将其与当前目录的路径拼接，最后返回提交路径的地址。

6.如权利要求1所述的WEB弱口令检测方法，其特征在于，所述口令使用常规字典、动态字典或万能口令字典生成，所述常规字典根据当前要爆破的用户名生成对应的字典，所述动态字典根据域名生成不同的动态字典，所述万能口令字典为根据常见的口令生成的字典。

Images