robots.txtに管理画面のURLを書くリスク｜「隠す」つもりが公開になる理由【第3回】～東京・札幌のWEB・システム・コンテンツ制作＞ブレッセ

前回までは、robots.txtとnoindexを併用したときに出る警告について、実害の有無を整理してきました。今回からは少し方向を変えて、robots.txtのもうひとつの側面をお話しします。

「検索エンジンに拾われたくないから」という理由で、管理画面やログインページのパスをrobots.txtのDisallowに書いた経験はないでしょうか。実は弊社にご相談いただくサイトでも、時々見かける設定です。悪意があるわけではなく、むしろ真面目に対策しようとした結果なのですが、この書き方は残念ながら逆方向に働いてしまいます。

robots.txtは、誰でも読めるファイル

まず前提の確認です。`https://自社ドメイン/robots.txt`は、ログインもパスワードも必要なく、誰でもブラウザから直接開けます。これは不具合ではなく、仕様です。検索エンジンのクローラーに指示を伝えるためのファイルなので、公開されていなければ役目を果たせません。

つまり、そこに管理画面のパスを書くということは、**「大事なものはここにあります」と書いた案内板を、玄関先に出しているのと同じ状態**になってしまいます。

Google検索セントラルの公式ドキュメントも、robots.txtはページを非公開にするための仕組みではないとはっきり書いています。検索結果に表示させたくない場合はnoindexを使うか、パスワードでページを保護してください、という案内です。「隠すため」の道具ではない、というのがGoogle自身の説明なのです。

セキュリティの世界では、まずrobots.txtを

ここは少し驚かれるかもしれません。

Webアプリケーションのセキュリティテストの現場では、robots.txtの中身を確認することが、調査の初手として当たり前に扱われています。OWASP(Webアプリケーションセキュリティの国際的な標準を策定している団体)が公開しているテストガイドにも、robots.txtのようなメタファイルを分析して、隠されたパスや機能を特定する手順が、情報収集フェーズの項目として記載されています。

つまり「検索エンジンには見せたくない場所」の一覧は、調べる側にとっては最初に目を通す資料になっているということです。

実際の解説記事でも、robots.txtの記述そのものが手がかりになってしまった例が紹介されています。あるセキュリティ技術者のブログでは、robots.txtの中に`/admin/`や`/api/`といったディレクトリの場所が明記されているケースを取り上げ、これが攻撃対象を特定するための「宝の地図」として機能してしまうと指摘しています。

さらにこの記事は、検索エンジンからパスを隠せば安全だと考える「Security by Obscurity(隠蔽によるセキュリティ)」という発想そのものが、機械的なスキャンツールの前では通用しないことを示す例だとも述べています。

別の解説でも、robots.txtは検索エンジンのクローラーとの協調を意図したものであり、機密性の高いパスをそこに開示すると、悪意ある第三者に不正アクセスや攻撃対象の特定に使われかねない情報を与えてしまう、と注意が促されています。この種の問題は、脆弱性の分類体系であるCWE-200(情報漏洩)に該当するものとしても扱われています。

—

もしご自身のサイトのrobots.txtに、管理画面やログインページ、あるいは社内向けのディレクトリを書いた記憶があるなら、一度開いて確認してみてください。「これは書かなくてもよかったかもしれない」という行が見つかるかもしれません。

見つかったとしても、慌てる必要はありません。次回は、こうした情報を実際に探すツールがどこまで一般化しているのか、そして本当に守りたいものをどのレイヤーで守るべきなのかを、具体的にお話しします。