界: 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 - CIS Azure Kubernetes Service Benchmark 1

[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1

[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4

[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

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

[7] Standards Mapping - FIPS200 IA

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

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

[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-23 Session Authenticity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[42] 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();
 }