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: Asserting Permissions

C#/VB.NET/ASP.NET

Abstract

The code asserts to its callers that a certain permission is given, potentially allowing an attacker to bypass security controls.

Explanation

Permissions in the .NET Framework work by going up the stack tree (where the tree grows downward), to check if permissions are set sufficiently to access a resource. When a developer uses Assert() with a specific permission it is a way to say that the current controlflow has the specified permission. This in turn leads to the .NET framework stopping any further permission checks as long as it satisfies the needed permissions, meaning that code that calls the code making the call to Assert() may not have the required permission. The use of Assert() is helpful in some cases, but can lead to vulnerabilities when this allows a malicious user to get control of a resource that they would not have permission to otherwise.

References

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

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002038, CCI-002039, CCI-002165

[3] Standards Mapping - FIPS200 AC

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

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1), IA-11 Re-Authentication (P0)

[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement, SC-11 Trusted Path

[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization

[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.5 Access Control Architectural Requirements (L2 L3)

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

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

[11] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control

[12] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference

[13] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References

[14] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References

[15] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control

[16] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4

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

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

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

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

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

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

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

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

[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls

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

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

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

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

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

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

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

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

[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II

[51] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)

[52] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization

desc.semantic.dotnet.often_misused_asserting_permissions