使用html僅阻止SQL注入

Question

我試圖驗證註釋框的輸入以僅接受文本，並在用戶輸入數字（1-0）或符號（@＃$％^ & * + _ =）。防止SQL注入

是有辦法做到，在HTML

Answer 1

您可以從未信任什麼是來自客戶端。您必須始終通過服務器端檢查來阻止諸如SQL注入之類的操作。

您當然可以添加您提到的客戶端驗證，但它只是幫助用戶不輸入垃圾數據。發送到服務器後仍然不能相信它。

Answer 2

的問題似乎更加直截了當，但我把我的答案和以前一樣：

決不驗證的客戶方信息。它沒有任何意義，因爲您需要在服務器上使用相同（甚至更好）的方法驗證相同的信息！在客戶端進行驗證僅會產生不必要的開銷，因爲來自客戶端的信息不可信。它浪費能源。

如果用戶發送許多不同的符號但沒有真正的消息的用戶有問題，你應該立即關閉你的服務器！因爲這可能意味着你的用戶試圖找到一種方法來侵入服務器以獲得控制權！

如果服務器不能正確逃避用戶輸入，一些奇怪的特殊字符組合可以允許這樣做！

簡而言之： HTML用於內容顯示，用於設計內容的CSS，用於交互的Javascript以及用於處理，傳遞和驗證信息的其他語言，如Perl，PHP或Python。這些最後被調用的語言通常在服務器上運行。即使你在服務器上使用它們，你也需要非常小心，因爲有可能使它們變得無用。 （例如，如果你用錯誤的方式使用全局變量，或者你沒有正確地逃避用戶輸入。）

我希望這有助於獲得正確的方向。

Answer 3

在使用Javascript/HTML，以提高安全性

是有辦法做到這一點在HTML

號正如其他人所指出的那樣，你不能做任何事情提高安全性你的HTML或Javascript。

原因是您的瀏覽器和您的服務器之間的通信對攻擊者完全透明。任何開發人員可能都熟悉Firefox，Chrome等中的「開發人員工具」。即使是那些在大多數新型瀏覽器中都有的工具，也足以創建任意HTML請求（甚至通過HTTPS）。

因此，您的服務器絕不能依賴請求任何部分的有效性。不是URL，不是GET/POST參數，不是cookies等;你總是必須自己驗證它，在服務器端。

在SQL注入

SQL注入是最好的確保從不迴避有這樣的代碼：

sql = "select xyz from abc where aaa='" + search_argument + "'" # UNSAFE 
result = db.execute_statement(sql) 

也就是說，你永遠要剛剛加入串在一起的SQL語句。

相反，你想要做的是使用綁定變量，類似這樣的僞代碼：

request = db.prepare_statement("select xyz from abc where aaa=?") 
result = request.execute_statement_with_bind(sql, search_argument) 

通過這種方式，用戶輸入的是永遠不會被解析爲SQL本身，這就使得SQL注入是不可能的。當然，檢查客戶端上的參數以改善用戶體驗（避免服務器往返延遲）仍然是明智的;也可能在服務器端（以避免隱晦的錯誤消息）。但是這些檢查不應該與安全性混淆。

Answer 4

簡答：不，你不能在HTML中做到這一點。即使是帶有單個複選框和提交按鈕的表單也可能被濫用。

較長的答案...

雖然我堅決不同意有什麼可以在HTML和JavaScript做來增強安全性，這方面的一個全面討論超出了這裏後的邊界的方式。

但最終你不能假設任何來自你不控制的計算機系統的數據都是安全的（事實上，在很多應用程序中，你不應該假設你控制的機器上的數據是安全的）。

對於任何攻擊，您的主要防禦措施是將數據在發送和接收組件之間轉換爲已知的安全格式，然後在您的系統組件之間傳遞。在這裏，我們具體討論將數據從服務器端應用程序邏輯傳遞到數據庫。此交換中不涉及HTML或JavaScript。

走向客戶，你有選擇。您可以驗證並接受/拒絕內容，以便根據數據中的模式進行進一步處理，也可以處理所有數據，並將您的信任放在正確處理內容的較低層中。通常，人們會採取第一種選擇，但這會產生新的安全問題;很容易找出防禦措施並找出差距。在一個無所謂的理想世界裏 - 更深層次的防禦能夠解決問題，然而在現實世界中，開發人員受時間和能力的限制。如果歸結爲您選擇何種技能/時間預算，那麼答案應該始終是讓輸出更安全以確認輸入。