计算机漏洞测试

去年某个周三凌晨，计算机漏我盯着Burp Suite的洞测扫描结果，发现一个电商后台的计算机漏订单查询接口居然没做权限校验。改一下URL里的洞测订单ID，就能看到别人的计算机漏收货地址和手机号。这不是洞测什么高深的技术漏洞，纯粹是计算机漏开发时漏写了一行判断代码。我把这事告诉朋友，洞测他反问：“这不就是计算机漏改个数字吗？也算漏洞？”对，漏洞测试很多时候就是洞测这么朴素。

很多人以为漏洞测试得靠自动化工具扫出一堆CVE编号才算数。计算机漏工具当然有用，洞测但真正有意思的计算机漏漏洞往往藏在业务逻辑里。比如某次我测试一个积分兑换功能，洞测正常流程是计算机漏“扣积分→生成订单→发货”。我试了试并发请求，同时提交20次兑换操作，结果系统只扣了一次积分，却生成了20个订单。这种漏洞扫描器根本发现不了，因为它不理解“积分”和“订单”之间的业务约束。你得手动去试，去猜开发人员可能在哪偷了懒。

说回技术层面。漏洞测试的核心动作就三个：信息收集、边界试探、异常验证。信息收集不是翻垃圾桶那种社工手段，而是看HTTP响应头、错误页面、JS文件里暴露的接口路径。有次我在一个网站的前端代码里看到注释掉的API地址，直接访问居然返回了数据库连接字符串。开发人员以为注释掉就没事了，但浏览器可不会帮你保密。

边界试探更有意思。输入框里填个单引号，看报不报SQL错误——这招老了，但依然管用。更隐蔽的是测试整数溢出。某次一个文件上传功能限制大小为2GB，我传了个4GB的文件，系统直接崩溃重启。后来发现它用32位整数存文件大小，溢出后变成负数，后续逻辑全乱套。这种漏洞不需要多强的编程能力，只需要你比开发人员多想一步：他用的数据类型够不够大？

异常验证是最后一步，也是最容易被忽略的。发现一个可能的注入点，别急着写报告。先试试能不能读到数据库版本，再试试能不能执行系统命令。有次我找到一个命令注入，兴冲冲地提交了; cat /etc/passwd，结果返回403。换了个编码方式，用%0a代替分号，成功了。同一个漏洞，不同的利用方式，危害等级可能从低危变成严重。

工具能帮你省时间，但别依赖它。AWVS扫一个站，报告里列了50个“疑似漏洞”，其中40个是误报。你一个个手动验证，累得半死，最后发现真正能利用的只有两个。反过来，有些逻辑漏洞工具永远扫不出来，比如“修改密码时不验证旧密码”或者“优惠券可以无限次使用”。这些得靠人去看、去点、去改参数。

我见过最离谱的漏洞是一个医院的挂号系统。输入身份证号查询预约记录，返回的JSON里居然包含了该身份证号对应的所有历史病历摘要。开发人员说“前端只显示了姓名和科室”，但后端把整个对象都吐出来了。漏洞测试有时候就是检查这种“不该给的东西给了没”。

写漏洞报告也别整那些花哨的术语。直接说“在X功能处，修改Y参数，可以Z”。附上请求包和响应包，截个图，完事。甲方要的是能复现的步骤，不是你的文学创作。我见过有人写“该漏洞可能导致横向越权，进而引发数据泄露风险”，绕了半天，其实就是“你能看到别人的订单”。

最后说个实话：漏洞测试不是找茬，是帮人补漏。你发现的每一个问题，都可能是别人熬夜改代码时漏掉的那一行。别觉得自己多厉害，也别觉得开发人员多蠢。大家都是人，都会犯错。你只是那个恰好路过、顺手试了一下的人。