jimble

セキュリティ#

脆弱性を見つけたら#

公開の Issue を立てないでください。

GitHub の非公開報告から知らせてください。

https://github.com/hidemikimura/jimble/security/advisories/new

やりとりも修正も公表も、そのスレッドの中で完結します。 **メールの窓口は用意していません。**受け口を1つにして、見落としを作らないためです。

書いていただけると助かるもの。

  • どの版で起きるか(0.3.0 など)
  • どのモジュールか(jimble-web など)
  • 再現の手順、できれば最小のコード
  • 何ができてしまうか

受け取ったあと#

受領の返事 数日以内。返事が無ければ届いていない可能性があります
修正の期限 約束していません(個人で開発しているためです)。影響の大きいものから手を付けます
公表 直った版を出してから、GitHub Security Advisory として
クレジット 報告してくださった方のお名前を載せます(不要と言われれば載せません)

どの版が直るか#

**最新の版に修正を入れます。**古い版へのバックポートはしません。 まだ 0.x なので、上げていただくのがいちばん早い道です。

対象の範囲#

対象になるもの — Maven Central に公開している io.jimble のライブラリと Gradle プラグイン。

対象にならないもの。

  • **examples/ のサンプルアプリ。**説明のためのもので、本番に置くようには作っていません。 接続情報も鍵も既定値のままです。そのまま動かさないでください
  • このドキュメントサイトの見た目や内容
  • **依存ライブラリそのものの脆弱性。**Dependency graph と Dependabot で追いかけています。 ただし「jimble の使い方のせいでそこに手が届く」のであれば対象です
  • 設定でそうすると決めたもの。server.trust_proxy = true にすれば X-Forwarded-For を 信じます(既定は false)。書いてあるとおりの動きは脆弱性ではありません

落とし穴

ドキュメントと実装が食い違っているなら、それは脆弱性として扱います。 「そう書いてあるから安全だと思っていた」が、いちばん危ない読み違いです。

自分のアプリを固くする#

jimble 側で用意しているものは、それぞれのページにあります。

何を どこに
セッションと CSRF、署名つき Cookie、鍵の入れ替え セッションとセキュリティ
流量制限と Bot 対策 流量制限
プロキシヘッダを信じるかどうか サーバー
エラー応答に内部情報を載せない エラー
鍵と接続情報の置き場 設定