Web 安全实战：Robots.txt 协议原理与利用防御指南

2.2 文件位置

固定位于网站根目录下：

http://example.com/robots.txt

2.3 基本语法

示例文件：

User-agent: *
Disallow: /admin/
Disallow: /backup/
Allow: /public/
Sitemap: http://example.com/sitemap.xml

2.4 常见误区

误区： 「Disallowed 的路径是受保护的，访问不了。」

真相： Disallow 只是请求爬虫别来，不代表禁止用户访问。任何知道路径的人都可以直接访问。

安全风险： 把敏感路径写在 robots.txt 里，等于主动告诉攻击者哪里有问题。

三、安全视角：如何利用 robots.txt

在授权渗透测试中，robots.txt 是信息收集的第一步。

3.1 直接访问查看

操作步骤：

1. 打开浏览器或 Burp Suite
2. 访问 http://目标域名/robots.txt
3. 分析 Disallow 后的路径

工具命令：

curl http://target.com/robots.txt

3.2 敏感路径识别

看到 Disallow 路径后，重点关注的关键词：

3.3 结合目录扫描工具

robots.txt 暴露的路径，可以作为目录扫描工具（如 Dirsearch、Gobuster）的自定义字典。

Dirsearch 示例：

# 将 robots.txt 中的路径提取出来，作为字典
dirsearch -u http://target.com -w robots_paths.txt

对本地搭建的靶站进行扫描：

# 由于本地的靶站的 robots.txt 没有路径，所以就不是用字典进行扫描
dirsearch -u http://192.168.6.100:8080 

优势： 比暴力扫描更精准，减少被封 IP 的风险。

• [200]：状态码（成功访问）
• [403]：权限拒绝（目录存在但无访问权限）

四、实战案例：三个真实场景

4.1 案例一：后台路径泄露

场景： 某企业官网，前台无任何漏洞。

过程：

1. 访问 /robots.txt
2. 发现 Disallow: /manage_system_v2/
3. 直接访问 http://target.com/manage_system_v2/
4. 发现未设防的后台登录页

结果： 通过弱口令进入后台，获取权限。

教训： 后台路径不应通过 robots.txt 隐藏，应使用强认证。

4.2 案例二：数据库备份文件下载

场景： 某电商系统迁移后，旧数据未清理。

过程：

1. 访问 /robots.txt
2. 发现 Disallow: /db_backup_20230501.sql
3. 直接访问该 URL
4. 浏览器开始下载 SQL 文件

结果： 文件中包含所有用户表结构和管理员密码哈希。

教训： 备份文件绝对不能放在 Web 目录下，更不能在 robots.txt 中引用。

4.3 案例三：API 接口未授权访问

场景： 某 APP 后端接口。

过程：

1. 访问 /robots.txt
2. 发现 Disallow: /api/v1/internal/
3. 访问该路径，发现返回 JSON 数据
4. 测试发现无需 Token 即可调用

结果： 获取内部用户数据。

教训： 接口安全依赖认证机制，而非路径隐藏。

五、防御方案：如何正确配置

5.1 核心原则：安全不靠隐匿

Security by Obscurity（隐匿式安全）是无效的。

不要指望通过 robots.txt 隐藏敏感路径来保护安全。攻击者不用爬虫，照样可以访问。

5.2 正确配置建议

5.3 安全配置示例

❌ 危险配置：

User-agent: *
Disallow: /admin/
Disallow: /config/database.yml
Disallow: /backup/full.zip

分析：直接告诉攻击者这三个地方有东西。

✅ 安全配置：

User-agent: *
Allow: / # 敏感路径根本不提，直接在服务器层禁止访问

服务器层禁止（Nginx 示例）：

location /admin/ { deny all; return 403; }

六、自查清单

发布网站前，对照此表检查 robots.txt：

• 是否包含后台管理路径（/admin/, /manage/）？
• 是否包含备份文件路径（.sql, .zip, .bak）？
• 是否包含配置文件路径（.yml, .conf, .env）？
• 是否包含测试环境路径（/test/, /dev/）？
• 敏感路径是否已通过权限控制（登录/鉴权）保护？
• 服务器是否对敏感路径返回 403 而非仅靠 robots.txt？
• 是否使用了 HTTPS 协议传输 robots.txt？

七、常见问题 Q&A

Q：robots.txt 能被删除吗？ A：可以。如果不需要搜索引擎收录，可以删除该文件。但删除后，爬虫可能会尝试抓取所有路径。

Q：隐藏 robots.txt 文件本身安全吗？ A：没用。攻击者会尝试访问 /robots.txt，如果返回 404，他们会认为没有限制，反而更放心地扫描。

Q：如何防止攻击者利用 robots.txt？ A：不要在里面写敏感路径。真正的安全靠权限控制（Authentication & Authorization），不靠隐藏路径。

Q：搜索引擎会遵守 robots.txt 吗？ A：正规搜索引擎（Google、百度）会遵守。但恶意爬虫和攻击工具完全无视。

Q：有没有工具自动分析 robots.txt 风险？ A：有。Burp Suite 插件、OWASP ZAP、以及在线工具（如 robotools.com）都可以分析。

八、信息收集中的位置

在 Web 安全测试流程中，robots.txt 属于信息收集阶段。

1. 信息收集 (Whois, DNS, robots.txt, 端口扫描)
↓
2. 漏洞扫描 (SQL 注入，XSS, 命令注入)
↓
3. 漏洞利用 (获取权限，数据提取)
↓
4. 后渗透 (维持权限，横向移动)
↓
5. 报告与修复

robots.txt 是第 1 步中最简单也最容易忽视的一环。

总结

我在安全行业多年，见过太多因为一个 robots.txt 配置失误导致的数据泄露。

核心要点：

1. robots.txt 是给爬虫看的，不是给黑客看的防线。
2. 敏感路径千万不要写进 robots.txt。
3. 真正的安全靠权限控制，不靠隐匿路径。
4. 信息收集阶段，必看 robots.txt。

免责声明： 本文所有内容仅供学习与授权测试使用，未经授权的攻击行为属于违法，请务必在法律允许范围内进行安全研究。