[技術解析] 006 資安視角下的 robots.txt：從「看不懂」到「能攻能守」

一份出現在 payload 裡的陌生檔案，一個看似無害的規範，卻可能成為滲透測試人員的第一張地圖。
本文帶你從零開始，完整理解 robots.txt 是什麼、為什麼有資安風險、以及真正的防禦方法。

---

1. robots.txt 是什麼？從頭說起

1994 年，網際網路剛開始蓬勃發展，搜尋引擎爬蟲開始四處抓取網頁內容。但有些網站不希望所有頁面都被索引——比如後台管理介面、測試中的頁面、或者私人文件。於是工程師 Martijn Koster 提出了一個簡單的規範，叫做 Robots Exclusion Protocol（機器人排除協定）。

這個規範的執行方式很簡單：在網站根目錄放一個純文字檔案，取名叫 robots.txt，裡面寫明哪些路徑可以讓爬蟲抓、哪些不行。搜尋引擎爬蟲（如 Googlebot）在爬取網站之前，會先讀這個檔案，依照裡面的規則行事。

無論是哪個網站，這個檔案的位置永遠固定在根目錄下：

https://example.com/robots.txt
https://shop.example.com/robots.txt
https://api.example.com/robots.txt

為什麼位置固定？
爬蟲程式必須在取得任何其他頁面之前就能找到這個檔案，所以規範要求它必須放在根目錄，不能放在子目錄下，也不能改名字。這個位置是全球統一的協議。

---

2. 檔案格式詳解：每一行的意思

robots.txt 是純文字格式，結構非常簡單：

# 這是注釋行，爬蟲會忽略

User-agent: *
Disallow: /admin/
Disallow: /private/
Disallow: /backup/
Allow: /public/

# 只針對 Google 爬蟲的規則
User-agent: Googlebot
Disallow: /staging/

# 告訴搜尋引擎網站地圖在哪
Sitemap: https://example.com/sitemap.xml

欄位說明

欄位	意思	常見值範例
User-agent	這條規則針對哪種爬蟲	*（全部）、Googlebot、Bingbot
Disallow	禁止爬蟲存取的路徑	/admin/、/private/
Allow	明確允許的路徑，優先級高於 Disallow	/public/、/blog/
Sitemap	網站地圖的完整 URL	https://example.com/sitemap.xml
Crawl-delay	要求爬蟲每次請求之間等待的秒數（非標準，部分爬蟲支援）	10

關於 Allow 欄位：Allow 並非 1994 年原始規範的一部分，是後來由 Google、Bing 等主流搜尋引擎擴充支援的。目前雖已普遍被接受，但嚴格來說屬於非正式擴充，並非所有爬蟲都會遵守。

特殊語意說明

• Disallow: /：禁止抓取整個網站所有頁面
• Disallow:（後面留空）：不禁止任何路徑，效果上等同允許所有路徑。注意這是「不設禁止」而非「明確允許」，語意上有差異
• User-agent: *：這組規則適用於所有爬蟲，除非某個爬蟲有專屬的規則區塊

常見誤解：很多人以為只要在 Disallow 裡列出路徑，那個頁面就「不存在」了。完全不是這樣。robots.txt 只是一個請求，不是技術封鎖。頁面還是照樣存在，任何人直接輸入網址都能存取。

---

3. 關鍵認知：這只是「君子協定」

就像現場沒有警察的道路標示牌——告訴用路人車該怎麼走、路該怎麼走，但用路人照不照規矩……那又是另一回事了。

robots.txt 沒有任何技術強制力。它的運作完全依賴爬蟲「願意遵守」這個前提。

誰會遵守？

• Google、Bing、Yahoo 等主流搜尋引擎
• Amazon、Twitter 等大平台的合規爬蟲
• 遵守規範的 SEO 工具（如 Screaming Frog 的預設設定）

誰不會遵守？

