MariaDB SQL注入保護

接受用戶輸入的簡單行為打開了利用的大門。 這個問題主要來自數(shù)據(jù)的邏輯管理，但幸運的是，很容易避免這些主要缺陷。

SQL注入的機會通常發(fā)生在輸入諸如名稱的數(shù)據(jù)的用戶上，并且代碼邏輯無法分析該輸入。 相反，代碼允許攻擊者插入MariaDB語句，該語句將在數(shù)據(jù)庫上運行。

始終考慮用戶輸入的數(shù)據(jù)，可疑的，在任何處理之前需要強大的驗證。 通過模式匹配執(zhí)行此驗證。 例如，如果期望的輸入是用戶名，將輸入的字符限制為字母數(shù)字字符和下劃線，并且限制為一定長度。 查看下面給出的示例 -

if(check_match("/^w{8,20}$/", $_GET['user_name'], $matches)) {
   $result = mysql_query("SELECT * FROM system_users WHERE user_name = $matches[0]");
} else {
   echo "Invalid username";
}

此外，在創(chuàng)建輸入約束時使用REGEXP運算符和LIKE子句。

考慮所有類型的必要的顯式控制輸入，如 - 

• 控制使用的轉(zhuǎn)義字符。

• 控制特定的適當數(shù)據(jù)類型以進行輸入。 將輸入限制為必需的數(shù)據(jù)類型和大小。

• 控制輸入數(shù)據(jù)的語法。 不要允許任何模式外的任何東西。

• 控制允許的條款。 黑名單SQL關鍵字。

你可能不知道注入攻擊的危險，或者可能認為它們不重要，但它們是安全問題的列表。 此外，考慮這兩個條目的效果 -

1=1
-or-
*

允許任何一個與正確的命令一起輸入的代碼可能導致揭示數(shù)據(jù)庫上的所有用戶數(shù)據(jù)或刪除數(shù)據(jù)庫上的所有數(shù)據(jù)，并且兩種注入都不是特別聰明。 在某些情況下，攻擊者甚至不花時間檢查孔; 他們用簡單的輸入執(zhí)行盲攻擊。

另外，考慮由與MariaDB配合的任何編程/腳本語言提供的模式匹配和正則表達式工具，它們提供更多的控制，有時更好的控制。