去年帮一家电商平台做授权测试，渗透客户只给了一个域名，测试其他什么信息都没有。黑盒这其实就是渗透最典型的黑盒渗透——你站在外面，对内部结构、测试代码逻辑、黑盒服务器配置一无所知，渗透全靠自己一点点摸。测试很多人觉得黑盒就是黑盒扫扫端口、跑跑字典，渗透真干起来远没那么简单。测试

黑盒的黑盒核心逻辑是模拟真实攻击者。攻击者不会拿到你的渗透网络拓扑图，也不会知道你的测试数据库版本。他们能看到的黑盒，和你把网站丢到公网上让所有人访问时看到的一样。所以黑盒测试的第一步往往不是技术操作，而是信息收集。我习惯先看HTTP响应头，Server字段有时候直接暴露Nginx版本，X-Powered-By偶尔会告诉你后端是PHP 7.4还是Java。这些细节单独看没什么，拼在一起就能画出一个粗略的攻击面。

举个例子。那次电商测试，主站响应头里有个X-Powered-By: Express，说明后端是Node.js。但静态资源走的是CDN，说明前端和后端分离。我试着访问了几个常见路径，/api/返回403，/admin/返回302跳转到登录页。到这里其实没什么特别的。真正有意思的是，我用subfinder跑了一遍子域名，发现一个test开头的子域，解析到一台独立IP。打开一看，是个旧版管理后台，登录框没有任何验证码，也没有频率限制。这就是黑盒的价值——你不需要知道他们内部怎么部署的，你只需要找到那个被遗忘的入口。

端口扫描是另一个绕不开的环节。nmap扫全端口太慢，我一般先用masscan快速过一遍，再对开放端口做服务识别。那次发现目标开了6379，Redis。未授权访问。直接连上去，keys * 一看，缓存里全是用户session。这意味着什么？我可以伪造任意用户登录。但这里有个坑，黑盒测试不能直接利用，你得先确认这个Redis是不是真的对公网开放且无认证。确认之后，我写了个脚本，把session里的用户ID替换成管理员ID，重新加密（其实Redis里存的是明文JSON），然后带着这个session去访问后台。进去了。整个过程没有碰任何漏洞利用工具，就是信息拼图。

Web层面的黑盒更依赖经验。比如看到URL里有?id=123，第一反应是测SQL注入。但现在的WAF不是吃素的，直接上sqlmap大概率被封IP。我通常先手动加个单引号，看报错信息。如果返回500且页面内容有变化，再尝试and 1=1和and 1=2对比。有一次遇到一个参数，加单引号没反应，加双引号也没反应，但加反斜杠返回了数据库错误。这说明后端用了转义，但转义函数写错了。这种细节，自动化工具扫不出来，得靠手感和耐心。

文件上传也是黑盒里经常出彩的地方。客户只给了一个前台，但前台有个头像上传功能。我试了改Content-Type、改后缀、加%00截断，都不行。后来发现上传后的路径是 /uploads/用户ID/文件名。用户ID是自增的，文件名没改。我注册了两个账号，发现用户ID是连续的。于是我把第一个账号的头像文件名改成shell.php.jpg，上传，然后访问第二个账号的目录，路径拼接后变成了 /uploads/2/shell.php.jpg。服务器解析时把.jpg当成了扩展名，但Nginx配置里有个location ~ \.php 的规则，匹配到了路径中的.php，结果执行了。这种逻辑漏洞，黑盒测试里全靠对URL结构和文件命名规则的观察。

黑盒测试的局限也很明显。你永远不知道代码里藏了什么后门，也看不到数据库里的敏感数据。但它最接近真实攻击场景。攻击者不会给你源码，不会告诉你哪个接口有漏洞。你只能从外部一点点试探，从响应时间、状态码、页面内容的变化里找线索。这活儿有时候像侦探，有时候像赌博。但当你从一个域名开始，最后拿到数据库权限的时候，那种感觉是白盒测试给不了的。

做黑盒测试，工具只是辅助。真正决定成败的是你对HTTP协议的理解、对常见框架的熟悉程度，以及愿不愿意花几个小时去翻一个不起眼的JS文件。那次电商测试的最后，我在一个打包后的app.js里找到了一段注释掉的API密钥。用它调了内部接口，直接返回了所有订单信息。客户后来问我怎么找到的，我说就是看代码。他说那代码压缩过的。我说压缩过的也有规律，变量名短但字符串不会骗人。