web 登录验证机制的攻与防

  • A+
所属分类:安全文章

学习打卡计划是信安之路知识星球开启的 “每天读书一小时,挑战打卡一百天” 主题活动,能够坚持学习打卡 100 天的同学可以获得信安之路提供的百分成就徽章和证书,学习书籍可以自选,主要目的是养成每日读书学习的好习惯,并将自己的学习心得分享出来供大家学习。

下图为目前星球成员的最新打卡内容,还有目前打卡活动的排行榜,坚持学习是一件非常难的事情,随着时间的推移,坚持的人越来越少,但这就是真实的情况,能够坚持到最后的一定是少数。

web 登录验证机制的攻与防

打卡一:web 实战 P210-248

这部分内容主要讲关于验证机制的安全问题,在学习这个之前,首先要知道关于验证都有哪些功能,对于不同的功能又有不同的安全风险和问题。验证登录的目的是对用户做区分,根据用户的登录信息来确定用户的访问权限,这块设计几个方面:登录、注册、重置/忘记密码、会话保持,下面根据不同的功能来总结不同的安全问题。

登录功能,这里涉及用户的账号密码,通常用户的账户信息都存在于数据库中,用户提交账号和密码到后端服务进行验证,服务器验证时可能由于程序员代码问题,将账号和密码直接通过拼接字符串的方式代入验证,从而导致万能密码的问题,通过构造 payload:admin or 1=1-- 就可以完成认证。排除代码本身的问题,普遍存在暴力破解的问题,重复提交账号密码进行认证,通常的防御措施是采用强验证码,从而引出验证码识别绕过的问题,既然涉及密码问题,就会存在因为用户安全意识问题导致的弱口令。防御暴力破解还有登录次数限制,由于登录次数的记录在客户端的 cookie 中从而导致这个策略失效,验证次数的统计还是需要在后端记录,不能相信客户端提交的任何数据。

注册功能,由于系统内有高权限的账户,比如 admin,在注册时如果没有验证用户名是否已经存在,那么就可以注册 admin 账户,从而达到越权的目的,注册还有一个问题就是垃圾注册,导致大量僵尸账户注册,成为别人薅羊毛的工具,防垃圾注册主要方式也是强验证码,还有就是限制单个手机号只能注册一个账户,来限制垃圾注册问题。

重置和忘记密码功能主要用来在用户忘记自己的密码时进行重置,重置密码通常要验证多个因素,比如短信验证码、账号和原始密码、邮件验证等,这里主要出现过的安全问题包括:验证码可枚举、验证链接不失效、验证码绕过、验证因素可预测等。

会话保持,通常使用 cookie 来记录用户的会话信息,这里的安全问题主要来自信任客户端提交的 cookie,cookie 中如果有明显的象征身份的信息,比如 admin=1 表示管理员,admin=0 表示普通用户,那么攻击者就可以修改 cookie 的值来进行越权。

还有些安全问题时认证信息被劫持,比如未使用 https 的网站,登录时使用明文的形式,通过抓包的方式就可以获取用户提交的数据,对于认证而言,post 的方式相对是比较安全的,如果是用 get 方式提交账户信息,那么敏感信息就有可能被劫持,或者被默认记录与网站的日志中,造成敏感数据的二次泄漏。

关于验证是如今网站的核心安全功能,也是最容易出安全问题的地方,之前有个小伙伴在群里说,一个登录口,由于登录错误的提示比较详细,比如用户名错误时提示用户名错误,密码错误时提示密码错误,他不认为是个安全问题,其实也算安全风险,因为可以让攻击者先猜测用户名,枚举用户名,然后再根据已知用户名进行密码破解,大大的降低了攻击难度。

关于登录这块的安全学习,在这里留两个实际操作的作业:

作业一:通过搜索以前寻找登录口,收集一些常用弱口令字典,使用 burp 来对该登录口进行暴力破解操作,字典至少 100 个,最终目标是找出一个存在的用户名,并且尝试密码 100 次,爆破过程使用 burp 实现。

