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

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. 此資料用來指定位於 LINQ 查詢中主要關鍵字的值。
範例 1：以下程式碼執行 LINQ 查詢以搜尋符合指定識別碼 [1] 的清單。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...

int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
	.Where(new Invoice { invoiceID = id });
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

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

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. 此資料用來指定資料庫名稱的值。

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

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用登錄金鑰 APPHOME 來決定目錄的安裝位置，並且根據指定目錄的相對路徑來執行初始化 Script。

...
CALL FUNCTION 'REGISTRY_GET'
  EXPORTING
     KEY   = 'APPHOME'
  IMPORTING
     VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

Example 1 中的程式碼允許攻擊者藉由修改登錄金鑰 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從登錄中讀取的值，所以如果攻擊者可以控制登錄金鑰 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

範例 2：以下程式碼來自一個用於管理性的 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份，並接著執行 cleanup.bat Script 來刪除一些暫存檔案。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
  EXPORTING
    commandname                   = cmd_exe
    long_params                   = cmd_string
  EXCEPTIONS
    no_permission                 = 1
    command_not_found             = 2
    parameters_too_long           = 3
    security_risk                 = 4
    OTHERS                        = 5.
...

這裡的問題是，程式沒有對來自使用者的 backuptype參數進行任何驗證。通常 SXPG_COMMAND_EXECUTE_LONG 函數模組不會執行多重指令，但在此例中，程式首先執行 cmd.exe shell，以在單一呼叫 CALL 'SYSTEM' 時執行多重指令。一旦叫用 Shell，Shell 就會允許執行多個由兩個 & 分隔的指令。如果攻擊者傳遞一個 "&& del c:\\dbms\\*.*" 形式的字串，那麼應用程式將會執行這個指令以及由此程式指定的其他指令。因為此應用程式本質的關係，所以應用程式必須要有權限才可與資料庫互動，這表示攻擊者插入的所有指令也都會使用這些權限進行運作。

範例 3：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。在特定網路環境中，更新密碼的部分程序是在 /var/yp 目錄下執行 make 指令。

...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

這裡的問題是，程式沒有指定一個絕對的路徑，並且沒能在執行 CALL 'SYSTEM' 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 make 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 make 將會在這些權限下執行，攻擊者可能會完全控制系統。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下程式碼使用來自組態設定檔案的輸入來決定目錄的安裝位置，並且根據指定目錄的相對路徑來執行初始化 Script。

        ...
        var fs:FileStream = new FileStream();
        fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
        home = String(fs.readObject(home));
        var cmd:String = home + INITCMD;
        fscommand("exec", cmd);
        ...

Example 1 中的程式碼允許攻擊者藉由修改組態設定檔案 configStream 的內容來指向包含惡意版本的 INITCMD 的其他路徑，藉此運用提升的應用程式權限來執行任意指令。因為程式不會驗證從檔案中讀取的值，所以如果攻擊者可以控制該值，他們就可以欺騙應用程式去執行惡意程式碼並控制系統。

範例 2：以下程式碼來自一個管理 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份，並接著執行 cleanup.bat Script 來刪除一些暫存檔案。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var btype:String = String(params["backuptype"]);
        var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
        fscommand("exec", cmd);
        ...

這裡的問題是，程式沒有對來自使用者的 backuptype參數進行任何驗證。通常 fscommand() 函數不會執行多重指令，但在此例中，程式首先執行 cmd.exe shell，以在單一呼叫 fscommnd() 時執行多重指令。一旦叫用 Shell，Shell 就會允許執行多個由兩個 & 分隔的指令。如果攻擊者傳遞一個 "&& del c:\\dbms\\*.*" 形式的字串，那麼應用程式將會執行這個指令以及由此程式指定的其他指令。因為此應用程式本質的關係，所以應用程式必須要有權限才可與資料庫互動，這表示攻擊者插入的所有指令也都會使用這些權限進行運作。

範例 3：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。在特定網路環境中，更新密碼的部分程序是在 /var/yp 目錄下執行 make 指令。

        ...
        fscommand("exec", "make");
        ...