• 惡意攻擊者自己寫的工具
• 以蒐集資料為目的的商業爬蟲（灰色地帶）
• 滲透測試工具（nikto、gobuster 等）
• 任何設定了忽略 robots.txt 的自動化工具

更重要的是：即使善意的爬蟲遵守了規則，robots.txt 這個檔案本身是完全公開的。任何人只要在瀏覽器輸入 https://example.com/robots.txt，就能立刻看到完整內容。這就是問題的核心所在。

---

4. 滲透測試人員怎麼利用它？

在滲透測試的第一個階段叫做「偵查（Reconnaissance）」，目標是在不觸碰目標系統的情況下，盡量蒐集關於它的資訊。robots.txt 在這個階段幾乎是必查的項目。

robots.txt 是資訊洩漏的金礦

網站管理員為了不讓 Google 索引某些「敏感路徑」，反而在 robots.txt 裡把這些路徑一條一條列出來。這等於是主動公告給全世界看，哪些地方是他們想藏起來的。

以下是一個現實中常見的例子：

# 以下是管理員「以為沒人注意」的內容

User-agent: *
Disallow: /admin-panel/        # 後台管理介面
Disallow: /backup_2024/        # 備份資料夾
Disallow: /internal-api/       # 內部 API 端點
Disallow: /.env                # 環境變數設定檔（通常含資料庫密碼）
Disallow: /config/database.yml # 資料庫設定檔
Disallow: /staging/            # 測試環境（通常防護較弱）
Disallow: /.git/               # Git 版本庫（可能下載完整原始碼）

一個有經驗的滲透測試人員看到這份清單，等於拿到了一份藏寶圖。

每種路徑洩漏了什麼？

洩漏的路徑	潛在風險	嚴重程度
/backup_2024/	可能包含完整的資料庫備份、使用者資料	極高
/.git/	可下載完整原始碼，歷史 commit 中可能含有密碼	極高
/.env	通常包含資料庫帳密、第三方 API 金鑰	極高
/admin-panel/	確認後台入口位置，可嘗試弱密碼或已知漏洞	高
/staging/	測試環境通常未啟用完整的安全設定	高
/internal-api/	內部 API 可能未設身份驗證機制	中高
/wp-admin/	確認網站使用 WordPress，可針對已知漏洞攻擊	中

怎麼查？實際指令

查看 robots.txt 不需要任何特殊工具或技術：

# 最簡單的方式：直接用瀏覽器開
https://target.com/robots.txt

# 用命令列取得
curl https://target.com/robots.txt

# 使用 wget 下載
wget https://target.com/robots.txt

# nikto 自動化弱點掃描工具會自動讀取並分析
nikto -h https://target.com

# gobuster 可進一步列舉目錄（會讀取 robots.txt 作為輸入）
gobuster dir -u https://target.com -w wordlist.txt

robots.txt 是完全公開的，讀取它不需要任何破解行為，任何人都能做到。

---

5. 實際攻擊鏈演示

以下是一個真實的攻擊情境，說明滲透測試人員如何從 robots.txt 出發，一步步取得系統存取權。

步驟一：讀取 robots.txt

打開 https://target.com/robots.txt，發現：

Disallow: /old-admin/
Disallow: /backup_db/

步驟二：直接存取被「禁止」的路徑

在瀏覽器輸入 https://target.com/old-admin/。因為 robots.txt 沒有技術封鎖，頁面直接開啟，是一個舊版的管理介面，顯然已被遺忘。

步驟三：嘗試預設帳號密碼

舊管理介面從未更新安全設定，使用預設帳密 admin / admin123 直接登入成功。

步驟四：存取備份資料夾

前往 https://target.com/backup_db/，發現完整的資料庫備份檔案可以直接下載，內含所有使用者的帳號、密碼雜湊值、個人資料。

步驟五：取得完整控制權

透過管理介面上傳 web shell，取得伺服器的命令執行能力。整個過程不需要任何高超的駭客技術，起點只是一份公開的 robots.txt。

