常见用户登录安全漏洞测试总结！

1.采用弱密码或者无密码进行登录（弱口令）

比如：

管理员账号：admin

密码：admin/123456/010203

测试账号：111

密码：111

万能账号：admin' or '1'='1（登录的sql注入）

修复建议：

1. 前端提醒用户提高密码复杂度
2. 后端检查数据库中测试环境余留下的账号
3. 前端对密码做加密（加密流程代码最好隐藏）

2.密码可爆破

可以通过密码字典，不断请求，爆破出密码

修复建议：

1. 后端限制一个账号请求次数，次数过多锁定账号
2. 前端输入验证码（类似谷歌的复杂验证码最好，否则可用pkav进行识别爆破，且验证码不可复用，前端验证，容易导致复用）

3.验证码可爆破

可以通过从0000遍历到9999来破解验证码

修复建议：

1. 加长验证码长度（加长攻击者爆破时间）
2. 限制尝试次数（采用后端验证）
3. 限制验证码的有效时间（1分钟内有效）

4.短信轰炸

未对发送验证码进行时间限制，导致可进行反复抓包重发验证码请求

修复建议：

前端，后端定时限制

5.手机验证码凭证可查看

1. 当对一个手机号发送验证码之后，后端会给一个包含验证码的返回包
2. 前端hide属性标签的隐藏有验证码，可通过F12查看

修复建议：

1. 后端不返回验证码
2. 前端控制台不显示验证码

6.万能验证码

1）验证码可复用

攻击使用以前使用过的验证码来通过验证

2）测试方便遗留下的万能验证码0000/1111/6666

修复建议：

1. 后端判断验证码是否被使用并且销毁
2. 去掉测试时遗留下的验证码

7.前端验证登录结果

点击登录之后，由后端返回以下登录结果，如果是前端验证，直接改为：{“result”:true}即可成功登录

如：{“result”:false}

修复建议：

使用后端验证

8.任意用户密码找回/重置

1. 找回或重置时，发送验证码的手机号，未做绑定，导致可以抓包，修改发送验证码的手机号（比如自己的手机号）并且成功获取验证码
2. 可以通过修改密码找回或重置的步骤参数，直接到最后一步，直接进行修改或者重置

如：url/?step=1 抓包修改为 step=3 直接跳到最后一步

修复建议：

1. 后端对所绑定手机号做验证
2. 前后端完善步骤的判断（如判断是否有正确的执行前面几步的操作）

9.未授权访问他人账号

1. 可直接修改用户id，平行越权访问其他用户账号
2. 请求中的令牌 加密性弱 只使用了简单的url或者base64 只破解其他账号的令牌，通过抓包修改已知账号的令牌换上他人的令牌，即可访问他人的账号

修复建议：

1. 后端完善会话绑定
2. 前后端加强令牌、cookie的加密强度

10.用户批量注册

可通过抓包，不断发送用户注册请求，导致服务器资源浪费，甚至遍历出他人的账号，以进行进一步的攻击

修复建议：

1. 前后端对注册时间限制
2. 后端对ip进行注册次数限制

11.注册导致存储型xss

注册时，未对用户输入信息进行验证，导致攻击者输入一些xss恶意脚本

修复建议：

1. 前端加强用户注册时输入内容的判断
2. 控制输入的字符，比如只能使用 . ！等安全的字符（白名单机制）一定禁用< >等字符

12.URL跳转（重定向）漏洞

如果url中有形如以下链接，导致攻击者可向被攻击者发送这样一个网址，如果攻击者点击之后，攻击者将能够盗取被攻击者的信息，恶意软件的安装

http://example.com/?url=http://bedurl.com

修复建议：

1. 不使用重定向
2. 使用相对url，取代完整的url
3. 白名单限制url的来源

13.CSRF漏洞

攻击者盗取了用户的cookie等信息之后即可直接登录用户账号

修复建议：

1. 使用session 会话（令牌）
2. 使用HTTPOnly 防止cookie被盗用

14.登录成功凭证可复用

当使用一个账号登录成功之后，抓取登录成功的请求凭证，再使用其他账号登录，并在登录过程中，利用之前登录成功的凭证，欺骗后端，导致登录成功

修复建议：

1. 加强session会话的绑定
2. 销毁登录成功的凭证防止复用

总结：“个人认为” 其实很多的逻辑漏洞都是前端验证，以及后端逻辑验证不正确，未对请求次数做限制，写代码偷懒了导致的，开发人员多站在攻击者的角度考虑，漏洞会少很多吧。