もっと身近にセキュリティ

セキュリティの報告先「security.txt」

▼Webサイトの脆弱性を発見したら
誰かがWebサイトの脆弱性を発見した時に、Webサイトの作成者にどのように連絡すればよいのでしょうか?

報告先が分からなければ報告されず脆弱性がそのまま放置されてしまいます。そんな問題に対して、発見者が脆弱性等の報告をするための情報をWebサイトの作成者が提供できるようにする仕様「security.txt」がIETFに提出されています。
https://tools.ietf.org/html/draft-foudil-securitytxt-00

ちなみに、IETF(Internet Engineering Task Force)とはインターネットで利用される様々な技術の標準について考える組織です。

通信プロトコルやデータ形式など、インターネットの技術標準の策定を行っています。IETFで決定された規格は「RFC」(Request For Comments)と呼ばれる文書にまとめられ、公開されます。例えばHTTP/2にはRFC7540という番号が振られています。

 

▼WHOISでよいのでは?
この「security.txt」は、様々なWebサイトの脆弱性を仕事や趣味で調べる脆弱性ハンターのような方々には便利な情報かもしれません。しかし、「security.txt」がなければWebサイトの作成者やしかるべき機関に報告することができないのでしょうか?

既にWHOISという仕組みがあります。WHOISを使えば、誰がどのドメインをどのサーバーで管理しているかといった情報を閲覧できます。WHOIS情報にはAbuse Contact Emailという項目があり、この項目がドメインに問題があった時の連絡先になっています。

その他、Webサイトの運営会社の情報があればその会社に電話をかけるという方法も考えられます。

 

▼課題は多い
「security.txt」は「robots.txt」と同じようにドメイン直下のディレクトリに設置します。したがって、Webサイトの脆弱性に気づいて「security.txt」に書かれている連絡先に連絡しようと思っても、「security.txt」が既に改竄されているかもしれないという問題があります。

一方、WHOISはドメインの管理組織が情報を持っているため、Webサイトもろとも連絡先が改竄される懸念はありません。「security.txt」が改竄されていないことを証明できるのは、Webブラウザの開発元のWebサイトぐらいでしょう。
また、「security.txt」に書かれたメールアドレスは の送信先として掻き集められ、攻撃の標的になります。

「security.txt」は連絡先だけでなく、報告を受け付けた場合の開示ポリシー等も記述できる特徴があります。しかし、そもそも脆弱性について外部から情報を受け付けようとしない組織は「security.txt」を設置しません。

このように、技術的な仕組みとして課題が多いため規格化は難しいと考えられます。IETFではどのような議論がなされていくのでしょうか。

 

ちなみに国内ではIPA(独立行政法人情報処理推進機構)が脆弱性関連情報の届出を受け付けています。
https://www.ipa.go.jp/security/vuln/report/