第一次上传
This commit is contained in:
375
02.WEB安全/14.逻辑漏洞.md
Normal file
375
02.WEB安全/14.逻辑漏洞.md
Normal file
@@ -0,0 +1,375 @@
|
||||
# 14.逻辑漏洞
|
||||
|
||||
## 1. 业务逻辑漏洞
|
||||
|
||||
#### 1.1 漏洞成因
|
||||
|
||||
逻辑错误漏洞是指由于程序逻辑不严谨或逻辑太复杂，导致一些逻辑分支不能够正常处理或处理错误。通俗地讲，一个系统的功能太多后，程序开发人员难以思考全面，对某些地方可能有遗漏，或者未能正确处理，从而导致逻辑漏洞。逻辑漏洞也可以说是程序开发人员的思路错误、程序开发人员的逻辑存在漏洞。
|
||||
|
||||
#### 1.2 特性
|
||||
|
||||
逻辑漏洞非常隐蔽，危害巨大，且无法被 WAF 等安全设备拦截。逻辑漏洞覆盖面很广，一直以来对于逻辑漏洞尚未产生明确的分类。其大致包括了：绕过功能限制、遍历、越权、弱口令、信息泄漏、任意用户密码重置、竞争性问题等。在一些场景下，由于功能本身设计复杂、易于出现纰漏，导致针对特定场景下的特定逻辑漏，如支付漏洞、验证码绕过漏洞等。
|
||||
|
||||
## 2. 账户
|
||||
|
||||
### 2.1 注册账户
|
||||
|
||||
#### 2.1.1 注册覆盖
|
||||
|
||||
注册重复用户名对用户数据进行覆盖
|
||||
|
||||
#### 2.1.2 注册遍历
|
||||
|
||||
进行注册的时候注册重复的用户名会提示用户名已被注册，我们可以利用该方法猜测用户名。如果可以批量提交，将会产生严重问题。
|
||||
|
||||
### 2.2 登陆账户
|
||||
|
||||
#### 2.2.1 登陆认证绕过
|
||||
|
||||
##### 2.2.1.1 直接访问登陆后的界面
|
||||
|
||||
一般登陆界面登陆成功后会进行跳转到主页面，例如：main.php。但是如果没有对其进行校验的话，可以直接访问主页面绕过了登陆认证。
|
||||
|
||||
##### 2.2.1.2 前端认证
|
||||
|
||||
登陆状态如果只以登陆状态码进行判断登陆成功标识，那么修改登陆状态码就能进行登录。
|
||||
|
||||
##### 2.2.1.3 暴力破解
|
||||
|
||||
暴力破解，又叫撞库、穷举，使用大量的字典逐个在认证接口尝试登录，理论上，只要字典足够强大，破解总是会成功的。
|
||||
撞库：黑客从别的站点获取到用户名和密码，然后用于爆破别的系统。
|
||||
阻止暴力破解的最有效方式是设置复杂度高的密码（英文字母大小写、数字、符号混合）并且同时设置验证码使其无法批量提交数据。
|
||||
靶场地址：dvwa
|
||||
打开 burpsuite 抓包
|
||||
输入任意用户名和密码，点击 login
|
||||
|
||||
|
||||
|
||||
将抓到的包发送到 Intruder 模块
|
||||
|
||||
|
||||
|
||||
Clear 原来的 tag，选择 Cluster bomb 模式
|
||||
|
||||
|
||||
|
||||
为 username 和 password 添加 tag
|
||||
|
||||
|
||||
|
||||
设置 payload，加载字典，设置完成后点击 Start Attack
|
||||
|
||||
|
||||
|
||||
根据长度判断用户名密码应该是 admin/password
|
||||
|
||||
|
||||
|
||||
##### 2.2.1.4 身份凭证可伪造
|
||||
|
||||
当用户登录后，在服务器就会创建一个会话（session），叫做会话控制，接着访问页面的时候就不用登录，只需要携带对应的 cookie 去访问。如果 cookie、session 等代表用户身份的凭证被设置的过于简单，或者有一定规律，就可以被黑客猜测出来，从而修改、伪造身份。
|
||||
靶场地址：DVWA
|
||||
Low：cookie 里面有一个 dvwaSession 的字段，点一下 Generate value 就 +1
|
||||
|
||||
|
||||
|
||||
Medium：dvwaSession 是个时间戳
|
||||
|
||||
|
||||
|
||||
High：dvwaSession 是经过 md5 加密的，但是过于简单可被破解
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### 2.2.2 验证码
|
||||
|
||||
##### 2.2.2.1 图形验证码
|
||||
|
||||
###### 2.2.2.1.1 前端可以获取验证码
|
||||
|
||||
验证码直接出现在 html 源码中或者隐藏在 Cookie 中，或者验证码使用前端校验
|
||||
靶场地址：pikachu
|
||||
查看前端 JS 源码，发现验证码是使用的前端 JS 校验，**前端校验等于没有校验**，解法有如下几种：
|
||||
|
||||
- 因为验证码是前端校验的，可以抓包删除掉验证码
|
||||
|
||||
抓取登录包，发送到 Repeater 模块
|
||||
|
||||
|
||||
|
||||
删除掉验证码，重放，发现返回包的长度和删除验证码之前是一样的
|
||||
|
||||
|
||||
|
||||
删除掉验证码，重放
|
||||
|
||||
|
||||
|
||||
- 直接删除掉 JS 代码或者禁用 JS
|
||||
-
|
||||
|
||||
###### 2.2.2.1.2 **图形验证码可识别**
|
||||
|
||||
这种验证码由于没有对其做模糊处理，导致可以利用脚本直接识别
|
||||
|
||||
1. OCR 识别
|
||||
2. xp_CAPTCHA 4.2 - Burp验证码识别插件
|
||||
|
||||
免费版：[https://github.com/smxiazi/NEW_xp_CAPTCHA](https://github.com/smxiazi/NEW_xp_CAPTCHA)
|
||||
收费版：[https://github.com/smxiazi/xp_CAPTCHA](https://github.com/smxiazi/xp_CAPTCHA)
|
||||
|
||||
###### 2.2.2.1.3 验证码重复利用
|
||||
|
||||
有的网页只要不刷新，验证码就能重复被利用。通常情况下，系统会比对 session 和用户输入的验证码值,当服务器端受理请求后,没有将上一次保存的 session 及时清空,将会导致验证码可重复使用
|
||||
修复建议：当服务器端处理完一次用户提交的请求之后,及时将 session 域中的验证码清除,并生成新的验证码。
|
||||
靶场地址：pikachu
|
||||
使用 burpsuite 抓包，开启 Intercept
|
||||
|
||||
|
||||
将抓到的包发送到 Repeater 模块，反复重放，发现返回包长度并没有变化，页面提示也是用户名或密码不存在，猜测验证码可以反复使用
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
将抓到的包发送到 Intruder 模块进行爆破
|
||||
|
||||
|
||||
|
||||
跑出密码为 123456
|
||||
|
||||
|
||||
|
||||
|
||||
##### 2.2.2.2 短信验证码
|
||||
|
||||
1. 短信验证码可重复利用
|
||||
|
||||
如果服务端未对短信验证码的验证时间/次数进行限制，那么我们就可以利用其进行爆破。
|
||||
此处测试方法等同图片验证码的测试
|
||||
|
||||
2. 短信验证码与用户未绑定
|
||||
|
||||
一般来说短信验证码仅能供自己使用一次，如果验证码和手机号未绑定，那么就可能出现如张三的手机的验证码，李四可以拿来用的情况。
|
||||
|
||||
修复建议：
|
||||
作为一个安全的短信验证码，他的设计要求应该满足如下几点：
|
||||
用户获取的短信验证码只能够供自己使用
|
||||
用户短时间内获取的多条短信只有最新的一条能使用
|
||||
短信验证码设置为6位数，有效期30分钟甚至更短，当验证码失败3次后失效。
|
||||
|
||||
### 2.3 密码找回/修改
|
||||
|
||||
找回密码的验证码为四位数字可爆破真实验证码；
|
||||
采用本地验证,可以先尝试修改自己的帐号密码，保存正确的返回包，然后修改他人密码的时候替换返回包；
|
||||
最终修改密码的数据包，以另外的ID作为身份判断（例如userid），而该ID在别处可以获取到；
|
||||
接受验证码的手机号修改为自己的号码，然后输入自己的号码接收到的验证码去进行密码重置；
|
||||
获取验证码的时候，会生成一个身份标识（例如cookie值），那么我们就替换他人账号的身份标识重置他人的密码；
|
||||
|
||||
#### 2.3.1 找回密码
|
||||
|
||||
##### 2.3.1.1 短信找回密码
|
||||
|
||||
类似短信验证码可以重复使用，攻击者就可以修改用户的密码。短信验证码未与用户绑定，攻击者可以利用其他用户的包来修改本用户的密码。
|
||||
|
||||
##### 2.3.1.2 用户名找回密码
|
||||
|
||||
随便输入一个用户他有一个包检验用户是否存在，这里回显了用户全部信息。
|
||||
这里的问题在于查询用户处，回显了多余的个人信息。
|
||||
|
||||
##### 2.3.1.3 邮箱找回密码
|
||||
|
||||
如果邮件中的重置密码链接未使用 token参数让链接具有唯一性，或者是 token 可预测，会导致链接可以直接被猜解访问。重置时验证码过于简单，如纯 4 位数字，则容易遭受验证码被穷举风险。
|
||||
|
||||
###### 2.3.1.3.1 cms 实战
|
||||
|
||||
靶场地址：semcms
|
||||
源码分析
|
||||
lnlq_Admin/index.html 文件
|
||||
从代码可以看到，当点击登录按钮旁边的链接"如果忘记账号与密码，试试找回？"，时，会执行 js 的 views() 函数，该函数是弹出一个对话框并向SEMCMS_Remail.php?type=find 发送请求，让用户填写要接收重置后密码的邮箱地址
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
点击确认找回，提交到了这个 URL
|
||||
|
||||
```php
|
||||
../Include/web_email.php?type=fintpassword
|
||||
```
|
||||
|
||||
查看找回密码的代码，代码会根据用户输入的 E-mail 地址，查找 sc_user 表，看是否存在使用该 E-mail 地址的用户，如果存在，则随机生成 4 位数的认证码，并将其拼接到一个密码重置链接中，最后以邮件的形式发送给用户。用户点击邮件中的密码重置链接即可；但如果不存在，则弹出对话框，提示“此邮箱不存在！”
|
||||
|
||||
|
||||
|
||||
认证码是随机的四位纯数字，很容易联想到爆破，但是每次重新进入到这里的时候认证码就会随机生成，难以利用。再回到 index.html 中
|
||||
|
||||
|
||||
|
||||
当请求参数 type=ok 时，SEMCMS_Remail.php 后面跟的参数 type 也是ok，而前面提到，这种情况下，SEMCMS_Remail.php 会构造另外一个表单，如下：
|
||||
|
||||
|
||||
|
||||
点击确认找回按钮，数据提交到
|
||||
|
||||
```php
|
||||
../Include/web_email.php?type=findok
|
||||
```
|
||||
|
||||
web_email 部分密码找回部分的代码如下
|
||||
|
||||
|
||||
|
||||
密码是经过 md5 加密后才存入数据库的，但是如果认证码正确就能将密码改掉。尝试使用 burpsuite 爆破这里的认证码从而修改掉密码
|
||||
查看数据库，原先的密码是 1234
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
使用 burpsuite 跑包，抓取重置密码的包，验证码处添加 tag，进行爆破
|
||||
|
||||
|
||||
|
||||
验证码正确与否，返回包长度和状态码都是一样的
|
||||
|
||||
|
||||
|
||||
查看数据库，密码已经变成了我们改的数据 11111
|
||||
|
||||
|
||||
|
||||
|
||||
##### 2.3.1.4 越权修改密码
|
||||
|
||||
有时候开发再写代码时，会直接用到某一参数直接调取该参数对应的数据，而再调用时并不考虑当前登陆用户是否有权限调用。这就导致了，可以利用抓该包工具，将传递给后台的数据进行修改，修改后可以查看原本自己没有权限看到内容。
|
||||
|
||||
##### 2.3.1.5 修改密码未验证旧密码
|
||||
|
||||
修改密码前应该先对用户身份进行再次校验，如验证旧密码。
|
||||
|
||||
## 3. 交易
|
||||
|
||||
### 3.1 购买
|
||||
|
||||
#### 3.1.1 支付逻辑漏洞
|
||||
|
||||
##### 3.1.1.1 靶场练习
|
||||
|
||||
靶场地址：
|
||||
访问 niushop，登录。选择任意一件商品购买，提交订单。
|
||||
|
||||
|
||||
|
||||
打开 burpsuite，再选择一件商品，开启 intercept 拦截数据包，点击立即购买，将数量改为 0.001
|
||||
|
||||
|
||||
|
||||
数量真的变成了 0.001，相应价格也变成了 0.1 元
|
||||
|
||||
|
||||
|
||||
点击提交订单，生成一个价格为 0.1 的订单。点击去支付
|
||||
|
||||
|
||||
|
||||
记下支付流水号
|
||||
|
||||
|
||||
回到刚刚第一个数量正常的订单，开启 intercept 拦截数据包，点击去支付
|
||||
|
||||
|
||||
将此处的支付流水号改为刚刚我们记录下来的流水号
|
||||
|
||||
|
||||
放包，发现支付流水号变成了刚刚的，订单金额也变成了 0.1
|
||||
|
||||
|
||||
|
||||
## 4. 越权
|
||||
|
||||
### 4.1 未授权访问
|
||||
|
||||
### 4.2 越权访问
|
||||
|
||||
该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得低权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定。越权访问漏洞主要分为水平越权访问和垂直越权访问。
|
||||
|
||||
#### 4.2.1 水平越权
|
||||
|
||||
定义：水平越权就是相同级别(权限)的用户或者同一角色的不同用户之间，可以越权访问、修改或者删除的非法操作。
|
||||
危害：如果出现此类漏洞，那么可能会造成大批量数据泄漏，严重的甚至会造成用户信息被恶意篡改
|
||||
挖掘思路：替换鉴权参数，定位出鉴权参数，然后替换为其他账户鉴权参数的方法来发现越权漏洞
|
||||
假设用户A和用户B属于同一角色，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫做水平越权访问。
|
||||
|
||||
##### 4.2.1.1 靶场练习
|
||||
|
||||
靶场地址：pikachu
|
||||
先登录，点击提示有用户名和密码
|
||||
|
||||
|
||||
|
||||
登录了 lucy 的号，查看个人信息
|
||||
|
||||
|
||||
|
||||
将名字改成 lili，个人信息也变成 lili 的了
|
||||
|
||||
|
||||
|
||||
#### 4.2.2 垂直越权
|
||||
|
||||
垂直越权是一种“基于URL的访问控制”设计缺陷引起的漏洞，又叫做权限提升攻击。
|
||||
由于后台应用没有做权限控制，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。
|
||||
|
||||
##### 4.2.2.1 靶场练习
|
||||
|
||||
登录管理员用户
|
||||
|
||||
|
||||
|
||||
管理员有添加用户功能
|
||||
|
||||
|
||||
|
||||
尝试添加一个用户
|
||||
|
||||
|
||||
|
||||
用 burpsuite 抓取添加用户的包并且发送到 repeater
|
||||
|
||||
|
||||
|
||||
退出管理员用户，登录普通用户，抓取普通用户的 cookie，并且替换刚刚抓取的修改密码的包的对应 cookie 位置
|
||||
|
||||
|
||||
|
||||
重放
|
||||
|
||||
|
||||
|
||||
以普通用户身份添加用户成功
|
||||
|
||||
|
||||
|
||||
##### 4.2.2.2 cms 实战
|
||||
|
||||
靶场地址：熊海 cms
|
||||
[http://d22.s.iproute.cn/admin/?r=login](http://d22.s.iproute.cn/admin/?r=login)
|
||||
|
||||
源码分析，如果 cookie 为空，则跳转到登录页面
|
||||
|
||||
|
||||
|
||||
访问靶场，右键检查，查看 cookie，此处 cookie 为空，尝试伪造任意一个 cookie
|
||||
|
||||
|
||||
|
||||
可以直接访问 [http://d22.s.iproute.cn/admin/?r=index](http://d22.s.iproute.cn/admin/?r=index) 读取后台内容
|
||||
|
||||
|
||||
|
||||
如果将 cookie value 改成 admin，能够以管理员身份访问
|
||||
|
||||
|
||||
Reference in New Issue
Block a user