（杂谈）攻击者与开发者的无形碰撞–逻辑漏洞的挖掘实战及反思（一）
? 逻辑漏洞的挖掘 （本文约3000字看完大约20分钟）
? 本文只代表个人的经历与见解，写的不好请多多理解。
前瞻
? 随着框架技术的不断发展，传统的漏洞，sql，xss，早已经被底层框架所消灭，（当然，不排除能够一一些其他方式利用 比如说“组合拳”），另外，加上各种“云waf”的存在，极大的增加了小白对一些规模稍大一点的网站的挖掘 难度，十几年前或许能凭借一个“明小子”横行一时，十多年后，面对预编译，waf基本就是束手无测，本人在测试的时候，即使可以感觉到某个网站安全做到很烂，可它偏偏就有waf，和waf死磕了半天也没有啥成果，反而吃了个封禁套餐。
? 当然，这里并不是说传统漏洞不重要，在没有一定的通用漏洞积累，代码审计，以及过waf能力的新手来说，还是建议在漏洞挖掘时侧重于逻辑漏洞 （个人不建议用直接用扫描器，直接拿一些10年不更新老网站下手，有法律风险的同时也没有多大技术增长 久而久之 形成依赖就不好了，而且但凡一些大站有点防护的，都不可能让你用扫描器一直扫）。
逻辑漏洞的挖掘-与开发者的无形碰撞
? 常言道：知己知彼-百战不殆
重放漏洞
首先拿最常见的短信轰炸漏洞来讲。
短信轰炸level1~level3
正常流程： 用户输入验证码→点击发送验证码→之后要等60s或重新输入验证码才可发送
攻击者思路：burpsuite抓包取发送的http数据包，绕过前端限制（这里的验证码是前端验证的），不就能达到短信轰炸的效果了么。
**开发者思路level1：**绕过前端60s限制我么没办法，但是我可以把你的验证码放在后端验证，验证一次就无效，或者根据电话号码，限制你的发送频率。
攻击者思路level1：好，又浪费你几根头发，验证码后端验证是吧，我测一下你之前有没有设的万能验证码（0000），或者在burpsuite中把验证码直接置空，根据电话号码限制频率，那我修改一下我电话号码的格式（加个空格或则特殊符号啥的），实在不行咱搞横向短信轰炸。
**开发者思路level2：**我承认修的时候太马虎了，我多花点时间加个token机制，你可以来爆破下token。
**攻击者思路level2：**看下token有没有回显，有的话还可以利用burpsutie中intruder模块的pitchfork还是能进行爆破。
开发者思路level3：N**B!!!,被产品经理叼就叼一顿把，直接给你上个图形验证码，我都看不清的那种！
攻击者思路level3： 润了润了，换一个功能点测，反正改代码的不是我。
**开发者：**你xxxxxxxx！！！
附一张 短信轰炸漏洞的奖金图片。。。。。
通过上面一个例子的，大家可以应该能明白，挖掘逻辑漏洞时，往往需要站在开发者的立场不断的去思考他的防御手段，从而衍生出绕过思路，而不仅仅是重放，或者是修改参数，简单的尝试了一下就run。而是要不断尝试，不断思考，最终确认，逻辑漏洞在此处不通。
优惠劵白嫖多张漏洞
现在在网上优惠劵无处不在，在很多时候，优惠劵只能领取一张，比如下图。
涉密原因：所以层层打码。
点击领取之后，这个领取的按钮可能就会变成灰白色。正常情况下，我们无法再次领取。
不过稍微理解HTTP协议是无状态的（如果web渗透这个不明白，建议重学）
我们就知道，可以通过burpsuite抓包，然后进行重放。这样就可以白嫖多张。
这个优惠劵白嫖领取其实挺容易理解的
简单重放漏洞的延申——学会逻辑漏洞的利用
很多时候，逻辑漏洞有的时候不仅仅是简单的重放，修改参数，我们需要经常从程序的实际功能点出发，结合我们的操作实现绕过开发者给我们的限制。
下面介绍我发现2个逻辑漏洞的过程。
1.生日重置逻辑漏洞
现在很多商家在自己的微信小程序有着生日优惠的活动，为了避免“客户天天过生日“的情况,通常设置只能在注册的时候填写一次。
那我们怎么达到”天天过生日“的目的呢？
其实和上面的优惠卷领取一样，我们同样利用重放漏洞。
只不过唯一不同的是：优惠劵我们是在同一天不断的重复领，而修改生日呢？ 则需要我们将设定生日的这个数据包记录下来，在需要领取的时候，通过burpsuite发送这个数据包，从而达到”天天过生日的效果”。这样就可以天天白嫖生日礼物啥的。
（郑重声明：这样违法）
2.验证码回显 从无危害到高危
事情起因：记得3个月前开始挖洞的时候，当时本人由于对逻辑洞见的比较少，所以只挑选了一个最擅长的短信轰炸，当时也没想着绕过，就搁哪一直重放，重放不了，我就run。
当时碰到了一个站，在注册界面，短信轰炸有限制，但是他喵的居然把验证码回显出来。
当时我的心路历程：短信轰不了，那么能回显有啥用么，哦对了，是不是用任何一个手机号我都能给他注册，转手交给BT（’简称‘懂得都懂 ），结果来个前台任意注册不收。
事情发展：通过3个多月的不断学习，个人的水平有着明显的提升，感觉不管是基础漏洞还是逻辑漏洞水平都提升很快。在一次对某APP的测试中，我又发现了这个洞（验证码回显）：
尽管是在注册界面发现的，只能算一个前端任意注册，但是我转而又想到，在登陆界面往往有个根据手机号码修改密码的，也就是说：只要能获取验证码，就意味着可以修改任意一个账户的密码。这样一交：无危害直接变高危！
越权漏洞挖掘的一些思考与理解
? 关于越权漏洞，通常我们一般都是在电商这样的网站进行测试的，通过抓取一些相关功能点（删除订单，购物车）的数据包，进行测试和分析从而判断出是否存在越权漏洞。在此列出我的几条经验
- cooike很长，存在token的大概率没有，有的话，也是在一些不重要的功能点上
- 有的网站功能整合的非常好，所有的数据包，都会验证cooike，从而确认你的权限
- 据个人观察：现在购物网站框架都比较成熟，一般较少出现越权。（反正我没碰过）
- 在某平台上面发现购物GZH都一个模子，完全没越权。…
? 当然，挖归难挖，但还是能挖到的。。。 看细不细心辣。qaq
关于开发者逻辑漏洞的预防与修复感想
? 对于开发人员来讲，一个网站是否存在逻辑漏洞和存在逻辑漏洞的多少和开发人员的思维，能力，以及严谨的态度是有非常大的关系的，个人感觉一些大厂的逻辑洞的确很少，这和他们的规范的开发流程和过硬的技术能力分不开，而本人其实也自己搭建过一些简单的网站做渗透测试，结果。。。一个xss语句有时都能给网站搞崩。 另外，转念一想开发者也的确不容易，我碰到过不止一次，漏洞报告上去，开发者处理的很随意，结果我一测，又可以绕过，或者是修复不全面，这里不能越权了，还有别处能越。。。。（这个其实没办法，因为一些系统比较老，重新开发一个是不实际的，所以只能简单处理）简单修了修不好，好好修了又费时间掉头发，心疼一波开发人员。。。。。
?
写了快估计有大半天了，算是对我这些天挖洞的一些总结把。
? 另外,如果觉得本文对你有帮助的话，点个左下方的赞，我觉得不过分。
