계: API Abuse

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

SQL Bad Practices: Underspecified Identifier

PLSQL/TSQL

Abstract

스키마가 없는 식별자는 호출자의 권한 패키지에 사용하지 않는 것이 좋습니다.

Explanation

호출자의 권한 또는 AUTHID CURRENT_USER 패키지에서 식별자는 먼저 현재 사용자의 스키마에 대해 확인됩니다. 그러면 식별자가 속해 있는 스키마를 코드의 정의자가 명시적으로 밝히지 않는 경우 예기치 못한 동작이 발생할 수 있습니다.

예제: 다음 코드는 권한 표에서 사용자를 조회하여 사용자에게 작업을 수행할 권한이 있는지 검사합니다. 대부분의 사용자는 SYS.PERMISSIONS에 대한 읽기 권한만 있으며 정의된 권한을 수정할 수 없습니다.


CREATE or REPLACE FUNCTION check_permissions(
  p_name IN VARCHAR2, p_action IN VARCHAR2)
  RETURN BOOLEAN
  AUTHID CURRENT_USER
IS
  r_count NUMBER;
  perm BOOLEAN := FALSE;
BEGIN
  SELECT count(*) INTO r_count FROM PERMISSIONS
    WHERE name = p_name AND action = p_action;
  IF r_count > 0 THEN
    perm := TRUE;
  END IF;
  RETURN perm;
END check_permissions

check_permissions 함수를 호출하는 사용자가 해당 스키마에서 PERMISSIONS 테이블을 정의하는 경우, 데이터베이스에서 식별자는 로컬 테이블을 참조합니다. 사용자는 새 테이블에 대한 쓰기 권한이 있으며 원래는 없던 권한을 얻도록 수정할 수 있습니다.

References

[1] Oracle Oracle Database PL/SQL Language Reference

[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1

[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial

[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2

[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

desc.structural.sql.sql_bad_practices_underspecified_identifier