信頼できないファイルやその他のリソースが安全に処理され、サービス拒否、認可されていないアクセス、リソース枯渇を防ぐことを確認します。
# | 説明 | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
1.12.1 | [削除, 12.4.1 と重複] | ||||
1.12.2 | [削除, 50.6.1 へマージ] | ||||
1.12.3 | [追加] アプリケーションがファイルのアップロードを許可している場合、ドキュメントでは各アップロード機能で許可されるファイルタイプ、想定されるファイル拡張子、最大サイズ (展開後のサイズを含む) を定義している。さらに、ドキュメントにはエンドユーザがファイルをダウンロードして処理する際に安全を確保する方法を指定している。 | ✓ | ✓ | ✓ |
アップロード機能は信頼できないファイルの主な発生源です。これらを慎重に検証して、サービス拒否、認可されていないアクセス、リソース枯渇などのリスクを防ぐ必要があります。
# | 説明 | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.1.1 | [修正] アプリケーションはパフォーマンスの低下やサービス拒否攻撃を引き起こすことなく処理可能なサイズのファイルのみを受け付けている。 | ✓ | ✓ | ✓ | 400 |
12.1.2 | アプリケーションが圧縮ファイル (zip, gz, docx, odt など) を展開する前に最大許容非圧縮サイズおよび最大ファイル数と照合している。 | ✓ | ✓ | 409 | |
12.1.3 | 1 人のユーザがあまりにも多くのファイルまたは極端に大きいファイルでストレージを圧迫させることができないように、ユーザあたりのファイルサイズクォータと最大ファイル数が適用されている。 | ✓ | ✓ | 770 | |
12.1.4 | [追加] 特に必要な場合 (その場合、シンボリックリンクできるファイルの許可リストを適用する必要がある) を除き、アプリケーションはシンボリックリンクを含む圧縮ファイルのアップロードを許可していない。 | ✓ | ✓ | 61 |
アップロードされたファイルやアーカイブ内にアップロードされたファイルは、想定されるファイルタイプとコンテンツ形式と一致していなければなりません。また、サイズが大きすぎる画像をブロックして、ピクセルフラッド攻撃を防がなければなりません。
# | 説明 | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.2.1 | [修正] アプリケーションはファイルを受け入れる際に、それ自体または zip ファイルなどのアーカイブ内のいずれかで、ファイル拡張子が予期されるファイル拡張子と一致するかどうかをチェックし、内容がその拡張子で表されるタイプに対応しているかどうかを検証している。これには最初の 'マジックバイト' のチェック、イメージの再書き込みの実行、ファイル内容のバリデーションのための専用ライブラリの使用が含まれるがこれに限定されない。 | ✓ | ✓ | 434 | |
12.2.2 | [追加] アプリケーションはピクセルフラッド攻撃を防ぐために、許容される最大値を超えるピクセルサイズのアップロードされた画像をブロックしている。 | ✓ | ✓ | ✓ | 400 |
ファイル操作では、パストラバーサルやインクルージョン攻撃を回避するために、ユーザが送信したファイル名やメタデータに依存すべきではありません。また、サーバサイドのファイル処理ではユーザが提供したパスの詳細を無視して、zip スリップなどの脆弱性を防ぐ必要があります。
# | 説明 | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.3.1 | [修正, 12.3.2, 12.3.3, 5.3.9 からマージ] ファイル操作では、パストラバーサル、ローカルまたはリモートファイルインクルージョン (LFI, RFI)、サーバサイドリクエストフォージェリ (SSRF) 攻撃から保護するため、ファイルパスを作成する際にユーザが送信したファイル名やファイルメタデータの使用を避けている。代わりに、ファイル I/O には内部の信頼できるデータを使用する。ユーザが送信したファイル名やファイルメタデータを使用しなければならない場合は、厳密なバリデーションとサニタイゼーションを適用しなければならない。 | ✓ | ✓ | ✓ | 73 |
12.3.2 | [削除, 12.3.1 へマージ] | ||||
12.3.3 | [削除, 12.3.1 へマージ] | ||||
12.3.4 | [12.5.3 へ移動] | ||||
12.3.5 | [削除, 5.3.8 と重複] | ||||
12.3.6 | [削除, 14.2.4 と重複] | ||||
12.3.7 | [追加] zip スリップなどの脆弱性を防ぐために、ファイル展開などのサーバサイドのファイル処理が、ユーザから提供されたパス情報を無視する。 | ✓ | ✓ | ✓ | 23 |
信頼できないソースからのファイルは、パブリックフォルダに保存される場合、サーバサイドコードとして実行可能であってはなりません。また、信頼できないソースからのファイルはアンチウィルスソフトウェアでスキャンして、悪意のあるコンテンツの提供を防がなければなりません。
# | 説明 | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.4.1 | [修正] 信頼できない入力によってアップロードまたは生成され、パブリックフォルダに保存されたファイルは、エンドユーザが直接アクセスした場合、サーバサイドのプログラムコードとして実行可能ではない。 | ✓ | ✓ | ✓ | 552 |
12.4.2 | 信頼できない場所から取得したファイルが、アプリケーションが想定する種類であることを検証し、既知の悪性コンテンツがアップロードおよび配信されるのを防止するためにアンチウイルスソフトで検査する。 | ✓ | ✓ | ✓ | 509 |
ダウンロードでの Content-Disposition ヘッダでは、ユーザが送信したファイル名は検証されるか無視されるべきです。また、提供されたファイル名はエンコードするかサニタイズして、インジェクション攻撃を防ぐ必要があります。
# | 説明 | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.5.1 | [14.3.6 へ移動] | ||||
12.5.2 | [50.6.1 へ移動] | ||||
12.5.3 | [修正, 12.3.4 から移動] アプリケーションが JSON、JSONP または URL パラメータに含まれるユーザが送信したファイル名をバリデートまたは無視し、レスポンスの Content-Disposition ヘッダフィールドでファイル名を指定している。 | ✓ | ✓ | ✓ | 641 |
12.5.4 | [追加] 提供されるファイル名 (HTTP レスポンスヘッダフィールドや電子メールの添付ファイルなど) は、ドキュメント構造を保持し、インジェクション攻撃を防ぐために、エンコードまたはサニタイズされている (RFC 6266 に従うなど)。 | ✓ | ✓ | ✓ |
# | 説明 | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.6.1 | [14.6.1 へ移動] |
アプリケーションは、データベース接続、オープンファイル、スレッドなどのシステムリソースを使用後に解放し、リソース枯渇を防がなければなりません。
# | 説明 | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.7.1 | [追加] アプリケーションは、データベース接続、オープンファイル、スレッドなどのシステムリソースを使用し終わると、リソースの枯渇を防ぐために積極的に解放している。 | ✓ | ✓ | 404 |
詳しくは以下の情報を参照してください。