搞安全的小伙伴只有一个登录框你都能测试哪些漏洞？

通常大家测试的都会测试关键部分，为了有更好的测试效果，小厂会提供给你用户名密码；但是一些比较重要的企业，而这个环境却是正式环境，里面存放着一些数据不希望被你看到的时候，是不会提供给给你登录账号的。这个时候，考验你基础知识是否扎实的时刻来临了。

漏洞描述：

一般存在于系统登录页面，利用登陆系统中的漏洞可以试验出是否存在的哪些用户名，返回不同的出错信息可枚举出系统中存在的用户名。

测试方法：

找到网站或者web系统登录页面。在web系统登录页面，通过手工方式，利用系统中存在的用户名和不存在的用户名，密码随意，尝试登录，查看其回显内容。例如：输入存在的用户名admin，回显如下：密码错误；输入不存在的用户名test，回显如下：用户不存在。

示例：

风险分析：

攻击者根据Web应用程序返回的上述提示信息即可枚举系统中存在的登录用户名，然后针对枚举出来的登录用户名，对其密码进行暴力破解。

修复方案：

建议对网站登录页面的判断回显信息修改为一致：用户名或密码错误。

漏洞描述：

有一部分厂商的设备存在默认的用户名以及密码（用户名以root、admin为主）

示例：

通常很多厂商后台默认账户为“admin”，密码为"admin"或“123456”，大家可以通过暴力破解去尝试

风险分析：

攻击者可利用互联网公开的常见弱口令尝试登录管理后台，对网站造成一定的影响。

修复方案：

禁止使用弱口令，口令应满足一定的复杂度（数字字母特殊符号，密码保持16位以上）。

给大家推荐一个随机生成密码的网站  https://suijimimashengcheng.bmcx.com/

漏洞描述：

找到网站登录页面，尝试输入用户名，密码为空进行登录。如果登录成功表示认证登录环节允许空口令

风险分析：

攻击者可利用该漏洞登录网站后台，操作敏感数据，甚至上传webshell，从而控制服务器。

修复方案：

判断输入密码是否为空，禁止空口令登录。

漏洞描述：

有的登录页面可以通过禁用js样式（不常见），能轻易的绕过登录认证，直接进入系统。或者是通过burp抓报改包进行登录绕过也是可以的（常见一点）

示例：

Apache shiro cve-2020-17523 Apache shiro较新的登录认证绕过，大概的方式就是使用空字符绕过www.xxx.com/admin/%20/www.xxx.com/admin/%2e/示例用户名密码可以乱写

点击登陆按钮同时使用抓包工具进行数据包拦截

将数据包返回至当前页面，修改code值登录成功

风险分析：

如果应用程序在认证上没有做好，可以导致恶意用户或者攻击者绕过认证，访问内部资源，这类漏洞通过防火墙和入侵检测系统很难预防。

修复方案：

可从以下几个方面预防认证绕过：

增加验证码，不使用前端验证，密码通过加密算法加密，失败次数多加锁，密码强度增加

漏洞描述：

就是用通过社工手段得到的信息随机组合的密码进行暴力破解，一般用户名密码都离不开身边的事物，并且网站密码字段是明文

测试方法：

找到网站登录页面。

利用burp对登录页面进行抓包，将其发送到Intruder,并设置其密码参数，如pwd=为变量，添加payload（字典），进行攻击，攻击过程中查看其返回的字节长度，来判断是否成功。

一般情况下，暴力破解有三种形式：

固定账号对密码暴力破解。

在得知账号具有规律性，或者通过某种方式获取到大量账号的前提下，固定密码对账号暴力破解。

使用网上流传的账号密码库进行撞库攻击。

示例：

风险分析：

攻击者一般会使用自动化脚本组合出常见的用户名和密码，即字典，再结合软件burpsuite的intruder功能进行暴力破解。

修复方案：

防止暴力攻击的一些方法如下：

增加验证码，密码通过加密算法加密，失败次数多加锁，密码强度增加

漏洞描述：

有些网站登录框存在图形验证码，防止暴力破解攻击，但是正常的逻辑是前端输入验证码之后进行校验图形验证码的正确性，而后若是为真则进行登录操作，为假则返回验证码输入错误，而使用一次的验证码应该立即失效。然而有些网站验证码可能是可控的，输入一些特殊字符可能就能打到欺骗服务器或验证码使用一次之后并没有及时刷新

测试方法：

输入用户名、密码、验证码后，点击登陆按钮同时将数据包使用burpsuite进行拦截，并使用Repeater模块或Intruder模块进行数据重放，重新发送五次观察页面变化，是否会提示验证码输入错误等信息示例：

此登录功能时存在图形验证码的，在输入了正确的图形验证码之后进行数据重放，发现图形验证码没有做到及时失效

修复方案：

1、系统在开发时注意验证识别后销毁session中的验证码。

2、限制用户提交的验证码不能为空

3、判断提交的验证码与服务器上存储的是否一致

漏洞描述：

一些网站使用手机短信登录，短信验证码可被绕过或者是验证码过短可以被爆破。

测试方法：

1.请求发送短信，填写任意验证码，然后提交其他操作请求，将验证码参数置空或删除，测试是否可绕过检测；

