プロジェクトの複数の場所でこのセキュリティ上の欠陥に直面しています。この欠陥が発生するたびにチェックするためのホワイトリストはありません。ESAPI 呼び出しを使用して、ファイル名の基本的なブラックリスト チェックを実行したいと考えています。ESAPI の SafeFile オブジェクトを使用できると読みましたが、その方法と場所がわかりません。
以下は私が思いついたいくつかのオプションです。どれがうまくいくか教えてください。
ESAPI.validator().getValidInput()また
ESAPI.validator().getValidFileName()
ブラックリストは勝ち目のないシナリオです。これは、既知の脅威からのみ保護できます。ここで使用するコード スキャン ツールは、引き続き脆弱性を報告します... ブラックリストは脆弱性であるためです。OWASPからのこのメモを参照してください。
「ネガティブ」または「ブラックリスト」検証とも呼ばれるこの戦略は、ポジティブ検証の弱い代替手段です。基本的に、%3f や JavaScript などの文字が表示されることが予想されない場合は、それらを含む文字列を拒否してください。考えられる不良データのセットは潜在的に無限であるため、これは危険な戦略です。この戦略を採用すると、「既知の悪い」文字とパターンのリストを永久に維持する必要があり、定義上、保護が不完全になります。
また、文字エンコーディングと OS もこれを問題にします。*.docx ファイルのアップロードを受け入れるとしましょう。考慮すべきさまざまなコーナー ケースを次に示します。これは、ポートフォリオ内のすべてのアプリケーションに当てはまります。
\Windows と/Linux にあります。) スペースは、システム間でファイル/ディレクトリ パスの扱いも異なります。netcat.exeした場合、アプリケーションは実際に、アップロードされているファイルにexe ファイルのマジック ナンバーfoo.docxが含まれているかどうかを確認しますか?これがあなたの会社のポートフォリオに対して複数のアプリケーションにまたがっている場合、これを明確に述べることがあなたの倫理的義務であり、あなたの会社はアプリ/アプリごとのホワイトリストを作成する必要があります.
ESAPIに関する限り、Validator.getValidInput()拒否したいすべてのファイルのORである正規表現を使用します。validation.propertiesあなたは次のようなことをします：Validator.blackListsAreABadIdea=regex1|regex2|regex3|regex4
ブラックリストの解析ペナルティも高いことに注意してください...すべての入力文字列は、ブラックリスト内のすべての正規表現に対して実行する必要があります.OWASPが指摘しているように、これは無限になる可能性があります.
繰り返しますが、正しい解決策は、ポートフォリオ内のすべてのアプリケーション チームにアプリケーションのホワイトリストを作成させることです。これが本当に不可能な場合 (そして私はそうは思いません)、ここで引用されているリスクを経営陣に明確に述べていることを確認する必要があります。また、会社がそのリスクを受け入れることを選択したという文書を作成するまで、ブラックリスト アプローチを続行することを拒否する必要があります。危険。これにより、ブラックリストが失敗し、法廷に持ち込まれた場合の法的責任から保護されます.
[編集]
お探しのメソッドはHTTPUtilites.safeFileUpload() 、承認基準としてここにリストされていますが、上記で投稿した問題のために実装されなかった可能性があります。ブラックリストは、アプリケーションに合わせて非常にカスタマイズされています。あなたが得る最善の方法は、キーの下でHTTPUtilities.getFileUploads()定義されたリストを使用する方法ですESAPI.propertiesHttpUtilities.ApprovedUploadExtensions
.classただし、ユーザーがファイルをシステムにアップロードすることを望んでいないため、デフォルトのバージョンをカスタマイズする必要がありますdll。
また、注意してください：このソリューションはaであり、aではwhitelistありませんblacklist.