界: Input Validation and Representation

输入验证与表示问题是由元字符、交替编码和数字表示引起的。安全问题源于信任输入。这些问题包括:“Buffer Overflows”、“Cross-Site Scripting”攻击、“SQL Injection”等其他问题。

Prototype Pollution

Abstract
应用程序允许用户污染原型。
Explanation
原型污染是一种攻击手段,它允许恶意用户覆盖对象的原型。
要了解原型污染,首先必须了解原型继承。原型和原型链用于查找 JavaScript 中的属性和函数,从而提供继承。当尝试访问给定对象的属性时,将检查当前对象定义。如果当前对象没有定义属性,则检查原型类。将以递归方式检查原型,直到找到属性,或者不再设置任何原型。

因为 JavaScript 中的大多数对象默认情况下都有一个指向 Object.prototype 的原型,所以如果攻击者可以覆盖对象的原型,他们通常可以覆盖 Object.prototype 的定义,从而影响应用程序内的所有对象。

如果应用程序(或其任何依赖项)依据的是属性可以 undefined 而不是始终显式设置的事实,那么如果原型已被污染,应用程序可能会无意中从原型而不是预期的对象中进行读取。

在以下情况下可能发生原型污染:

1.数据从一个不可信数据源进入程序。



2.将数据传递到允许覆盖原型的 API。

示例 1:以下代码使用了一个易受攻击的 lodash 版本污染对象的原型:


import * as lodash from 'lodash'
...
let clonedObject = lodash.merge({}, JSON.parse(untrustedInput));
...


此时,如果不受信任的输入为 {"__proto__": { "isAdmin": true}},则 Object.prototype 将定义 isAdmin = true

考虑应用程序中稍后存在以下代码。


...
let config = {}
if (isAuthorizedAsAdmin()){
config.isAdmin = true;
}
...
if (config.isAdmin) {
// do something as the admin
}
...


即使 isAdmin 仅在 isAuthorizedAdmin() 返回 true 时才应设置为 true,但由于应用程序无法在 else 条件下设置 config.isAdmin = false,因此它依据的是 config.isAdmin === undefined === false 这一事实。
不幸的是,由于原型已被污染,因此 config 的原型现已设置 isAdmin === true,因此允许绕过管理员授权。
References
[1] Olivier Arteau Prototype pollution attack.
[2] Open Web Application Security Project (OWASP) Prototype Pollution Prevention Cheat Sheet
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1321
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-2 Application Partitioning (P1), SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-2 Separation of System and User Functionality, SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.1.2 Input Validation Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[12] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002150 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.dataflow.javascript.prototype_pollution