版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/jlu16/article/details/83065203
今天下午看完了《业务安全实战指南》，是一本2018年的新书。这本书包含的业务安全内容感觉挺全的，不过编排并不好，很多地方都有重复；应该是不同作者写了不同章节，但是事先没有分的太清楚。
我将结合以往知识与这本书的内容总结一下Web安全中的业务安全问题。
业务安全问题给我的最大感觉就是：漏洞本身技术含量并不高，关键是处理逻辑是否足够严密。我想大致可以将导致业务漏洞的原因分为以下两类：1.过于信赖客户端传入的数据，没有在服务器端验证一致性；2.暴露密令或者密令过于简单。
业务安全漏洞可以分为如下几种类型：1.篡改型 2.回显型 3.跳过型 4.弱验证
篡改型
1.对各类id的篡改
说是对各类id的篡改，其实就是对各种标识的篡改，只是这些标识往往起名为uid、pid之类的名字所以我这么叫它。各种id可以存在于很多地方，最多的肯定就是url中，还有可能出现在post内容和cookie中，它们往往可以代表用户标识、订单标识、商品标识等等，通过对它的篡改往往造成水平越权访问，或者是用A商品的价格购买B商品。
2.对邮箱、手机号的篡改
涉及到邮箱与手机号的地方往往是在对用户的身份进行验证，它最常出现在忘记密码、重置密码的位置。假设我们用陌生人A的账号进行重置密码操作，本地也许会向服务器发送一个请求其中包含A的注册用手机号或者邮箱，如果我们修改为自己的手机号或者邮箱也许就能获得该验证码。3.对session的篡改
这里主要想说的是session覆盖。还是以重置密码举例子，假设重置密码需要三个步骤：- 输入账号
- 输入验证码
- 输入新密码
我们自己已经注册账号B，目标是修改账号A的密码。那么，在第一步我们输入B的账号，此时session被设置为账号B的信息。然后进行第二步，由于B账号是自己的，我们可以获取到验证码并进入第三步。这时新打开一个标签页，在第一步输入账号A并进入第二步，这时session被更新为A的信息。再返回刚才标签的第三步，如果上面有账号提示可以刷新看看是否会变成A的账号，如果变成此时再输入新密码就更新了A的密码。
4.对返回值的篡改
假如在输入某一个无法获取的验证码时，有可能提交验证码的页面逻辑是发送Ajax请求并读取返回值结果。比如我们输入错误的验证码会返回{res:0}，也许用burpsuite截取response并将其改为{res:1}再传给本地就相当于输入了正确的验证码。不过我觉得这种本地处理直接看代码也可以绕过，但是比较麻烦。5.对数量、金额的篡改
这种篡改不必多说，是一种让人很容易想到的篡改，填负数之类都是常见的手段。不过我今天看到一个之前没有注意过的金额篡改，就是一些网站在调用支付宝之类第三方付款时，也许付款成功就算成功，并不检查付款金额，所以可以抓调用支付宝的请求并修改其中金额。回显型
回显型主要是指各种验证码，密保问题答案被隐藏在客户端中，比如URL中、页面源代码中。这种隐藏也许是编码后的，也许是未编码的。跳过型
所谓跳过型，举这么一个例子。我想往我的账户上充值100元，分为下面几步：- 打开充值页面，选择充值方式(www.xxx.com/pay.php)
- 跳转第三方支付并成功
- 返回原网站，并显示充值成功(www.xxx.com/pay_success.php?num=100)
假设我跳过1、2步，直接输入第三步的URL，也许同样能够充值成功。
弱验证
1.校验码弱验证
假设验证码位数比较少，重新刷新时间又比较充足，就可以使用穷举的方式破解验证码。2.密码重置链接Token弱验证
在很多网站密码重置的方式是向注册用邮箱发送一个重置链接，点击链接进行重置。虽然我们不能登录攻击目标的邮箱，却可以尝试猜解该重置链接的Token。比如自己先注册一个名为test的用户，验证发现它的重置链接是：
www.xxx.com/changePass.php?id=test&token=098F6BCD4621D373CADE4E832627B4F6
Token就是md5加密的test，我们找到该规律后就可以猜到目标用户的重置链接。