這裡的問題是，程式沒有指定一個絕對的路徑，並且沒能在執行 fscommand() 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 make 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 make 將會在這些權限下執行，攻擊者可能會完全控制系統。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用系統屬性 APPHOME 來決定其安裝目錄，並且根據指定目錄的相對路徑來執行初始化 Script。

...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...

Example 1 中的程式碼允許攻擊者藉由修改系統屬性 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從環境中讀取的值，所以如果攻擊者可以控制系統屬性 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

範例 2：以下程式碼來自一個管理 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份，並接著執行 cleanup.bat Script 來刪除一些暫存檔案。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
              + btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...

這裡的問題在於：程式不會對 BackupTypeField進行任何驗證。通常 Process.Start() 函數不會執行多重指令，但在此例中，程式首先執行 cmd.exe shell，以在單一呼叫 Process.Start() 時執行多重指令。一旦叫用 Shell，Shell 就會允許執行多個由兩個 & 分隔的指令。如果攻擊者傳遞一個 "&& del c:\\dbms\\*.*" 形式的字串，那麼應用程式將會執行這個指令以及由此程式指定的其他指令。因為此應用程式本質的關係，所以應用程式必須要有權限才可與資料庫互動，這表示攻擊者插入的所有指令也都會使用這些權限進行運作。

範例 3：以下程式碼來自一個 Web 應用程式，允許使用者存取他們用於在系統上更新密碼的介面。在此網路環境中，更新密碼的部分程序是執行 update.exe 指令，如下所示：

...
Process.Start("update.exe");
...

這裡的問題是，程式沒有指定一個絕對的路徑，並且沒能在執行 Process.start() 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 update.exe 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 update.exe 將會在這些權限下執行，攻擊者可能會完全控制系統。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此案例中，我們著重於第一種情況，即攻擊者準確地控制了所執行的指令。此類型的 Command injection 弱點會在以下情況中出現：

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


2.資料被應用程式當作指令所執行的字串的一部分。


3.藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：下面這個簡單的程式將一個檔案名稱作為一條指令行引數，並將檔案內容顯示給使用者。程式是按照 setuid root 安裝的，因為這個程式的意圖是作為一個學習工具來使用，以便讓那些仍在培訓中的系統管理員查看各權限的系統檔，而不給他們篡改權限，或者損壞系統的能力。

int main(char* argc, char** argv) {
	char cmd[CMD_MAX] = "/usr/bin/cat ";
	strcat(cmd, argv[1]);
	system(cmd);
}

因為程式是以 root 的權限來執行，所以 system() 的呼叫也以 root 的權限來執行。如果使用者指定了一個標準的檔案名稱，那麼呼叫就能如預期般執行。但是，如果攻擊者傳遞 ";rm -rf /" 形式的字串，則對 system() 的呼叫會由於缺少引數而無法執行 cat，然後以遞迴方式刪除根分割的內容。

範例 2：以下來自具有特殊權限的程式之程式碼，使用環境變數 $APPHOME 來決定應用程式的安裝目錄，並在該目錄中執行初始化指令碼。

	...
	char* home=getenv("APPHOME");
	char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
	if (cmd) {
		strcpy(cmd,home);
		strcat(cmd,INITCMD);
		execl(cmd, NULL);
	}
	...

如 Example 1 所述，這個範例中的程式碼提升了應用程式的權限，允許攻擊者隨意執行任何指令。在此範例中，攻擊者可能修改環境變數 $APPHOME 來指定包含 INITCMD 惡意版本的不同路徑。由於程式不會驗證從環境讀取的值，透過控制該環境變數，攻擊者可能欺騙應用程式執行惡意程式碼。

因為攻擊者使用環境變數來控制程式呼叫的指令，所以在這個範例中環境的影響是直接明瞭的。現在，我們會留意當攻擊者可能變更指令解譯方式時會發生的情況。

範例 3：以下程式碼以 CGI 公用程式為基礎，可讓使用者變更其密碼。在網路資訊服務 (NIS) 下的密碼更新過程，包括在 /var/yp 目錄中執行 make。注意，程式更新密碼記錄後，就已按照 setuid root 進行安裝了。

程式會以下列方式呼叫 make：

system("cd /var/yp && make &> /dev/null");

