Skip to content

Latest commit

 

History

History
166 lines (122 loc) · 23.9 KB

0x13-V5-Validation-Sanitization-Encoding.md

File metadata and controls

166 lines (122 loc) · 23.9 KB

V5 バリデーション、サニタイゼーション、エンコーディング

管理目標

この章では、信頼できないデータの安全でない処理に関する、最も一般的な Web アプリケーションセキュリティの弱点に焦点を当てます。これは、信頼できないデータが、関連するインタプリタの構文ルールを使用して解釈され、さまざまな技術的な脆弱性につながります。

現代の Web アプリケーションでは、パラメータ化されたクエリ、自動エスケープテンプレートフレームワークなどのより安全な API を使用することが常に最善でしょう。それ以外には、出力のエンコード/エスケープやサニタイズを注意深く実行することが、アプリケーションのセキュリティにとって重要です。

この章では、入力バリデーションについても説明します。これは、予期しない危険なコンテンツから保護するための強力な多層防御メカニズムですが、特定のセキュリティコントロールとして考慮すべきではありません。

V1.5 入力および出力ドキュメント

# 説明 L1 L2 L3 CWE
1.5.1 [1.11.5, 1.11.6 へ分割]
1.5.2 [削除, 5.5.3 へマージ]
1.5.3 [11.3.4 へ移動]
1.5.4 [5.6.2 へ移動]

V5.1 入力バリデーション

HTML フォームフィールド、REST リクエスト、URL パラメータ、HTTP ヘッダフィールド、Cookie、ディスク上のファイル、データベース、外部 API など、アプリケーションが使用または処理するすべてのものはユーザ入力として処理しなければなりません。

ポジティブ許可リストと強いデータ型付けを使用して、入力バリデーション制御を適切に実装すると、アプリが受け取ることを期待するデータの種類に関するビジネスロジック制御や機能上の期待の重要な実施を提供します。ビジネスロジック制御では、特定の入力が 100 未満の数値であるべきとするかもしれません。機能上の期待では、特定の数値は特定の閾値以下であるべきです。その数値は特定のループが実行すべき回数を管理するため、高い数値は過剰な処理やサービス拒否状態につながる可能性があります。

入力バリデーションは、データが正しい形式で受信されたことを確認する上で、アプリケーションに貴重な衛生管理を提供し、可能な限りすべての入力に適用すべきです。但し、次のコンポーネントに対してデータを使用するときや、出力のためにデータを提示するときに、正しいエンコード、エスケープ、サニタイズを使用する必要性をなくしたり置き換えたりするものはありません。

# 説明 L1 L2 L3 CWE
5.1.1 [10.4.7 へ移動]
5.1.2 [10.4.4 へ移動]
5.1.3 [11.3.1 へ移動]
5.1.4 [11.3.2, 11.3.3 へ分割]
5.1.5 [修正, 50.8.1 に分割] アプリケーションは、宛先が許可リストに記載されているもののみ、アプリケーション URL から直接別の URL にユーザーを自動的にリダイレクトしている。 ✓ ✓ ✓ 601
5.1.6 [追加] アプリケーションは、HTTP リクエストヘッダフィールド内のユーザ制御の入力がサーバの最大ヘッダフィールドサイズ制限 (通常は 4kB または 8kB) を超えていないことを検証し、クライアントベースのサービス拒否攻撃を防止している。 ✓ ✓

V5.2 サニタイゼーションとサンドボックス化

信頼できないコンテンツを安全でないコンテキストで使用することに対する理想的な保護は、コンテキスト固有のエンコーディングやエスケープを使用することです。これにより、安全でないコンテンツと同じ意味を維持しながら、この特定のコンテキストで安全に使用できるようになります。これについては、次のセクションで詳しく説明します。

これが不可能な場合、他の選択肢としてサニタイゼーションとサンドボックス化があります。サニタイゼーションは、潜在的に危険な文字やコンテンツを削除します。場合によっては、入力の意味を変えるかもしれませんが、セキュリティ上の理由から選択の余地がないこともあります。サンドボックス化は、潜在的に危険な操作を封じ込め、セキュリティ上の脆弱性が生じても、より広範なアプリケーションを危険にさらすことがないようにします。

