SQL注入的潛力在這裏？

這可能是一個非常愚蠢的問題，但我想爲什麼不...SQL注入的潛力在這裏？

我使用實體框架RIA服務作爲後端。我在我的應用程序中有一些地方接受用戶輸入，並使用他們的數據直接詢問RIA Services（反過來EF和我的數據庫）問題。這些圖層中的任何一個都有助於防止安全問題，還是應該自己清理數據？

例如，每當一個新用戶註冊使用的應用程序，我把這個方法：

[Query] 
public IEnumerable<EmailVerificationResult> VerifyUserWithEmailToken(string token) 
{ 
    using (UserService userService = new UserService()) 
    { 
     // token came straight from the user, am I in trouble here passing it directly into 
     // my DomainService, should I verify the data here (or in UserService)? 
     User user = userService.GetUserByEmailVerificationToken(token); 
     ... 
    } 
}

（我是否應該是我自己的滾動用戶驗證系統的完全是另一個問題，我們在這個過程中我對sql注入和RIA服務更感興趣）

來源

2010-06-10 Matt Greer

SQL注入是基於未轉義串生成原始SQL字符串

例如，當正在使用

"SELECT * FROM `user` WHERE `name` = '" . $name . "'"

是脆弱的，因爲$name的值可以包含一個「標記，從而修改的含義sql語句。一個很好的例子是，如果$ name是' OR 1=1; --因此使該SQL查詢：

"SELECT * FROM `user` WHERE `name` = '' OR 1=1; --'"

這是繞過密碼檢查我可以告訴你:)

解決這個正確的方法是爲了躲避「非常有用字符到\'（對於mysql）。這就是爲什麼諸如php這樣的語言提供了mysql_real_escape_string。但是，如果您使用適當的參數化查詢系統，則可以傳遞任何您喜歡的內容，並且庫將正確地轉義它。

看你的代碼，沒有任何理由來檢查token價值，除非你UserService做一些狡猾的SQL字符串代（我敢肯定，實體框架沒有這樣做，所以你應該就好了）

來源

2010-06-10 15:08:57 oedo

無論它們來自哪裏，您都應該清理數據庫查詢。執行SQL注入的方法非常有趣，程序員從來沒有想到過它。而清理輸入根本不是資源消耗。 – TheLQ 2010-06-10 15:15:21

當然，如果庫/框架已經在擦洗它們呢？否則你可能會得到不正確的（例如雙重轉義數據）數據。 – oedo 2010-06-10 15:20:10

你應該是安全的，我確信EF正在生成參數化查詢來從數據庫中檢索數據。

來源

2010-06-10 15:07:14 scottm

EF會爲您設置參數，但是如果您確實要確保啓動SQL Profiler並查看發送給SQL Server的內容，請執行以下操作：

來源

2010-06-10 15:10:57 SQLMenace

SQL注入的潛力在這裏？

回答

相關問題