不同於先前的範例，因為這個範例中的指令是使用強制編碼方式，所以攻擊者不能控制傳輸到 system() 的引數。但是，由於程式沒有指定 make 的絕對路徑，而且沒有在叫用指令之前清除任何環境變數，因此攻擊者可能修改他們的 $PATH 變數，以指向名為 make 的惡意二進位碼，並從 shell 提示執行 CGI 指令碼。而且因為程式是按照 setuid root 安裝的，所以攻擊者的 make 版本現在會以 root 權限執行。

在 Windows 中，存在其他風險。

範例 4：直接或透過呼叫 _spawn() 系列中的一個函數來叫用 CreateProcess() 時，如果執行檔或路徑中包含空格，請務必小心。

...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...

由於 CreateProcess() 剖析空格的方式，作業系統嘗試執行的第一個執行檔會是 Program.exe，而不是 MyApplication.exe。所以，如果攻擊者能夠在系統上安裝名為 Program.exe 的惡意應用程式，任何會使用 Program Files 目錄不正確呼叫 CreateProcess() 的程式將會執行此應用程式，而不會執行原本所要執行的應用程式。

環境在程式的系統指令執行過程中扮演很重要的角色。如 system()、exec() 和 CreateProcess() 這類的函數，可利用程式呼叫這些函數的環境，因此攻擊者會有機會去影響這些呼叫的運作情況。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1： 下列程式碼允許攻擊者透過 cmd 要求參數指定任意指令。

    ...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
    arguments = "/c #var#"
    timeout = "1"
    variable="mycmd">
</cfexecute>
    ...

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此案例中，我們著重在第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2.資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3.藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用系統屬性 APPHOME 來決定目錄的安裝位置，並且根據指定目錄的相對路徑來執行初始化 Script。

	...
	final cmd = String.fromEnvironment('APPHOME');
    await Process.run(cmd);
	...

Example 1 中的程式碼允許攻擊者藉由修改系統屬性 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從環境中讀取的值，所以如果攻擊者可以控制系統屬性 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此案例中，我們著重在第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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


2.資料當作表示應用程式執行之指令的字串或字串的一部分使用。

3.藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下程式碼會執行使用者控制的指令。

  cmdName := request.FormValue("Command")
  c := exec.Command(cmdName)
  c.Run()

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用系統屬性 APPHOME 來決定目錄的安裝位置，並且根據指定目錄的相對路徑來執行初始化 Script。

	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD;
	java.lang.Runtime.getRuntime().exec(cmd);
	...

Example 1 中的程式碼允許攻擊者藉由修改系統屬性 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從環境中讀取的值，所以如果攻擊者可以控制系統屬性 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

範例 2：以下程式碼來自一個管理 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份，並接著執行 cleanup.bat Script 來刪除一些暫存檔案。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...

這裡的問題是，程式沒有對來自使用者的 backuptype參數進行任何驗證。通常 Runtime.exec() 函數不會執行多重指令，但在此例中，程式首先執行 cmd.exe shell，以在單一呼叫 Runtime.exec() 時執行多重指令。一旦叫用 Shell，Shell 就會允許執行多個由兩個 & 分隔的指令。如果攻擊者傳遞一個 "&& del c:\\dbms\\*.*" 形式的字串，那麼應用程式將會執行這個指令以及由此程式指定的其他指令。因為此應用程式本質的關係，所以應用程式必須要有權限才可與資料庫互動，這表示攻擊者插入的所有指令也都會使用這些權限進行運作。

範例 3：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。在特定網路環境中，更新密碼的部分程序是在 /var/yp 目錄下執行 make 指令。

...
System.Runtime.getRuntime().exec("make");
...

這裡的問題是，程式沒有指定一個絕對的路徑，並且沒能在執行 Runtime.exec() 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 make 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 make 將會在這些權限下執行，攻擊者可能會完全控制系統。

有人認為在行動環境中，典型的弱點 (例如指令插入) 沒有意義，因為使用者為何要攻擊自己呢？但是請謹記，行動平台的本質是從多種來源下載，並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高，這必然會擴大行動應用程式的受攻擊面，將程序之間的通訊包括在內。

