web安全与渗透测试

2017年，全渗Equifax公司因为一个未修补的透测Apache Struts漏洞，泄露了1.43亿用户的全渗社保号、驾照号和信用卡信息。透测事后调查发现，全渗漏洞补丁在两个月前就发布了，透测但负责运维的全渗团队压根没当回事。这件事让我想起一个老生常谈却总被忽视的透测事实：绝大多数web攻击，打的全渗不是高科技，而是透测懒惰和疏忽。

渗透测试说白了，全渗就是透测站在黑客的角度，用他们的全渗工具和思路去捅自己的系统。不是透测拿着扫描器跑一遍就完事，那是全渗安全巡检，不是渗透。真正的渗透测试，开头往往很无聊——信息收集。子域名枚举、端口扫描、指纹识别，翻github上的泄露代码，甚至去LinkedIn上看看目标公司的运维人员最近在学什么新框架。这些活儿干起来像侦探，不像程序员。

有一次我测试一个电商网站，常规的SQL注入和XSS都试过了，没戏。WAF挡得严严实实，参数过滤得跟筛子似的。后来我注意到它的密码重置功能，发送验证码时会先调用一个接口检查用户是否存在。响应时间差了几百毫秒——存在与不存在的用户，返回速度不一样。就凭这一点，我枚举出了全站的管理员账号。接着用撞库的弱密码字典试了试，还真让我蒙对一个。整个过程没碰任何漏洞，全是逻辑设计上的糙点。

这种案例多了以后，我越来越觉得，渗透测试的本质是“假设验证”，而不是“漏洞扫描”。你得先假设某个业务逻辑能绕过，然后设计实验去验证。比如“上传头像”这个功能，开发者可能只检查了Content-Type头，但真正的文件内容是不是图片，他根本没管。你传一个PHP webshell，改一下Content-Type为image/jpeg，服务器就乖乖收下了。这种问题，扫描器永远发现不了，只有人脑能想到。

工具当然重要。Burp Suite、sqlmap、nmap，这些是标配。但工具只能帮你扩大攻击面，真正决定成败的是你对web协议和服务器配置的理解深度。有个朋友问我，为什么他用sqlmap跑不出注入点，我上去一看，他连cookie都没带上，工具连登录态都没有，当然跑不出来。这种低级错误，每天都在发生。

再往深了说，渗透测试的边界其实很模糊。你拿到一个测试授权，但测试过程中不小心看到了数据库里的真实用户密码——明文存储的。这时候你怎么办？报告里写不写？写了可能得罪人，不写又违背职业操守。我通常的做法是，在报告中用加粗字体标注，但不直接粘贴数据内容。这行当讲究“点到为止”，你证明能拿到数据就够了，没必要真把数据拖出来晒。

web安全这些年变化太快。早几年SQL注入遍地都是，现在开发者多少有点意识了。但新的坑又冒出来——云存储桶配置错误、JWT密钥硬编码、第三方npm包投毒。每个新技术的流行，都伴随着新的攻击面。我见过一家创业公司，把API密钥直接写在前端代码里，以为没人会扒拉JS文件。结果我用浏览器F12一搜，AWS的AccessKey就躺在minified代码里，跟垃圾数据混在一起。这种案例，说出去都丢人。

所以渗透测试这活儿，永远有得干。不是因为黑客多厉害，而是因为开发者的健忘症和业务压力永远存在。你修好一个漏洞，下个季度新功能上线，又带着新漏洞回来了。这就像打地鼠游戏，但地鼠是无限繁殖的。我有时候觉得，安全工程师的宿命就是跟人性的弱点缠斗——跟懒惰缠斗，跟侥幸心理缠斗，跟“先上线再说”的冲动缠斗。

最后说句实在话。如果你是个刚入行的新人，别急着学那些花哨的利用技巧。先把你手头的业务逻辑琢磨透，想想如果你是开发者，会怎么偷懒，会怎么留后门。安全漏洞从来不是技术问题，而是人的问题。想通了这一点，你的渗透测试水平，至少能超过一半的“扫描器使用者”。