機密情報の漏洩: OAuth2 client secret が管理者設定で露出 (マスク未処理)

問題の説明

カスタムされた Discourse デプロイメントのセキュリティレビュー中に、管理画面の「設定」インターフェイスにおいて、OAuth2 クライアントシークレットに関する潜在的な機密情報漏洩を発見しました。

詳細

  • 管理者の設定ページでは、OAuth2 クライアントシークレット(およびその他の機密性の高いトークン/キーの可能性)が、マスク(例:アスタリスクで表示)されるのではなく、プレーンテキストで表示されています。

  • 管理者は、プレーンテキストのシークレットを直接設定に入力する必要があります。管理者 UI にアクセスできるユーザーなら誰でも、シークレット全体を見ることができます。

  • 攻撃者が管理者セッションに(一時的であっても)アクセスした場合、クライアントシークレットを容易に取得し、不正な OAuth2 トークン要求や、サードパーティサービスへの要求の偽装に使用できます。

セキュリティへの影響

  • 管理者 UI でのシークレットのプレーンテキスト表示は、認証情報の漏洩リスクを高めます。

  • マスキングの欠如は、シークレットの取り扱いに関するセキュリティベストプラクティスに準拠していません。

  • シークレット/トークンは、権限昇格、なりすまし、または統合サービスに対するさらなる攻撃に悪用される可能性があります。

質問

  • 管理者の設定 UI で OAuth2 シークレットのような機密フィールドをマスクする(例:必要に応じて表示するオプション付きで ****** として表示する)計画はありますか?

  • Discourse デプロイメントにおける機密性の高い認証情報の保護を強化するためのお勧めの方法やプラグインはありますか?

  • この問題は以前に議論されましたか?公式の修正が行われるまでの回避策はありますか?

この重要なセキュリティ上の懸念にご注意いただきありがとうございます!

@Evie_Tao さん

多くのセキュリティ上の懸念を報告されていますが、GitHubリポジトリで説明されているように、HackerOneで報告することを検討されましたか?

「いいね!」 2

管理者への情報開示は問題とは考えていませんが、google_oauth2_client_secretなどと同様に、不必要に表示されないように機密情報としてマークされるべきです。

これは簡単な修正です:

秘密性と利便性にはトレードオフがあります。UIでシークレットをマスクできないようにしても、アクセスできないという幻想を与えるだけです。データベースから管理者が簡単に読み取る他の方法もあります。

ただし、環境変数経由でシークレット(実際には任意のサイト設定)を指定できます。そうすれば、管理UIに表示されなくなります。

@pmusarajさん、そうですよね?)

「いいね!」 2