範例 4：以下程式碼從 Android 用意中讀取將執行的指令。

...
        String[] cmds = this.getIntent().getStringArrayExtra("commands");
	Process p = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(p.getOutputStream());
        for (String cmd : cmds) {
        	os.writeBytes(cmd+"\n");
        }
        os.writeBytes("exit\n");
        os.flush();
...

在已取得 Root 權限的裝置上，惡意應用程式會強迫受害者應用程式以超級使用者的權限執行任意指令。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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


2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用環境變數 APPHOME 來決定其安裝目錄，並且根據指定目錄的相對路徑來執行初始化 Script。

var cp = require('child_process');
  ...
  var home = process.env('APPHOME');
  var cmd = home + INITCMD;
  child = cp.exec(cmd, function(error, stdout, stderr){
    ...
  });
  ...

Example 1 中的程式碼允許攻擊者藉由修改系統屬性 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從環境中讀取的值，所以如果攻擊者可以控制系統屬性 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

範例 2：以下程式碼來自一個管理 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
  var btype = url.parse(request.url, true)['query']['backuptype'];
  if (btype !== undefined){
    cmd = "c:\\util\\rmanDB.bat" + btype;
    cp.exec(cmd, function(error, stdout, stderr){
      ...
    });
  }
  ...
}
...
http.createServer(listener).listen(8080);

這裡的問題是，程式沒有對來自使用者的 backuptype參數進行任何驗證，只有驗證此參數是否存在。一旦叫用此 Shell，就可能允許執行多個指令，並且因為應用程式本質的關係，應用程式將會使用與資料庫互動的必要權限來執行，這表示攻擊者插入的所有指令也會使用這些權限來執行。

範例 3：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。在特定網路環境中，更新密碼的部分程序是在 /var/yp 目錄下執行 make 指令。

...
require('child_process').exec("make", function(error, stdout, stderr){
  ...
});
...

這裡的問題是，程式沒有指定 make 的絕對路徑，因此沒能在執行 child_process.exec() 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 make 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 make 將會在這些權限下執行，攻擊者可能會完全控制系統。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用系統屬性 APPHOME 來決定目錄的安裝位置，並且根據指定目錄的相對路徑來執行初始化 Script。

	...
	$home = $_ENV['APPHOME'];
	$cmd = $home . $INITCMD;
	system(cmd);
	...

Example 1 中的程式碼允許攻擊者藉由修改系統屬性 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從環境中讀取的值，所以如果攻擊者可以控制系統屬性 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

範例 2：以下程式碼來自一個管理 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份，並接著執行 cleanup.bat Script 來刪除一些暫存檔案。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...

這裡的問題是，程式沒有對來自使用者的 backuptype參數進行任何驗證。通常 Runtime.exec() 函數不會執行多重指令，但在此例中，程式首先執行 cmd.exe shell，以在單一呼叫 Runtime.exec() 時執行多重指令。一旦叫用 Shell，Shell 就會允許執行多個由兩個 & 分隔的指令。如果攻擊者傳遞一個 "&& del c:\\dbms\\*.*" 形式的字串，那麼應用程式將會執行這個指令以及由此程式指定的其他指令。因為此應用程式本質的關係，所以應用程式必須要有權限才可與資料庫互動，這表示攻擊者插入的所有指令也都會使用這些權限進行運作。

範例 3：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。在特定網路環境中，更新密碼的部分程序是在 /var/yp 目錄下執行 make 指令。

...
$result = shell_exec("make");
...

這裡的問題是，程式沒有指定一個絕對的路徑，並且沒能在執行 Runtime.exec() 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 make 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 make 將會在這些權限下執行，攻擊者可能會完全控制系統。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下程式碼定義了 T-SQL 儲存的程序，當使用不可信賴的資料呼叫時，該程序會執行由攻擊者控制的系統指令。

...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用系統屬性 APPHOME 來決定目錄的安裝位置，並且根據指定目錄的相對路徑來執行初始化 Script。

	...
	home = os.getenv('APPHOME')
	cmd = home.join(INITCMD)
	os.system(cmd);
	...

Example 1 中的程式碼允許攻擊者藉由修改系統屬性 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從環境中讀取的值，所以如果攻擊者可以控制系統屬性 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

