匿名バインドの元で、LDAP クエリを実行すると、事実上 Authentication が行われてなくても、攻撃者は脆弱な設定となっている LDAP 環境を侵害できます。

例 1: 次のコードは ldap_simple_bind_s() を使用して、LDAP ディレクトリを匿名でバインドします。

...
rc = ldap_simple_bind_s( ld, NULL, NULL );
  if ( rc != LDAP_SUCCESS ) {
    ...
  }
...

ld に対するすべての LDAP クエリは、Authentication および Access Control なしで実行されます。攻撃者は予期しない方法でこれらのクエリのいずれかを操作して、ディレクトリの Access Control メカニズムにより保護されている可能性があるレコードにアクセスする可能性があります。

匿名バインドの元で、LDAP クエリを実行すると、事実上 Authentication が行われてなくても、攻撃者は脆弱な設定となっている LDAP 環境を侵害できます。

例 1: 次のコードは、匿名バインドを使用して、DirContext ctx を作成します。

...
env.put(Context.SECURITY_AUTHENTICATION, "none");
DirContext ctx = new InitialDirContext(env);
...

ctx に対するすべての LDAP クエリは、Authentication および Access Control なしで実行されます。攻撃者は予期しない方法でこれらのクエリのいずれかを操作して、ディレクトリの Access Control メカニズムにより保護されている可能性があるレコードにアクセスする可能性があります。

匿名バインドのもとで認証なしで効果的に LDAP クエリを実行すると、攻撃者は設定が不十分な LDAP 環境を悪用できるようになる可能性があります。

例 1: 次のコードでは、ユーザーが空のパスワードを入力した場合に匿名バインドを作成しています。

...
$ldapbind = ldap_bind ($ldap, $dn, $password = "" );
...

この接続を介して実行される、それに続くすべての LDAP クエリは、認証もアクセス制御もなく実行されます。攻撃者はこれらのクエリのいずれかを予期しない方法で操作して、ディレクトリのアクセス制御メカニズムで保護されていたはずのレコードに対するアクセス権を得る可能性があります。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、整数に依存するため、SQL Injection の脆弱性に対して脆弱ではないステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

DATA: id TYPE i.
...
id = request->get_form_field( 'invoiceID' ).

CONCATENATE `INVOICEID = '` id `'` INTO cl_where.
SELECT *
    FROM invoices
    INTO CORRESPONDING FIELDS OF TABLE itab_invoices
    WHERE (cl_where).
ENDSELECT.
...

問題は、開発者が ID に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var id:int = int(Number(params["invoiceID"]));
        var query:String = "SELECT * FROM invoices WHERE id = :id";

        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.parameters[":id"] = id;
        stmt.execute();
        ...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SOQL/SOSL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコード例では、inputID 値は事前定義されたリストから取得されていて、バインド変数は SOQL/SOSL Injection を防止するのに役立ちます。

...
result = [SELECT Name, Phone FROM Contact WHERE (IsDeleted = false AND Id=:inputID)];
...

上記の例で問題となるのは、事前定義された ID リストを使用するだけでは、ユーザーによる inputID の値の変更を防止するには不十分なことです。攻撃者がインターフェイスをバイパスし、別の値を使用してリクエストを送信できる場合は、他の連絡先情報にアクセスできてしまいます。この例のコードの場合、リクエストされた連絡先へのアクセス権限がユーザーにあるか確認しないため、ユーザーがこの連絡先を表示する権限がない場合でも、すべての連絡先が表示されます。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1:次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
ACCEPT ID.
EXEC SQL
    DECLARE C1 CURSOR FOR
    SELECT INVNO, INVDATE, INVTOTAL
    FROM INVOICES
    WHERE INVOICEID = :ID
END-EXEC.
...

問題は、開発者が ID に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入力された場合。


2. データベース名の値を指定するのにデータが使用される場合。

データベースの Access Control エラーが発生するのは次の場合です。

1.信頼できないソースからデータがプログラムに入力された場合。


2.SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

一部には、モバイルの世界ではデータベースの Access Control エラーのような古典的な Web アプリケーションの脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 2: 次のコードでは、Android プラットフォームにExample 1 を応用しています。

...
        String id = this.getIntent().getExtras().getString("invoiceID");
        String query = "SELECT * FROM invoices WHERE id = ?";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, new Object[]{id});
...

最新の Web フレームワークの多くが、ユーザー入力を検証するためのメカニズム (Struts および Struts 2 を含む) を提供しています。検証されていない入力ソースの問題を正確に反映させるために、Fortify セキュア コーディング ルールパックは、フレームワーク検証メカニズムが使用されている場合には、その証拠を示し、悪用の可能性を低く見積もり、Fortify Static Code Analyzer により報告される問題の優先度を動的に変更します。この機能は、状況依存ランキングと呼ばれます。Fortify ユーザーがさらに監査プロセスを効果的に進めることができるように、Fortify Software Security Research グループでは、入力ソースに適用される検証メカニズムを基準としたフォルダに問題をグループ化する Data Validation (データ検証) プロジェクト テンプレートのフォルダを用意しています。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

	...
	var id = document.form.invoiceID.value;
	var query = "SELECT * FROM invoices WHERE id = ?";
	db.transaction(function (tx) {
		tx.executeSql(query,[id]);
		}
	)
	...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...

        NSManagedObjectContext *context = [appDelegate managedObjectContext];
        NSEntityDescription *entityDesc = [NSEntityDescription entityForName:@"Invoices" inManagedObjectContext:context];
        NSFetchRequest *request = [[NSFetchRequest alloc] init];
        [request setEntity:entityDesc];
        NSPredicate *pred = [NSPredicate predicateWithFormat:@"(id = %@)", invoiceId.text];
        [request setPredicate:pred];

        NSManagedObject *matches = nil;
        NSError *error;
        NSArray *objects = [context executeFetchRequest:request error:&error];

        if ([objects count] == 0) {
                 status.text = @"No records found.";
        } else {
                matches = [objects objectAtIndex:0];
                invoiceReferenceNumber.text = [matches valueForKey:@"invRefNum"];
                orderNumber.text = [matches valueForKey:@"orderNumber"];
                status.text = [NSString stringWithFormat:@"%d records found", [objects count]];
        }
        [request release];
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

        ...
	$id = $_POST['id'];
	$query = "SELECT * FROM invoices WHERE id = ?";
	$stmt = $mysqli->prepare($query);
	$stmt->bind_param('ss',$id);
	$stmt->execute();
        ...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

