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

修复建议：

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

修复建议：

1. 加长验证码长度（加长攻击者爆破时间）

2. 限制尝试次数（采用后端验证）

3. 限制验证码的有效时间（1分钟内有效）

修复建议：

前端，后端定时限制

1. 当对一个手机号发送验证码之后，后端会给一个包含验证码的返回包
   

2. 前端hide属性标签的隐藏有验证码，可通过F12查看

修复建议：

1. 后端不返回验证码

2. 前端控制台不显示验证码

   
   

1）验证码可复用

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

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

   
   

如：{“result”:false}

修复建议：

使用后端验证

1. 找回或重置时，发送验证码的手机号，未做绑定，导致可以抓包，修改发送验证码的手机号（比如自己的手机号）并且成功获取验证码
   

2. 可以通过修改密码找回或重置的步骤参数，直接到最后一步，直接进行修改或者重置

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

修复建议：

1. 后端对所绑定手机号做验证

2. 前后端完善步骤的判断（如判断是否有正确的执行前面几步的操作）

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

修复建议：

1. 后端完善会话绑定

2. 前后端加强令牌、cookie的加密强度

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

修复建议：

1. 前后端对注册时间限制

2. 后端对ip进行注册次数限制

修复建议：

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

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

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

修复建议：

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

修复建议：

1. 使用session 会话（令牌）

2. 使用HTTPOnly 防止cookie被盗用

修复建议：

1. 加强session会话的绑定

2. 销毁登录成功的凭证防止复用

希望大佬们多多纠正，多多补充，多多评论哦！！感谢感谢！！

文章来源：CSDN博客（谁不曾是小白捏）原文地址：https://blog.csdn.net/qq_63217130/article/details/130187929

 还在等什么？赶紧点击下方名片关注学习吧！

推 荐 阅 读

原文始发于微信公众号（潇湘信安）：常见的登录逻辑漏洞总结