範例 2：以下程式碼來自一個管理 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份，並接著執行 cleanup.bat Script 來刪除一些暫存檔案。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

...
	btype = req.field('backuptype')
	cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
	os.system(cmd);
...

這裡的問題是，程式沒有對來自使用者的 backuptype參數進行任何驗證。通常 Runtime.exec() 函數不會執行多重指令，但在此例中，程式首先執行 cmd.exe shell，以在單一呼叫 Runtime.exec() 時執行多重指令。一旦叫用 Shell，Shell 就會允許執行多個由兩個 & 分隔的指令。如果攻擊者傳遞一個 "&& del c:\\dbms\\*.*" 形式的字串，那麼應用程式將會執行這個指令以及由此程式指定的其他指令。因為此應用程式本質的關係，所以應用程式必須要有權限才可與資料庫互動，這表示攻擊者插入的所有指令也都會使用這些權限進行運作。

範例 3：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。在特定網路環境中，更新密碼的部分程序是在 /var/yp 目錄下執行 make 指令。

...
result = os.system("make");
...

這裡的問題是，程式沒有指定一個絕對的路徑，並且沒能在執行 os.system() 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 make 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 make 將會在這些權限下執行，攻擊者可能會完全控制系統。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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


2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用系統屬性 APPHOME 來決定目錄的安裝位置，並且根據指定目錄的相對路徑來執行初始化 Script。

...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...

Example 1 中的程式碼允許攻擊者藉由修改系統屬性 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從環境中讀取的值，所以如果攻擊者可以控制系統屬性 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

範例 2：以下程式碼來自一個用於管理性的 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份，並接著執行 cleanup.bat Script 來刪除一些暫存檔案。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...

這裡的問題是，程式沒有對來自使用者的 backuptype參數進行任何驗證。一旦透過 Kernel.spawn 叫用 Shell，Shell 就會允許執行多個由兩個 & 分隔的指令。如果攻擊者傳遞一個 "&& del c:\\dbms\\*.*" 形式的字串，那麼應用程式將會執行這個指令以及由此程式指定的其他指令。因為此應用程式本質的關係，所以應用程式必須要有權限才可與資料庫互動，這表示攻擊者插入的所有指令也都會使用這些權限進行運作。

範例 3：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。在特定網路環境中，更新密碼的部分程序是在 /var/yp 目錄下執行 make 指令。

...
system("make")
...

這裡的問題是，程式沒有指定一個絕對的路徑，並且沒能在執行 Kernel.system() 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 make 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 make 將會在這些權限下執行，攻擊者可能會完全控制系統。

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第二種情況，即攻擊者能夠藉由變更環境變數或預先在搜尋路徑中輸入可執行的惡意內容，進而變更指令的意義的可能性。此類型的 Command injection 弱點會在以下情況中出現：

1.攻擊者修改應用程式的環境。

2.應用程式沒有指定絕對路徑，或沒有驗證所執行的二位元碼就執行指令。

3.藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。

def changePassword(username: String, password: String) = Action { request =>
    ...
    s'echo "${password}" | passwd ${username} --stdin'.!
    ...
}

Command injection 弱點有以下兩種形式：

- 攻擊者可以篡改程式執行的指令：攻擊者直接控制指令內容。

- 攻擊者可以篡改指令執行的所在環境：攻擊者間接控制指令代表的意義。

在此例中，我們著重於第一種情況，即攻擊者可控制執行指令的可能性。此類型的 Command injection 弱點會在以下情況中出現：

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 藉由執行指令，應用程式給予攻擊者原本不該擁有的權限或能力。

範例 1：以下來自於系統公用程式的程式碼使用系統屬性 APPHOME 來決定其安裝目錄，並且根據指定目錄的相對路徑來執行初始化 Script。

	...
	Dim cmd
	Dim home

	home = Environ$("AppHome")
	cmd = home & initCmd
	Shell cmd, vbNormalFocus
	...

