界: API Abuse

API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルート ディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の API を悪用します。また、相手側から、呼び出し元と呼び出し先のコントラクトを違反することもできます。例えば、コーダーが SecureRandom をサブクラス化し、ランダムではない値を返した場合、コントラクトに違反することになります。

SQL Bad Practices: Underspecified Identifier

Abstract
スキーマのない識別子を、実行者権限パッケージでは使用すべきではありません。
Explanation
実行者権限または AUTHID CURRENT_USER パッケージでは、現在のユーザースキーマに対して識別子が最初に解決されます。その結果、識別子がどのスキーマに属しているのかをコードの定義が明示していない場合、予期せぬ動作が引き起こされる可能性があります。

例 1: 次のコードは権限テーブルでユーザーを検索して、ユーザーがアクションを実行する権限を持っているかどうかを確認します。大半のユーザーは 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 - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
desc.structural.sql.sql_bad_practices_underspecified_identifier