若未經 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 的情況下執行。攻擊者可能會以意想不到的方式來操縱其中的一個查詢，以取得原本應受目錄的 access control 機制所保護的記錄。

若未經 authentication 便在匿名連結下有效地執行 LDAP 查詢，會讓攻擊者濫用低階配置的 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 之下直接執行。攻擊者可能會以意想不到的方式操縱這些查詢之一，以取得對記錄的存取權，否則這些記錄將受到目錄 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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SOQL/SOSL 查詢中主要金鑰的值。
範例 1：在以下程式碼範例中，inputID 值來自於預先定義的清單，而繫結變數可協助防止 SOQL/SOSL injection。

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

上述範例存在的問題是，使用預先定義的 ID 清單不足以阻止使用者修改 inputID 的值。如果攻擊者能夠略過介面並使用其他值傳送要求，便可存取其他聯絡人資訊。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求聯絡人的權限，所以即使該使用者未獲得查看的授權，程式碼也會顯示任何聯絡人。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫 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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫 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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

有人認為在行動環境中，典型的 Web 應用程式弱點 (例如資料庫 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});
...

有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源，Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性，並在使用框架驗證機制時提供支援證據的指標，以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序，Fortify Software 安全研發團隊提供了資料驗證專案範本，該範本會依據套用到其輸入來源的驗證機制，按資料夾對問題進行分組。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源，Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性，並在使用框架驗證機制時提供支援證據的指標，以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序，Fortify Software 安全研發團隊提供了資料驗證專案範本，該範本會依據套用到其輸入來源的驗證機制，按資料夾對問題進行分組。

在以下情況會發生資料庫 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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫 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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

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 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫 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 的值，會發生什麼情況。因為此範例中的程式碼是在匿名連結下執行查詢，所以不管目前驗證的使用者身份如何，它都會將任何有效的員工識別碼傳回目錄項目中。

在以下情況會發生資料庫 Access Control 錯誤：

1. 資料從一個不可信賴的來源進入程式。

2. 資料用在 LDAP 查詢中指定資料值。
範例 1：目前已驗證的使用者的員工識別碼，會隨著每個用戶端介面的要求自動傳遞。以下的程式碼在使用員工識別碼建立 LDAP 查詢之前，使用了安全名單適當地驗證此員工識別碼。此驗證避免了 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 的值，會發生什麼情況。儘管介面自動傳遞目前使用者的員工識別碼，但是攻擊者仍可能在惡意要求傳遞其他代替目前識別碼的值。因為此範例中的程式碼是在匿名連結下執行查詢，所以不管目前驗證的使用者身份如何，它都會將任何有效的員工識別碼傳回目錄項目中。