常见逻辑漏洞总结

常见逻辑漏洞

简介

逻辑漏洞是指由于程序逻辑不严导致一些逻辑分支处理错误造成的漏洞。 在实际开发中，因为开发者水平不一没有安全意识，而且业务发展迅速内部测试没有及时到位，所以常常会出现类似的漏洞。

1.账户

1.1注册账户

1.1.1 注册覆盖

注册重复用户名对用户数据进行覆盖
对于注册页面覆盖注册是指原来用一个手机号已经注册了账号，但是由于漏洞，导致可以再利用该手机号进行注册，并且会将之前注册的记录覆盖！

当我们用已经注册了的账号准备再注册时，发现会提示该手机号码已经存在！

我们抓包，发现后端检测该手机号已经注册了的话，会返回 true。如果检测该手机号没注册的话，会返回false。

修改回传参数，达到重复注册目的。

修复建议：对注册的用户数据进行审核，禁止覆盖数据库已经存在的用户名

1.1.2 注册遍历

进行注册的时候注册重复的用户名会提示用户名已被注册，我们可以利用该方法猜测用户名

1.2 登陆账户

1.2.1 登陆认证绕过

1. 直接访问登陆后的界面
一般登陆界面登陆成功后会进行跳转到主页面，例如：main.php。但是如果没有对其进行校验的话，可以直接访问主页面绕过了登陆认证。
2. 前端认证
登陆状态如果只以登陆状态码进行判断登陆成功标识，那么修改登陆状态码就能进行登录。
对登陆状态抓包：

修改这里的code值,修改成1，放行成功登入

修复建议 ：对账户登陆添加认证机制，可以在用户在登陆成功时应该设置一个有时效性的登陆唯一标识中。如：session

1.2.2 验证码

1.2.2.1 图形验证码

1. 前端可以获取验证码
验证码一般直接出现在html源码中或者隐藏在Cookie中

2. 图形验证码可识别
这种验证码由于没有对其做模糊处理，导致可以利用脚本直接识别

3. 验证码重复利用
有的网页只要不刷新，验证码就能重复被利用。通常情况下，系统会比对session和用户输入的验证码值,当服务器端受理请求后,没有将上一次保存的session及时清空,将会导致验证码可重复使用

重复利用验证码进行密码爆破：

修复建议：当服务器端处理完一次用户提交的请求之后,及时将 session域中的验证码清除,并生成新的验证码。

1.2.2.2 短信验证码

1. 短信验证码可重复利用
如果服务端未对短信验证码的验证时间/次数进行限制，那么我们就可以利用其进行爆破。

修复建议： 服务端要对验证码的验证时间和次数进行限制

2. 短信验证码与用户未绑定
一般来说短信验证码仅能供自己使用一次，如果验证码和手机号未绑定，那么就可能出现如下张三的手机的验证码，李四可以拿来用的情况。

修复建议：
作为一个安全的短信验证码，他的设计要求应该满足如下几点：

• 用户获取的短信验证码只能够供自己使用
• 用户短时间内获取的多条短信只有最新的一条能使用
• 短信验证码设置为6位数，有效期30分钟甚至更短，当验证码失败3次后失效。

1.3 密码找回/修改

1. 找回密码的验证码为四位数字可爆破真实验证码；
2. 采用本地验证,可以先尝试修改自己的帐号密码，保存正确的返回包，然后修改他人密码的时候替换返回包；
3. 最终修改密码的数据包，以另外的ID作为身份判断（例如userid），而该ID在别处可以获取到；
4. 接受验证码的手机号修改为自己的号码，然后输入自己的号码接收到的验证码去进行密码重置；
5. 获取验证码的时候，会生成一个身份标识（例如cookie值），那么我们就替换他人账号的身份标识重置他人的密码；

1.3.1 找回密码

1.3.1.1 短信找回密码

类似1.2.2.2 如短信验证码可以重复使用，攻击者就可以修改用户的密码。短信验证码未与用户绑定，攻击者可以利用其他用户的包来修改本用户的密码。

1.3.1.2 用户名找回密码

随便输入一个用户 他有一个包检验用户是否存在，这里回显了用户全部信息。
这里的问题在于查询用户处，回显了多余的个人信息。

1.3.1.3 邮箱找回密码

1. 链接弱token可伪造
这种一般都是找回密码链接处对用户标识比较明显，弱token能够轻易伪造和修改