這在現實中真的發生過。 從 robots.txt 發現敏感路徑是 CTF 競賽和實際滲透測試中最基本的第一步。這類漏洞在 Bug Bounty 平台（HackerOne、Bugcrowd）上也有大量記錄。問題的根本不是 robots.txt 本身，而是那些不應該暴露在網路上的路徑和檔案。

---

6. 爬蟲工程師如何繞過它？

robots.txt 對爬蟲工程師來說是一個「建議」，不是強制規定。以下是常見的繞過方式：

方法一：直接在設定中關閉遵守選項

大多數爬蟲框架都提供選項讓你選擇是否遵守 robots.txt：

# Python Scrapy 框架 — settings.py
ROBOTSTXT_OBEY = False  # 預設是 True，改為 False 即忽略

# 或直接用 requests 存取被禁止的路徑，完全不理會 robots.txt
import requests
response = requests.get("https://target.com/admin/")
print(response.status_code)

方法二：偽造 User-Agent，假裝是普通瀏覽器

robots.txt 的規則是針對不同 User-Agent 設定的。如果爬蟲假裝自己是 Chrome 瀏覽器，那些針對爬蟲的規則就不適用：

import requests

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36"
}

# 以瀏覽器身份發送請求
response = requests.get("https://target.com/private/", headers=headers)
print(response.text)

方法三：反向利用 Disallow 清單

這是最諷刺的地方：惡意爬蟲會特別優先爬取那些被 Disallow 的路徑，因為那些往往包含更有價值的資料。

import requests
from urllib.robotparser import RobotFileParser

# 解析 robots.txt，然後反向爬取被禁止的路徑
rp = RobotFileParser()
rp.set_url("https://target.com/robots.txt")
rp.read()

# 取得所有被禁止的路徑
disallowed_paths = [entry.path for entry in rp.entries]

for path in disallowed_paths:
    url = f"https://target.com{path}"
    r = requests.get(url)
    print(f"路徑: {url} | 狀態碼: {r.status_code}")

法律提醒：在未取得授權的情況下，對他人網站進行上述操作可能觸犯法律，包含台灣《刑法》第三十六章妨害電腦使用罪等相關條款。本文的程式碼範例僅供學習理解，請務必只在自己擁有或已取得授權的環境中測試。

---

7. 現代防禦工具：真正有效的替代方案

既然 robots.txt 對惡意行為者幾乎沒有約束力，以下是真正在技術層面有效的防禦方式：

工具 / 方法	原理	能解決的問題
身份驗證（Authentication）	要求使用者登入後才能存取	敏感路徑的根本保護，不登入就直接回傳 401/403
WAF（網頁應用防火牆）	在流量進入伺服器前過濾惡意請求	阻擋已知攻擊模式、爬蟲偵測、IP 封鎖
Rate Limiting（速率限制）	限制同一 IP 在單位時間內的請求次數	防止大量自動化爬取、暴力破解
CAPTCHA / Bot Detection	透過行為分析辨別人類與機器	擋下自動化工具，保護登入、表單提交
IP 封鎖 / GeoBlocking	封鎖特定 IP 或地區的流量	快速應對已知惡意來源
Nginx / Apache 存取控制	在伺服器設定層直接拒絕存取	比 robots.txt 具備真正的技術強制力
Honeypot 路徑	設置假路徑誘捕惡意爬蟲	偵測並記錄惡意行為，提供攻擊者行為的情報

Nginx 伺服器層級存取控制範例

這才是真正「有警察」的路標——在伺服器設定中直接拒絕存取：

server {
    listen 443 ssl;
    server_name example.com;

    # 完全封鎖 /admin/，只允許內部網路存取
    location /admin/ {
        allow 192.168.1.0/24;  # 只允許內網
        deny all;              # 其他全部拒絕，回傳 403
    }

    # 封鎖常見備份檔案類型
    location ~* \.(sql|bak|backup|zip|tar\.gz)$ {
        deny all;
        return 404;  # 回傳 404 而非 403，假裝路徑不存在
    }

    # 封鎖敏感目錄和設定檔
    location ~ /\.(git|env|htaccess) {
        deny all;
    }
}