Example 1 中的程式碼允許攻擊者藉由修改系統屬性 APPHOME，來指向包含惡意版本的 INITCMD 的其他路徑，運用提升的應用程式權限來執行任意指令。因為程式不會驗證從環境中讀取的值，所以如果攻擊者可以控制系統屬性 APPHOME 的值，那麼他們就可以欺騙應用程式去執行惡意程式碼並取得對系統的控制。

範例 2：以下程式碼來自一個管理 Web 應用程式，可允許使用者使用 rman 公用程式周圍的批次檔包裝函式來開始 Oracle 資料庫備份，並接著執行 cleanup.bat Script 來刪除一些暫存檔案。Script rmanDB.bat 會接受單一指令行參數，其中指定了要執行的備份類型。因為存取資料庫是受限制的，所以應用程式需具有較高權限的使用者來執行備份。

...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...

這裡的問題是，程式沒有對來自使用者的 backuptype參數進行任何驗證。一旦叫用 Shell，Shell 就會允許執行多個由兩個 & 分隔的指令。如果攻擊者傳遞一個 "&& del c:\\dbms\\*.*" 形式的字串，那麼應用程式將會執行這個指令以及由此程式指定的其他指令。因為此應用程式本質的關係，所以應用程式必須要有權限才可與資料庫互動，這表示攻擊者插入的所有指令也都會使用這些權限進行運作。

範例 3：以下程式碼來自一個 Web 應用程式，提供了可讓使用者在系統上更新密碼的介面。在特定網路環境中，更新密碼的部分程序是在 /var/yp 目錄下執行 make 指令。

...
$result = shell_exec("make");
...

這裡的問題是，程式沒有指定一個絕對的路徑，並且沒能在執行 Runtime.exec() 呼叫前清除它的環境變數。如果攻擊者能夠修改 $PATH 變數，指向名為 make 的惡意二進位碼，並使得程式在它們的環境中執行，那麼程式會載入此惡意的二進位碼，代替原來的程式碼。由於應用程式的特性，它需要特定的權限才能執行系統作業，這表示攻擊者的 make 將會在這些權限下執行，攻擊者可能會完全控制系統。

Cross-site scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。在 Persistent XSS (也可稱為 Stored XSS) 案例中，不可信賴的來源通常為資料庫或其他後端資料儲存區，而在 Reflected XSS 案例中，來源通常為網頁要求。


2. 未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。

範例 1：以下的 ABAP 程式碼片段會根據所給予的識別碼在資料庫中查詢員工，並列印該員工姓名。

...
DATA: BEGIN OF itab_employees,
        eid   TYPE employees-itm,
        name  TYPE employees-name,
      END OF itab_employees,
      itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
  FROM employees
  INTO CORRESPONDING FIELDS OF TABLE itab_employees
  FOR ALL ENTRIES IN itab
  WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...

name 值正常運作時，此程式碼也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險，是因為 name 值是從資料庫中讀取的，且顯然是由應用程式管理這些值的內容。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

範例 2：以下的 ABAP 程式碼片段會從 HTTP 要求中讀取員工的識別碼 eid，並將識別碼顯示給使用者。

...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...

如 Example 1 所述，如果 eid 只包含標準英數字元，這個程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？其實，真正的危險在於攻擊者會建立惡意的 URL，接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

如同範例中所示，XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者：

- 如 Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。

- 如 Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。

- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。

Cross-site scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。在 Persistent XSS (也可稱為 Stored XSS) 案例中，不可信賴的來源通常為資料庫或其他後端資料儲存區，而在 Reflected XSS 案例中，來源通常為網頁要求。


2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。

範例 1：以下 ActionScript 程式碼片段會根據所給予的識別碼在資料庫中查詢員工，並列印該員工姓名。

  stmt.sqlConnection = conn;
  stmt.text = "select * from emp where id="+eid;
  stmt.execute();
  var rs:SQLResult = stmt.getResult();
  if (null != rs) {
    var name:String = String(rs.data[0]);
    var display:TextField = new TextField();
    display.htmlText = "Employee Name: " + name;
  }

name 值正常運作時，此程式碼也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險，是因為 name 值是從資料庫中讀取的，且顯然是由應用程式管理這些值的內容。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

範例 2：以下 ActionScript 程式碼片段會從 HTTP 要求中讀取員工的識別碼 eid，並將識別碼顯示給使用者。

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...

