使用int參數的SQL注入漏洞使用int參數

大多數時候我使用存儲過程訪問數據，但有時我使用的語句我認爲不容易受SQL注入攻擊。使用int參數的SQL注入漏洞使用int參數

下面是一個例子，我用

protected void Page_Load(object sender, EventArgs e) 
{ 
     try 
     { 
      int CatID = Request["CatID"]; 

      if (!IsPostBack) 
      { 
       getDetails(CatID); 
      } 
     } 
     catch (Exception ex) 
     { 
      Response.Write(ex.Message.ToString()); 
     } 
    } 

    private DataTable getDetails(int CatID) 
    { 
     try 
     { 
      DataSet ds = new DataSet(); 

      string strSql = "SELECT * FROM TableXYZ WHERE CatID = "+CatID ; 
      ds = DataProvider.Connect_Select(strSql); 
      DataTable dt = ds.Tables[0]; 
      return dt; 
     } 
     catch (Exception ex) 
     { 
      throw; 
     } 
    }

過濾我的輸入或查詢字符串，然後我打電話getDetails功能，並通過CatID作爲參數傳遞給函數&然後SQL語句。由於這是一個整型數據，這個代碼容易受到SQL注入的影響嗎？

我想澄清我的疑問，以便我不使用像這樣的SQL語句。

來源

2013-11-25 Learning

這並不容易注入，但你應該更容易查詢計劃緩存的好處，反正使用參數 –

我將永遠是關於附加來自用戶的內容直接到SQL非常謹慎，除非你過濾。它很重（例如在這種情況下，你可以做一個Int.TryParse（Cat ID）首先要確保它只是一個數字，這可以幫助你避免崩潰）。即便如此，爲什麼還要過濾它，並且只需使用SqlParameters就不用擔心？ – Tobberoth

@ ta.speot.is：「普通SQL字符串」可以緩存查詢計劃。 @Tobberoth：爲什麼要使用'Int.Parse（CatID）'？ CatID已經（保證是！）'int'（見方法簽名）。 – RobIII

當然，直接格式化查詢字符串並不是一個好習慣。 SqlParameter 類是適合你的目的而設計的 - 簡化查詢構建，防止SQL注入完全

來源

2013-11-25 08:55:13

由於CATID是int，不，在這種情況下你不容易受到SQL注入。但是你選擇的路徑是一個滑坡，並且有朝一日，在重構或改變你的代碼時很容易發生SQL注入。最好養成使用參數化查詢並堅持使用它的習慣。

我可以wholehartedly建議你嘗試Dapper（其可作爲NuGet包（;這將大大簡化事情，你不會有改變那麼多它的好處

你的代碼就成爲財產以後。像：

myConnection.Query<Customer>("SELECT * FROM TableXYZ WHERE CatID = @catid", new { catid = CatID });

來源

2013-11-25 08:57:45 RobIII

我更喜歡存儲過程更好的執行計劃...我只是想知道是否上面的例子易受sql注入考慮輸入被過濾爲'int CatID = Request [「CatID」];'我感謝你的建議，我會看看'Dapper' – Learning

但是你可能仍然可以傳遞類似'42 OR 1 = 1'的東西，然後基本上從TableXYZ中取回所有行......將SQL連接在一起總是**一個壞主意！ –

@marc_s：我假設你正在回答KnowledgeSeeker，因爲使用'Dapper'，如果這就是你所指的，這將會爲你處理（例如正確參數化）。此外，在原始問題中，CatID的類型爲int，因此您無法通過42或1 = 1，但KnowledgeSeeker似乎在遊戲開始後會改變遊戲規則，並且他的回覆超出了您的回答（雖然CatID仍然是'int'類型，但是，只要他不使用'var'或'string'，他就會安全），並確保（例如，當使用'var'時）參數是解析爲int。 – RobIII

使用int參數的SQL注入漏洞使用int參數

回答

相關問題