您應該將輸入驗證實現為縱深防禦方法。因此，輸入驗證不應成為防範SQL注入的主要手段，而應該是準備好的語句。作為一項額外的防禦措施，應限制允許的輸入。

這永遠都不應限制功能。如果有合法的用例在輸入中包含撇號，則應允許使用。因此，您應該在名稱字段，描述，密碼中使用單引號，但在數字字段，用戶名字段，車牌字段中不允許使用單引號。

在所有輸入中均禁止使用單引號是很瘋狂的。這破壞了應用程序的功能，甚至不是針對SQL注入的正確解決方案。

請考慮您誤解了滲透測試公司的可能性。如果這是他們的嚴重建議，那麼這對滲透測試公司會造成嚴重影響，我建議您尋找滲透測試合作夥伴，以幫助適當保護您的軟件，而不是使其無法使用。

在註入攻擊的上下文中，這顯然是錯誤的-您的數據庫層正在正確處理字符串還是沒有。由於撇號在名稱和自由文本中都是有效的，因此完全阻止撇號將破壞應用程序，而選擇性地阻止它們將無法解決注入問題。

但是嚴格的輸入驗證 很好按照一般原則進行練習，並且在撇號不是合法值的情況下，過度放任是沒有意義的。您以 EUR 1'000'000 為例，它是一種特定於語言環境的格式（僅瑞士，AFAIK）-但是，允許該格式成為值的一部分毫無意義。如果用戶輸入 1,500 ，您的應用程序應該按原樣存儲嗎？您是否必須確定每次處理時應將其解釋為1.5還是1500？在客戶端處理特定於區域設置的表示，並在內部以規範的形式處理數字值會更有意義。

因此，此處的答案取決於審計是否在抱怨特定字段在有意義的地方，或者建議徹底禁止撇號。如果是前者，那是合理的觀點。如果是後者，則它們很愚蠢，並且可能會盲目地遵循清單。

步驟1）參數化您的SQL。

步驟2）確保您正在使用SQL DB連接庫設置參數值，不是只是內聯設置。這是針對SQL注入的實際防禦措施。

第3步）不要在SQL中進行查詢構建。

第4步）添加配置開關，將錯誤一直傳播到用戶。

第5步）告訴滲透測試人員找到一種生成帶有單引號奇數或關閉的SQL錯誤的方法。

準備好的語句（參數化查詢）非常棒，只需確保正確實現即可。我見過“準備好的語句”實現，每個實現都一樣脆弱。對於實現細節的討論，我建議堆棧溢出。

縱深防御也沒有錯（在這種情況下為輸入驗證），但做得很好...拒絕所有單引號可能不是最佳實踐：）

我不是安全人員。我是一個必須維護安全代碼的程序員。這就是我所說的“脆性”練習。入口點分散在整個典型項目中。找到並清除所有這些錯誤是一項艱鉅的工作，只能解決一個問題，需要進行大量的維護和麻煩工作，以確保在代碼更改時該代碼仍然有效，並且存在使該代碼無效的各種假設。

而是使用更易於維護，分層，上下文化和解決大量問題的實踐。這樣一來，您就不需要昂貴的，過於寬泛的過濾。

如果您不知道輸入將如何使用，就無法保證輸入的安全。

假設您已經通過從所有輸入中去除所有單引號來“保護”系統。太好了，您可以安全地抵禦一種類型的SQL注入攻擊。如果該輸入用於允許雙引號的MySQL查詢...

• MySQL查詢
• 文件系統操作
• Shell命令
• 網絡查詢
• 方法名稱
• 類名稱
• eval

每個它們具有不同的特殊字符，轉義序列，引用規則和安全性慣例。您可能無法預測輸入內容將如何使用。試圖去除所有特殊字符是瘋狂的，只能“解決”一類攻擊。

或者如果允許用戶使用該怎麼辦？輸入頁數限制。該限制在參數化查詢中應有盡有；沒有SQL注入，是的！用戶輸入 9999999999 ，現在您可以進行DOS攻擊。

您必須在執行可能不安全的操作時應用適當的安全措施。這考慮到了操作所特有的許多因素。清理輸入字符只是一個。

