We Keep Coding

How to pass schema name in a parameterized query

I need to add the schema value dynamically to the query. I was trying to construct it the way we usually use values but realised it does not work with the schema names the same way.
This was what I was trying to do
sql = "SELECT Name FROM [#dbo].[Members]";
...
command.Parameters.Add("#dbo", SqlDbType.VarChar).Value = "dbo";
I know I can construct the query by directly adding the variable in the query like this:
sql = $#"SELECT Name FROM [{parameter}].[Members]";
But I wanted to disallow any kind of SQL Injection so want to go ahead using the parameterized query as above.
Can anyone help with a possible idea to implement this?
TIA

The schema is not a parameter. Query parameters are equivalent to function parameters in eg C#. They're used to pass values. In SQL, the table and columns are equivalent to C# types and properties. You can't specify them by name. The schema in a SQL query is similar to the Namespace in C#. The table is equivalent to a Type. In C#, just because Sales.Record and Diagnostics.Record have the same type name doesn't mean the two types can be used the same way.
The question doesn't explain why the schema name is passed dynamically. It's almost certain there are easier, more efficient and safer ways to query similar tables in multiple schemas, but the solution would depend on the actual problem.
There are some techniques that can be used to make such a dynamic query safe if not efficient. I'd really, really try to avoid treating the schema as a value though.
Using QUOTENAME
One option, is to use QUOTENAME in a T-SQL script to construct a dynamic query. At least this way a syntax error will be thrown if the schema and table names are wrong:
sql = #"declare #sql nvarchar(max)='SELECT Name FROM ' + QUOTENAME(#dbo) + '.[Members]';
select #sql;
exec sp_executesql #sql;";
...
command.Parameters.Add("#dbo", SqlDbType.NVarChar,100).Value = "dbo";
QUOTENAME will convert something like sys].schemas; PRINT ''x''; -- to [[sys]].schemas; PRINT 'x'; --]. This will result in an error :
declare #sql nvarchar(max)= 'select * from [' +quotename('sys].schemas; PRINT ''x''; --')
select #sql
exec sp_executesql #sql;
--------
select * from [[sys]].schemas; PRINT 'x'; --]
Invalid object name '[sys].schemas; PRINT 'x'; --'.
It's too easy to make quoting mistakes with such scripts. This could be extracted into a stored procedure :
CREATE PROCEDURE GetMemberNameBySchema
#dbo nvarchar(100)
as
declare #sql nvarchar(max)='SELECT Name FROM ' + QUOTENAME(#dbo) + '.[Members]';
exec sp_executesql #sql;
Verify the Schema name
Query sys.schema to ensue the schema is correct before constructing the query. Let's say you're using Dapper (so I don't have to write all the ADO.NET code) :
var schema="dbo";
var isValid=connection.ExecuteScalar<bool?>(
"select 1 from sys.schema where name=#name",
new {name=schema});
//isValid will be null if nothing is found
if(isValid ==true)
{
var names=connection.Query($"SELECT Name FROM [{schema}].[Members]");
...
}
This is safe to do because the first query ensured the schema name is valid.

You can only pass parameters to dynamic query not object names as far as I know. You can do something like below:
Update after seeing Panagiotis' solution. we can take out the exists part outside. I am no expert in C# but something similar we want to do:
DECLARE #Table NVARCHAR(100);
DECLARE #Schema NVARCHAR(50);
SET #Schema = 'dbo'; --This part will come from C#
SET #Table = 'Tablename'; --This part will come from C#
DECLARE #sql NVARCHAR(MAX);
IF EXISTS(SELECT * FROM sys.tables WHERE name = #Table and schema_id = SCHEMA_ID(#Schema))
BEGIN
SET #sql = N'SELECT TOP 1 * FROM '+ QUOTENAME(#Schema) + '.' + QUOTENAME(#Table) +';';
PRINT #sql;
EXEC sp_executesql #sql;
END
ELSE
RAISERROR('Table or Schema doesn''t exist.',16,1);
In the IF EXISTS you need to pass the table name and schema name as parameter to dynamic query.
In the actual query you need to make a concatenation of table name and schema name.
This will prevent sql injection as well and if the table is not there then raise an error.

Preventing SQL injection when using dynamic SQL

I've got a stored procedure that returns data for a grid control. Given a table name, the grid will display data from that table. The user can sort and filter this data. There is also paging logic for large data sets.
The names of the tables that data is pulled from is not known until runtime, so dynamic SQL was used. This works well, but is vulnerable to SQL injection - the tableName, sortExpression and filterExpression variables are generated clientside and passed through to the server.
Below is a simplified version of the procedure:
create procedure ReadTable (
#tableName as varchar(128),
#sortExpression as varchar(128),
#filterExpression as varchar(512)
)
as
begin
declare #SQLString as nvarchar(max) =
'select * from ' + #tableName +
' where ' + #filterExpression +
' order by ' + #sortExpression
exec Sp_executesql #SQLString
end
I'm struggling to find a way to easily prevent SQL injection in this case. I've found a good answer explaining how to check the #tableName is legitamite (How should I pass a table name into a stored proc?), but the approach won't work for the filtering or sort strings.
One way would be perhaps to do some sanitizing server side before the data is passed through to the database - breaking the expressions down into column names and checking them against the known column names of the table.
Would there be an easier way?

Getting data from stored procedure with Entity Framework

I am trying to get the content a table with a dynamic SQL stored procedure called from the database context object (using Entity Framework 6.1.1), in order to populate a GridView control. I fail to retrieve the data.
Here's the stored procedure. It is for a student demonstration about SQL injection in stored procedures, so I KNOW this is inject-able and it's fine.
ALTER PROCEDURE dbo.SearchProducts
#SearchTerm VARCHAR(max)
AS
BEGIN
DECLARE #query VARCHAR(max)
SET #query = 'SELECT * FROM dbo.Products WHERE Name LIKE ''%' + #SearchTerm + '%'''
EXEC(#query)
END
The C# code behind I then use to execute the stored procedure is :
var db = new MyEntities();
var TEST_SEARCH_TERM = "product";
var result = db.SearchProducts(TEST_SEARCH_TERM);
MyGridView.DataSource = result;
MyGridView.DataBind();
When executed, in the Database Explorer in Visual Studio, the stored procedure works fine. But when executed in the running ASP.NET app, I get an exception in the DataBind() method because result returns -1 instead of an IEnumerable DataSet containing the objects resulting from the stored procedure's SELECT.
How can I retrieve the data and populate my GridView?

Use the following steps to solve this issue:
You need to Import the stored procedure as a Function. Right-click on the workspace area of your Entity model and choose Add -> Function Import.
In the Add Function Import dialog, enter the name you want your stored procedure to be referred to in your model for example Search_Products, choose your procedure from the drop down list, and choose the return value of the procedure to be Entities and choose Products from the drop down list.
Then in the code behind:
var db = new MyEntities();
var TEST_SEARCH_TERM = "product";
var result = db.Search_Products(TEST_SEARCH_TERM);//Search_Products is the name that you specified in Function Import dialog
MyGridView.DataSource = result;
MyGridView.DataBind();
The reason that you get -1 for result is that Entity Framework cannot support Stored Procedure Return values out of the box. I think support of stored procedure return values depends on version of Entity framework. Also Entity Framework doesn't have rich stored procedure support because its an ORM, not a SQL replacement.

I have come across this before with stored procedures using dynamic SQL. I have had success using complex types if I add the line 'SET FMTONLY OFF;' (see https://msdn.microsoft.com/en-us/library/ms173839.aspx) to the top of my stored procedure before it is added to the EF model. Once you have your model setup with your complex type, be sure to remove this line.
Example:
ALTER PROCEDURE dbo.SearchProducts
#SearchTerm VARCHAR(max)
AS
BEGIN
SET FMTONLY OFF;
DECLARE #query VARCHAR(max)
SET #query = 'SELECT * FROM dbo.Products WHERE Name LIKE ''%' + #SearchTerm + '%'''
EXEC(#query)
END

Verify that your EDMX has a return type:
Go to Function Imports --> SearchProducts, and double click it.
In order to utilize a Complex return type, Entity Framework will require that you explicitly define column names in your stored procedure instead of using *.
Once your stored procedure is modified to define the column names, you can update your model in the project. (Note, performing a complete drop of the SP, and then adding it back to your edmx may be the best route.)
EDIT
Maybe you can modify your SP like the following:
ALTER PROCEDURE dbo.SearchProducts
#SearchTerm VARCHAR(max)
AS
BEGIN
SELECT * FROM dbo.Products WHERE Name LIKE '%' + #SearchTerm + '%'
END

You seem to have sorted your problem out, there is official documentation from Microsoft available at the links below:
How to import a stored procedure into your entity data model:
https://msdn.microsoft.com/en-us/library/vstudio/bb896231(v=vs.100).aspx
Complex types in the EF designer:
https://msdn.microsoft.com/en-gb/data/jj680147.aspx
Make sure you are working with the latest version of .net and you keep your model up to date when you make changes to your database.

Is this susceptible to an injection attack

Is the following c# snippet susceptible to a SQL Injection Attack?
string sql = #"
declare #sql navarchar(200)
set #sql = 'select * from customers where customerId = ' + convert(navarchar, #custId)
exec sp_sqlexec #sql
"
oSQL.Parameters.Add("custId", CustomerId);
DataTable dt = oSQL.ExecuteDataTable(sql);
I understand this is a trivial sql statement but I'm more interested in the approach of using exec sp_sqlexec. The sql statement is more dynamic than the one stated but don't think it's important for my question.

A slightly more secure solution would be to make the dynaimc query parameterized as well:
(Note that you should be using sp_executesql as well:
string sql = #"
declare #sql navarchar(200)
set #sql = 'select * from customers where customerId = #customerId'
exec sp_sqlexecuseSQL #sql, N'#customerId INT`, #customerId = #custId
"
oSQL.Parameters.Add("custId", CustomerId);
DataTable dt = oSQL.ExecuteDataTable(sql);

Updating answer based on comments from SO. Dynamic SQL (or really any SQL statement, this is a good rule to follow) in general usually is open to SQL Injection if their is a potential for user input. If all your parameters that make the SQL statment say come from another database or say a dropdown, etc then No it is not succeptible to SQL Injection.
The general rule to remember: Don't ever allow unvalidated data to get into a SQL statement. Everything should be validated and add them to the database as a parameter.

Pass operator to stored procedure

I have an ASP.NET MVC 3 app that lets users to create their own filters. Something like amount > 5 and amount <= 7, and so on. The user can choose both the amount value and the operator.
My problem is how to pass those filters to the stored procedure that retrieves the data. The stored procedure is already pretty complicated, meaning there are a lot of parameters passed which are checked to be null, so I can't really apply the answer I found here: T-SQL Stored Procedure - Dynamic AND/OR Operator
Is there any other way I can do this?

Operators cannot be parameterized. Since you mention this is a stored procedure, the only option is to write the T-SQL inside the SP, and use sp_executesql, i.e.
//TODO : verify (whitelist) that #operator is in a known set of values...
// '=', '<>', '>', '<' etc - otherwise security risk
declare #sql varchar(4000) = 'select * from Foo where Bar '
+ #operator + ' #value'
exec sp_executesql #sql, N'#value int', #value
This builds the query (#sql) on the fly, but keeps the value (#value) parameterized throughout, so we only need to white-list the operator (#operator).
Just to show how the value remains parameterized, we could also have used:
//TODO : verify (whitelist) that #operator is in a known set of values...
// '=', '<>', '>', '<' etc - otherwise security risk
declare #sql varchar(4000) = 'select * from Foo where Bar '
+ #operator + ' #p'
exec sp_executesql #sql, N'#p int', #value
Here, #p is the name of the parameter in the inner sql, and #value is the name of the parameter in the stored procedure; the third/fourth/fifth/etc parameters to sp_executesql are mapped to the parameters declared in the second parameter to sp_executesql (which in this example, declared just #p).
Note that if this wasn't a stored procedure, you could perform the query-construction step in C#, again keeping the value as a parameter.

I think the only way is to use dynamic sql, e.g., sq_executesql. This allows you to create your SQL statement as a string, and then execute it. But it will probably mean a lot of rewriting of your existing stored procedure!