SecMap - 验证码

本文最后更新于:5 个月前

SecMap - 验证码

SecMap - 验证码

功能点介绍

全自动区分计算机和人类的图灵测试(Completely Automated Public Turing test to tell Computers and Humans Apart,简称 CAPTCHA),验证码,作为区分人与机器的经典手段,安全中有着特殊的地位。作为辅助的安全手段,和 Web 中的其他漏洞相比似乎微不足道,但如果能绕过验证码,则可以把手动变为自动,对于攻击者也是扫清了一个大障碍。

验证码常见的有纯文本验证码、图形验证码、行为验证码:

  1. 纯文本验证码:比如 今天是星期几?75 * 2 = ?,这种验证码很容易破解,比如对于四则运算,攻击者只需要在 html 中用正则拿一下问题就可以直接算结果了,所以现在已经非常少见了,基本上可以被秒杀。
  2. 图形验证码:现在非常多网站采用的就是这种,主要的思路就是“用户识别”,有简单的纯数字、加英文字母、加各种干扰线、加噪点、Apple 会动的验证码、Google/12306 选物体的验证码,难度依次递增。图形验证码是对抗历史最为悠久的一种,攻击者利用各种算法识别验证码,甚至动用了机器学习/深度学习,肯下成本的还用了人工打码平台。总体而言,对于攻击者来说成本不算高。
  3. 声音验证码:有些验证码为了提高用户体验和照顾视觉障碍的用户,会用声音验证码,一般来说是机器生成一段读数字的语音,然后让用户识别,有些是给你打电话,有些是直接网页上就可以听语音。由于攻击者要识别(有时候需要接管通话)语音,所以相对来说成本高了一些。
  4. 行为验证码:总之就是思路从验证“用户识别”变成了验证“用户操作”,比如有滑动验证码、拼图验证码、还有各种诸如“投篮”等奇葩的验证码。比较有代表性的就是极验的滑动验证码,比较有名,很多厂都在用。滑动验证码不但不是很好模拟,而且往往加入了生物特征识别,比较难自动化,对于攻击者来说成本比较高。

攻击思路

客户端生成验证码

验证码由客户端生成,比如用 js,在客户端验证,可以直接伪造数据包绕过;或者发回给服务端校验,修改响应就轻易可以绕过验证码。

修复方法:验证码的生成、比对应该放在服务端进行。

验证码回显在响应中

有些程序会将验证码放在响应中(body、Set-Cookie),这个时候只要拦截发送的请求,查看响应就可以获得验证码了。

修复方法:避免将验证码回显在响应包中,验证的比对应该放在服务端进行。

验证码可以为空

后端没有考虑到验证码为空的情况,不传验证码可以直接通过验证码的认证。ecshop 曾经出现过此问题。

修复方法:后端的逻辑应该是,没有收到验证码,等同于验证码错误。

万能验证码

一般是开发人员测试时所用的测试验证码直接部署在线上,不用调用任何获取验证码请求的接口,直接输入该万能验证码,即可通过验证。

修复方法:上线之前去除所有测试、调试逻辑。

验证码可复用

对于一个 session,验证码可以重复使用,攻击者只需要保证 cookie 没变,这个验证码就基本没有用了。

修复方法:一个 session 的验证码,一旦使用过了就应该销毁。

验证码可被自动识别

最常见的,就是验证码图像过于简单,比如没有任何干扰线/扭曲的验证码。但是本文不打算讲验证码的识别方式,网上有很多资料,橘友们如果感兴趣的话可以看看这一篇:https://wooyun.x10sec.org/static/drops/tips-141.html

还有一类是,验证码图像复杂,但是存在其他特征可以间接识别。一个经典案例是:https://segmentfault.com/a/1190000021903141 。这个验证码其虽然不好直接识别,但是可以利用 svg path 长度这一特征,将其映射到特定验证码图片的字符上,遇到特定长度的 svg path 就等于见到了特定的字符,那么就可以自动化识别了。拓展一下思路,类似的问题可能是:返回验证码的数据包大小存在特征、验证码字符固定的颜色…

修复方法:1. 保证验证码图像本身其复杂度(添加英文字母或者汉字、扭曲字体、加干扰线、加噪点、粘连,有必要可以上行为验证码);2. 实现的时候注意验证码是否有其他特征可以间接识别出每个字符。

验证码可暴力破解

  1. 验证码提交错误之后,后端没有把对应 session 的验证码重置,导致攻击者可以重复尝试同一个验证码,导致验证码可暴力破解
  2. 验证码所有的可能性应该是很大的,这样可以避免攻击者重复提交一个答案绕过。但如果验证码本质上是在做选择题(通常只有 A、B、C、D 四个选项),那么所有的可能性就只有 4 种。案例:wooyun-2013-025245

修复方法:1. 一个 session 的验证码,一旦错误就应该销毁;2. 提升用户体验的时候,也要时刻注意验证码的空间大小,防止空间缩小导致验证码容易破解。

验证码功能开关可控

后端有关闭验证码的功能,但这个启用的变量可以由前端传递参数控制。为什么会有这种情况呢?可能是调试功能没有下掉;或者,有些验证码接口是 A 部门统一提供的,然后某个业务方用的某个前端框架是已经直接封装好了验证码功能,但是实际上又不需要使用它(比如内部的某个不重要的系统),就可能要求验证码接口有个关闭验证的参数。

案例:wooyun-2014-071289wooyun-2013-026219wooyun-2012-014563

修复方法:没有必要就别设置开关了;一定要设置开关的话,不能由前端控制;非要用前端控制的话。。。参数值加个密吧,但这个控制方式一定只能放在内网的系统上使用。

DDoS

有些验证码的实现是,前端传参中含有证码图片的大小,后端根据这个参数来生成验证码图片;加上后端没有限制验证码图片的大小,那么攻击者只需要生成超大的图形验证码,就很容易造成内存耗尽,达到拒绝服务的目的。

修复方法:验证码生成的一切逻辑应在后端完成;如考虑服务兼容性一定要接受前端传参时,也要对其进行大小限制。

验证流程的顺序有误

验证码在验证的时候,顺序/逻辑关系不正确,导致验证码失效。

如:先校验用户名和密码,然后再验证验证码是否正确,这明显逻辑顺序有误,验证码实际上没起到防护的作用。

修复方案:先校验验证码,再继续后面的业务逻辑。

总结

还是那句话,验证码更多时候是作为辅助的防御手段,简单却有效(虽然牺牲了一些用户体验)。验证码失效,一般不会直接带来安全问题,但是却会降低攻击者的攻击成本,导致出现安全问题的可能性增加。

攻与防,“成本” 是永恒的话题。


祝橘友们五一 “长” 假快乐
(其实就放了半天假)


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!