資料庫SQL陳述句的安全方案
1.必須禁用字串操作的方式來組合執行SQL陳述句，而使用預編譯陳述句 Prepared statements 來生成 并執行SQL 的請求，
2.服務端代碼中使用字串拼接的方式來生成SQL陳述句進行UPDATE，INSERT是很常見的，
我們通常會用 escape_string 的方式來進行轉義來防止SQL注入，
這種操作方式進行操作資料庫存在的風險非常高，除了SQL注入漏洞的風險之外，在實際專案中它還會出現一些更難以預防的風險，記憶體錯誤等問題，
根據谷歌官方曾經披露的資料，繁忙的業務集群中，每8GB記憶體每小時的錯誤率高達5個bit，當然服務器必須使用ECC記憶體，但雖然ECC記憶體中每 64bit 的 word 中發生1 bit 錯誤時可以被控制器修正，
但如果發生2個bit的錯誤時，就無法被修正了，那么計算一下，ECC記憶體發生無法修復的記憶體錯誤的概率是：每8GB每小時 1/2.2737368e-11，看上去好像很低，但是如果是一組200臺x每臺512G記憶體的服務器集群，一年內發生無法修正的記憶體錯誤的概率可以高達達到千分之2.5，
比如一段SQL代碼本來是 UPDATE data=‘xxxx’, b=10003 WHERE n=8888 ，因為錯了一個bit, 3變成#，陳述句變成 UPDATE data=‘xxxx’, b=1000# WHERE n=8888 ，我們知道 # 是 mysql 行內注釋，所以這個陳述句還能正常執行，只是沒有了 WHERE 條件，并把整個庫的所有用戶資料都 update 了……
比較好的解決方案是：使用 MySQL 的預編譯陳述句 Prepared statements 來生成 SQL 請求，這樣做的好處，不僅是防止 SQL 陳述句出錯甚至被注入，而且還能獲得更高性能，
更多安全技術文章，請關注 “游戲安全攻防” 公眾號，一起學習，一起進步，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/246511.html
標籤：其他
上一篇：Apache網頁優化實用技巧
下一篇：和面試官對線HashMap