完全なhttpリクエストを適切にログに記録することが悪い習慣になるのはなぜですか？
私は現在、Veracodeがコード分析ツールと一緒に提供するセキュアコーディングプラクティスのドキュメントを調べています。
「安全なロギングの実践」セクションでは、エラーが発生した場合の完全なHTTPリクエストのロギングはよくある間違いであると述べていますが、その理由については説明していません。
私は2つの個別のログファイルがある個人のWebサイトで作業しています。
errors.log：予期しない例外が発生すると、そのファイルに捕捉されてログに記録されます。そこで、私は単にスタックトレースをログに記録します（クラシックでシンプルな基本的な例外ロギング）
security.log：偽造されたリクエストのサインである、UIを介して作成できなかったリクエスト（例：他のユーザーからのデータにアクセスしようとするIDORの試み）により、カスタムランタイムセキュリティ例外がスローされます。そのセキュリティ例外には、作成されたHTTPリクエストが特に保存され、ログに記録されます。基本的に、すべてのバックエンドバリデーター（フロントエンドバリデーターと同じチェックを行う）は、何か問題が発生したときにこのセキュリティ例外をスローします。つまり、私（またはCronnedタスク;））は定期的にsecurity.logが空であることを確認できます。
私は完全なhttpリクエストをログに記録することに決めました（つまり、生のリクエストではありませんが、すべてのヘッダー/ Cookieとパラメーターを抽出し、それらを読み取り可能な方法で表示し、タイムスタンプ、Origin IPなどの情報も表示します）。セキュリティ例外のみ（潜在的なビジネスロジック関連の攻撃の分析を容易にするため）。
そのログファイルはテキストエディターでのみ開かれ（おそらくVI）、ツールによって自動的に解析されたり、Webアプリで表示されたりすることはありません。
現在、完全なHTTPリクエストのロギングは、いくつかの条件下で活用できることを理解しています。典型的な例は、ヘルプデスクが使用するXSS攻撃を受けやすいログ分析Webアプリケーションです。この場合、攻撃者は、ヘルプデスクの担当者が脆弱なWebアプリケーションを介してログの内容を確認すると、悪意のある要求を偽造してペイロードを爆発させる可能性があります。
あまりにも多くのものをログに記録すると、ディスクがいっぱいになってサービス拒否につながる可能性があることも理解していますが、スタックトレースの場合はすでにそうです。
私の場合、リクエストのロギングからどのような危険が発生する可能性がありますか？私が見る唯一の（技術的には有効ですが非現実的で、Webサイトの感度が低いため）特別に細工されたペイロードがVIによる解析時に何らかのバッファオーバーフローを引き起こす可能性があります（攻撃者はVI + useを使用する必要があります。 0日間など。Ok NSAの場合は可能ですが、この小さなサイトでは非現実的ですが、一部のスクリプトキディ以外の対象ではありません）。
誰かがログ偽造を行うことができると思いますが、私のユニークなリクエスト表示を見つけて頑張ってください：Pリクエストでデータを抽出して自分の方法で表示するので、ログ偽造によって私をだますことは事実上不可能です。
ファイルの終わりVI制御文字を具体的に確認する必要がありますか（存在するかどうか）。
他に何がうまくいかない可能性がありますか？ここで何か不足していますか？私の質問は言い換えることができることに気づきました。「最新のウェルによってのみ開かれる私のマシン上の単一の制御されたファイルに（リクエストコンテンツを介して）ユーザーがテキストを書き込むと、何が問題になるのでしょうか。 -実績のあるテキストエディター」
[〜＃〜]更新[〜＃〜]
最初の3つのフィードバックに関する詳細情報を提供するための更新（素晴らしいフィードバックをありがとう！）
- ログインフォームはメカニズムでカバーされていません（しかし、登録フォームは！）
- 私はショップを運営していません。機密性の高い情報はありません。最も機密性の高い情報は、ユーザー登録時の姓名と生年月日です。ポイントとランキングのあるゲームがあるので、不正行為を防ぐためにセキュリティが重要です（したがって、このカスタムロギング）
- 悪意のある（フロントエンド検証のバイパス）リクエストのみがログに記録されるという事実を主張し、ユートピアの世界では、secure-log-fileはいつまでも空のままです
あなたのフィードバックのおかげで、とりわけ次のことに気づきました：
- このファイルのコンテンツの開示により、リクエストからセッションCookieが抽出されるため、セッションハイジャックが可能になる
- リクエストパーサーのバグにより、リクエストが記録されない場合がある
- 私のコードのバグは、secu-logに機密情報を保存する不正なユーザー登録要求を記録する可能性があります（パスワードが明らかに最も機密性が高い）
取り扱い：
- ファイルの内容の開示に関しては、誰かがそこに到着した場合、私はすでに苦しんでいると思います:)
- パーサーのバグに関して、確かに、しかしそれは「通常の」ロガーに記録される例外をトリガーするでしょう、これは許容されます
- 登録フォームに関しては、そのようなまれなバグが発生したとしても、偶然にも平文のパスワードにアクセスするべきではないと考えています。
*password*パターンに一致する要求パラメーターを保管しないようにパーサーを調整します。
ユーザーを保護するために、それ以上に現実的に進むことはできないと思います（ビジネスロジック攻撃をライブで検出できるようにしたい場合）。私は、ウェブ上のサイトの99％が、これらの考慮事項の半分まで進んでいないと思います:)）。小さな追加の攻撃面は、このカスタムログが提供するセキュリティ上の利点よりも重要であることは私には明らかです。
最終的にバグのリスクを減らすために、コードベースのその部分に追加の完全な単体テストを追加します。
企業環境では、機密データのログ記録について2回推測します-データコンプライアンス担当者などとこの問題について話し合うと思います
キーワードは適切にです。
必要なときにHTTPリクエストを適切に記録することは悪い習慣ではありません。私はペンテスターであり、テストの一部として作成したすべてのHTTPリクエストをログに記録します。そうすることが期待されています。また、多数の複雑なレガシーシステムと統合するサーバーシステムにも取り組んでいます。エラー時に完全なHTTPリクエストをログに記録することは必要な機能です。クラスター内のどのシステムが誤った要求を行ったかなどの詳細を表示できます。
Veracodeは、自動化されたソースコード分析システムです。 HTTPリクエストをログ関数に渡すかどうかを確認できます。ただし、「適切に」ログを記録しているかどうかは、実際にはわかりません。ですから、彼らはこの曖昧な発見を思いついたのです。それにあまり重きを置かないでください。この問題にはリスク評価がありますか？リスクは低いと思います。ほとんどの人は自分よりも徹底的ではなく、低リスクの問題にほとんど注意を払っていません。
適切にロギングするための重要な部分は次のとおりです。
- ログインジェクション/鍛造
- サービス拒否
- ログの機密性
あなたはあなたの質問の最初の2つについて言及します。個人のWebサイトの場合、3番目のWebサイトは問題ではありません-あなたは所有者であり、システム管理者であり、すべてであり、あなただけがアクセスできます。これは、企業環境でははるかに大きな問題であり、リクエストの機密データ（ユーザーパスワードなど）に会社の全員がアクセスできるようにしたくないのは確かです。一部のシステムは、PCI準拠のために、ログのデータの一部、特にクレジットカード番号を意図的にマスクしています。
ヘッダー、Cookie、パラメーターを抽出し、ログファイルでフォーマットすることについて言及しました。生のリクエストをログに記録し、それらをフォーマットするための別のポストプロセッサーを用意することをお勧めします。奇妙な状況になります-例えばURLおよびPOST body-で重複しているパラメーター-これはエラーの原因となる可能性があります。抽出およびフォーマットすると、元の要求の機能が失われる可能性があります。
すべてをログに記録することに関する問題は、それを間違って実装する可能性があることではありません（たとえば、XSS、コード実行、バッファオーバーフローなどを許可する）。 [追加の攻撃面を提供しますが、追加のログを保持することが重要であると判断した場合は、それだけの価値があります]
問題はあなたがログに記録したものにあります：all the headers / cookies and parameters。これらには明らかに、セッションID、ログインCookie、パスワード、クレジットカード情報などの機密情報がプレーンテキストで含まれている可能性があります。
これで、悪意のあることがわかっているリクエストのみをログに記録する場合は、これらのログを記録しても問題ありません。しかし、あなたはそれを確信できますか？たぶん、有効なアクションで誤ってセキュリティ例外をスローしたり、タイプミスによる無効なログインなど、有効なユーザーが生成したセキュリティインシデントで例外をスローしたりする場合があります。
これらのログを安全に保存しても、コードに脆弱性があり、攻撃者がとにかく（たとえばLFIを介して）ログを読み取ることができる可能性があります。また、これらのログのバックアップが存在する可能性があります。または、攻撃者がサーバーへのアクセスを制限し、これらのログからその他の有用な情報を入手した可能性があります。