資料庫的injection 對資料庫管理人員來說是非常重要的,而 資料庫的injection 主要是防止駭客及因語法錯誤,所造成資料庫可能嚴重的破壞或入侵,由其是駭精心設計的攻擊,可以入侵資料庫其所有秘密。瞭解攻擊的基本形式以及如何去防範,這對限制威脅與保護有很大的幫助。

 

資料庫的演化

許多web的企業應用程式背後都一定有其資料庫。對於使用者來說,應用程式本身只不過是一個位於資料庫之上的使用者介面。而到2020年時,資料庫幾乎都是使用結構化查詢語言(SQL)。對於在創建應用程式時需要較大靈活性的開發人員來說,這是個好消息。

 

 資料庫的injection 的危險

資料庫injection又稱SQL注入,是一種駭客技術,最早在1998年就出現了。它的成功利用了兩個關鍵的因素:首先,web應用程式經常向資料庫詢問資料;其次,這些應用程式在向使用者提供的資料的同時,將其資料作為指令的一部分傳遞給資料庫。在沒有基本代碼條件的約束情況下會將它們放在一起,而罪犯就有可能透過此將應用程式或資料庫進行破壞。

 

 資料庫的injection 結構

資料庫的injection在常見的應用程式片段舉例來說,使用者可能在頁面上會被要求詢問其用戶名稱,以便查看企業在其帳戶上所持有的資訊及權限。當使用者在應用程式中輸入他們的用戶名並點擊“Enter”時,資料庫的結果可能是這樣的:語句= “SELECT * FROM users WHERE name = ‘” + userName + “‘;”這將告訴資料庫選擇資料表名稱為“users”的資料庫中的所有內容(“*”),並且設立查詢條件為該資料庫中有一條用戶名需與使用者剛剛輸入的內容相匹配一致的記錄。

但如果用戶輸入的用戶名是這樣的:’OR’ 1 ‘ = ‘ 1,然後生成的代碼將告訴資料庫返回資料庫中每條記錄的所有資訊,因為語法中的查詢條件語法,以致無論檢查結果“1=1”都為真。這種攻擊是因為大多數資料庫接受所謂的“批次處理”SQL命令,其中可以同時輸入多個指令,並用分號分隔。在這種情況下,攻擊者可以命令受害者資料庫做大量工作。

 

資料庫的injection防禦結構

在應用程式開發和執行過程中,對SQL注入的防範可以在兩個不同的地方發生:第一個是在代碼開發期間,第二個是在執行時。在開發期間防止SQL注入意味著編寫不允許將命令作為應用程式查詢的一部分傳遞到資料庫的代碼。其中一部分可能是輸入的驗證,例如如果要求輸入名稱,則不允許使用數位或特殊字元。一些基於開發的保護可能是代碼識別,其中任何SQL代碼(或SQL代碼片段)在傳遞到資料庫之前都被識別並從查詢中刪除。在理想情況下,將使用這兩種技術來確保創建的查詢不會提供應用程式設計人員預期的結果。

資料庫的injection 的防護,就類似部署web應用程式防火牆(WAF),先以掃描輸入的內容以查找非法查詢和命令,這與電子郵件過濾系統一樣,安全人員將需要以一種不干擾合法使用的方式建立WAF。