注意: この記事はLLMによって英語から翻訳されたものです。正確性については保証いたしかねますので、あらかじめご了承ください。英語の原文はこちら。
最近、初めてのCVE（CVE-2023-22481 - FreshRSSログファイルにおける機密情報の漏洩）を報告したことをきっかけに、発見した内容、過剰なログ記録がこのケースで引き起こした可能性のある問題、そしてログ記録のベストプラクティスについて書きたいと思います。
発見した内容#
最近FreshRSS（素晴らしいソフトウェアで、ぜひおすすめします）を使い始め、スマートフォンからすべてを読めるようにモバイルアプリケーションをインストールしました。アプリケーションをインストールした後、ユーザー名とパスワードでログインしようとしましたが、アクセスが拒否されました。たまたまサーバーにSSHコンソールを開いていたので、ログを確認したところ、以下の内容を発見しました：
[_POST] => Array
(
[Email] => MyUserName
[Passwd] => MyPassword
)
[_COOKIE] => Array
(
)
[INPUT] => Email=MyUserName&Passwd=MyPassword「ちょっと待て」と思いました。「あれは私のパスワードそのものじゃないか」。そこでソースコードをダウンロードし、APIを使用した際に何が起きているのかを調べました。以下が見つけた内容のスニペットです：
if user exists:
if user configuration is missing:
log the error and dump the request's headers, get, post, and cookie values
if password is correct:
accept login
else if password is incorrect:
log the error and dump the request's headers, get, post, and cookie values
else if user does not exist:
log the error and dump the request's headers, get, post, and cookie values基本的に、認証が失敗した場合、HTTPログインリクエスト内のすべてのデータがソフトウェアのログファイルとsyslogに記録されていました。
疑似コードではパスワードと記載していますが、実際に期待されていたのはAPIキーでした（ユーザーパスワードはUIでのみ使用可能）。
どのような影響があり得たか？#
このソフトウェアが複数のユーザーで本番運用されていた場合、以下のことが起こり得ました：
- ユーザーが間違ったユーザー名とAPIキーを入力する
- ユーザーが誤って別のサービスで使用しているユーザー名とパスワードを入力する
- ユーザーがユーザー名とアカウントパスワードを入力する（期待されるAPIキーではなく）
- ユーザーが有効なユーザー名とAPIキーを入力するが、何らかの理由でログイン時に設定ファイルが読み取れない
悪意のあるユーザーがログファイルを読み取れるバグを悪用した場合（syslogはデフォルトですべてのユーザーがアクセス可能であることに注意）、以下のことが可能になります：
- パスワードを使用してそのユーザーとしてソフトウェアにログインする（ユーザーの個人データが漏洩し、攻撃対象領域が拡大する）
- ログインIDとパスワードを使ってクレデンシャルスタッフィングを行い、そのユーザーが所有する他のアカウントにアクセスする可能性がある
適切なログ記録のプラクティス（概要）#
ログ記録はシステムに必要なものです。システムやユーザーが経験する問題のトラブルシューティングに役立つだけでなく、セキュリティインシデントの調査にも役立ちます。
しかし、過剰なログ記録も問題になり得ます。詳細すぎるログは、前述の例で見たようなセキュリティリスクや法的リスクなど、さまざまなリスクを生み出す可能性があります。
経験則として、パスワード、APIキー、PII（例えば健康データ、クレジットカード番号、公的ID番号）、ログ記録システムが保存を許可されているセキュリティ分類より高いデータなどは、絶対にログに記録してはいけません。何をログに記録できるか（または記録すべきか）は、対象となる規制や基準（例えばGDPR、PCI DSS、HIPAA）にも依存します。
イベントデータの過剰なログ記録（例：HTTPリクエストの全内容）は避けるべきですが、システムに関連するすべてのイベントはログに記録する必要があります。例えば（これに限定されませんが）：
- データ検証の失敗
- ユーザー認証（失敗と成功）
- 認可の失敗
- システムの状態変更（アプリケーションの起動、停止、など）
- 機密データのアクセスとデータの変更
- 特権アクセスの使用（新規ユーザーの追加、パスワードの変更、など）
- アプリケーションとシステムの障害やエラー
- データのエクスポート
このようなものをログに記録する際は、「誰が？いつ？どこで？何を？」という質問に答えることを心がけてください。ログに記録する内容によっては、追加情報を含めたい場合もあるでしょう（例えば、プログラムが失敗した場合のJava例外など）。
先ほどの状況におけるログの例としては、[IP] [Date] Authentification failed for username [username] : wrong passwordのようなものが考えられます。
要するに、「インシデントが発生した場合、ログだけを見て原因を特定し、何が起きたかを理解するのに十分な情報があるか？」と考えることが重要です。
まとめ#
ログ記録は広大なテーマであり、ブログ記事一つですべてを語ることはできませんが、ログ記録についてもっと学びたい方には、OWASPの非常に優れた詳細なチートシートがあります。こちらで紹介した Practical Monitoring という書籍も素晴らしいリソースです。
ログ記録について語る際に言及する価値があるのは、過剰なデータをログに記録することによる金銭的コストと、サニタイズされていないデータをログに記録するリスク（log4j）です。
クレジット#
- カバー写真: Jake Walker（Unsplash）