V5: バリデーション、サニタイゼーション、エンコーディング
管理目標
最も一般的な Web アプリケーションセキュリティ脆弱性は、出力エンコーディング、クエリのパラメータ化、あるいはその他の出力処理防御を行わずに、安全でないコンテキストで信頼できないコンテンツを使用することです。この脆弱性は、クロスサイトスクリプティング (XSS) 、SQL インジェクション、OS コマンドインジェクション、テンプレートインジェクション、ログインジェクション、LDAP インジェクションなど、Web アプリケーションにおける重大な脆弱性のほとんどすべてにつながります。
検証対象のアプリケーションが以下の上位要件を満たすことを確認します。
入力バリデーションと出力エンコーディングアーキテクチャはインジェクション攻撃を防ぐために合意されたパイプラインを持っています。
入力データは厳密な型付け、妥当性確認、範囲や長さのチェック、または最低でもサニタイズまたはフィルタリングされています。
出力データは可能な限りインタプリタに近いデータのコンテキストごとにエンコードまたはエスケープされています。
現代の Web アプリケーションアーキテクチャでは、出力エンコーディングがこれまで以上に重要です。特定のシナリオでは堅牢な入力バリデーションを提供することは困難であるため、パラメータ化されたクエリ、自動エスケープテンプレートフレームワークなどの安全な API の使用や、注意深く選択された出力エンコーディングがアプリケーションのセキュリティにとって重要です。
V5.1 入力バリデーション
入力は HTML フォームフィールド、REST リクエスト、URL パラメータ、HTTP ヘッダ、Cookie、ディスク上のファイル、データベース、外部 API など、さまざまなソースからもたらされます。
ポジティブ許可リストと強いデータ型付けを使用して、入力バリデーション制御を適切に実装すると、アプリが受け取ることを期待するデータの種類に関するビジネスロジック制御の重要な実施を提供します。しかし、特定の場合を除き、一般的に特定の攻撃を防ぐことを意図していません。
入力バリデーションは依然として価値のあるセキュリティ衛生を提供するため、可能な限りすべての入力に適用すべきです。しかし、入力バリデーションは完全なセキュリティ戦略でははないため、潜在的に危険なコンテキストで入力が使用される際には常に、サンドボックス化、サニタイゼーション、エンコーディング、パラメータ化も利用すべきです。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
5.1.1 | [修正] 特にアプリケーションフレームワークがリクエストパラメータ (クエリ文字列, ボディパラメータ, cookie, ヘッダ) のソースについて判別していない場合、アプリケーションが HTTP パラメータ汚染攻撃を防御している。 | ✓ | ✓ | ✓ | 235 |
5.1.2 | フレームワークがマスパラメータアサインメント攻撃から保護されている、またはフィールドにプライベートなどのマークをつけるなど、危険なパラメータアサインメントから保護するための対策がアプリケーションにある。 | ✓ | ✓ | ✓ | 915 |
5.1.3 | [修正] すべての入力は、値やパターンの許可リストを使用した、ポジティブバリデーションを使用して検証されている。 | ✓ | ✓ | ✓ | 20 |
5.1.4 | [文法] 許可された文字、長さ、パターンなど、定義されたスキーマに対して構造化データが強く型付けおよび妥当性確認されている (例えば、クレジットカード番号、電子メールアドレス、電話番号、または住所と郵便番号の一致などの二つの関連するフィールドが妥当であることの確認) 。 | ✓ | ✓ | ✓ | 20 |
5.1.5 | [修正, 50.7.1 に分割] アプリケーションは、宛先が許可リストに記載されているもののみ、アプリケーション URL から直接別の URL にユーザーを自動的にリダイレクトしている。 | ✓ | ✓ | ✓ | 601 |
5.1.6 | [追加] 信頼できない入力は Cookie (JWT の一部として含める) に含める前に長さが検証され、Cookie 名と値の長さを合わせて 4096 バイトを超えていない。 | ✓ | ✓ |
V5.2 サニタイゼーションおよびサンドボックス
入力バリデーションは複雑なトピックです。
入力バリデーションがセキュリティに役立たないこともあれば、中程度に役立つこともあり、セキュリティ防御の要となることもあります。入力バリデーションがどれほど有効であるかは、データの種類とそのデータの使用方法に依存します。
例:
サニタイゼーション: ユーザが HTML をオーサリングする場合、標準的な防御策は HTML を標準化して削除することです。 JSON パーサーを使用する前に JSON サニタイズを実行します。もちろん XSS 防御のために HTML サニタイゼーションも行います。
エスケープ化: ユーザが入力したとおりにコンテンツを表示したい場合に UI で行われます。また LDAP インジェクション保護などのインジェクション保護のためにも行われます。
パラメータ化: 主に SQL インジェクションに対して行われます。
サンドボックス化: 何らかの理由で HTML をサニタイズできず、潜在的にアクティブなコンテンツを Web ページにダンプする必要がある場合、 iFrame サンドボックス化は非常に重要です。 CSP にもサンドボックス化の機能があります。
Web UI の URL は XSS 攻撃に対する防御として JavaScript やデータ URL をブロックする必要があります。しかし多くの場合には有効なデータであっても依然として脅威となる可能性があることに注意することが重要です。
| # | 説明 | 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() や他の動的コード実行機能の使用を回避している。代替手段がない場合には、含まれているユーザ入力を実行する前にサニタイズまたはサンドボックス化する必要がある。 | ✓ | ✓ | ✓ | 95 |
5.2.5 | [修正] アプリケーションは信頼できない入力に基づくテンプレートの作成を許可しないことで、テンプレートインジェクション攻撃から保護している。代替手段がない場合、テンプレート作成中に動的に含まれるすべての信頼できない入力はサニタイズまたは厳密に妥当性確認する必要がある。 | ✓ | ✓ | ✓ | 94 |
5.2.6 | ファイル名や URL 入力フィールドなどの信頼できないデータや HTTP ファイルメタデータを妥当性確認またはサニタイズする、およびプロトコル、ドメイン、パス、ポートの許可リストを使用することにより、アプリケーションが SSRF 攻撃から保護している。 | ✓ | ✓ | ✓ | 918 |
5.2.7 | アプリケーションはユーザが提供する Scalable Vector Graphics (SVG) スクリプト可能コンテンツ、特にインラインスクリプトによる XSS や foreignObject に関するものをサニタイズ、無効化、またはサンドボックス化する。 | ✓ | ✓ | ✓ | 159 |
5.2.8 | アプリケーションは、マークダウン、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 に送信する前にコンテンツをサニタイズし、インジェクション攻撃を防いでいる。 | ✓ | ✓ |
V5.3 出力エンコーディングおよびインジェクション防止
使用中のインタプリタに近いまたは隣接する出力エンコーディングはあらゆるアプリケーションのセキュリティにとって重要です。通常、出力エンコーディングは永続化されず、適切な出力コンテキストで出力を安全にレンダリングして、すぐに使用されます。出力のエンコードに失敗すると、セキュアではなく、インジェクション可能で、危険なアプリケーションとなります。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
5.3.1 | [修正] 出力エンコーディングは要求されているインタプリタやコンテキストに応じたものである。例えば、具体的には HTML 値、HTML 属性、JavaScript、CSS、URL パラメータ、HTTP ヘッダ、SMTP、およびコンテキストの要求に応じて、特に信頼できない入力 (例えば、ねこ や O'Hara など、Unicode やアポストロフィを持つ名前) などにエンコーダを使用する。 | ✓ | ✓ | ✓ | 116 |
5.3.2 | [削除, 14.4.1 と重複] | ||||
5.3.3 | コンテキストを意識した (できれば自動化された、あるいは最悪でも手動による) 出力エスケープが反射型 XSS、ストア型 XSS、DOM ベース XSS から保護する。 | ✓ | ✓ | ✓ | 79 |
5.3.4 | [修正] データ選択またはデータベースクエリ (SQL, HQL, NoSQL, Cypherなど) がパラメータ化クエリ、ORM、エンティティフレームワークを使用している、またはデータベースインジェクション攻撃から保護されている。 | ✓ | ✓ | ✓ | 89 |
5.3.5 | [削除, 5.3.4 と重複] | ||||
5.3.6 | [修正] アプリケーションが JSON インジェクション攻撃から保護する。 | ✓ | ✓ | ✓ | 75 |
5.3.7 | アプリケーションが LDAP インジェクション脆弱性から保護する、または LDAP インジェクションを防ぐために特定のセキュリティ管理策が実装されている。 | ✓ | ✓ | ✓ | 90 |
5.3.8 | アプリケーションが OS コマンドインジェクションから保護する、およびオペレーティングシステムがパラメータ化 OS クエリを使用するか、コンテキストに応じたコマンドライン出力エンコーディングを使用する。 | ✓ | ✓ | ✓ | 78 |
5.3.9 | [削除, 12.3.2, 12.3.3 と重複] | ||||
5.3.10 | アプリケーションが XPath インジェクションや XML インジェクション攻撃から保護する。 | ✓ | ✓ | ✓ | 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 インジェクション攻撃を防ぐためにコマンド許可リストを使用している。 | ✓ | ✓ |
注意: パラメータ化クエリや SQL エスケープの使用は必ずしも十分ではありません。テーブル名や列名、ORDER BY などはエスケープできません。これらのフィールドにエスケープされたユーザ指定データを含めると、クエリの失敗または SQL インジェクションを引き起こします。
注意: SVG フォーマットはほとんどすべてのコンテキストで ECMA スクリプトを明示的に許可しているため、すべての SVG XSS ベクトルを完全にブロックすることはできないかもしれません。SVG アップロードが必要な場合には、これらのアップロードされたファイルを text/plain として提供するか、アプリケーションを奪う XSS の成功を別のユーザ提供コンテンツドメインを使用して防ぐことを強くお勧めします。
V5.4 メモリ、文字列、アンマネージコード
以下の要件はアプリケーションがシステム言語またはアンマネージコードを使用する場合にのみ適用されます。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
5.4.1 | アプリケーションがメモリセーフな文字列、安全なメモリコピーおよびポインタ演算を使用して、スタック、バッファ、またはヒープオーバーフローを検出または防止する。 | ✓ | ✓ | 120 | |
5.4.2 | フォーマット文字列が潜在的に悪意のある入力を受け取らず、固定である。 | ✓ | ✓ | 134 | |
5.4.3 | 整数オーバーフローを防ぐために符号、範囲、および入力バリデーション技法が使用されている。 | ✓ | ✓ | 190 |
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 からマージ] 信頼できないウライアントと通信するときに逆シリアル化が使用される場合、入力は安全に処理されている。たとえば、逆シリアル化攻撃を防ぐために、オブジェクトタイプの許可リストのみを許可するか、クライアントが逆シリアル化先のオブジェクトタイプを定義できないようにしている。 | ✓ | ✓ | ✓ | 502 |
5.5.4 | ブラウザまたは JavaScript ベースのバックエンドで JSON をパースする場合には、JSON ドキュメントのパースに JSON.parse が使用されている。JSON のパースに eval() を使用してはいけない。 | ✓ | ✓ | ✓ | 95 |
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.3 から移動, レベル L2 > L1] アプリケーションは信頼できるサービスレイヤで入力バリデーションを実行するように設計されている。クライアントサイドのバリエーションはユーザービリティを向上しますが、セキュリティはそれに依存してはいけない。 (C5) | ✓ | ✓ | ✓ | 602 |
5.6.3 | [修正, 1.5.4 から移動] アプリケーションはそれが意図されているインタプリタまたはインタプリタ自体によって使用される前の最終ステップとして、出力エンコーディングおよびエスケープを実行する。 (C4) | ✓ | ✓ | 116 |
参考情報
詳しくは以下の情報を参照してください。
自動エスケープの詳細については、以下を参照してください。
逆シリアル化やパースの問題の詳細については、以下を参照してください。
Last updated