あなたのWebサービスの脆弱性を発見者から教えてもらう方法 - RFC9116が発表されました
先日、RFC9116が発表されました🚀
あなたのWebサービスに潜在する未知の脆弱性を誰かが見つけた時、それをあなたに連絡する方法を提示するsecurity.txt
を標準化するものです。
この記事では何故これが必要だったのか、そして私たちがこれを実装する方法を簡潔に説明します。
なぜこれが必要だったのか
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
ジェネレータが用意されています。
最低Contact(連絡先)とExpires(security.txt
自体の失効日)さえ指定しておけば生成することが出来ます。
上の入力内容だと以下のようなsecurity.txt
が生成されます
この内容をあなたのwebサイトの/.well-knonw/security.txt
にコピペしておけば無問題です!(でもContactはよく見る連絡先にしておくのをおすすめします。気づけなかったら意味がありませんから・・・)
まとめ
-
security.txt
を使って脆弱性発見者への報告先を開示するRFCが正式に発表された - webサイトの
/.well-known
下にsecurity.txt
を置く - web上で簡単に
security.txt
は生成できる
個人的にはHiringの項目があるのがが少し面白かったです。
Discussion