記一次防止SQL注入引起的生產問題
最近在生產系統上遇到了一個問題.
在前後端代碼都沒有修改的情況下,某個用@RequestBody ADTO接受請求參數的接口,突然報錯了
錯誤信息大概是說,入參xxxupdateXXX,在 ADTO中找不到對應的屬性.
ADTO中有屬性xxxUpdateXXX,就是差了一個大寫一個小寫.
但是抓包看前端的入參,確實是xxxUpdateDate但是到了請求裏面,不知道怎麼變成小寫的了.
然後聽另外一個同事說,她那邊也有select從大寫被替換成小寫的問題.
才反應過來,兩個都是sql關鍵字,那麼應該是在SQL處理的環節出現了問題,
諮詢了同事,才知道最新系統爲了防止SQL注入,對請求入參中的所有包含有SQL關鍵字的地方,都做了處理,但是他們的方案是有問題的,是簡單粗暴的對所有請求入參中的所有字符串,都做了替換.
所以導致了我們這個問題.
這個問題其實應該更好排除出來.還是思維方式不夠正確,沒有遵循我們之前的排除問題的分析方法
從問題的原因入手:分析字段得知,只有Update字段,會被修改成update,而其他的字母有大寫也沒有被替換.
所以得出第一個結論
1.只對Update字段做了變小寫處理
2.從Update中應該得知,update是屬於SQL關鍵字.問題應該出現在SQL相關配置中.
3.從前端入參正確,後端接受改變,應該能推導出來,是後端某個攔截器之類的,對入參做了Update的處理,所以就應該是SQL注入過濾器等.