去年冬天，现平我在一个电商平台下单时发现了个怪事：把商品加入购物车后，台漏修改数量为负数，现平总价居然没变。台漏当时我就笑了——这八成是现平个逻辑漏洞。后来一查，台漏果然，现平通过构造特定负数，台漏能绕过优惠券的现平限领逻辑。这种漏洞不靠扫描器，台漏靠的现平是人脑子里那根“不对劲”的弦。

发现漏洞的台漏第一步，从来不是现平打开Burp Suite或者Nmap。是台漏学会对正常流程感到别扭。你每天点外卖、现平刷视频、填表单，系统告诉你“操作成功”，你就信了？我认识一个搞安全的哥们，他点外卖时故意在备注里填了段JS代码，结果商家后台打印小票时弹出了个alert。这不是什么高深技术，就是手痒加好奇。平台把用户输入直接渲染到了后台页面，连转义都没做。这种漏洞叫XSS，但发现它的起点，只是“我想看看它怎么处理我的备注”。

很多人以为漏洞都在犄角旮旯的接口里。其实最肥的漏洞往往在业务流程的“正常路径”上。比如注册环节：你填手机号，收验证码，点下一步。试试把手机号改成别人的，验证码还能用吗？很多平台只校验验证码对不对，不校验它跟手机号是否绑定。我见过一个交友App，注册时用A手机号收码，提交时改成B手机号，照样通过。这意味着我能用自己手机号收码，注册出一堆别人的账号。这种漏洞不需要任何工具，就靠你多改一个参数。

参数篡改是发现漏洞的捷径。但别只盯着URL里的id=123。试试把id改成123'，看看报不报数据库错误。或者把JSON里的"user_id": 1001改成1002，看能不能看到别人的订单。有个做测试的朋友跟我讲，他测一个SaaS后台时，发现删除自己项目的请求里有个project_id，他随手改成隔壁公司的，结果真删了。平台只校验了你有没有登录，没校验这个项目是不是你的。这叫水平越权，比SQL注入还常见，因为开发经常忘了加“where user_id = 当前用户”这个条件。

逻辑漏洞更隐蔽。比如优惠券：满100减50，你买90块的东西，加个10块的袜子，用券后总价50。然后你把袜子退了，系统退你10块，但券已经用了。最终你花40买了90的东西。平台亏了。这种漏洞没有固定模式，得靠你像薅羊毛党一样思考。我观察过，很多平台的退款逻辑是独立的，它不会去重算优惠券的分配。你退掉凑单商品，优惠券的抵扣额就全落在主商品上了。

工具当然有用。但别一上来就AWVS扫全站。先手动走一遍核心流程，用Burp抓包，把每个请求的参数都改一改。看到数字就试试加减1，看到字符串就试试加单引号，看到布尔值就试试取反。我自己的习惯是：注册、登录、下单、支付、退款，这五步里每个请求都至少改三个地方。十次里有八次没反应，但剩下两次往往就是中危起步。

还有一点：别忽略前端。F12打开控制台，看看有没有注释掉的接口，或者隐藏的input字段。有次我测一个后台，页面上只显示了“查看”按钮，但源码里有个display:none的“删除”按钮。我把它改成block，点了一下，真删了。前端隐藏不等于后端鉴权。开发以为用户看不到按钮就不会发请求，但攻击者可以直接构造请求。这种“隐藏即安全”的思维，是漏洞的温床。

最后说个实在的：发现漏洞靠的是耐心和一点点恶意。你得假设平台在骗你，在偷懒，在把用户当傻子。然后去证明它确实这么干了。别指望自动化工具告诉你一切。工具能扫出已知的Pattern，但逻辑漏洞和业务漏洞，得靠你亲手去点、去改、去试。就像那个负数购物车，扫描器不会去试，因为它不知道“数量”还能是负的。你知道，因为你是人，你会好奇。