界: API Abuse

API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルート ディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の 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 は、DDL (Data Definition Language) の一部に分類されているステートメントのみを実行します。埋め込み 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: URL が http://www.example.com/index.php?param=... の場合、index.php 内の PHP の次のスニペットは、「ゼロ以上の英数字」を示す POSIX 正規表現 '^[[:alnum:]]*$' と一致した場合に、(「...」の適切な位置に渡される) URL パラメーター param の値を画面に出力します。

<?php
$pattern = '^[[:alnum:]]*$';
$string = $_GET['param'];
if (ereg($pattern, $string)) {
echo($string);
}
?>
Example 1 が英数字入力で想定通りに動作しているときには、安全でない ereg() 関数が汚染された入力の検証に使用されているので、null バイト インジェクションを経由した Cross-site Scripting (XSS) 攻撃が実行される可能性があります。有効な英数字の直後に null バイトが続く文字列が含まれる param に値を渡すことにより、ereg() 関数が入力文字列を (左から右に) 読み込むときに null バイト文字に続くすべてを無視するため、<script> タグ (例: "Hello123%00<script>alert("XSS")</script>")、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