2.尝试特权验证码，如000000、111111等；

3.同一个短信验证码是否能使用多次；

示例：

正确的逻辑应当是，短信验证码获取后，服务器校验短信验证码的来源以及有效性，使用一次后应该立即失效。但是我遇到的这个就是使用验证码登录后，注销用户登录后再一次使用验证码发现依然登陆成功，也就是短信验证码没有被删除

风险分析：

修改／重置密码、交易操作等功能通常需要短信验证码，若验证码可绕过，攻击者可利用该漏洞进行重置他人密码或转账等危险操作。

修复方案：

1.若存在特权验证码，建议将其删除；

2.应用服务端应严格校验验证码参数是否为空，格式是否正确；

3.关键操作每提交一次请求，应发送新的短信验证码，并且不可继续使用旧的验证码。

漏洞描述：

短信验证码位数太短或有效期太长导致可暴力破解

测试方法：

点击发送短信验证码，输入任意验证码，提交请求，使用burpsuite拦截请求，在intruder模块设置验证码参数为枚举变量，这是payload类型为numbers，对验证码进行暴力破解。

示例：

这里的短信验证码可被暴力破解，是因为并没有设置短信验证码使用错误几次后失效，故可被暴力破解

风险分析：

修改／重置密码、交易操作等功能通常需要短信验证码，若验证码可暴力破解，攻击者可利用该漏洞进行重置他人密码或转账等危险操作。

修复方案：

1.短信验证码不少于6位；

2.有效期不超过1分钟；

3.验证码错误次数超过上限应采取账户锁定策略。

漏洞描述：

短信攻击时常见的一种攻击，攻击者通过网站页面中所提供的发送短信验证码的功能处，通过对其发送数据包的获取后，进行重放，如果服务器短信平台未做校验的情况时，系统会一直去发送短信，这样就造成了短信轰炸的漏洞。

测试方法：

1、手工找到有关网站注册页面，认证页面，是否具有短信发送页面，如果有，则进行下一步。

2、通过利用burp或者其它抓包截断工具，抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到10条以上短信，如果收到大量短信，则说明存在该漏洞。

示例：

点击获取验证码同时拦截数据包

使用burpsuite进行数据重放

风险分析：

攻击者通过填写他人的手机号，使用软件burpsuite的intruder功能重复提交发送短信的请求包，达到短时间内向他人的手机上发送大量垃圾短信的目的。

修复方案：

1、合理配置后台短信服务器的功能，对于同一手机号码，发送次数不超过3-5次，并且可对发送的时间间隔做限制。

2、页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且限制发送的时间间隔。

漏洞描述：

通过不断的输入错误的密码可恶意锁定任意账号

测试方法：

针对测试账户，不断输入错误的密码，直至将其锁定

示例：

风险分析：

若系统认证功能无防自动化处理模块，攻击者可编写脚本批量锁定系统账号。

修复方案：

1.账户锁定之后应不能继续使用认证功能

2.认证功能防自动化操作，如添加图形验证码。

漏洞描述：

认证过程中传输未加密（用户名密码等敏感数据明文传输）。

测试方法：

通过对网站登录页面的请求进行抓包，工具可用burp、wireshark、filder、等等，分析其数据包中相关password（密码）参数的值是否为明文。如图利用wireshark抓包分析的密码：

示例：

1.输入用户名密码

2. 使用burpsuite进行数据包拦截

风险分析：

攻击者通过在局域网中嗅探网络流量，获取明文传输的认证凭证，如用户名密码、SESSIONID等敏感信息。

修复方案：

建议按照网站的密级要求，需要对密码传输过程中进行加密得使用加密的方式传输，如使用HTTPS， 但加密的方式增加成本，或许会影响用户体验。如果不用 HTTPS，可以在网站前端用 Javascript 做密码加密，加密后再进行传输。

漏洞描述：

跨站脚本攻击的英文全称是Cross Site Script，为了和样式表区分，缩写为XSS。发生的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。跨站脚本攻击,它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。已知的跨站脚本攻击漏洞有三种：1）存储式；2）反射式；3）基于DOM。

测试方法：

1、GET方式跨站脚本：

在输入的参数后逐条添加以下语句，以第一条为例，输入http://www.exmaple.com/page.xxx?name=文本输入框：需要对页面上所有可以提交参数的地方进行测试。具体跨站脚本的测试语句根据实际情况的不同而不同，可自行构造，以及触发事件等切换，这里只列出了一些最常见构造语句。

示例：登录窗口用户名处存在反射型XSS注入点击登陆，成功弹出内容

风险分析：

攻击者可以使用该漏洞构造钓鱼链接，诱骗受害者访问并填写用户名和密码，从而窃取用户的认证凭据

修复方案：

1、总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下 ：

2、输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。

3、输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。

4、明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。

5、注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如"“或类似"script"的关键字)，很容易被XSS变种攻击绕过验证机制。

警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。对客户端提交的数据进行过滤，一般建议过滤掉双引号（”）、尖括号（）等特殊字符，或者对客户端提交的数据中包含的特殊字符进行实体转换，比如将双引号（”）转换成其实体形式”，