• 基于用户id标识 例如:http://xxx.com/member/getbackpasswd.html?sendTime=MjAxOC0wNC0wNyAxMjozOQ==&userValue=bGlsZWlAdnNyYy5jb20= 这里使用的是base64编码sendTime = 2018-04-07 12:39``````userValue为 = [email protected] 知道构造方式了 我们就可以自己构造找回密码的链接了
• 基于服务器时间 例如http://xxx.com/member/[email protected]&startClickTime=20180810105628 这里startClickTime = 20180810105628，我们不确定服务器时间时候，可以在同一时间同时重置账户甲和账户乙，根据账户甲收到的url中token值来推断乙对应的值

1.3.2 修改密码

1.3.2.1 越权修改密码

有时候开发再写代码时，会直接用到某一参数直接调取该参数对应的数据，而再调用时并不考虑当前登陆用户是否有权限调用。这就导致了，可以利用抓该包工具，将传递给后台的数据进行修改，修改后可以查看原本自己没有权限看到内容。

这个后台我们本来是管理员权限，正常情况下用户管理的数据包id=5。而我们将数据包id改为1，修改以后发现调出了admin界面

这样我们就可以越过权限去修改超管账户。

修复建议： 在每次调用用户数据时必须检验当前登陆用户是否有权限调用

1.3.2.2 修改密码未验证旧密码

输入正确旧密码和新密码，可成功修改密码。

再尝试输入错误的旧密码，看系统是否会对输入的旧密码进行判断正误

可以看到，使用错误密码也能成功修改账户密码,没有对账户的旧密码进行正误判断。
因此我们可以通过修改id参数的值，再利用错误密码也可修改密码这个漏洞进行任意用户密码修改。

2. 交易

2.1 购买

2.1.1修改支付的价格

案例：
顺丰宝存在支付逻辑漏洞，可以允许用户1元变1亿元。原因是页面交互都使用了对字段做签名。但是顺丰宝没做签名，导致支付金额可以被修改为任意数值。
充值，填写充值金额1

开启firefox的tamper，点击支付，截取数据包，修改参数Amount为一分

支付成功后，招行扣去一分

修改支付的状态
修改购买数量为负数
修改金额为负数
重放成功的请求

3. 越权

3.1 未授权访问

一、MongoDB 未授权访问漏洞
漏洞信息
(1) 漏洞简述开启 MongoDB 服务时若不添加任何参数默认是没有权限验证的而且可以远程访问数据库登录的用户无需密码即可通过默认端口 27017 对数据库进行增、删、改、查等高危操作。刚安装完毕时MongoDB 都默认有一个 admin 数据库此时 admin 数据库为空没有记录权限相关的信息。当 admin.system.users 一个用户都没有时即使 MongoDB 启动时添加了 –auth 参数还是可以做任何操作不管是否以 –auth 参数启动直到在 admin.system.users 中添加了一个用户。

检测方法
可以自己编制相应脚本或利用专用工具检测也可以查看配置文件

(1) 检测是否仅监听 127.0.0.1

--bind_ip 127.0.0.1
or
vim /etc/mongodb.conf
bind_ip = 127.0.0.1

(2) 检测是否开启 auth 认证

mongod --auth
or
vim /etc/mongodb.conf
auth = true

修复方法
(1) 为 MongoDB 添加认证
① MongoDB 启动时添加 -auth 参数。
② 给 MongoDB 添加用户

(3) 限制绑定 IP

启动时加入参数
–bind_ip 127.0.0.1
或在 /etc/mongodb.conf 文件中添加以下内容
bind_ip = 127.0.0.1

3.2越权访问

该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得低权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定。越权访问漏洞主要分为水平越权访问和垂直越权访问。

3.2.1 水平越权

水平越权访问是一种“基于数据的访问控制”设计缺陷引起的漏洞。由于服务器端在接收到请求数据进行操作时没有判断数据的所属人/所属部门而导致的越权数据访问漏洞。
假设用户A和用户B属于同一角色，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫做水平越权访问。

• 如：getAddress.do?addressId=12345 攻击者修改addressId即可得到他人的address信息。

3.2.2 垂直越权

垂直越权是一种“基于URL的访问控制”设计缺陷引起的漏洞，又叫做权限提升攻击。
由于后台应用没有做权限控制，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。

将超管的包里的cookie替换成普通管理员，也能成功执行，从而达到垂直越权的目的