业务 Web 漏洞攻击与防御的思考

随着网络安全观念的进一步强化，以及在开发过程中越来越成熟的自动化防护机制使得基础 web 漏洞的挖掘和利用变得越来越困难，所以加强对业务安全逻辑漏洞的学习和利用变得尤其重要，这篇文章也算是我学习和思考的一个记录。

0X01 为什么学习业务安全

其实除了我个人在实战中深刻的体会到基础 Web 漏洞的挖掘困难以外(常常是 xss 或者 csrf之类的，sqli 都少之又少)，我还从一些安全事件(比如 pdd 的百元优惠券)中发现业务逻辑的安全漏洞可能造成的危害更大，涉及到的经济利益也更多，这也成为了不法分子重点关注的对象，我们作为安全研究人员也要重点学习研究。

0X02 业务安全测试的一般流程

1.前期熟悉

要去了解当前系统的规模、已经具备的安全措施、系统的部署情况等

2.场景建模

掌握重要的系统功能，并将每个系统功能划分成待测试的模块，如下图所示

3.功能梳理

对每个不同的模块的运作流程进行梳理，通常分为以下两个维度：

(1)用户端、管理员端

(2)客户端、服务器端

如下图：

4.风险分析

可能存在的风险点如下图

(1)业务环节存在的风险

主要是用户可见的，如注册登录等是否有完善的身份验证机制，cookie session 机制，验证码能否被爆破等

(2)支撑系统存在的风险

用户访问控制机制是否完善，是否存在水平或垂直越权，用户数据是否加密存储，是否明文传输，是否存在未授权的接口调用，重放遍历等

(3)业务环节间存在的风险

业务流程是否存在乱序，是否可以跳过、回退或者是重放。环节间的数据传输是否有一致性校验以及加密机制，是否可以被监听、窃取、篡改或者重放。

(4)支撑系统间存在的风险

系统间传递的参数是否加密，是否能监听窃取或者篡改，是否有着完备的过滤机制来预防 SQLi XSS 等攻击

(5)业务环节与支撑系统间存在的风险

数据传输是否加密，是否用不完善的加密机制(如：前端加密，简单的md5等),是否能比较好的处理请求的并发，防止出现条件竞争，是否有完善的过滤和编码机制预防 SQLi XSS 等攻击。

5.开始测试

手工与自动化 工具 结合，白盒和黑盒相结合的方式进行测试

6.撰写报告

根据不同企业或者公司的要求进行撰写，详细说明漏洞点，触发条件以及修复建议等

0X03 业务测试技术

1.登录认证模块

(1)暴力破解

[测试方法]

常常使用 Bp 结合字典对账号密码进行暴力破解

注意：

1.intercept is on 关闭的时候浏览器的请求依然会经过 Bp 只是不被拦截，所有的请求可以在 history 中查看

[修复建议]

1.设置登录验证码，并在尝试登录后改变，同时验证码的强度不能过低，防止攻击者使用 OCR 识别

2.设置登录失败次数限制，相同用户五分钟内失败6次则三小时内禁止登录

3.可增加手机短信校验等辅助校验方式

(2)本地加密传输测试

[测试方法]

(1)首先查看是否使用了 SSL(HTTPS)，如果没有使用 SSL 的话，使用 Bp 获登录数据包，查看是否存在明文传输，如图所示

此时可判定存在风险

(2)如果是使用了 SSL 可以使用 wireshark 抓包看一下是不是真的加密了，如图所示

[修复建议]

1.部署有效的 SSL 证书

2.及时部署了 SSL 也尽可能不要使用纯明文传输，降低被攻击的风险

(3)Session测试

1.Session 会话固定测试

[漏洞原理]

在用户进入登录页面，但还未登录时，就已经产生了一个session，用户输入信息，登录以后，session的id不会改变，也就是说没有建立新session，原来的session也没有被销毁）。攻击者事先访问系统并建立一个会话，诱使受害者使用此会话登录系统，然后攻击者再使用该会话访问系统即可登录受害者的账户。会话固定攻击的原理及流程如下图所示：

[测试方法]

(1)打开登录页面

(2)使用 Bp 查看登录前的 cookie 中的 SESSID(如果没有可以尝试登录然后伪造一个)，登陆后再查看 SESSID 如果没有更新则说明存在该漏洞

[修复建议]

在用户输入正确的用户名和密码以后(用户的权限级别发生了变化)，系统需要强制更新 SESSION，并强制原始会话失效。