只要您這樣做，還可以對查詢進行參數化。這樣一來，就不再需要做所有的工作，也不必破壞橡皮布的報價。

過濾所有輸入非常困難。

在給定的項目中有很多很多方法來獲取和傳遞輸入：

• 表單輸入
• URLs
• 文件名
• 文件內容
• 數據庫查詢
• 網絡讀取
• 環境變量

這些通常是非常自由的形式，可以使用許多不同的庫。我不知道有任何靜態分析工具可以驗證所有潛在的易受攻擊的輸入是否已通過過濾。某些語言具有 taint 系統，但是很難有效使用。即使您過濾了所有輸入，如果沒有靜態分析工具，未經過濾的輸入也會隨著開發的進行而洩漏回來。維護結果不完整，成本高昂會影響功能。

相反，通常只有一種方法可以在項目中執行SQL。存在靜態和運行時工具來自動檢測潛在的SQL注入。您甚至可以完全禁止使用字符串，並要求所有查詢均為SQL查詢對象。這些良好做法易於維護，並且越來越多地融入工具和SQL庫中。

“防火牆”導致安全性寬鬆。

類似於某些辦公網絡的做法非常不安全，因為“我們有防火牆”，由於“輸入是安全的”，因此團隊有可能懶於保護代碼安全。輸入的內容絕對是不安全的。

機會成本

有人可能會說“為什麼不同時使用？”您只有這麼多小時來從事項目。低效率，高維護實踐是很麻煩的。實施和維護它會花費您有限的時間來避免更高效，更易於維護的實踐。在最壞的情況下，您將花費大量時間來玩弄輸入漏洞，以及隨後因過於激進的過濾而導致的問題，以致您將永遠沒有時間採取適當的安全措施。

簡而言之，輸入過濾昂貴，洩漏，難以維護，無法解決問題並且可能使情況變得更糟。

正如您自己說的那樣，如果您使用的是參數化查詢，那麼單引號就不成問題。在這種情況下，您可以拒絕他們的建議。如果這樣做，請強調您使用參數化查詢 的事實，這也有助於提高可用性（使用先前的示例）。

如果您100％確保始終在所有地方防止SQL注入，那確實是胡說八道。

但是，SQL注入是最常見的安全風險之一，即使您確定自己如果正確編寫了您的應用程序以使用參數，那麼草率的DBA可能會執行查詢，而該查詢可能會受到二階SQL注入的威脅。它甚至可能不會存儲在任何地方，而可能只是複製表的查詢。

二階攻擊更難以執行，但更難以防範。防範二次攻擊意味著需要檢查在數據庫上運行的具有寫權限的每個動態SQL語句是否存在SQL注入的風險，不僅是處理來自不受信任來源的輸入的SQL語句。

不允許使用引號到處都是對第二級攻擊的草率防護，但確實降低了它們的可能性。在理想的世界中，這不是必須的，但是不幸的是我們並不生活在一個世界中。

如果許多用戶對數據庫具有任何形式的寫訪問權限，並且能夠寫自己的SQL語句，則這可能是明智的安全措施。如果您的應用程序是訪問數據庫的唯一方法，並且只有非常有知識的用戶可以執行具有寫訪問權的查詢，那麼通常就沒有必要。

雖然我不知道您的應用程序的詳細信息，但是我會遵循您的說法。

有些字段不需要包含某些字符。在這些字段中，您可以使用輸入驗證來過濾單引號（和雙引號以及其他內容）。

如果轉義無法正常工作，則輸入驗證可能是緩解策略，但是（正確地）使用準備好的語句應該是減輕SQL注入風險的首選方法。

如果這是真正的滲透測試的結果，那麼他們應該能夠為您提供一個值，以證明這是一個可利用的問題。如果他們不能，那麼我建議您要求進行適當的滲透測試，以證明它們可以被利用。

但是，如果這是通用漏洞掃描的結果，那麼我會期望像這樣的模糊通用響應，只會標記能夠插入單引號。在這種情況下，如果您對沒有問題感到高興，那麼您可以很高興地忽略該結果。

