Kingdom: API Abuse

An API is a contract between a caller and a callee. The most common forms of API abuse are caused by the caller failing to honor its end of this contract. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.

Often Misused: Authentication

Abstract

Attackers may spoof DNS entries. Do not rely on DNS names for security.

Explanation

Many DNS servers are susceptible to spoofing attacks, so you should assume that your software will someday run in an environment with a compromised DNS server. If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names.
Example 1: The following code sample uses a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.


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

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers may easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for 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 Data Security Standard Version 4.0.1 Requirement 6.2.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

desc.semantic.dotnet.often_misused_authentication

Abstract

The getlogin() function is easy to spoof. Do not rely on the name it returns.

Explanation

The getlogin() function is supposed to return a string containing the name of the user currently logged in at the terminal, but an attacker may cause getlogin() to return the name of any user logged in to the machine. Do not rely on the name returned by getlogin() when making security decisions.
Example 1: The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.


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