2.Session 会话注销测试

[漏洞原理]

在用户退出登录或者注销之后，服务端应将用户的会话标识 SESSID 在服务端立即注销，如果不及时注销，将导致其在退出后依然有效，攻击者在非法获取其标识符后可进行无认证登录

[测试方法]

登陆后使用 Bp 截获数据包，然后退出登录后，对该数据包进行重放，如果重放成功则证明漏洞存在

[修复建议]

退出登录后服务端应及时清除 SESSION 会话标识符，并清空客户端浏览器的 SESSID

3.Session 会话超时测试

[漏洞原理]

客户登陆后如果长时间与服务器没有交互操作，session 应在规定的时间内自动失效，并要求重新登录，否则可能会存在信息泄露风险。

[测试方法]

登陆后使用 Bp 截获数据包，然后等待20~30分钟，对该数据包进行重放，如果重放成功则证明漏洞存在。

[修复建议]

建议设置会话的生存时间不要超过30分钟

(4)Cookie 伪造测试

[漏洞原理]

服务端为了鉴别用户身份将用户的身份信息存储在 cookie 中并通过浏览器存储在用户本地的文件中，但这些信息是明文存储的，攻击者一旦通过某种攻击手段获取了用户的 cookie 就可以篡改用户的信息然后伪装成其他用户甚至是更高权限的用户进行登录。

[测试方法]

通过 Bp 抓包然后，尝试修改用户的 cookie 部分内容，比如修改用户 id 或者用户名等，然后重放，看是否能未授权访问其他用户信息

[修复建议]

使用 session 机制解决，并设置 cookie 为 http-only ,设置 cookie 的 secure 属性(至于 cookie 和 session 机制的比较请看我的这篇文章 )

(5)密文比对认证测试

[漏洞原理]

一般网站在输入密码以后会在服务器端进行 hash 加密然后再与数据库中的信息进行比对来判断密码正误，但是有些网站的在输入密码以后会在客户端本地(前端)进行 hash 加密然后再传到服务器端进行验证，这样就会泄露加密方式和密钥信息。

[测试方法]

使用 Bp 检查传输的密码的形式是不是经过了加密，然后我们可以去前端寻找有没有对应的前端加密代码，并判断加密方式和使用的密钥，然后我们可以对密码字典进行对应的加密以后再进行暴力破解

[修复建议]

请不要使用前端对密码进行加密的方式，加密处理要放在后台进行。

(6)登录失败信息测试

[漏洞原理]

在登录失败时会明确提示 用户名错误或者密码错误的信息，而不是模糊的用户名密码错误，这样攻击者就能通过返回的信息对用户名和密码进行暴力破解

[测试方法]

使用正确的账号登录时输入错误的密码，看返回信息是否是密码错误，如果是则说明漏洞存在。

[修复建议]

不管是用户名错误还是密码错误都不能明确的提示，返回统一的提示 “用户名或密码错误”

2.业务办理模块

(1)订单ID篡改测试

[漏洞原理]

攻击者只要注册一个普通用户的账号就能通过遍历订单的 ID 来越权查看其它用户的订单，其中可能包含用户的身份证信息，家庭住址，电话等敏感信息。

[测试方法]

通过抓包查看是否可以有订单号信息可以直接修改等进行越权测试

[修复建议]

查看订单的时候要通过 session 校验查看订单者的身份，防止平行越权

(2)手机号码篡改测试

[漏洞原理]

有时候手机号码作为鉴定用户身份的参数，在登录成功以后，开发者可能对一些页面的身份校验出现缺失，这样就可以通过篡改用户的手机号来进行越权

[测试方法]

通过抓包查看是否可以有手机号信息可以直接修改从而进行越权测试

[修复建议]

通过 session 来校验身份，防止平行越权，另外对于APP，不要完全相信从手机中读取的手机号，要做好完善的身份认证。

(3)用户ID篡改测试

[漏洞原理]

有时候用户 ID 作为鉴定用户身份的参数，在登录成功以后，开发者可能对一些页面的身份校验出现缺失，这样就可以通过篡改用户的手机号来进行越权

[测试方法]

通过抓包查看是否可以有手机号信息可以直接修改从而进行越权测试

[修复建议]

通过 session 判断用户的身份，不要轻易相信用户传过来的 ID ，如果想通过 id 判断，那也要与 session 进行对比

