界: API Abuse

API 就像是呼叫者與被呼叫者之間簽訂的規定。最常見的 API 濫用形式是由呼叫者這一當事方未能遵守此規定所造成的。例如，如果程式在呼叫 chroot() 後無法呼叫 chdir()，即違反規範如何以安全方式變更使用中根目錄的規定。程式庫濫用的另一個好例子是期待被呼叫者向呼叫者傳回值得信賴的 DNS 資訊。在這種情況下，呼叫者是透過對其行為做出某些假設 (傳回值可用於驗證目的) 來濫用被呼叫者 API。另一方也可能違反呼叫者與被呼叫者間的規定。例如，如果編碼器衍生出子類別 SecureRandom 並傳回一個非隨機值，則違反了規定。

Often Misused: Authentication

Abstract

攻擊者可能欺騙 DNS 項目。為了安全起見，請勿依賴 DNS 名稱。

Explanation

許多 DNS 伺服器很容易被攻擊者欺騙，所以您必須設想到您的軟體某一天將會在有問題的 DNS 伺服器環境下執行。如果允許攻擊者進行 DNS 更新 (有時候稱為 DNS 快取下毒)，則他們能夠透過他們的機器制定您網路流量的路徑，或者讓他們的 IP 位址像是在您的領域中。請勿將您系統的安全性依賴於 DNS 名稱上。
範例：以下程式碼範例使用 DNS 尋找來決定進入的要求是否來自可信賴的主機。如果攻擊者可以對 DNS 快取下毒，那麼他們就可以取得信賴。


 IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
 IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
 if (hostInfo.HostName.EndsWith("trustme.com")) {
   trusted = true;
 }

IP 位址比 DNS 名稱可靠，但仍有可能被欺騙。攻擊者可能輕鬆偽造他們所傳送之資料包的來源 IP 位址，但回應資料包將傳回至偽造的 IP 位址。為了查看回應封包，攻擊者需要在受害者的機器和偽造的 IP 位址之間攔截網路資料。為達到所需的攔截，攻擊者一般的做法是嘗試把他們的機器和受害者的機器放在相同的子網路內。攻擊者可藉由使用來源路徑來達到此目的，但現今在大部分的網際網路上已無法使用來源路徑。總而言之，驗證 IP 位址是一種有效的 authentication 方案，但它不是唯一的 authentication 方案。

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807

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

[3] Standards Mapping - FIPS200 IA

[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)

[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-11 Trusted Path, SC-23 Session Authenticity

[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication

[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization

[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1

[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management

[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management

[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management

[13] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management

[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication

[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures

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

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

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

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

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

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

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

[27] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807

[28] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807

[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I

[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I

[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II

[38] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)

[39] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication

desc.semantic.dotnet.often_misused_authentication

Abstract

getlogin() 函數很容易欺騙。請勿依賴其傳回的名稱。

Explanation

getlogin() 函數應該傳回包含目前已登入終端機的使用者名稱的字串，但是攻擊者可能讓 getlogin() 傳回登入該機器的任意使用者的名稱。請勿依賴 getlogin() 傳回的名稱來確定是否安全。
範例 1：以下程式碼依賴 getlogin() 來判定是否信任使用者。這很容易被推翻。


 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }