계: API Abuse

API는 호출자와 피호출자 간의 계약입니다. 가장 흔한 형태의 API 오용은 호출자가 이 계약에서 자신의 몫을 이행하지 못하기 때문에 발생합니다. 예를 들어, 프로그램이 chroot()를 호출한 후 chdir()을 호출하지 못하면 활성 루트 디렉터리를 안전하게 변경하는 방법을 지정하는 계약을 위반하는 것입니다. 라이브러리 오용의 또 다른 좋은 예는 피호출자가 호출자에게 신뢰할 만한 DNS 정보를 반환할 것으로 예상하는 것입니다. 이 경우, 호출자는 자신의 행동에 대해 특정한 가정을 함으로써(반환 값이 인증 목적으로 사용될 것으로 예상) 피호출자 API를 오용합니다. 다른 쪽에서 호출자-피호출자 계약을 위반할 수도 있습니다. 예를 들어, 코더가 하위 클래스 SecureRandom을 지정하고 임의 값이 아닌 값을 반환하는 경우 계약을 위반하는 것입니다.

81 개 항목 찾음
취약점
Abstract
안전하게 사용할 수 없는 함수는 사용하지 않는 것이 좋습니다.
Explanation
일부 함수는 사용 방법에 관계 없이 위험하게 동작합니다. 이 카테고리에 속하는 함수는 보안 문제를 고려하지 않고 구현된 것입니다.

desc.semantic.cpp.dangerous_function.master
Abstract
안전하게 사용할 수 없는 함수는 사용하지 않는 것이 좋습니다.
Explanation
일부 함수는 사용 방법에 관계 없이 위험하게 동작합니다. 이 카테고리에 속하는 함수는 보안 문제를 고려하지 않고 구현된 것입니다.

desc.semantic.php.dangerous_function.master
Abstract
안전하게 사용할 수 없는 함수는 사용하지 않는 것이 좋습니다.
Explanation
DBMS_UTILITY.EXEC_DDL_STATEMENT는 데이터 정의 언어의 일부로 분류된 문만 실행합니다. 포함된 SQL에서 지원하지 않는 기타 SQL 문은 포함된 자동으로 무시됩니다. 이 동작은 해당 절차를 사용할 때 오류를 감지하기 어렵게 합니다.
References
[1] How to write SQL injection proof PL/SQL
desc.semantic.sql.dangerous_function_exec_ddl
Abstract
안전하게 사용할 수 없거나 안전하게 사용하기가 매우 어려운 함수는 사용하지 않아야 합니다.
Explanation
특정 함수는 위험하거나 예기치 않은 방식으로 동작합니다. 이 카테고리에 속하는 함수는 보안 문제를 고려하지 않고 구현된 것입니다.

desc.structural.ruby.dangerous_function
Abstract
안전하게 사용할 수 없는 함수는 사용하지 않는 것이 좋습니다.
Explanation
일부 함수는 사용 방법에 관계 없이 위험하게 동작합니다. 이 카테고리에 속하는 함수는 보안 문제를 고려하지 않고 구현된 것입니다.

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 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 676
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-0-5
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[12] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[13] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP2060.4 CAT II, APP3590.2 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP2060.4 CAT II, APP3590.2 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP2060.4 CAT II, APP3590.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP2060.4 CAT II, APP3590.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP2060.4 CAT II, APP3590.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP2060.4 CAT II, APP3590.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP2060.4 CAT II, APP3590.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.semantic.cpp.dangerous_function_strcpy
Abstract
안전하게 사용할 수 없는 함수는 사용하면 안 됩니다.
Explanation
특정 함수는 사용 방법에 관계없이 위험한 방식으로 동작합니다. 이 카테고리의 함수는 보안을 고려하지 않고 구현된 경우가 많습니다.

예제 1:http://www.example.com/index.php?param=...이라는 URL에서 index.php 내 php의 다음 조각은 "0 또는 더 많은 영숫자"를 표시하는 POSIX 정규식 '^[[:alnum:]]*$'와 일치하는 경우 화면에 URL 매개 변수 param("..."의 지난 자리) 값을 인쇄합니다.

