聯合登錄（OpenID，例如）是否構成SQL注入風險？

是否可以安全地假定所有身份提供者都要對用戶信息進行消毒，或者是否可以創建一個帳戶或身份提供者來傳遞惡意用戶名，電子郵件，聯繫人列表等？聯合登錄（OpenID，例如）是否構成SQL注入風險？

2011-09-07 America

現有供應商的可信度是不相關。攻擊者可以編寫自己的身份提供者並使用它來發送任何他們想要的內容。您幾乎不應該信任第三方數據。

2011-09-07 16:04:59

我應該更多地沿着這些方向說出我的問題。很高興知道。 – America

與我之前一小時之前的答案完全相同： –

永遠不要假設別人會爲您清理數據。自己做，或者（更好地）以一種防止通過正確編碼參數進行SQL注入的方式連接到數據庫。

2011-09-07 15:55:03

我們有幾個人在他們的電子郵件地址中有撇號，這不是無效的......問題不是撇號，而是編碼員沒有使用參數化查詢和/或存儲過程。真的沒有人應該使用內聯SQL並串聯串，這些天，這將防止幾乎所有的SQL注入攻擊

如果你必須使用例如SQL服務器，然後使用sp_executeSQL與參數，而不是EXEC動態SQL ...

2011-09-07 15:55:23 SQLMenace

有動態SQL的有效用例說它應該永遠不會被使用是天真的 –

我在哪裏提到最後一段之前的動態SQL？ – SQLMenace

暗示，你說使用除存儲過程或參數化查詢以外的任何內容都是錯誤的，默認情況下唯一的其他事情是動態SQL。許多由ORM框架構建的'SELECT'查詢依賴動態SQL作爲唯一的方法來執行您想要的操作。唯一的方法是根據輸入動態地創建查詢字符串。 –

即使他們不允許這樣的字符，即使規範禁止這些字符，你也不應該依賴它。

確保當您收到數據時，它符合您的期望。此外，玩安全並始終使用準備好的語句/參數化查詢，無需轉義參數，或者，如果不可能，則轉義查詢參數。通過習慣做到這一點，你不會有令人討厭的驚喜。

2011-09-07 15:57:20 Artefacto

回答