作业二:使用自己擅长的语言,编写一个登录页面,后端使用数据库,用户密码在数据库中使用 md5 存储,也可以使用其他加密手段,最终目标是实现可访问的登录口,并使用 burp 进行撞库操作,撞库的原理是使用其他网站的账号密码库来进行尝试,这个可以自己使用脚本生成一个账号和密码对应的字典库。

以上作业,大家可以将过程编写成报告或者录制成小视频在圈子内进行分享,涉及代码可以贴出来让大家审计,说不定有惊喜,期待大家的成果。

打卡二:web 实战 P249-260

这部分主要讲了三点,一是认证代码缺陷,在验证登录时将账号和密码一起带入数据库查询语句,判断是否可以查询出内容,如果查询出数据则认为认证成功,否则为失败,还做了异常处理,正常来说出异常为失败才对,而代码中写的是异常之后则为成功,那么就存在问题,我们可以通过构造畸形的参数,来触发异常,从而实现认证成功。

二是多步骤认证的实现,比如先进行账号和密码的认证,然后再根据用户名,这里的用户名是通过隐藏表单来提交,这里通过数据包可以修改,从而导致越权问题的出现,用一个普通账号认证成功,然后第二步伪造任意用户名认证,获取任意用户的数据。

三是存入数据库的密码加密方式的问题,以前都是明文存储,只要存在 SQL 注入的问题,就能获取所有用户的明文密码的问题,后来出现了 md5、sha1 等,为了对抗破解,出现二次 md5、加 salt 加密等。

打卡三:web 实战 P261-272

这部分内容主要讲如何针对验证机制做安全防御,安全往往与用户体验成反比,越安全的系统,使用起来越繁琐,安全的目标是要平衡与业务的关系,找到平衡点,在不那么影响业务的前提下,实现安全防御的最优解,所有安全策略比一定都要在业务系统上实现,选择适合当前系统的即可。

1、限制用户密码的设置规范:大于 8 位必须包含大小字母和数字特殊字符(这是大部分网站的设置)、用户名唯一(避免注册时用户身份被冒用)、默认密码要足够随机(一些系统注册时不是自己设置,而是给初始化密码,很多情况是默认相同的密码或者密码按一定规律生成,这样容易被恶意猜解)。

2、认证信息安全传输:全站 HTTPS、提交使用 POST 不用 GET 或 Cookie、存入数据库的密码要进行加密(sha256、md5+salt)、定期修改密码(办公网经常 3 月强制失效改一次)、存在初始化密码的系统,首次登录强制修改密码、密保问题使用下拉框来抵御键盘记录器。

3、密码认证安全:区分大小写,不过滤和修改字符,不截取字段、异常处理,清除所有会话数据、多阶段认证信息禁止由客户端提供数据。

4、防止信息泄漏:对于数据提交返回的错误信息一致,无区分(防止通过返回信息判断是用户名还是密码错误)、对于达到错误次数锁定的功能,可能因为锁定这个功能来枚举有效用户、注册时给用户生产唯一用户名,如果是使用邮箱注册,已注册和未注册返回同样的信息,避免出现不一样的信息来让攻击者可枚举有效账户。

5、防止暴力破解:设置登录失败阈值、使用强验证码、对同一 IP 来源设置登录阈值

6、防止密码修改功能问题:只能在已通过验证的会话中访问该功能、不能直接出现用户名、要求重新输入当前密码、新密码要输入两次一致、失败次数设置阈值、修改成功通过邮箱或者手机短信来提示用户。

7、防止忘记密码功能问题:不使用密码提示、改密链接具有时限(通常为一天),使用之后即失效,改密 token 随机不可预测、多因素验证(用户名、手机号等)

8、日志留存:所有用户相关操作均留下详细的日志,供事后溯源和大数据分析。

登录验证是出问题最多的地方,希望大家可以好好学习思考。这部分内容可以结合之前的作业,改善自己的代码,做到尽可能少的安全问题出现。

web 登录验证机制的攻与防

本文始发于微信公众号(信安之路):web 登录验证机制的攻与防

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: