1 回答

TA貢獻1898條經驗 獲得超8個贊
輸入清理是一個誤導性術語,表示您可以對所有數據揮動魔杖并將其設為“安全數據”。問題是當數據被不同的軟件解釋為編碼要求時,“安全”的定義會發生變化。同樣,“有效”數據的概念因上下文而異——您的數據很可能需要特殊字符('、、&、<)——請注意,SO 允許所有這些作為數據。
可以安全嵌入到 SQL 查詢中的輸出可能不安全地嵌入到 HTML 中?;蛩雇蛱??;?JSON?;蛲鈿っ??;?CSV。并且剝離(或徹底拒絕)值以便它們可以安全地嵌入所有這些上下文(以及許多其他上下文)中,限制性太強。
那么我們應該怎么做呢?確保數據永遠不會造成損害。實現這一點的最佳方法是首先避免解釋數據。參數化 SQL 查詢就是一個很好的例子;參數永遠不會被解釋為 SQL,它們只是作為數據放入數據庫中。
相同的數據可用于其他其他格式,例如 HTML。在這種情況下,數據應在嵌入時針對該特定語言進行編碼/轉義。因此,為了防止 XSS,數據在被放入輸出時應該是 HTML 轉義(或 javascript 或 URL 轉義)。不是在輸入時。這同樣適用于其他嵌入情況。
那么,我們應該直接將我們得到的任何東西傳遞給數據庫嗎?
不 - 您肯定可以檢查有關用戶輸入的內容,但這高度依賴于上下文。讓我們稱其為 - 驗證。確保這是在服務器上完成的。一些例子:
如果一個字段應該是一個整數,你當然可以驗證這個字段以確保它包含一個整數(或者可能是 NULL)。
您通??梢詸z查特定值是否是一組已知值中的一個(白名單驗證)
您可以要求大多數字段具有最小和最大長度。
您通常應該驗證任何字符串僅包含對其編碼的有效字符(例如,沒有無效的 UTF-8 序列)
如您所見,這些檢查非常依賴于上下文。所有這些都是為了幫助增加您最終獲得有意義數據的幾率。它們不應該是保護您的應用程序免受惡意輸入(SQL 注入、XSS、命令注入等)的唯一防御,因為這不是這樣做的地方。
- 1 回答
- 0 關注
- 143 瀏覽
添加回答
舉報