July 23, 2017 at 1:16 pm
Hi all,
I've a question regarding potential vulnerabilities in my application, with respect to SQL Injection.
Most of my database queries operate loosely as such (non-relevant parts stripped out):
SqlCommand objCommand = new SqlCommand();
SqlDataAdapter objAdapter = new SqlDataAdapter();
ArrayList paramsArray = new ArrayList
{
new SqlParameter("@Param1", param1),
new SqlParameter("@Param2", param2),
new SqlParameter("@Param3", param3)
};
foreach (SqlParameter Parameter in paramsArray )
{
objCommand.Parameters.Add(Parameter);
}
objAdapter.Fill(objDataSet);
My questions are as follows:
1) In the above example, param1, param2, etc... are supplied from inputs on the webform. Some of these inputs may include textboxes where the user could, theoretically, put any text they want. Those parameters may map into SQL variables that are VARCHAR(MAX) fields. Hypothetically, if the user put in SQL-Injection-esque text ("Name; SELECT * FROM sys.tables"), am I exposed to any risk? My database is set up such that the user executing these procedures has access only to executing procedures; as such, would the permissions prevent them from being able to do anything of real danger?
2) In the above example, if the parameters "@Param1", etc ... are dynamically created in my application (example, instead of "@Param1", it would be "@" + param1 + "ID" ), am I any more at-risk? Again I assume that with the permissions there wouldn't be any real danger.
3) If the parameter were actually provided in the HTML code via a field that had display: none, would that increase the risk? Now in this case they know the actual parameters of my procedure, but can they do anything of significance with that information?
July 23, 2017 at 2:10 pm
It's got nothing to do with permissions. Permissions are good, but they're not there to prevent SQL injection.
Your code is not vulnerable to SQL injection because you're parameterising the database calls. User input is not anywhere been treated as executable commands, it's treated as data.
What's a risk is code like this (bad C#, I don't write it often):
SQLCommand.CommandType = CommandType.Text;
SQLCommand.Command = "EXEC MyProcedure @Param1 = " + txtUserInput.txt;
SQLCommand.Execute; -- whatever method
In that, the user input is made part of the command that the DB will execute, hence injection is a possibility. In parameterised code, the parameters are data, not executable code.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 23, 2017 at 2:20 pm
GilaMonster - Sunday, July 23, 2017 2:10 PMIt's got nothing to do with permissions. Permissions are good, but they're not there to prevent SQL injection.Your code is not vulnerable to SQL injection because you're parameterising the database calls. User input is not anywhere been treated as executable commands, it's treated as data.
What's a risk is code like this (bad C#, I don't write it often):SQLCommand.CommandType = CommandType.Text;
SQLCommand.Command = "EXEC MyProcedure @Param1 = " + txtUserInput.txt;
SQLCommand.Execute; -- whatever methodIn that, the user input is made part of the command that the DB will execute, hence injection is a possibility. In parameterised code, the parameters are data, not executable code.
Awesome. Thanks Gila, just wanted to make sure I wasn't about to create a monster I'd later regret.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply