あなたのWebサービスの脆弱性を発見者から教えてもらう方法 - RFC9116が発表されました

先日、RFC9116が発表されました🚀

あなたのWebサービスに潜在する未知の脆弱性を誰かが見つけた時、それをあなたに連絡する方法を提示するsecurity.txtを標準化するものです。

この記事では何故これが必要だったのか、そして私たちがこれを実装する方法を簡潔に説明します。

https://www.rfc-editor.org/rfc/rfc9116

なぜこれが必要だったのか

https://securitytxt.org/のSummary(概要)にはこのように書かれています。

Webサービスのセキュリティリスクが、リスクの重大性を理解している独立したセキュリティ研究者によって発見された場合、それらを適切に開示するためのチャンネルが不足していることがよくあります。 その結果、セキュリティの問題が報告されないままになる可能性があります。 security.txtは、組織がセキュリティ研究者がセキュリティの脆弱性を安全に開示するためのプロセスを定義するのに役立つ標準を定義しています。

つまり、

• 今まではセキュリティ研究者がWebサービスの運営者に脆弱性を報告する宛がなかった
• security.txtは脆弱性報告のプロセスを発見者向けに定義するのに役立つ

ということです。

私たちが実装する方法

実はsecurity.txtはいくつかの組織で既に定義されていますし、私たちが実装するのも非常に簡単です。

実装されている例

• Google - https://www.google.com/.well-known/security.txt
• Facebook - https://www.facebook.com/.well-known/security.txt
• Github - https://github.com/.well-known/security.txt

上の例のように、定められたフォーマットのsecurity.txtをWebサイトの指定の場所に置くことで実装できます。

どこに置く？

あなたのドメインの/.well-known/ディレクトリ下に置きます。置く場所は自由に決められるものではない点は注意が必要です。(もし/.well-knownディレクトリってなに？という疑問を持った方はRFC8615を参照してください)

フォーマットがあるんでしょ？

あります。詳細はRFC9116で見ることが出来ます。

「実際にフォーマットを見ながら書くのは労力が・・・」というあなたのためにsecuritytxt.orgにsecurity.txtジェネレータが用意されています。

https://securitytxt.org/

最低Contact(連絡先)とExpires(security.txt自体の失効日)さえ指定しておけば生成することが出来ます。

上の入力内容だと以下のようなsecurity.txtが生成されます

この内容をあなたのwebサイトの/.well-knonw/security.txtにコピペしておけば無問題です！(でもContactはよく見る連絡先にしておくのをおすすめします。気づけなかったら意味がありませんから・・・)

まとめ

• security.txtを使って脆弱性発見者への報告先を開示するRFCが正式に発表された
• webサイトの/.well-known下にsecurity.txtを置く
• web上で簡単にsecurity.txtは生成できる

個人的にはHiringの項目があるのがが少し面白かったです。