從一位前Web開發人員到我自己的筆測試儀，我不想限制用戶的輸入，但這可能是一個主要問題。我知道我自己就是使用這種技術來破壞Web應用程序和數據庫的。對輸入進行迭代以確保其格式正確。

撇號可以是有效輸入，但也可以避免傳遞數據庫語句並引入攻擊向量。 DB和Web語言具有可以處理這些類型實例的模塊，但是編寫自己的模塊進行仔細檢查仍然是一個好主意。

我認為這是一個觀點問題。您的系統具有應首先滿足的功能要求。這並不意味著不值得考慮輸入驗證的問題。順便說一句，兩者並不直接矛盾。我不建議這樣做，但是可以在前端進行編碼和解碼，並讓SQL存儲和查詢使用編碼形式。

平衡是主觀的，取決於許多事情沒有提到。您可以嘗試讓他們澄清。他們可能有很好的理由，但可能沒有。

我將與大多數其他當前答案相矛盾。

您的滲透測試者幾乎可以肯定100％是正確的。

我的假設：沒有值得花費的五分錢他們的鹽會報告此情況，除非他們發現您的應用程序在沒有撇號有效的情況下接受並回傳了撇號。

也許您的用戶名，電話號碼，域名和日期都應具有特定格式和字符範圍。所有人都應該沒有撇號。但是，相反，對於所有這些字段，您只接受它們給您的任何舊字符串。

如果此假設為假，並且您已經盡可能嚴格地驗證輸入，則

如果這個假設是正確的，並且撇號在該輸入中無效，那麼：

• 是，您應該直接拒絕無效輸入。
• 您應該不允許他人使用損壞的數據污染數據庫。
• 您應該不要嘗試在顯示時清理數據，這要比嘗試清理 <script> 的嘗試多，因為攻擊者只會找到一種利用清理的方法算法，例如 <script > 或 <scr<script>ipt> 或 + ADw-script + AD4-或其他任何方法。
• 有例外，但應將其明確定義為s
• 除非您的要求明確處理帶撇號的瑞士地區貨幣，否則您的示例“ 1'000'000”不再是“ 1〜000〜000”或“ 1ba​​nana000apple000”。拒絕它。不要試圖清除“ 1'000”，您不知道它們是指1,000還是1.000或14000，還是一個英尺或一個學位或完全不同的東西。

查詢參數化僅避免大多數 SQL注入類：並非所有可能的無效數據濫用。

但是所有其他系統呢？依靠符合公司標準的用戶名？您剛剛破壞了它們。

• 用戶是否有主目錄？
• 他們的名字會被記錄在任何地方嗎？
• 他們曾經被顯示嗎？
• 用戶名是否曾經在系統的命令參數中使用？
• 他們曾經發送過AJAX或XML數據嗎？
• 是否存在對一批用戶名運行的批處理模式操作，例如名稱以A到M開頭，N通過Z接下來，第三天的0-9，然後重複？這些批次永遠不會對您的用戶'-_ haxxor _-'不利。
• 在某些情況下，冒充其他用戶對某人有害或有用，所以您希望他們都有唯一的名字？但是他們可以通過註冊JohnͿοոЈоհ或like來冒充用戶John。
• 所有使用名稱的系統都不能拒絕您提供的值。處理無效的輸入，嘗試清除或轉義它們，即使我們已經表明這是不安全的並且注定要失敗。但是，由於該用戶已經註銷很久了，因此他們不會看到任何要求輸入新電子郵件地址的錯誤。
• 您的DBA現在在他的數據庫中有廢話。這不僅使他在日常工作中，而且在他不得不遷移數據時，都會給他帶來很多痛苦，因為目標系統中任何更嚴格的約束都會破壞舊數據。
• 您的同事您的數據的其他使用者現在必須驗證他們從數據庫讀取的所有內容，因為他們甚至不相信您已經執行了完全記錄的標準。
• 您的用戶現在使用的是不太安全的系統。
• 您現在必須對所有這些輸入進行重新處理，以確保不再將廢話添加到數據庫中。

查詢參數化不是正確清理輸入的替代方法。