最新の Web フレームワークの多くが、ユーザー入力を検証するためのメカニズム (Struts および Struts 2 を含む) を提供しています。検証されていない入力ソースの問題を正確に反映させるために、Fortify セキュア コーディング ルールパックは、フレームワーク検証メカニズムが使用されている場合には、その証拠を示し、悪用の可能性を低く見積もり、Fortify Static Code Analyzer により報告される問題の優先度を動的に変更します。この機能は、状況依存ランキングと呼ばれます。Fortify ユーザーがさらに監査プロセスを効果的に進めることができるように、Fortify Software Security Research グループでは、入力ソースに適用される検証メカニズムを基準としたフォルダに問題をグループ化する Data Validation (データ検証) プロジェクト テンプレートのフォルダを用意しています。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

procedure get_item (
itm_cv IN OUT ItmCurTyp,
id in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'invoiceID = :invid' ||
     	using id;
end get_item;

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。 識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

  def searchInvoice(value:String) = Action.async { implicit request =>
    val result: Future[Seq[Invoice]] = db.run {
      sql"select * from invoices where id=$value".as[Invoice]
    }
    ...
  }

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Invoices", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
let pred : NSPredicate = NSPredicate(format:"(id = %@)", invoiceId.text)
fetchRequest.setPredicate = pred
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    invoiceReferenceNumber.text = result.valueForKey("invRefNum")
    orderNumber.text = result.valueForKey("orderNumber")
    status.text = "\(results.count) records found"
} catch let error as NSError {
    print("Error \(error)")
}
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

	...
	id = Request.Form("invoiceID")
	strSQL = "SELECT * FROM invoices WHERE id = ?"
	objADOCommand.CommandText = strSQL
	objADOCommand.CommandType = adCmdText
	set objADOParameter = objADOCommand.CreateParameter("id" , adString, adParamInput, 0, 0)
	objADOCommand.Parameters("id") = id
	...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データが LDAP クエリのデータ値を指定するために使用される場合。
例 1: 次のコードは、LDAP クエリの構築に使用する前に、許可リストを使用してソケットから読み取った従業員の名前を検証します。この検証により、LDAP Injection の脆弱性を防ぐことができますが、コードは脆弱なままとなります。

char* allowlist_verify(char* name) {
    const char *error;
    int errOffset;
    char* regex = "^[a-zA-Z\\-\\.']+$";
    pcre* re = pcre_compile(regex, 0, &err, &errOffset, NULL);
    int rc = pcre_exec(re, NULL, name, strlen(name), 0, 0, NULL, 0);
    if (rc == 1)
        return name;
    return NULL;
}
...
fgets(managerName, sizeof(managerName), socket);
char* verified_name = allowlist_verify(managerName);
if(verified_name != NULL) {
    snprintf(filter, sizeof(filter), "(manager=%s)", verified_name);
    if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
            filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
            LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
    ...
    }
}

この問題は、開発者が username に攻撃者が別の値を指定したときにどのような動作が起こりうるかを検討していない点にあります。この例のコードは、匿名バインドでクエリを実行しているため、現在認証されているユーザーの ID に関わらず、すべての有効な従業員 ID のディレクトリエントリを返します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データが LDAP クエリのデータ値を指定するために使用される場合。
例 1: 現在認証されているユーザーの従業員 ID は、クライアントサイドインターフェイスからの各リクエストで自動的に送信されます。次のコードは、LDAP クエリの構築に使用する前に、整数として従業員 ID を適切に検証します。この検証により、LDAP Injection の脆弱性を防ぐことができますが、コードは脆弱なままとなります。

...
env.put(Context.SECURITY_AUTHENTICATION, "none");
DirContext ctx = new InitialDirContext(env);

String empID = request.getParameter("empID");

try
{
  int id = Integer.parseInt(empID);

  BasicAttribute attr = new BasicAttribute("empID", empID);

  NamingEnumeration employee =
            ctx.search("ou=People,dc=example,dc=com",attr);
...

この問題は、開発者が empID に攻撃者が別の値を指定したときにどのような動作が起こりうるかを検討していない点にあります。このインターフェイスは、現在のユーザーの従業員 ID を自動的に送信しますが、攻撃者は悪意あるリクエストの一部として別の値を送信できる場合があります。この例のコードは、匿名バインドでクエリを実行しているため、現在認証されているユーザーの ID に関わらず、すべての有効な従業員 ID のディレクトリエントリを返します。