我正在構建一個晦澀難懂的應用程序，只有在涉及註冊過程後纔可用，因此提交惡意數據不應該經常發生。表單驗證主要在JavaScript中，只有安全驗證服務器端
我使用Codeigniter 2.1來過濾所有POST變量。 Codeigniter使用PHP函數mysql_real_escape_string以及其他措施來防止通過POST數據進行SQL注入攻擊。
我使用JavaScript做所有我的驗證客戶端。 JavaScript驗證運行良好。當然，用戶可以使用cURL或其他實用程序繞過客戶端驗證，但Codeigniter中的股票PHP驗證應防止SQL注入，對吧？
我可以做我的驗證客戶端並信任Codeigniter保護數據庫免受SQL注入攻擊嗎？
這是codeigniter聲稱的。你可以在system/core/Security.php文件中找到它。
清理數據，以防止跨站點腳本攻擊。 這個功能做了相當多的工作，但它非常全面， 旨在防止即使最晦澀的XSS嘗試。沒有什麼是 從來沒有100％萬無一失，當然，但我一直沒有能夠得到任何通過過濾器的東西 。
這很簡單恕我直言。如果它使用mysql_real_escape_string，則在所有情況下都不安全。請參閱此答案以獲取更多信息：Best way to prevent SQL Injection in PHP。
除了你不安全的事實，它也使用過時的功能與mysql交談。
另外：你應該總是做服務器端驗證！永遠不要相信客戶端！
我同意應該實施服務器端驗證，並且Codeigniter確實實現了服務器端驗證的級別。問題：Codeigniter是否做了足夠的驗證，而不是任何需要的驗證。 – steampowered 2012-07-05 17:48:01
SQL注入只是一件需要擔心的事情（你可能對這個問題很安全）。你應該**總是使用服務器端驗證**，Javascript驗證只是一個方便的功能（Javascript甚至可以關閉，當談論安全性時，它是沒有價值的）。用戶可以發送任何類型的數據，他們可以操縱你的表格，他們甚至不需要捲曲。 – kapa 2012-03-08 10:23:54
我同意服務器端驗證應該實現，並且Codeigniter確實實現了服務器端驗證的級別。問題：Codeigniter是否做了足夠的驗證，而不是任何需要的驗證。 – steampowered 2012-07-05 17:48:16
當然還不夠。它可以防止某些類型的攻擊，但是你總是要嚴格。如果你期望一個日期，只接受一個日期。如果你期望一個號碼，只接受一個號碼。等等您應該考慮客戶端驗證不存在。另外，篩選和驗證也不相同。 – kapa 2012-07-05 17:51:47