界: API Abuse

API 是调用方和被调用方之间的约定。最常见的 API 滥用是由于调用方未能遵守此约定的终止导致的。例如,如果某个程序在调用 chroot() 后未能调用 chdir(),则违反了用于指定如何安全地更改活动根目录的约定。库滥用的另一个典型示例是期望被调用方向调用方返回可信的 DNS 信息。在这种情况下,调用方通过对被调用方行为做出某种假设(返回值可用于身份验证目的)滥用其 API。另一方也可能违反调用方-被调用方约定。例如,如果编码器子类化 SecureRandom 并返回一个非随机值,则将违反此约定。

81 个项目已找到
弱点
Abstract
Struts 2.x Action 实施类,使攻击者有机会通过将任意数据绑定到会话、应用程序或请求服务器端对象,修改应用程序的业务逻辑。
Explanation
Apache Struts 2.x 包含新的 Aware 接口,允许开发人员使用相关运行时信息,轻松将映射注入到其 Actions 代码中。这些接口包括:org.apache.struts2.interceptor.ApplicationtAwareorg.apache.struts2.interceptor.SessionAwareorg.apache.struts2.interceptor.RequestAware。为了将这些数据映射中的任意内容注入到其 Actions 代码中,开发人员需要实现接口中指定的 setter(例如:setSession,适用于 SessionAware 接口):

public class VulnerableAction extends ActionSupport implements SessionAware {

protected Map<String, Object> session;

@Override
public void setSession(Map<String, Object> session) {
this.session = session;
}

另一方面,Struts 2.x 会自动通过 Action 中定义的 public accessors 将来自用户的请求数据绑定到 Action 的属性。由于 Aware 接口要求实现 Aware 接口中定义的 public setter,因此这一 setter 也将自动绑定到与 Aware 接口 setter 名称相匹配的任意请求参数,这可允许远程攻击者通过伪造的参数修改应用程序的运行时数据值,使其实现的接口受到影响,如 SessionAwareRequestAwareApplicationAware 接口所示。

下面的 URL 将允许攻击者重写会话映射中的“roles”属性。这可能会使攻击者成为管理员。

http://server/VulnerableAction?session.roles=admin


当这些接口仅要求实现 setter accessors 时,如果同时也实现相应的 getter,则对这些映射集合的更改将在会话范围内持续,而不是仅影响当前的请求范围。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 20
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[18] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[19] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[20] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
desc.structural.java.struts2_bad_practices_session_map_tampering
Abstract
覆盖系统字段会打破系统的正常稳定运行。
Explanation
ABAP 系统字段在 ABAP 程序中始终可用。运行时系统会在启动程序后、发送屏幕后和更改内部模式后,根据上下文填充这些字段。然后,这些字段可在程序中用于查询系统状态。系统字段为变量,但应始终将其作为常量和只读字段处理。更改这些字段的值会导致程序运行所需的重要信息丢失。因此,在客户 ABAP 程序中只能更改其中有限的字段。


对向 ABAP 程序传送运行时特定信息的系统字段值进行更改,会导致服务中断或 ABAP 程序行为异常。
References
[1] ABAP System Fields SAP
desc.structural.abap.system_field_overwrite
Abstract
忽略方法的返回值会导致程序无法发现意外状况和情况。
Explanation
程序员常常会误解包含在许多 System.IO 类中的 Read() 及相关方法。大部分错误和异常事件在 .NET 结果中都会被作为一个异常抛出。(这是 .NET 相对于 C 语言等编程语言的优势:各种异常更加便于程序员考虑是哪里出现了问题。)但是,如果只有少量的数据可用(可读),stream 和 reader 类并不认为这是异常的情况。这些类只是将这些少量的数据添加到返回值缓冲区,并且将返回值设置为读取的字节或字符数。所以,并不能保证返回的数据量一定等于请求的数据量。

这样,程序员就需要检查 Read() 和其他 IO 方法的返回值,以确保接收到期望的数据量。
示例:下列代码会在一组用户中进行循环,读取每个用户的私人数据文件。由于程序员假设这些文件始终为 1 KB,因此忽略了检查 Read() 的返回值。如果攻击者能够创建一个较小的文件,程序就会重复利用前一个用户的剩余数据,并对这些数据进行处理,就像这些数据属于攻击者一样。


char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {
string userName = (string) i.Current();
string pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);
}
desc.semantic.dotnet.unchecked_return_value
Abstract
忽略方法的返回值会导致程序无法发现意外状况和情况。
Explanation
几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后,程序员的假设看起来既脆弱又拙劣,但攻击前,许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中很容易发现的两个可疑的假设是:一是这个函数调用不可能出错;二是即使出错了,也不会对系统造成什么重要影响。当程序员忽略函数返回值时,就暗示着自己是基于上述任一假设来执行操作。
示例:请考虑以下代码:


char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);


程序员希望在 fgets() 返回时,buf 包含一个以“null”结尾的字符串,并且该字符串的长度小于或等于 9。但是,如果发生了 I/O 错误,fgets() 将不会返回以“null”结尾的 buf。此外,如果在读取任何字符之前,已经到达文件的结尾处,那么 fgets() 在返回时就不会在 buf 中写入任何内容。在这两种情况下,fgets() 会通过返回 NULL 来表示已发生异常情况,但在该代码中,不会发出警告。如果 buf 中缺少一个 null 终止符,则可能会导致在随后调用 strcpy() 时出现缓冲区溢出。
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
desc.semantic.cpp.unchecked_return_value
Abstract
忽略方法的返回值会导致程序无法发现意外状况和情况。
Explanation
Java 程序员常常会误解包含在许多 java.io 类中的 read() 及相关方法。在 Java 结果中,将大部分错误和异常事件都作为异常抛出。(这是 Java 相对于 C 语言等编程语言的优势:各种异常更加便于程序员考虑是哪里出现了问题。)但是,如果只有少量的数据可用,stream 和 reader 类并不认为这是异常的情况。这些类只是将这些少量的数据添加到返回值缓冲区,并且将返回值设置为读取的字节或字符数。所以,并不能保证返回的数据量一定等于请求的数据量。

这样,程序员就需要检查 read() 和其他 IO 方法的返回值,以确保接收到期望的数据量。

示例:下列代码会在一组用户中进行循环,读取每个用户的私人数据文件。程序员假设这些文件总是正好 1000 字节,从而忽略了检查 read() 的返回值。如果攻击者能够创建一个较小的文件,程序就会重复利用前一个用户的剩余数据,并对这些数据进行处理,就像这些数据属于攻击者一样。


FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {
String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);
}
References
[1] EXP00-J. Do not ignore values returned by methods CERT
[2] FIO02-J. Detect and handle file-related errors CERT
desc.semantic.java.unchecked_return_value
Abstract
忽略方法的返回值会导致程序无法发现意外状况和情况。
Explanation

对于程序员而言,检查返回值以确保从方法调用返回预期状态非常重要。

示例:下列代码会在一组用户中进行循环,读取每个用户的私人数据文件。程序员假设这些文件始终为 1000 字节,从而忽略了检查 read() 的返回值。如果攻击者能够创建一个较小的文件,程序就会重复利用前一个用户的剩余数据,并对这些数据进行处理,就像这些数据属于攻击者一样。


var fis: FileInputStream
val byteArray = ByteArray(1023)
val i: Iterator<*> = users.iterator()
while (i.hasNext()) {
val userName = i.next() as String
val pFileName: String = PFILE_ROOT.toString() + "/" + userName
val fis = FileInputStream(pFileName)
fis.read(byteArray) // the file is always 0k bytes
fis.close()
processPFile(userName, byteArray)
}
References
[1] EXP00-J. Do not ignore values returned by methods CERT
[2] FIO02-J. Detect and handle file-related errors CERT
desc.semantic.kotlin.unchecked_return_value
Abstract
函数不检查消息调用的返回值。
Explanation
当调用其他合约时,请务必检查消息调用的返回值,以正确处理调用是否成功。如果不这样做,则在调用失败或者抛出未正确处理的异常时,可能会导致意外逻辑行为。

示例 1:以下代码不检查调用的返回值。


function callnotchecked(address callee) public {
callee.call();
}
References
[1] Enterprise Ethereum Alliance Check External Calls Return
desc.structural.solidity.swc104
Abstract
用户或系统相关的程序流是不良的编程习惯,并表明可能存在后门。
Explanation
SAP 系统提供了广泛的授权配置和访问管理。系统级配置也可用来基于系统角色限制权限。总之,这些功能使得用户或系统相关的编程变得无关紧要。也就是说,在安全配置的客户生产系统中不能出现这样一种情形:一个程序的功能依赖于执行程序的用户或在其中执行程序的系统。因此,查询用户或系统详细信息来影响程序流是一种不良的做法,表明存在可能的后门。
desc.structural.abap.user_system_dependent_flow