계: API Abuse

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

Often Misused: Authentication

Abstract

공격자가 DNS 항목을 스푸핑할 수 있습니다. 보안을 DNS 이름에 의존하지 마십시오.

Explanation

많은 DNS 서버가 스푸핑 공격에 취약하기 때문에 언젠가는 소프트웨어가 손상된 DNS 서버가 있는 환경에서 실행될 수도 있다고 가정해야 합니다. 공격자가 DNS 업데이트를 수행할 수 있게 되면(DNS 캐시 감염(cache-poisoning)이라고도 함) 네트워크 트래픽을 자신의 시스템을 통과하도록 라우팅하거나 자신의 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에 필요한 유일한 요소는 아닙니다.

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 Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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