# 説明 L1 L2 L3 CWE
5.2.1 [修正] WYSIWYG エディタ等から取得した信頼できない HTML 入力が、よく知られた安全な HTML サニタイゼーションライブラリもしくはフレームワークの機能を使用して適切にサニタイズされている。 ✓ ✓ ✓ 116
5.2.2 [修正] 潜在的に危険なコンテキストに渡されるデータは、事前にサニタイズして、このコンテキストにとって安全な文字だけを許可したり、長すぎる入力を切り詰めるなどの安全対策を実施している。 ✓ ✓ ✓ 138
5.2.3 SMTP または IMAP インジェクションから保護するため、アプリケーションがメールシステムに渡す前にユーザ入力をサニタイズする。 ✓ ✓ ✓ 147
5.2.4 [修正] eval()もしくはSpring Expression Language (SpEL) などの動的コード実行機能を使用しない。代替方法がない場合は、実行前に含まれるユーザ入力のサニタイズもしくはサンドボックス化する。 ✓ ✓ ✓ 95
5.2.5 [修正] アプリケーションは信頼できない入力に基づくテンプレートの作成を許可しないことで、テンプレートインジェクション攻撃から保護している。代替手段がない場合、テンプレート作成中に動的に含まれるすべての信頼できない入力はサニタイズまたは厳密にバリデーションする必要がある。 ✓ ✓ ✓ 94
5.2.6 [修正] アプリケーションは、信頼できないデータをプロトコル、ドメイン、パス、ポートの許可リストに照らして検証し、そのデータを使用して別のサービスを呼び出す前に潜在的に危険な文字をサニタイズすることで、サーバサイドリクエストフォージェリ (SSRF) 攻撃から保護している。 ✓ ✓ ✓ 918
5.2.7 ユーザの指定した Scalable Vector Graphics (SVG) スクリプト化可能コンテンツ（特に XSS に関連するインラインスクリプトや foreignObject）に対して、アプリケーションがサニタイズまたはサンドボックス化している。 ✓ ✓ ✓ 159
5.2.8 ユーザ指定の Markdown、CSS、XSL スタイルシート、BBCode のようなスクリプト可能もしくは式のテンプレート言語コンテンツに対して、アプリケーションがサニタイズ、無効化またはサンドボックス化されている。 ✓ ✓ ✓ 94
5.2.9 [追加] アプリケーションはスラッシュを使用して、正規表現で使用される特殊文字を正確にエスケープし、制御文字として誤って解釈されないようにしている。 ✓ ✓ ✓ 624
5.2.10 [追加] 正規表現に指数関数的なバックトラッキングを引き起こす要素がないことを検証している。また、信頼できない入力をサニタイズし、ReDoS 攻撃や Runaway Regex 攻撃を軽減している。 ✓ ✓ ✓ 1333
5.2.11 [追加] アプリケーションは Java Naming and Directory Interface (JNDI) クエリで使用する前に信頼できない入力を適切にサニタイズし、JNDI を可能な限り安全に構成して JNDI インジェクション攻撃を防いでいる。 ✓ ✓ ✓ 917
5.2.12 [追加] アプリケーションは memcache に送信する前にコンテンツをサニタイズし、インジェクション攻撃を防いでいる。 ✓ ✓
5.2.13 [修正, 5.4.2 から移動] 使用時に、予期しないあるいは悪意のある方法で解決される可能性のあるフォーマット文字列は、処理される前にサニタイズされている。 ✓ ✓ 134

注: SVG フォーマットはほとんどすべてのコンテキストで ECMA スクリプトを明示的に許可するため、SVG XSS ベクトルを完全にブロックすることはできないかもしれません。SVG のアップロードが必要な場合、アップロードされたファイルを text/plain として提供するか、ユーザが提供する別のコンテキストドメインを使用して、XSS がアプリケーションを乗っ取るのを防ぐことを強くお勧めします。

V5.3 インジェクション防御