<?php
$pattern = '^[[:alnum:]]*$';
$string = $_GET['param'];
if (ereg($pattern, $string)) {
echo($string);
}
?>
Example 1이 영숫자 입력과 함께 예상대로 작동하는 동안 불안전한 ereg() 함수는 감염된 입력 확인에 사용되므로 null byte injection을 통해 Cross-Site Scripting(XSS) 공격을 수행할 수 있습니다. null 바이트와 <script> 태그가 붙는 유효한 영숫자 문자열을 포함한 param 값을 전달하면(예: "Hello123%00<script>alert("XSS")</script>") ereg() 함수가 입력 문자열을 왼쪽에서 오른쪽으로 읽을 때 null 바이트 문자 뒤에 오는 모든 사항을 무시하며 ereg($pattern, $string)true를 계속 반환합니다. 이 예제에서는 null 바이트 뒤에 삽입된 <script> 태그가 사용자에게 표시되며 평가된다는 의미입니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 676
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[16] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[17] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP2060.4 CAT II, APP3590.2 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP2060.4 CAT II, APP3590.2 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP2060.4 CAT II, APP3590.2 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP2060.4 CAT II, APP3590.2 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP2060.4 CAT II, APP3590.2 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP2060.4 CAT II, APP3590.2 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP2060.4 CAT II, APP3590.2 CAT II
desc.semantic.php.dangerous_function_unsafe_regular_expression
Abstract
xp_cmdshell 함수는 안전하게 사용할 수 없습니다. 사용하지 않는 것이 좋습니다.
Explanation
일부 함수는 사용 방법에 관계 없이 위험하게 동작합니다. xp_cmdshell 함수는 Windows 명령 셸을 시작하여 제공된 명령 문자열을 실행합니다. 명령은 기본 시스템이나 제공된 프록시 컨텍스트에서 실행됩니다. 그러나 미리 지정된 권한 작업 세트에 대해 사용자를 제한할 수 없으며 권한 승인은 사용자가 명령 문자열을 실행할 수 있도록 합니다.
References
[1] xp_cmdshell
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 242
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 7.1.2
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 7.1.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 7.1.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 7.1.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 7.2.2
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[19] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[20] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
desc.semantic.sql.dangerous_function_xp_cmdshell
Abstract
메서드는 위험한 것으로 주석 추가되었습니다. 이 메서드의 모든 사용은 이슈로 플래그 지정되었습니다.
Explanation
FortifyDangerous 주석이 이 메서드에 적용되었습니다. 이는 위험하다는 것을 표시하는 데 사용되며 모든 사용은 안전을 위해 검토해야 합니다.
desc.structural.java.dangerous_method
Abstract
이 변수는 위험한 것으로 주석 처리된 유형의 변수입니다.
Explanation
FortifyDangerous 주석이 이 형식에 적용되었습니다. 이는 위험하다는 것을 표시하는 데 사용되며 모든 사용은 안전을 위해 검토해야 합니다.

desc.structural.java.dangerous_class_variable
Abstract
chroot() 시스템 호출을 잘못 사용하면 공격자가 chroot jail을 빠져나갈 수 있습니다.
Explanation
chroot() 시스템 호출로 프로세스가 file system의 루트 디렉터리 개념을 변경할 수 있습니다. chroot()를 올바로 호출하면 프로세스가 새 루트 디렉터리에서 정의한 디렉터리 트리 외부의 파일에 접근할 수 없습니다. 그런 환경을 chroot jail이라고 하며 일반적으로 프로세스를 훔쳐 파일의 무단 접근에 사용할 가능성을 방지하기 위해 사용합니다. 예를 들어, 많은 FTP 서버를 chroot jail에서 실행하여 서버에서 새 취약점을 발견한 공격자가 시스템에서 암호 파일 또는 기타 민감한 파일을 다운로드하는 것을 방지합니다.

chroot()를 잘못 사용하면 공격자가 chroot jail을 빠져나갈 수 있습니다. chroot() 함수 호출은 프로세스의 현재 작업 디렉터리를 변경하지 않기 때문에 chroot()가 호출된 후에도 상대 경로가 chroot jail 외부의 file system 리소스를 참조할 수 있습니다.

예제 1: (가상의) FTP 서버의 다음 소스 코드를 보겠습니다.


chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);


이 코드는 네트워크에서 파일 이름을 읽고 로컬 컴퓨터에서 파일을 연 다음 네트워크로 파일 내용을 보냅니다. 이 코드는 FTP GET 명령을 구현하는 데 사용할 수 있습니다. FTP 서버는 /var/ftproot 외부의 파일에 대한 접근을 막기 위해 초기화 루틴에서 chroot()를 호출합니다. 그러나 서버가 chdir("/")를 호출하여 현재 작업 디렉터리를 변경할 수 없기 때문에 공격자가 "../../../../../etc/passwd" 파일을 요청하여 시스템 암호 파일의 복사본을 얻을 수 있습니다.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] A. Chuvakin Using Chroot Securely
desc.semantic.cpp.directory_restriction