(4)邮箱和用户篡改测试

[漏洞原理]

发送邮件的时候篡改其中的发件人参数可能会使得攻击者伪造发件人进行钓鱼攻击，

[测试方法]

通过抓包查看是否可以有发件人信息可以直接修改从而进行伪造

[修复建议]

发消息时要通过 session 判断用户的身份，只有 发件人 id 和 session 一致的时候服务器才会接受该邮件

(5)商品编号篡改测试

[漏洞原理]

在生成订单跳转支付页面的时候，如果抓包可以篡改商品的金额，那么就能实现小金额购买商品，同样，除了篡改金额，还能够篡改商品的编号，即使用一个商品的价格来购买另一件商品。

[测试方法]

通过抓包查看是否可以有金额或者商品编号信息可以直接修改从而进行伪造

[修复建议]

商品的金额不要在客户端传入，防止被恶意篡改，如果必须在客户端输入，交易之前必须要验证

(6)条件竞争测试

[漏洞原理]

在服务端逻辑与数据库读写存在时序问题时，可能会存在条件竞争，攻击者可以多线程并发请求，在数据库余额更新以前多次兑换积分或者购买商品。

[测试方法]

攻击者在提交订单的时候抓包，并使用多线程的方式重放此包，部分包就可能绕过金额和次数的判断从而请求成功。

[修复建议]

处理订单业务的时候使用锁的方式，保证业务的原子性

3.业务授权访问模块

(1)未授权访问测试

[漏洞原理]

用户在没有授权的情况下能直接访问需要授权才能访问的页面，

[测试方法]

尝试在登录后台等需要授权访问的页面以后，把 URL 复制到别的浏览器中看是否能访问成功

[修复建议]

对需要权限的页面进行 SESSION 认证，对用户访问的每一个 URL 做身份鉴别，正确校验用户的身份和 token

(2)越权测试测试

[漏洞原理]

水平越权：普通用户之间操作可互相影响

垂直越权：低权限用户能操作高权限用户才能操作的东西

[测试方法]

Bp 抓包查看并修改低权限用户的身份信息为同等权限的其他用户或者是高权限用户后进行重放，如果成功则说明漏洞存在

[修复建议]

对需要权限的页面进行 SESSION 认证，对用户访问的每一个 URL 做身份鉴别，正确校验用户的身份和 token

4.回退模块测试

(1)回退访问测试

[漏洞原理]

很多 web 应用存在修改密码等模块，那么在修改成功后点击浏览器的回退按钮，发现依然能重复之前的操作，这样就破坏了分步骤进行

[测试方法]

很多 web 应用存在修改密码等模块，那么在修改成功后点击浏览器的回退按钮，发现依然能重复进行的就说明存在漏洞

[修复建议]

对于业务流程有多步的情况，收下判断该步的请求是不是由上一步发起的，如果不是则返回错误或者是页面失效

5.验证码机制测试

(1)验证码暴力破解测试

[漏洞原理]

有些验证码是 4~6 位数字，或者是有一定可控区间的数字字符，如果没有设置好验证码的失效时间或者最大的尝试次数吗，那么攻击者就可以对其进行暴力破解。

[测试方法]

Bp 抓取填写验证码的数据包，然后对其进行暴力破解攻击，如果在跑了数十个可能的值以后返回值没有出现失效或者出错的问题的话，那么判断漏洞存在

[修复建议]

(1)增加验证码的强度

(2)合理设置验证码的失效时间

(3)限制一定时间内的重复尝试次数

(2)验证码重复使用测试

[漏洞原理]

如果验证码验证成功后没有将 session 及时清空，验证码即可重复使用。

[测试方法]

Bp 抓取提交验证码的请求包，在首次验证成功以后重复提交，如果依然提交成功则说明漏洞存在。

[修复建议]

验证码在一次认证成功以后，服务端便清空认证成功的 session ，防止验证码被重复利用。

(3)验证码客户端回显测试

[漏洞原理]

浏览器请求服务器发送如手机验证码的同时在浏览器中查看返回包，如果此时验证码也在返回包中出现则会泄露验证信息

[测试方法]

浏览器请求服务器发送如手机验证码的同时在浏览器中查看返回包，如果此时验证码也在返回包中则说明漏洞存在

[修复建议]

禁止验证码本地生成，或者验证，要采取服务器端生成并验证的方式

(4)验证结果篡改测试

[漏洞原理]