潜在的に危険なコンテキストの近くあるいは隣接する場所での出力エンコーディングやエスケープは、あらゆるアプリケーションのセキュリティにとって重要です。通常、出力エンコーディングとエスケープは永続化されるのではなく、適切なインタプリタですぐに使用できるように出力を安全にするために使用されます。これをあまりに早い段階で行おうとすると、不正なコンテンツとなったり、エンコーディングやエスケープが効かなくなることがあります。

多くの場合、ソフトウェアライブラリは自動的にこれを行う安全な関数やより安全な関数を含みますが、それらが現在のコンテキストに対して正しいことを確認する必要があります。

# 説明 L1 L2 L3 CWE
5.3.1 [修正, 5.3.13 へ分割] HTTP レスポンス、HTML ドキュメント、XML ドキュメントの出力エンコーディングは、メッセージやドキュメント構造の変更を避けるために、HTML 要素、HTML 属性、HTML コメント、CSS、HTTP ヘッダフィールドに関連する文字をエンコードするなど、要求されるコンテキストに関連している。 ✓ ✓ ✓ 116
5.3.2 [削除, 14.4.1 と重複]
5.3.3 [修正, 50.6.2 へ分割] 出力エンコーディングまたはエスケープは、JavaScript コンテンツ (JSON を含む) を動的に構築するときに使用され、メッセージやドキュメント構造の変更を回避している (JavaScript および JSON インジェクションを回避するため)。 ✓ ✓ ✓
5.3.4 [修正] データ選択またはデータベースクエリ（例、SQL、HQL、NoSQL、Cypher）がクエリのパラメータ化、ORM、エンティティフレームワークもしくは他の方法により保護されており、SQL インジェクションや他のデータベースインジェクション攻撃の影響を受けない。これはストアドプロシージャを記述する際にも考慮している。 ✓ ✓ ✓ 89
5.3.5 [削除, 5.3.4 と重複]
5.3.6 [削除, 5.3.3 と重複]
5.3.7 アプリケーションが LDAP インジェクションの影響を受けない、またはセキュリティ管理策によって LDAP インジェクションが防止される。 ✓ ✓ ✓ 90
5.3.8 OS コマンドインジェクションに対して保護していること、およびオペレーティングシステムコールがパラメータ化された OS クエリを使用、もしくはコンテキストコマンドライン出力エンコーディングを使用する。 ✓ ✓ ✓ 78
5.3.9 [削除, 12.3.1 へマージ]
5.3.10 [修正] アプリケーションは、クエリパラメータ化やコンパイル済みクエリを使用することで、XPath インジェクション攻撃から保護されている。 ✓ ✓ ✓ 643
5.3.11 [追加] アプリケーションが CSV インジェクションや数式インジェクションから保護されている。アプリケーションは CSV ファイルをエクスポートする際に RFC4180 2.6 および 2.7 で定義されているエスケープ規則に従う必要がある。アプリケーションは CSV ファイルや xls, xlsx, odf などのその他のスプレッドシート形式をエクスポートする際に、フィールドの最初の文字が '=', '+', '-', '@', '\t' (タブ), '\00' (ヌル文字) などの特殊文字である場合、シングルクォートを使用してエスケープする必要がある。 ✓ ✓ ✓ 1236
5.3.12 [追加] LaTeX プロセッサは ("--shell-escape" フラグを使用しないなど) 安全に構成されており、LaTeX インジェクション攻撃を防ぐためにコマンドの許可リストを使用している。 ✓ ✓
5.3.13 [追加, 5.3.1 から分割] URL を動的に構築する場合、信頼できないデータはそのコンテキストに応じてエンコードされている (例: クエリやパスパラメータの URL エンコーディングや base64url エンコーディング)。安全な URL プロトコルのみが許可されるようにしている (例: javascript: や data: を許可しない)。 ✓ ✓ ✓ 116

注:クエリのパラメータ化や SQL のエスケープだけでは必ずしも十分ではありません。テーブル名やカラム名、ORDER BY などはエスケープできません。これらのフィールドにエスケープされたユーザ作成データが含まれていると、クエリの失敗や SQL インジェクションが発生します。

