界: API Abuse
API 就像是呼叫者與被呼叫者之間簽訂的規定。最常見的 API 濫用形式是由呼叫者這一當事方未能遵守此規定所造成的。例如,如果程式在呼叫 chroot() 後無法呼叫 chdir(),即違反規範如何以安全方式變更使用中根目錄的規定。程式庫濫用的另一個好例子是期待被呼叫者向呼叫者傳回值得信賴的 DNS 資訊。在這種情況下,呼叫者是透過對其行為做出某些假設 (傳回值可用於驗證目的) 來濫用被呼叫者 API。另一方也可能違反呼叫者與被呼叫者間的規定。例如,如果編碼器衍生出子類別 SecureRandom 並傳回一個非隨機值,則違反了規定。
Dangerous Function: Unsafe Regular Expression
Abstract
絕不能使用無法安全使用的函數。
Explanation
某些函數無論使用方法為何,都有危險性。這一類函數的執行通常都沒有經過安全方面的考量。
範例 1:根據 URL
雖然
範例 1:根據 URL
http://www.example.com/index.php?param=...
,以下在 index.php
中的 php 片段會將 URL 參數 param
(以取代「...」的方式傳遞) 的值列印至畫面,只要其符合代表「零或多個英數字元」的 POSIX 一般表示式 '^[[:alnum:]]*$'
:
<?php
$pattern = '^[[:alnum:]]*$';
$string = $_GET['param'];
if (ereg($pattern, $string)) {
echo($string);
}
?>
雖然
Example 1
會按照英數輸入如期操作,但是因為不安全的 ereg()
函數會用於驗證受感染的輸入,所以還是可能會透過 null
位元組執行 Cross-site scripting (XSS) 攻擊。藉由傳遞 param
的值,其中包含有效的英數字串,後面依序接著 null
位元組與 <script>
標籤 (例如 "Hello123%00<script>alert("XSS")</script>"
),ereg($pattern, $string)
依然會傳回 true
,因為 ereg()
函數在讀取輸入字串 (由左到右) 時,會忽略接在 null
位元組字元後面的任何內容。在此範例中,這表示接在 null
位元組後面注入的 <script>
標籤,將會顯示給使用者並接受評估。References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 676
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[3] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[11] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[12] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[13] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP2060.4 CAT II, APP3590.2 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP2060.4 CAT II, APP3590.2 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP2060.4 CAT II, APP3590.2 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP2060.4 CAT II, APP3590.2 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP2060.4 CAT II, APP3590.2 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP2060.4 CAT II, APP3590.2 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP2060.4 CAT II, APP3590.2 CAT II
desc.semantic.php.dangerous_function_unsafe_regular_expression