既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
预防思路
1.response数据内不包含验证码,验证方式主要采取后端验证,但是缺点是服务器的运算压力也会随之增加。
2.如果要进行前端验证的话也可以,但是需要进行加密。当然,这个流程图还有一些安全缺陷,需要根据公司业务的不同而进行更改。
三.未进行登陆凭证验证
解析
有些业务的接口,因为缺少了对用户的登陆凭证的效验或者是验证存在缺陷,导致黑客可以未经授权访问这些敏感信息甚至是越权操作。
常见案例:
- 某电商后台主页面,直接在管理员web路径后面输入main.php之类的即可进入。
- 某航空公司订单ID枚举
- 某电子认证中心敏感文件下载
4.某站越权操作及缺陷,其主要原因是没对ID参数做cookie验证导致。
- 实际上还有很多案例,这里就不一一例举了,但是他们都存在一个共同的特性,就是没有对用户的登陆凭证进行效验,如下图为例。
预防思路
对敏感数据存在的接口和页面做cookie,ssid,token或者其它验证,如下图所示。
四:接口无限制枚举
解析
有些关键性的接口因为没有做验证或者其它预防机制,容易遭到枚举攻击。
常见案例:
- 某电商登陆接口无验证导致撞库
- 某招聘网验证码无限制枚举
- 某快递公司优惠券枚举
- 某电商会员卡卡号枚举
- 某超市注册用户信息获取
预防思路
1. 在输入接口设置验证,如token,验证码等。
如果设定验证码,最好不要单纯的采取一个前端验证,最好选择后端验证。
如果设定token,请确保每个token只能采用一次,并且对token设定时间参数。
-
注册界面的接口不要返回太多敏感信息,以防遭到黑客制作枚举字典。
-
验证码请不要以短数字来甚至,最好是以字母加数字进行组合,并且验证码需要设定时间期限。
-
优惠券,VIP卡号请尽量不要存在规律性和简短性,并且优惠券最好是以数字加字母进行组合。
-
以上这是部分个人建议,实际方案需要参考业务的具体情况。
五:cookie设计存在缺陷
解析
这里需要对其详细的说一下。我们先一个一个来吧。
- Cookie的效验值过于简单。有些web对于cookie的生成过于单一或者简单,导致黑客可以对cookie的效验值进行一个枚举,如下图所示
根据上图,我们可以分析出,这家网站对于cookie的效验只单纯的采用了一组数字,并且数值为常量,不会改变,这样非常容易遭到黑客的枚举。甚至有一些网站做的更简单,直接以用户名,邮箱号或者用户ID等来作为cookie的判断标准。
- cookie设置存在被盗风险
有很多时候,如果一个用户的cookie被盗取,就算用户怎么修改账号和密码,那段cookie一样有效。详情可以参考《BlackHat(世界黑帽大会)官方APP出现两个逻辑漏洞》。
其原理如下:
国内大部分厂商都不会把这个地方当作安全漏洞来处理,他们认为这个漏洞的利用条件是黑客必须要大批量获取到用户的cookie。虽然事实如此,但是这个也是一个安全隐患。
3.用户的cookie数据加密应严格使用标准加密算法,并注意密钥管理。
有一些厂商为了图方便,没有对用户的cookie做太多的加密工作,仅仅是单纯的做一个静态加密就完事了。我之前就碰到一个,可以为大家还原一下当时的场景。
当时我看到cookie中有个access token参数,看到value后面是两个等号,习惯性的给丢去base64解码里面,发现解出来后是我的用户名。因此只要知道一个人的用户名就可以伪造对方的cookie,登陆他人账户。
4.还有多个案例不再做重复说明,大家可以深入研究一下cookie中的逻辑漏洞。但是cookie中的漏洞大多都是属于一个越权漏洞。越权漏洞又分为平行越权,垂直越权和交叉越权。
平行越权:权限类型不变,权限ID改变
垂直越权:权限ID不变,权限类型改变
交叉越权:即改变ID,也改变权限
如下图所示:
预防思路
1.cookie中设定多个验证,比如自如APP的cookie中,需要sign和ssid两个参数配对,才能返回数据。
2.用户的cookie数据加密应严格使用标准加密算法,并注意密钥管理。
3.用户的cookie的生成过程中最好带入用户的密码,一旦密码改变,cookie的值也会改变。
4.cookie中设定session参数,以防cookie可以长时间生效。
5.还有很多方法,不再一一例举,请根据业务不同而思考。
六:找回密码存在设计缺陷
解析
1.auth设计缺陷
经常研究逻辑漏洞的人可能会对以下URL很熟悉
www.xxx.com/resetpassword.php?id=MD5
用户修改密码时,邮箱中会收到一个含有auth的链接,在有效期内用户点击链接,即可进入重置密码环节。而大部分网站对于auth的生成都是采用rand()函数,那么这里就存在一个问题了,Windows环境下rand()最大值为32768,所以这个auth的值是可以被枚举的。
如下面这个代码可以对auth的值做一个字典。
然后重置某个账号,并且对重置链接内的auth进行枚举
整个漏洞的运作的流程图如下:
2.对response做验证
这个漏洞经常出现在APP中,其主要原因是对于重置密码的的验证是看response数据包,由于之前的案例没有截图,只能画个流程图给大家演示一下。
3.《密码找回逻辑漏洞总结》这篇文章很全面的总结了密码找回漏洞的几个具体思路和分析,这里我就不再继续滚轮子了。
预防思路
1.严格使用标准加密算法,并注意密钥管理。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
vfOJly-1715222709951)]
[外链图片转存中…(img-7vQGoSLU-1715222709951)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新