ユーザー提供の入力が必須のビジネスケースである場合、ディレクトリトラバーサルを緩和するにはどうすればよいですか？
管理ユーザーが指定したsftpコマンドを設定する機能を必要とするアプリケーションがあるインスタンスがあります。これらは、アプリケーションのフロントエンドを介して構成されます。 Veracodeは、ここでディレクトリトラバーサル攻撃を正しく識別しています。
私はB2B企業で働いています。このsftpプロセスは、クライアントが自分のシステムのディレクトリ構造を指定してファイルを送受信するためのものです。
接続はAPIを介して処理され、現在のライブラリは入力としてデータを正しくエスケープします（つまり、「../ && rm *」を送信すると、「cd」のディレクトリとして扱われます。コピーするターゲットファイルISシステムによって明示的に制御されますが、常にそうであるとは限りません。
しかし、 "../"のような特定のディレクトリパスをブラックリストに登録しないと、この攻撃を防ぐために使用できるアプリケーションレベルでの他の戦略について迷っています。
追加情報
誤解している可能性があります。問題は、アプリケーションがサーバー上で独自のインスタンスとして実行されることです。 Chrootの刑務所は私たちの側では問題ありませんが、クライアントのサーバーはどうですか？ビジネスロジックでは、指定したシステム上のディレクトリにファイルを配置します。それを制御することはできません。また、アプリケーションにファイルを保存するディレクトリを正確に指定できる柔軟性が必要です。
あなたは何を見逃したのかわからないので、私はブラックリストのアプローチが好きではありません。そして理論的には、このプロセスはunixボックスではなくWindowsボックスをポイントするように設定でき、リモートサーバーでの環境検出は言うまでもなく、突然コード化する必要があるブラックリストルールの2つのセットがあります。
- chroot刑務所。各クライアントは、a）システムまたはb）他のクライアントにアクセスできないディレクトリ階層に接続する必要があります。
- 入力の検証。ええ、.. /、$、*などをブラックリストに登録する必要があります。APIを制御できる場合は、cdに渡そうとする前にディレクトリの存在をテストするなど、さらに良い方法があります。防御的プログラミングが進むにつれ、これはロケットサイエンスではないので、ええ、少し厄介ですが、それは正しいことです。
次のロジックは、通常、ディレクトリトラバーサルから保護します。
- ディレクトリ/ファイル名は、
../などを解決する絶対+正規パスに展開する必要があります。詳細は getCanonicalPath を参照してください - パスを許可されたパスのホワイトリストと比較します
ブラックリストは含まれていません。
ケースシナリオまたは特定の懸念を完全に理解しているかどうかはわかりませんが、上記は多くのユースケースで機能する傾向があります。