渗透敏感

去年冬天，渗透敏感我在一个做企业安全的渗透敏感朋友那儿看到一份渗透测试报告。报告第17页写着：“目标系统对异常请求的渗透敏感响应时间存在0.3秒的稳定延迟，可据此判断SQL注入是渗透敏感否命中。”我当时愣了一下——0.3秒，渗透敏感人眨个眼都不止这点时间，渗透敏感但足够让攻击者把数据库里的渗透敏感用户表拖走。

这就是渗透敏感“渗透敏感”的起点：不是漏洞本身多严重，而是渗透敏感系统对异常行为的反应太有规律了。有规律，渗透敏感就能被利用。渗透敏感

很多人以为渗透测试是渗透敏感拿着扫描器跑一遍，出一堆红黄蓝的渗透敏感告警就完事。真不是渗透敏感。我见过太多系统，渗透敏感扫描器报了一百个“高危”，结果一个都利用不了；也见过扫描器全绿的站点，被人用一条精心构造的请求直接拿到管理员权限。差别在哪？在于“敏感”二字。

敏感不是指系统有多脆弱，而是指它对输入的反应有多“诚实”。一个登录接口，如果用户名不存在时返回“用户不存在”，密码错误时返回“密码错误”，那攻击者就能用这个差异把有效用户名一个一个试出来。这叫用户名枚举。修复方法也简单——不管哪种失败，统一返回“用户名或密码错误”。但就这么一行代码的事，很多系统懒得做。

更隐蔽的是时间敏感。比如一个查询接口，正常请求耗时50毫秒，如果注入的SQL语句里带了sleep(5)，服务器老老实实睡了5秒才返回。攻击者不需要看到报错信息，不需要回显数据，只需要掐表。这种盲注手法，防火墙根本拦不住——流量看起来完全正常，只是慢了一点。

我自己的博客之前就吃过亏。有次我图省事，在搜索功能里直接拼接SQL。后来看访问日志，发现有人用search=test' AND 1=1--这种请求反复试探。他大概是在确认注入点。我赶紧改成参数化查询，但心里清楚——那几天里，数据库里那点文章和评论，早被人看了个遍。

渗透敏感还体现在错误处理上。有些开发图方便，把数据库报错直接抛给前端。攻击者看到You have an error in your SQL syntax near...，等于拿到了数据库类型、表名甚至字段名的线索。更狠的是，有人用报错注入，把数据塞在错误信息里带出来。你这边看着满屏红字以为系统坏了，人家那边已经拿到管理员密码的哈希了。

那怎么办？说几个实在的。第一，所有用户输入都当成脏数据，别信任何前端校验。第二，统一错误页面，别把技术细节暴露给外人。第三，给关键操作加延迟或随机化响应时间，让时间盲注没那么准。第四，日志里盯住那些“差一点就成功”的请求——比如返回403但参数里带union select的，那是在试探，不是误报。

说到底，渗透敏感不是让你把系统包成铁桶。铁桶也有缝。它是让你意识到：你系统每一个微小的反应差异，在攻击者眼里都是路标。你越“诚实”，路标越清晰。反过来，你越“迟钝”、越“一致”、越“不露声色”，攻击者就越难判断自己走到哪儿了。

我那个做安全的朋友后来跟我说，他们给客户做渗透测试，最怕的不是漏洞多，而是系统太“敏感”——一碰就报错，一错就回显，一回显就把家底抖干净。这种系统，修起来最累。因为要改的不是一个两个漏洞，而是整个开发团队对“输入”的态度。

态度这东西，比技术难改多了。