在实际渗透中，HTTP头信息是一座富矿

没错，一次普通的访问，返回的HTTP响应头里就藏着不少“宝贝”。仔细看看，能直接读到服务器用的是Nginx 1.0.10，PHP版本是5.2.17p1。

不仅如此，服务器时间、背后是否用了袋里或负载均衡（比如Via字段里的Squid），都一览无余。这些信息虽然不能直接帮你拿到服务器权限，但在真正的攻防对抗中，却是勾勒攻击路径、寻找薄弱点的宝贵情报。

想亲自体验一下？有个简单的工具网站可以帮你快速抓取这些信息。

不过，事情可不止“暴露信息”这么简单。这里头的水，其实要深得多。

一个危险的“玩笑”：Server头里的潜在杀机

试想一下，如果我们把HTTP响应头里的“Server”字段，改成这么一段东西：'; DROP TABLE servertypes; --。

这显然不是一个正常的服务器标识，那它是什么？

懂点数据库的一眼就能看出来，“DROP TABLE”是SQL语言里删除数据表的命令。整段意思就是：删除名为“servertypes”的表。

这会造成什么后果？假设有一个网络爬虫（或者叫“蜘蛛”）来抓取你的网站，并且它恰好在记录或分析Server头信息。如果这个爬虫的后端程序没有对读取到的数据进行严格的过滤和转义，就直接拼接进了SQL查询语句里……后果可想而知。这不就成了一次被动的、由服务器自己“提供”攻击载荷的SQL注入了吗？

当然，这只是个理论推演，现实里主流的搜索引擎爬虫没那么“笨”。但这个思路本身很有启发性，它揭示了一种“被动注入”的可能性。顺着这个思路拓展下去，你还能想到什么？

拓展思维：监控系统与薄弱环节

在大型网络架构里，运维团队为了掌握系统状态，往往会部署各种监控系统。问题在于，开发这些内部监控工具的同学，其安全意识有时比不上核心业务的开发人员。如果某个监控探针去抓取服务状态，并天真地将HTTP头信息直接存入数据库而未经处理，那么一个被恶意篡改的Server头，就可能在其监控系统内部引发一场数据灾难。

我们回头再仔细看看一个典型的响应头，信息密度其实很高：

HTTP/1.1 200 OK
Server: nginx/1.0.10
Date: Wed, 25 Apr 2012 11:51:39 GMT
Content-Type: text/html
Vary: Accept-Encoding
X-Powered-By: PHP/5.2.17p1
Cache-Control: no-store, no-cache, must-revalidate
Set-Cookie: TPn_sid=8MQ9st; expires=Wed, 02-May-2012 11:51:39 GMT; path=/; httponly
X-Cache: MISS from 2vs.3
X-Cache: MISS from ce.3
Transfer-Encoding: chunked
Via: 1.1 2vs.3:83 (squid), 1.1 ce.3:83 (squid)

每一行都可能成为信息拼图的一部分，也都有可能在某些特定场景下成为攻击的切入点。

如何加固：修改你的服务器标识

出于安全最佳实践，减少不必要的敏感信息泄露是很有必要的。修改或隐藏Web服务器的默认标识（Banner）是一个基础但有效的步骤。

最后，如何实际操作呢？这里提供几篇来自官方或社区的指导文章，虽然是英文，但步骤清晰，相信对于实操的朋友来说理解起来并不困难：

Apache: https://httpd.apache.org/docs/2.0/mod/mod_headers.html

IIS7: https://technet.microsoft.com/en-us/library/cc753133(v=ws.10).aspx

NginX: https://blog.secaserver.com/2012/03/customize-server-header-nginx/

DiS9 TeAm [Joe Lynch]