사실상 authentication 없이 익명의 바인딩에서 LDAP 쿼리를 실행하면 공격자가 빈약하게 구성된 LDAP 환경을 남용할 수 있습니다.

예제 1: 다음 코드는 ldap_simple_bind_s()를 사용하여 LDAP 디렉터리에 익명으로 바인딩합니다.

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

ld에 대해 실행된 모든 LDAP 쿼리는 authentication 및 access control 없이 수행됩니다. 공격자는 디렉터리의 액세스 제어 메커니즘으로 보호되는 레코드에 대한 액세스를 얻기 위해 예기치 못한 방법으로 이러한 쿼리 중 하나를 조작할 수도 있습니다.

사실상 authentication 없이 익명의 바인딩에서 LDAP 쿼리를 실행하면 공격자가 빈약하게 구성된 LDAP 환경을 남용할 수 있습니다.

예제 1: 다음 코드는 익명 바운딩을 사용하여 DirContext ctx를 생성합니다.

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

ctx에 대해 실행된 모든 LDAP 쿼리는 authentication 및 access control 없이 수행됩니다. 공격자는 디렉터리의 액세스 제어 메커니즘으로 보호되는 레코드에 대한 액세스를 얻기 위해 예기치 못한 방법으로 이러한 쿼리 중 하나를 조작할 수도 있습니다.

실질적으로 인증 없이 익명 바인딩으로 LDAP 쿼리를 실행하는 경우 공격자는 잘못 구성된 LDAP 환경을 남용할 수 있습니다.

예제 1: 다음 코드는 사용자가 빈 암호를 입력하는 경우 익명 바인딩을 생성합니다.

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

이 연결을 통해 실행되는 모든 후속 LDAP 쿼리는 인증 및 액세스 제어 없이 수행됩니다. 공격자는 이러한 쿼리 중 하나를 예상하지 못한 방법으로 조작하여 디렉터리의 액세스 제어 메커니즘으로 보호될 수 있는 레코드에 대한 액세스 권한을 얻을 수 있습니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 정수에 의존하기 때문에 SQL injection 취약점에 취약하지 않은 문을 사용하여 지정한 ID([1])와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

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 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

        ...
        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 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
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 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다[1]. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
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 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다[1]. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
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 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
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 오류와 같은 전형적인 웹 응용 프로그램 취약성이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.

예제 2: 다음 코드는 Example 1을 Android 플랫폼에 맞게 조정합니다.

...
        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});
...

많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(Struts 및 Struts 2 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 방지하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

	...
	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 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...

        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 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

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

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(Struts 및 Struts 2 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.

2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 방지하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

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 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
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 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

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

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 액세스 제어 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL Injection 취약점을 예방하는, 매개 변수가 있는 SQL 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다[1]. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

  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 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
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 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

	...
	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에 대한 디렉터리 항목을 반환할 것입니다.