如 Example 1 所述，如果 eid 只包含標準英數字元，這個程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？其實，真正的危險在於攻擊者會建立惡意的 URL，接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

如同範例中所示，XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者：

- 如 Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。

- 如 Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。

- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。

Cross-site scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。如果是 Persistent XSS，不可信賴的來源大多為資料庫查詢的結果，而如果是 Reflected XSS，來源大多為 Web 要求。

2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

惡意內容通常為 JavaScript 程式碼片段，但也可以是 HTML、Flash 或瀏覽器可執行的任何其他作用中內容。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。

範例 1：以下 Apex 程式碼片段會在資料庫中查詢具有指定 ID 的聯絡人名稱並傳回對應的員工姓名 (之後由 Visualforce 程式碼進行列印)。

...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>

對 name 的值進行明確界定時 (例如，僅英數字元)，此程式碼會正常運作，但無法檢查惡意資料。即使該值讀取自資料庫，也應該對其進行適當驗證，因為資料庫的內容可能源自於使用者提供的資料。這樣一來，攻擊者可以在使用者的網頁瀏覽器中執行惡意指令，而無需與受害者進行互動 (類似於 Reflected XSS)。此類攻擊稱為 Stored XSS (或 Persistent XSS)，可能非常難以偵測，因為資料是以間接方式提供給易受攻擊的函數，並且由於影響多個使用者的可能性，此類攻擊的影響會更強烈。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

範例 2：以下 Visualforce 程式碼片段會讀取 HTTP 要求參數 username，並向使用者顯示。

<script>
document.write('{!$CurrentPage.parameters.username}')
</script>

此範例中的程式碼旨在僅接收英數文字並加以顯示。但是，如果 username 包含中繼字元或來源程式碼，則會由網頁瀏覽器執行。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？其實，真正的危險在於攻擊者會建立惡意的 URL，接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

如同範例中所示，XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。有兩種途徑可執行 XSS 攻擊：

- 如 Example 1 所述，資料庫或其他資料儲存區會向應用程式提供將包含在動態內容中的危險資料。從攻擊者的角度來看，儲存惡意內容的最佳位置是可供所有使用者 (尤其是擁有較高權限的使用者) 存取的區域，這些使用者更有可能會處理敏感資訊或執行關鍵作業。

- 如 Example 2 所述，會從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者將危險內容傳遞至易受攻擊的 Web 應用程式，然後回傳給使用者並透過其瀏覽器執行時，會出現 Reflected XSS。傳遞惡意內容最常用的機制就是，將惡意內容當作參數包含在公開發佈的 URL 中，或者以電子郵件方式直接傳送給受害者。透過此方式修改的 URL 是許多釣魚架構的核心，其中攻擊者會誘騙受害者造訪該 URL。當網站回傳內容給使用者後便會加以執行，並且可執行多個動作，例如轉送隱私、敏感的資訊、在受害者電腦上執行未經授權的作業等。

Cross-site scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。在 Persistent XSS (也可稱為 Stored XSS) 案例中，不可信賴的來源通常為資料庫或其他後端資料儲存區，而在 Reflected XSS 案例中，來源通常為網頁要求。


2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。

範例 1：以下的 ASP.NET 網頁表單使用指定的員工識別碼向資料庫查詢員工，並列印出與識別碼相對應的名字。

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>

其中，EmployeeName 是定義如下的表單控制項：

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

範例 2：以下 ASP.NET 程式碼片段的功能與之前的 Example 1 相當，不過卻是以程式設計方式來實作所有的表單元素。

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;

name 值正常運作時，這些程式碼範例也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險，是因為 name 值是從資料庫中讀取的，且顯然是由應用程式管理這些值的內容。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

範例 3：以下 ASP.NET 網頁表單會從 HTTP 要求讀取員工識別碼，然後顯示給使用者。

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

其中，Login 和 EmployeeID 是定義如下的表單控制項：

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

範例 4：以下的 ASP.NET 程式碼片段會示範以程式設計方式來實作 Example 3。

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

如 Example 1 和 Example 2 所述，如果 Login 只包含標準英數字元，這些範例就會正確運作。如果 Login 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？ 真正的危險是攻擊者會建立惡意的 URL，然後使用電子郵件或社交工程技倆來誘騙受害者按下連結。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