我们可以通过 Bp 抓取返回包，对验证结果的标志位进行篡改，如 0 改成 1 ,然后 forward 以后欺骗验证成功

[测试方法]

我们可以通过 Bp 抓取返回包，对验证结果的标志位进行篡改，如 0 改成 1 ,然后 forward 以后欺骗验证，如果成功，则说明漏洞存在

[修复建议]

建议在服务器端增加验证码的认证机制，对验证结果进行二次校验

(5)验证码自动识别测试

[漏洞原理]

验证码强度不够，导致可以使用自动化工具进行 OCR 识别

[测试方法]

使用自动化识别工具对验证码进行识别测试，如果识别成功则说明漏洞存在

[修复建议]

(1)增加背景元素的干扰，如背景颜色背景字母等

(2)字符字体进行扭曲、粘连

(3)使用问答题作为验证方式，如四则运算等

(4)使用和使用者有关联的信息作为验证码，如最近买过的商品等

6.业务流程乱序测试

(1)业务流程绕过测试

[漏洞原理]

例如整个业务流程分为三步，第一步：注册发送验证码，第二步：输入验证码，第三步：注册成功，那么如果在输入验证码后抓包修改用户身份信息可以的话，就会导致第一第二步被绕过。

[测试方法]

例如整个业务流程分为三步，第一步：注册发送验证码，第二步：输入验证码，第三步：注册成功，那么如果在输入验证码后抓包修改用户身份信息可以的话，则说明漏洞存在

[修复建议]

对敏感信息如身份 ID 等进行加密处理，并要在服务器端进行二次校验

7.业务接口调用模块测试

(1)接口调用重放测试

[漏洞原理]

在短信，邮件的调用测试中，对短信邮件等接口进行重复调用测试可以发出多条数据

[测试方法]

在短信，邮件的调用测试中，对短信邮件等接口进行重复调用测试，如果能成功发送多条数据则说明漏洞存在

[修复建议]

(1)对生成订单环节进行验证码测试

(2)每个订单使用唯一的 token ，提交一次 Token 失效

(2)接口未授权访问测试

[漏洞原理]

敏感的接口的调用需要用户的权限信息，但是由于没有对接口进行身份校验，攻击者可以直接去调用接口的功能，对接口进行攻击

[测试方法]

使用 Bp 的爬虫功能对整站进行爬取，筛选出特定类型(如 json 等)的请求，然后判断该接口是否存在敏感信息，并直接将其放在浏览器中访问，如果返回的几结果包含敏感信息则说明漏洞存在

[修复建议]

(1)使用 token 校验，在 URL 中设置 Token 字段，只有 token 验证通过后才能使用接口，并且使用一次后 token 失效

(2)使用接口时，后端对登录状态进行验证，如果登陆成功则返回数据，如果失败则返回错误

(3)callback自定义测试

[漏洞原理]

由于同源策略的限制，有时候我们需要使用 jsonp 的方式在不同源的两个地址之间交互，其中 回调函数作为 jsonp 的参数之一决定了使用的函数名，那么如果没有对 callback 的输入进行白名单过滤，被攻击者控制的话，那么就会造成 xss 等攻击

[测试方法]

使用 Bp 的爬虫功能对整站进行爬取，筛选出带有 callback 或者 jsonp 参数的请求，并对请求响应的类型进行判断，如果是 text/html 则对该 Callback 进行注入，看能否触发 xss

[修复建议]

(1)严格定义返回包的 content-type 为 applocation/json 而不是 text/html

(2)建立 callback 白名单

(3)对 callback 参数进行过滤 HTML 标签

(4) Webservice 测试

[漏洞原理]

Webservice 这个 api 接口如果不对用户的输入进行过滤，则可能会受到 sql 注入攻击

[测试方法]

通过爬虫或者目录扫描的方法找到服务器的 webservice 链接，然后使用 AWVS 的 webservice editor 功能导入各个接口函数，通过关键词(如 get exec )定位到函数接口，使用 Http editor 对每一个接口的输入参数进行测试

[修复建议]

(1)为 webservice 添加身份认证，认证成功才能调用

(2)后端对输入参数进行过滤才能将其输入到函数当中

(3)对敏感功能的函数添加密码认证，认证通过才能使用

0X04 总结

结合着书本和资料简单总结了一下常见的一些应用逻辑漏洞和利用方式，当然还是很不全面，未来或许还会补充完善。