逻辑漏洞是指由于程序逻辑不严导致一些逻辑分支处理错误造成的漏洞,在实际开发中,因为开发者水平不一,没有安全意识,而且业务发展迅速,内部测试没有及时到位,所以常常会出现类似的漏洞,导致攻击者可以修改、绕过或者中断整个程序,让程序按照开发人员的预料之外去执行
安装逻辑
1.查看是否绕过判定重新安装
2.查看能否利用安装文件获取信息
3.查看能否利用更新功能获取信息
漏洞特点
1.普遍存在性:由于功能的实现需要大量的逻辑操作,同时受制于程序员的背景,这类缺陷普遍存在于各类应用程序中。
2.不固定性:因为每一种逻辑缺陷似乎都是唯一的,它是基于逻辑操作,不同的功能逻辑不同,因此无法用一般的工具发现它们。
3.隐蔽性:大多数的逻辑漏洞都十分隐蔽,它存在于操作与操作关系当中,甚至是属于应用程序正常的功能
漏洞出现的原因
SOL注入是程序开发者也没有想过你可以拼接他的语言产生他意料之外的危害,他不过是按照程序逻辑完成了整个查询的动作;那么为什么会产生逻辑漏洞就很容易理解了:研发人员只负责满足客户的需求,大部分的研发人员并不懂安全,所以并不会带着黑客的思维考虑这个软件的安全性
逻辑漏洞的分类
从漏洞的本质上,习惯将逻辑漏洞分为两类:
1.软件(系统)设计之初便存在的漏洞
比如永恒之蓝,sql注入漏洞、文件上传等等,均为设计的时候未能按照安全设计的方法就行所产生的,攻击者只需要找的特定的点,执行特性的代码即可产生研发预料之外的现象
2.使用者未能安全使用软件所产生的
关键在于使用者,比如弱口令、匿名用户,程序开发者会设计很多便捷的功能,但由于使用者使用不当,产生了新的问题
逻辑漏洞总结
身份验证漏洞
暴力破解漏洞
漏洞介绍:攻击者可以通过该漏洞获取用户名和对应弱口令密码,并进行登录操作
漏洞原理:由于没有设置登录失败次数限制,导致攻击者可以通过口令字典进行特定用户的密码爆破或通过用户名字典进行特定弱口令的用户枚举
漏洞点:系统登录点
漏洞修复:对于固定用户名爆破密码,可以针对用户名进行错误次数计算,高于一定阈值账号锁定一段时间,或者添加验证码,但是不能永久锁定,可能被用来进行账户恶意锁定;对于固定密码枚举用户名、需要计算IP对URL的请求情况,某个IP短时间大量请求登录应该加入黑名单进行传输数据加密有一定的防护效果
2.Session固定攻击
漏洞介绍:会话固定攻击是利用服务器的session不变机制,借他人之手获得认证和授权,然后冒充他人
漏洞原理:在请求登录过程时候,URL带有一个session,登录成功之后会将登录成功的信息绑定到这个session中,攻击者可以发送带有session的URL给相关工作人员诱导其登录,相当于获取了其身份信息
漏洞点:在GET方法请求登录时候带有session值
修复思路:只要避免在URL中带入session信息即可比较有效的防御,另外也要注意POST请求中带有sessionid进行session固定攻击,虽然可利用性比较低,但是建议修复
3.Cookie欺骗漏洞
漏洞介绍:通过伪造cookie信息能够伪造其他用户进行登录
漏洞原理:开发者为了方便将身份信息/登录信息明文或者只是简单编码、哈希之后存放在cookies中,网站通过获取得到的cookies进行授权或者身份验证
漏洞点:cookie中有明显或者只是简单编码、哈希的字段时候,修改lsLogin值为1可以判定为用户已经登录修改cookie为asp163=UserName=admin
漏洞修复:Cookie不应该存储可理解的身份信息和登录信息按照规定,cookie对身份信息和登录信息的存储只能通过存储足够长度的随机字符串进行,避免篡改
4.权限类逻辑漏洞
(1) 平行权限跨越
漏洞介绍:即普通用户/管理员能访问其他普通用户/管理员才能够访问的系统信息或者系统功能
漏洞原理:在进行方法调用时候未进行请求用户和目标信息拥有者是否匹配一致,直接用userid/email之类的容易遍历的参数进行数据库查询
漏洞点:在普通用户/管理员登录后的能访问的链接或者功能中都可能存在
漏洞修复:在权限管理中,平行越权的权限管理颗粒度最小
修复思路:
需要在方法中进行相关的获取请求request
再利用getAttribute("userid")获取其userid
直接使用该userid作为参数进行数据增删查改,避免userid参数传输
(2) 垂直权限跨越
漏洞介绍:即普通用户能够访问管理员甚至超级管理员才能够访问的系统信息或者系统功能
漏洞原理:程序在方法调用时候,缺少角色等级校验
漏洞点:在任何用户登录后才能访问的链接或者功能中都可能存在;对每一个传输的参数都要了解参数的目的,尝试将用户名改为admin尝试绕过
漏洞修复:
需要校验用户是否有权限访问这个方法
修复思路:
获取请求request
再利用getAuttribute("roleid")获取其角色等级
检查角色等级是否合法,错误则直接返回错误跳转,返回页面必须仍然从Attribute中获取userid再进一步查询相关信息
值得注意的是切勿将错误跳转写到Javascript里面,还返回目标URL页面的相关信息。
(3) 未经授权访问
漏洞介绍:即游客能够访问普通用户甚至超级管理员才能访问的系统信息或者系统功能
漏洞原理:主要是系统设计期间没有进行全局用户身份校验;或者校验存在缺陷
漏洞点:在任何用户登录后才能访问的链接或者功能中都可能存在
漏洞修复:J2EE中存在filter,可以获取用户的cookie等信息
修复思路:
建立LoginList,值是当前在线用户的id
对所有需要登录访问到URL,获取请求request
再利用 getAttribute("userid") 获取其userid
检查userid是否存在于LoginList中,不存在则直接返回错误跳转
值得注意的是切勿将错误跳转写到Javascript里面,还返回目标URL页面的相关信息
5.图形验证码漏洞
(1) 图形验证码突破
漏洞介绍:攻击者通过突破图形验证码的验证,可以实现如登录爆破、验证码绕过等攻击
漏洞原理:图形验证码在错误后未失效;返回验证码信息;分步验证验证码
漏洞点:任何存在图形验证码的功能中
漏洞修复:一旦验证码使用过了,必须要进行删除,重新生成验证码。可以放到attribute中;验证码需要设置超时,时间一到立即删除旧验证码,用户需要获取新的验证码;验证码只需要返回图片,切勿将生成验证码的字符串也一并返回;验证码不应该进行分布校验,应该连同请求数据一起发送到目标服务器进行校验,服务器校验通过则返回合法数据,否则返回错误
6.找回密码逻辑漏洞
(1) 密码找回漏洞
漏洞介绍:攻击者通过密码找回逻辑漏洞,可以重置他人账号密码,危害他人账号安全
漏洞原理:其实是验证码漏洞的一种;验证码时间长可爆破;返回重置密码凭证;加密的重置密码凭证
漏洞点:任何密码找回处(可延伸至相似具有验证功能)修改接受校验码目标
漏洞修复:一旦验证码使用过了,必须要进行删除,重新生成验证码,可以放到attribute中;验证码需要设置超时,时间一到立即删除旧验证码,用户需要获取新的验证码
校验凭证不能够随着返回包进行返回;验证码不应该进行分布校验,应该连同请求数据一起发送到目标服务器进行校验,服务器校验通过则返回合法数据,否则返回错误;校验凭证的生成需要进行随机生成,防止凭证破解;用户身份凭证和权限类漏洞修复一样,需要从attribute中获取
7.业务数据篡改漏洞
(1) 业务数据篡改(赋值反冲)
漏洞介绍:攻击者通过进行数值篡改进行攻击,从而获利
漏洞原理:没有对传输数据添加相关的校验参数;后台未对参数值进行校验并直接使用数据包中的参数
漏洞点:抽奖、购买、转账、返现等功能
漏洞修复:
对于软件来说,需要保护好内存数据,防止内存数据篡改
计算传输数据的哈希,并将哈希附加在传输数据中作为校验值,避免被篡改
先校验数值,防止大整数和负数;接着利用传输的商品ID从数据库中获取商品单价重新进行价格计算;最后生成订单(订单号应为随机值)
8.执行顺序逻辑漏洞
(1) 执行顺序篡改
漏洞介绍:攻击者通过篡改分步逻辑中的步骤数字,达到绕过支付、校验等效果
漏洞原理:程序逻辑分布进行,但是对步骤、验证信息、支付信息没有做好严格校验,导致修改步骤就直接绕过验证或者支付
漏洞点:任何分布逻辑且带步骤数字,或者利用JS进行步骤控制的功能中
漏洞修复:
在请求最后一步时候需要带入前面的验证信息,服务端再进行一次校验信息的验证,验证正确方能继续执行数据操作
也可以及通过getAttributr("userid")获取userid进行userid和验证结果绑定,最后一步不带入验证信息,但是仍然要获取userid进行校验
再最后一步通过验证之后或者服务器收到支付信息后再生成相应的数据交给用户
9.其他类型逻辑漏洞
(1) 条件竞争漏洞
漏洞介绍:可以通过同时重放大量数据包进行漏洞利用,通常用于突破限量、限额的问题都有奇效
漏洞原理:由于目标函数中,判断与数据修复两个步骤之间,或者两个数据修改步骤之间存在时间差,且函数未进行同步锁定,则可以造成漏洞
漏洞点:程序中存在限制,可以猜测到后台有判断与修改操作的方法
修复思路:使用synchronized关键字,可以限制同一时间内访问方法的只有单一线程
并不是每个条件竞争都必须修复
(2) 数据包重放漏洞
漏洞介绍:通过数据包重放,可以造成短信轰炸、邮件轰炸、重复提交订单等
漏洞原理:后台未进行相关操作的技术导致数据包重放
漏洞点:短信验证码、邮件校验、提交订单等功能。
修复思路(针对短信、邮件):
构造一个Hashmap<String,short>,存放邮箱或电话号码及对应次数
只要某个邮箱或者电话号码次数够了,就不能继续发送了
或者计算两次发送的时间间隔,时间过短就不继续发送了
通用修复方案,需要建立token机制或验证码机制,一次有效
(3) 参数绑定漏洞
漏洞介绍:通过添加对象字段相关参数进行数据篡改
漏洞原理:对象自动绑定被许多框架支持,它允许将HTTP请求参数自动的绑定到对象,开发者没有对其进行安全校验则容易导致数据篡改
漏洞点:常见的所有输入的地方都会出现这个漏洞,特别是金融、用户、缓存等。
漏洞修复:Spring MVC中可以使用@InitBinder注释,通过WebDataBinder的方法setAllowedFields、setDisallowedFields设置允许或不允许绑定的参数
1.交易
1.修改支付的价格
2.修改支付的状态
3.修改购买数量为负数
4.修改金额为负数
5.重放成功的请求
6.并发数据库锁处理不当
2.业务风控
1.刷优惠劵
2.套现
(2) 账户
1.注册
2.覆盖注册
3.尝试重复用户名
4.注册遍历猜解已有账号
(3)密码
1)密码未使用哈希算法保存
2)没有验证用户设置密码的强度
(4)邮箱用户名
1)前后空格
2)大小写变换
(5)Cookie
1)包含敏感信息
2)未验证合法性可伪造
(6)手机号用户名
1)前后空格
2)+86
(7)登录
1.撞库
a.设置异地登录检查等机制
2.账号劫持
3.恶意尝试账号密码锁死账户
a.需要设置锁定机制与解锁机制
4.不安全的传输信道
5.登录凭证存储在不安全的位置
(8)找回密码
1.重置任意用户密码
2.密码重置后新密码在返回包中
3.Token验证逻辑在前端
4.X-Forwarded-Host处理不正确
5.找回密码功能泄露用户敏感信息
⑧ 修改密码
1)越权修改密码
2)修改密码没有旧密码验证
⑨ 申诉
1)身份伪造
2)逻辑绕过
⑩ 更新
1)ORM更新操作不当可更新任意字段
2)权限限制不当可以越权修改
(11)信息查询
1.权限限制不当可以越权查询
2.用户信息ID可以猜测导致遍历
3. 2FA
1.重置密码后自动登录没有2FA
2.OAuth登录没有启用2FA
3.2FA可爆破
4.2FA有条件竞争
5.修改返回值绕过
6.激活链接没有启用2FA
7.可通过CSRF禁用2FA
4. 验证码
1.验证码可重用
2.验证码可预测
3.验证码强度不够
4.验证码无时间限制或者失效时间长
5.验证码无猜测次数限制
6.验证码传递特殊的参数或不传递参数绕过
7.验证码可从返回包中直接获取
8.验证码不刷新或无效
9.验证码数量有限
10.验证码在数据包中返回
11 修改Cookie绕过
12 修改返回包绕过
13 验证码在客户端生成或校验
14 验证码可OCR或使用机器学习识别
15 验证码用于手机短信/邮件轰炸
5.Session
1.Session机制
2.Session猜测/爆破
3.Session伪造
4.Session泄露
5.Session Fixation
6.越权
1.未授权访问
2.静态文件
3.通过特定url来防止被访问
(2)水平越权
1.攻击者可以访问与其他拥有相同权限的用户的资源
2.权限类型不变,ID改变
(3)垂直越权
1.低级别攻击者可以访问高级别用户的资源
2.权限ID不变,类型改变
(4)交叉越权
1.权限ID改变,类型不变
7.随机数安全
1.使用不安全的随机数发生器
2.使用时间等易猜解的因素作为随机数种子
8.其他
1.用户/订单/优惠劵等ID生成有规律,可枚举
2.接口无权限、次数限制
3.加密算法实现误用
4.执行顺序
5.敏感信息泄露
★
欢 迎 加 入 星 球 !
代码审计+免杀+渗透学习资源+各种资料文档+各种工具+付费会员
进成员内部群
星球的最近主题和星球内部工具一些展示
关 注 有 礼
还在等什么?赶紧点击下方名片关注学习吧!
推荐阅读