如同範例中所示，XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者：

- 如 Example 1 和 Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。

- 如 Example 3 和 Example 4 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。

- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。

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

Cross-site scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。在 Persistent XSS (也可稱為 Stored XSS) 案例中，不可信賴的來源通常為資料庫或其他後端資料儲存區，而在 Reflected XSS 案例中，來源通常為網頁要求。


2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。

範例 1： 以下的 CFML 程式碼片段，根據提供的員工識別碼來查詢資料庫，並列印出該員工的相應姓名。

 
<cfquery name="matchingEmployees" datasource="cfsnippets">
  SELECT name
  FROM Employees 
  WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>

name 值正常運作時，此範例中的程式碼也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險，是因為 name 值是從資料庫中讀取的，且顯然是由應用程式管理這些值的內容。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

範例 2： 以下的 CFML 程式碼片段，會從網路表單中讀取員工識別碼 eid，並將其顯示給使用者。

<cfoutput>
Employee ID: #Form.eid#
</cfoutput>

如 Example 1 所述，如果 Form.eid 只包含標準英數字元，這個程式碼會正確地執行。如果 Form.eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？其實，真正的危險在於攻擊者會建立惡意的 URL，接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

如同範例中所示，XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者：

- 如 Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。

- 如 Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。

- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。

Cross-Site Scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中，不可信賴的來源通常為網頁要求，而在 Persisted XSS (也可稱為 Stored XSS) 案例中，來源通常為資料庫或其他後端資料儲存區。

2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。


範例 1：以下 Go 程式碼片段會從 HTTP 要求中讀取使用者名稱 user，並向使用者顯示。

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

如果 user 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 user 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？其實，真正的危險在於攻擊者會建立惡意的 URL，接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

範例 2：以下 Go 程式碼片段會查詢資料庫中具有指定 ID 的員工，然後列印相對應的員工姓名。

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", name)
}

如 Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果沒有對所有儲存在資料庫中的資料進行適當的輸入驗證，那麼攻擊者即可在使用者的網頁瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其極其隱蔽，會因為間接的資料儲存方式而難以辨別該威脅，並會提高影響多個使用者的可能性。XSS 弱點會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

如同範例中所示，XSS 弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者：

- 如 Example 1 所示，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由網頁瀏覽器執行時，就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。

- 如 Example 2 所示，應用程式會將危險資料儲存在資料庫或其他可信任的資料存放區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者執行需要權限許可的操作，或者取得存取使用者專屬敏感資料的權限。

- 應用程式以外的來源會在資料庫或是其他資料存放區中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。

Cross-site scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。在 Persistent XSS (也可稱為 Stored XSS) 案例中，不可信賴的來源通常為資料庫或其他後端資料儲存區，而在 Reflected XSS 案例中，來源通常為網頁要求。


2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。

範例 1：以下 JSP 程式碼片段會在資料庫中查詢具有指定識別碼的員工，並列印相應的員工姓名。

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

name 值正常運作時，此程式碼也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險，是因為 name 值是從資料庫中讀取的，且顯然是由應用程式管理這些值的內容。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

範例 2：以下 JSP 程式碼片段會從 HTTP 要求中讀取員工識別碼 eid，並將其向使用者顯示。

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

如 Example 1 所述，如果 eid 只包含標準英數字元，這個程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？其實，真正的危險在於攻擊者會建立惡意的 URL，接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

有人認為在行動環境中，典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響，因為使用者為何會攻擊自己呢？但是請謹記，行動平台的本質是從多種來源下載，並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高，這必然會擴大行動應用程式的受攻擊面，將程序之間的通訊包括在內。

範例 3：以下程式碼會在 Android 的 WebView 中啟用 JavaScript (預設狀況下停用 JavaScript)，並根據從 Android 用意接收的值載入頁面。

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

若 url 的值以 javascript: 開頭，隨後的 JavaScript 程式碼將在網頁範圍中的 WebView 內執行。

如同範例中所示，XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者：

- 如 Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。

- 如 Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。

- 如 Example 3 所述，應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。

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