Rate Limiting 範例（Express.js）

const rateLimit = require('express-rate-limit');

// 每個 IP 每 15 分鐘最多 100 個請求
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  message: '請求過於頻繁，請稍後再試',
  standardHeaders: true,
  legacyHeaders: false,
});

// 只對 API 路由套用限制
app.use('/api/', limiter);

縱深防禦（Defense in Depth）：好的資安防禦不靠單一工具。上述工具應該組合使用——身份驗證作為第一道門，WAF 過濾惡意流量，Rate Limiting 防止暴力測試，伺服器設定確保敏感路徑即使知道位置也進不去。

---

8. 正確的安全設計思維

「不被看見」不等於「安全」

把路徑寫在 robots.txt 的 Disallow 裡，只是讓搜尋引擎不去索引它。但「不在 Google 搜尋結果裡」跟「安全」之間，有很大的距離。

這種錯誤的思維方式在資安領域有個名字叫做 Security through Obscurity（透過隱晦達到安全）——靠著藏起來而不是真正設防。這是最不可靠的安全策略，因為它假設攻擊者找不到目標，但攻擊者通常比你預期的更有耐心，也有更多工具。

# 錯誤思維
「我把後台路徑寫在 robots.txt 的 Disallow 裡，
 Google 不會索引它，就沒人知道它在哪了。」

# 正確思維
「所有敏感路徑都必須有身份驗證保護。
 即使攻擊者知道 URL，沒有帳號也進不去。
 robots.txt 我只用來做 SEO，不依賴它做安全。」

關於在 robots.txt 裡寫假資訊

有些人建議在 robots.txt 裡故意填假路徑，讓爬蟲浪費時間。這個做法有一定干擾效果，但本質上還是依賴迷惑而非真正封鎖，不應當作主要防禦手段。

更有效的策略是設置 Honeypot（蜜罐）路徑——設計一些看起來有吸引力但實際上受到嚴密監控的假路徑，讓惡意爬蟲掉入其中，觸發警報並記錄攻擊者的 IP、行為模式等情報，作為後續防禦和溯源的依據。

robots.txt 真正適合的用途

用途	說明	有無資安意義
SEO 控制	不讓測試頁、重複內容出現在 Google 搜尋結果	有（間接）
節省伺服器資源	阻止爬蟲重複抓取沒有意義的路徑	無
Sitemap 引導	讓搜尋引擎更快找到重要頁面	無
防止惡意爬蟲	❌ 完全無效，不應依賴	無
保護敏感路徑	❌ 完全無效，反而可能洩漏路徑資訊	負面

---

9. 總結對照表

面向	結論
設計年代	1994 年，是上個世紀的產物，但仍在廣泛使用
對善意爬蟲（Google 等）	有效，主流搜尋引擎都會遵守
對惡意工具或攻擊者	完全無效，等於沒有
對滲透測試人員	反而是情資來源，偵查階段的必查項目
技術強制力	零，純粹依賴對方願意遵守
資安防護價值	幾乎為零，且可能洩漏敏感路徑
唯一實際功效	控制搜尋引擎索引範圍（SEO 用途）
應該怎麼用	只用於 SEO，不要把敏感路徑列在裡面
敏感路徑的正確保護方式	身份驗證 + 伺服器層級存取控制 + WAF

robots.txt 是給搜尋引擎看的 SEO 工具，不是資安防護機制。把它當防火牆用，等於在大門口貼「請勿闖入」的紙條，然後忘記裝鎖。

---

延伸學習

• OWASP Web Security Testing Guide — 滲透測試方法論
• robots.txt 官方規範 — 原始規格文件
• TryHackMe — 免費資安實戰練習平台
• PortSwigger Web Security Academy — 免費網頁資安課程（含互動 Lab）
• OWASP Top 10 — 最常見的十大網頁安全風險