如果你使用 剝離字符 為了清理使用者輸入，你並不孤單。許多開發者都依賴這種技術。 輸入淨化 為了阻止注入嘗試。乍一看，這似乎合乎邏輯：移除危險字符，有效載荷就會消失。然而，這種方法會給人一種虛假的安全感。事實上，攻擊者可以繞過簡單的過濾器，例如 剝離字符 使用 混淆的有效載荷編碼或巧妙的上下文切換。這就是為什麼聰明的開發者不會止步於此。相反，他們會使用 參數化查詢這樣就能從根源上防止注入攻擊。
在這篇文章中，你將會了解為什麼 剝離字符 我們將探討這些過濾器在實際場景中的失效情況，攻擊者如何濫用這些過濾器，以及哪些安全的替代方案真正有效。我們將透過程式碼範例，展示常見的繞過技術，並解釋其工作原理。 輸入淨化 必須始終與結構保護措施結合，例如 參數化查詢否則你將一直處於弱勢。
事件 剝離字符 實際上會（也會不會）
許多開發者使用 stripchar 或使用類似函數從使用者輸入中移除不安全字元。通常，它會移除標點符號、特殊符號或任何非字母數字字元。乍聽，這似乎… 輸入淨化但這並非真正的保護。
讓我們來詳細分析一下。像這樣的函數：
刪除類似這樣的字符 ', "， 或者 ;所以，如果你輸入：
它變成了：
即使使用者輸入看起來很乾淨，攻擊者仍然可以僅使用邏輯注入 SQL 有效載荷，尤其是在應用程式透過字串連接建立查詢時。 要真正防止 SQL 注入您必須使用參數化查詢和上下文感知輸入處理。字元過濾器，例如 stripchar() 僅僅這些是不夠的。
沒錯，乍一看，去除冗餘資訊的輸入似乎更安全。然而，這種方法並不能消除惡意邏輯，它只是改變了惡意邏輯的寫法。事實上，攻擊者經常利用這一點，透過對有效載荷進行編碼、插入空格或巧妙地使用被移除的字元來完全繞過你的過濾器。
除了， 剝離字符 缺乏關鍵上下文資訊。它不知道輸入的內容是要傳送到資料庫、shell 還是瀏覽器。這意味著它無法應用正確的轉義或編碼。在不知道目標位置的情況下對輸入進行清理，就像在真正的威脅出現之前就對 HTML 進行轉義一樣。 SQLi.
在最後， 剝離字符 它既不解釋也不保護任何內容，只是編輯字串。而編輯並不等於安全。如果你想要真正的保護，請使用結構化、經過驗證且參數化的查詢。就這麼簡單。
為了更清楚地說明區別，以下將 stripchar 與參數化查詢進行並排比較：
Stripchar 查詢與參數化查詢：哪種方式更能保護你的程式碼？
| 獨特之處 | stripchar() | 參數化查詢 |
|---|---|---|
| 防護等級 | 基本的字串清理。很容易透過編碼或邏輯技巧繞過。 | 強大的防護能力，可抵禦所有形式的 SQL 注入攻擊。 |
| 上下文意識 | 完全不考慮上下文（SQL、HTML、shell 等），所有地方都採用相同的規則。 | 完全上下文感知。針對每種環境使用正確的轉義字元。 |
| 開發人員的努力 | 實施起來快速方便，但長期使用不可靠。 | 需要正確集成，但功能強大且面向未來。 |
| 旁路電阻 | 低風險－攻擊者很容易利用空格、編碼或邏輯來適應。 | 高－將程式碼與資料分離，可靠地阻止注入。 |
| 安全信心 | 虛假的安全感－可能會掩蓋問題而不解決問題。 | 值得信賴的行業 standard 為了安全執行查詢。 |
攻擊者如何繞過輸入過濾
這就是開發人員依賴以下機制時，典型的易受攻擊流程的樣子： 剝離字符 用於輸入資料清理：
攻擊者不需要突破你的過濾器，他們只需要… 繞過他們當開發者依賴 剝離字符 為了進行輸入清理，攻擊者通常認為移除引號或分號等字元就能阻止注入攻擊。然而，攻擊者會迅速調整策略。他們會精心設計並建構新的攻擊手段。 混淆的有效載荷 尤其是在缺乏上下文的情況下，這些過濾器會漏過基於正規表示式的過濾器。
例如，假設您嘗試像這樣對輸入進行清理：
即使用戶無法提交經典作品 ' OR 1=1 --它們可以使用 Unicode 技巧、字串拼接或仍然可運行的語法錯誤。像這樣的有效載荷通常都能奏效：
要么：
如果你的函數會移除非單字字符，你可能會… 意外地重構了一個有效的 SQL 指令更糟的是，攻擊者可以以能夠通過你的過濾器但會被目標系統解碼的方式對值進行編碼。
除了 SQL 注入之外， 剝離字符 在其他情況下也會失敗，例如 shell 指令、檔案路徑，甚至是 JavaScript 執行。由於它無法感知輸入的內容將在哪裡使用，因此無法進行正確的轉義或驗證。
其結果是， 輸入淨化 - 剝離字符 很容易繞過。真正的安全來自 情境感知控制，尤其是 參數化查詢 完全阻止邏輯注入。
為什麼你應該使用參數化查詢
如果你想真正阻止注入攻擊，你需要… 停止使用字串建構查詢。. 那就是那裡 參數化查詢 進來。不像 剝離字符他們不進行過濾，他們 將程式碼與資料分離 在發動機層面。
讓我們重新檢視一下這個出錯的查詢：
這樣做很危險，因為輸入會直接注入 SQL 。即使進行了字元剝離，你仍然會建立一個可能被濫用的字串。相反，請使用參數化查詢，例如：
在這裡，資料庫驅動程式知道 userInput 是數據， 非可執行程式碼它會自動轉義並阻止注入，即使輸入包含引號、分號或十六進位編碼的有效載荷。
在Python中：
在 PHP 中使用 PDO：
在所有這些例子中， 參數化查詢 無需猜測哪些字元可能有風險，即可防止注入。您不需要 脫脂劑， 你需要結構化的、上下文相關的查詢建構方式。
此外，該技術還能阻止混淆的有效載荷、Unicode技巧和編碼繞過，這些手段與在以下情況下發現的規避模式相同： XSS 漏洞像 Xygeni 這樣的工具可以及早發現這些威脅。 SAST 分析.
簡而言之，真正的防禦並不依賴過濾器，而是依賴協定、可信的 API 和完整的上下文。如果您使用框架或動態服務注入，請務必了解輸入如何在您的程式碼庫中傳播。 安全依賴注入 確保即使是複雜的流程也不會打開新的攻擊面。
不要依賴 剝離字符使用 Xygeni 加強真正的防禦
即使你使用 參數化查詢並不能保證你的整個程式碼庫都遵循相同的規範。 standard遺留邏輯、第三方腳本或 PR 中被忽略的程式碼行仍然可能引入註入風險。而這正是 Xygeni 的作用所在。
Xygeni 會掃描你的原始碼， pull requests和 CI pipeline需要捕捉的：
- 使用連接建立 SQL 的查詢字串
- 弱效或自製過濾器，例如 剝離字符
- 可疑邏輯與已知的混淆有效載荷相匹配
您無需逐行檢查。 Xygeni 會及早標記不安全的模式並套用。 自動修復 在可能的情況下，可以透過可自訂的方式阻止有風險的合併。 Guardrails.
總之， Xygeni 確保參數化查詢不僅僅是一種最佳實踐，而且能夠大規模地強制執行。 無需猜測，無需擔心漏檢，只有真正的保護。
重點總結：需要記住的內容 剝離字符 注射風險
- 剝離字符 不是一項安全功能 ——它移除的是字符，而不是風險。
- 輸入清理還不夠。 當您使用字串連接建立查詢時。
- 參數化查詢才是正確的防禦措施。而且，每一種現代語言或框架都支援它們。
- 混淆後的有效載荷可以繞過過濾器。尤其是當涉及到編碼技巧時。
- 靜態分析（SAST工具能夠捕捉到人類所忽略的東西。包括隱藏在遺留程式碼中的不安全模式。
- Xygeni 可自動進行偵測、優先排序，甚至還能自動進行修復。 這樣你的團隊就可以專注於寫功能，而不是追蹤漏洞。
結論：不要相信過濾器。安全設計才是王道。
依賴諸如此類的功能 剝離字符 乍看之下似乎是權宜之計，但它們會給人一種虛假的安全感。攻擊者的進化速度遠遠超過字串過濾器。阻止注入攻擊的唯一可靠方法是從一開始就編寫安全的程式碼，並在所有地方強制執行這種設計。
Xygeni 等工具可以幫助您自動完成此操作。 pull request 至 pipeline它們能發現你的過濾器漏掉的東西，並在它進入生產環節之前將其修復。