V5.4 メモリ、文字列、アンマネージドコード

以下の要件は、アプリケーションがシステム言語またはアンマネージドコードを使用している場合にのみ適用されます。

# 説明 L1 L2 L3 CWE
5.4.1 メモリセーフな文字列、安全なメモリコピー、ポインタ演算を使って、スタック、バッファ、ヒープのオーバーフローをアプリケーションが検出または防止する。 ✓ ✓ 120
5.4.2 [5.2.13 へ移動]
5.4.3 整数オーバーフローを防ぐために符号、範囲および入力のバリデーションが使用されている。 ✓ ✓ 190
5.4.4 [追加] 動的に割り当てられたメモリとリソースが適切に解放され、解放されたメモリへの参照やポインタが削除されるか null に設定されて、ダングリングポインタや use-after-free 脆弱性を防いでいる。 ✓ ✓ 416

V5.5 安全なデシリアライゼーション

何らかの保存または転送された表現から実際のアプリケーションオブジェクトへのデータの変換 (デシリアライゼーション) はこれまでさまざまなコードインジェクション脆弱性の原因となってきました。このような問題を回避するには、このプロセスを慎重かつ安全に実行することが重要です。

# 説明 L1 L2 L3 CWE
5.5.1 [削除, 不正確]
5.5.2 アプリケーションが XML パーサを可能な限り最も制限の厳しい構成のみを使用するように正しく制限し、外部エンティティの解決などの危険な機能を無効にして XML 外部エンティティ (XML eXternal Entity, XXE) 攻撃を防ぐようにしている。 ✓ ✓ ✓ 611
5.5.3 [修正, 1.5.2 からマージ] 信頼できないクライアントによるデシリアライゼーションでは、オブジェクトタイプの許可リストを使用したり、クライアント定義のオブジェクトタイプを制限するなど、安全な入力処理を強制してデシリアライゼーション攻撃を防いでいる。明示的に安全でないと定義されているデシリアライゼーションメカニズム (BinaryFormatter など) は信頼できない入力では使用してはいけない。 ✓ ✓ ✓ 502
5.5.4 [削除, 5.2.4 と重複]
5.5.5 [修正, 13.1.1 から移動, レベル L1 > L2] JSON 相互運用性の脆弱性や、さまざまな URI やファイルの解析動作がリモートファイルインクルージョン (RFI) やサーバサイドリクエストフォージェリ (SSRF) 攻撃で悪用されるような問題を回避するために、同じデータ型に対してアプリケーションで使用されるさまざまなパーサー (JSON パーサー、XML パーサー、URL パーサーなど) は一貫した方法で解析を実行し、同じエンコードメカニズムを使用する。 ✓ ✓ 436

V5.6 バリデーションおよびサニタイゼーションアーキテクチャ

上記のセクションでは、セキュリティの脆弱性を回避するために、安全でないコンテンツを安全に処理するためのシンタックス固有またはインタプリタ固有の要件を示しました。このセクションの要件は、この処理が行われるべき順序と場所をカバーしています。また、二重エンコーディング問題を防ぐために、データが保存されるときは常に、エンコードまたはエスケープされた状態 (HTML エンコーディングなど) ではなく、元の状態で保存されることを保証することも目的としています。

# 説明 L1 L2 L3 CWE
5.6.1 [追加] 入力は一度だけ標準形式にデコードまたはアンエスケープされ、その形式でエンコードされたデータが期待される場合にのみデコードされ、これは入力をさらに処理する前に行われる。たとえば、入力バリデーションやサニタイゼーションの後には実行されない。 ✓ ✓ ✓ 174
5.6.2 [修正, 1.5.4 から移動] アプリケーションはそれが意図されているインタプリタまたはインタプリタ自体によって使用される前の最終ステップとして、出力エンコーディングおよびエスケープを実行する。 ✓ ✓ 116

参考情報

詳しくは以下の情報を参照してください。

自動エスケープの詳細な情報はこちらをご覧ください。

デシリアライゼーションやパースの問題の詳細情報はこちらをご覧ください。