I often have to construct long and difficult queries "in code". I know, that I can pass any parameters using SqlDataAdapter.SelectCommand.Parameters.Add() method. But what should I do if i need in some cases make multiple concatenations like this:
var subquery = ConstructSubquery(param1, paramN);
query += subquery;
And so on. Code analyzer in VS offers me to use parameters instead of simple string concatenation, but something like
dataBaseSQL.SqlDataAdapter.SelectCommand.Parameters.Add("#subquery", SqlDbType.VarChar).Value = subquery;
//subquery = "WHERE param1 IN ('A', 'Z') AND param2 <> param3" (for example...)
does not work, of course! Queries are dynamic, subqueries are generated by special functions.
What is the best decision?
Parameters are for values, not for statements (or pieces of statements).
A and Z are values that can be put in a parameter (let's say #value1 and #value2) (and we will ignore the complexity of doing the IN operator using a variable number of parameters... there is an hard limit on the number of parameters in SQL Server, 2100). So for example WHERE param1 IN (#value1, #value2) is perfectly ok...
You can't put the whole WHERE param1 IN (#value1, #value2) in a parameter.
You shouldn't/mustn't let the user write SQL statements or piece of SQL statements (so no SELECT or WHERE written by the user), it is very highly insecure, and I don't think it can really be secured.
Even letting the user fill the name of columns to be selected can be insecure. Always ask yourself: what happens if the user writes, as the column name, for example?
-- DROP TABLE SomeTable --
And even letting the user select the column names from a "closed list" could be insecure, because 9 times out of 10 you won't check if the user manipulated the javascript of the page to write whatever he wants in the combobox/listbox (it is quite easy... press F12 on Chrome and the whole javascript of the page is in your hands).
Related
I need to filter a sql request by passing a list of id to , this is the command:
var command = "select Software.Name as SoftwareName,SoftwareType.Name as SoftwareType from AssetManagement.Asset as Software inner join AssetManagement.AssetType as SoftwareType on (SoftwareType.Id = Software.TypeId) where Software.Id in (#P)";
cmd.Parameters.AddWithValue("#P", authorizedSoftwaresId);
authorizedSoftwaresId is a list of string , containing data like :
"7D23968B-9005-47A9-9C37-0573629EECF9,F1982165-3F6D-4F35-A6AB-05FA116BA279"
with that it returns to me just one row, I tried adding quotes foreach value but i got "converstion from string caractere to uniqueidentifier failed " exception
This is a pretty common problem and the answer might depend on your database engine and whether you're using ADO.Net, Dapper, etc.
I'll give you some hints from my own experience with this problem on both MS Sql Server and PostgreSQL.
A lot of people think AddWithValue is a devil. You might consider Add instead.
The IN (#P) in your SQL statement might be the source of your problem. Try the Any option instead. See Difference between IN and ANY operators in SQL ; I've had success with this change in similar situations.
If all of your inputs are GUIDs, you might consider changing the type to a collection of GUIDs, although I don't think this is the fix, you have to try everything when you're stuck.
If you have to, you can parse the string version of your collection and add the ticks (') around each value. This choice has consequences, like it may prevent you from using a parameter (#P), and instead construct the final SQL statement you desire (i.e., manually construct the entire WHERE clause through string manipulations and lose the parameter.)
Good luck.
Trying to Insert into database from textboxes, but it will only accept integers and not characters - what could the problem be?
string sCMD = string.Format("INSERT INTO [Table] ([Item], [Des1],[Des2], [Prodline], [ANR], [STime]) VALUES({0},{1},'0',{2},{3},{4})"
,txtText1.Text, txtText2.Text, txText3.Text, txtText4.Text, txtText5.Text);
The name "" is not permitted in this context. Valid expressions are constants, constant expressions, and (in some contexts) variables. Column names are not permitted.
Here's something to consider:
using (SqlConnection c = new SqlConnection(connString))
{
c.Open();
using (SqlCommand cmd = new SqlCommand("INSERT INTO [Table] ([Item], [Des1],[Des2], [Prodline], [ANR], [STime]) VALUES(#Item,#Des1,'0',#ProdLine,#ANR,#STime)", c))
{
cmd.Parameters.AddWithValue("#Item", txtText1.Text);
cmd.Parameters.AddWithValue("#Des1", txtText2.Text);
cmd.Parameters.AddWithValue("#ProdLine", txText3.Text);
cmd.Parameters.AddWithValue("#ANR", txtText4.Text);
cmd.Parameters.AddWithValue("#STime", txtText5.Text);
cmd.ExecuteNonQuery();
}
}
If you were to send the SQL statement you're building to the server it might look something like this:
INSERT INTO [Table] ([Item], [Des1],[Des2], [Prodline], [ANR], [STime])
VALUES(Item Name,Here is my description.,'0',Prod line,ANR value,some time)
Clearly that's going to fail. It's not even surrounding the values with single quotes. Now, all of them may not be character, I get that, but you get my point.
But to add insult to injury it's wide open to SQL Injection the way you have it written. With the parameterized approach it's not.
This is a very dangerous line of code.
For starters, you are creating a string with no delimiters whatsoever for the values, which means that the only values that could pass withour issue are integers. Anything else needs to be delimited, which you don't do in this String.Format statement.
Worse, you are trying to create a sql statement from direct user input. Any weird value can cause your code to fail, or worse, cause execution of unwanted code. Imagine what would happen in a user entered eg 'sdf','sdfs',sdf' as the FIRST value. The resulting string would have 3 correct values for the first three columns that came from the first textboxt.
Now image what would happen if the user entered something like 'blablabla';DROP TABLE sometable;--. This would cause the Delete command to execute. This is a standard SQL injection attack scenario.
There are many more problems, eg when you try to pass numbers with floats, dates or any type whose conversion to string depends on your locale.
Instead of trying to construct a SQL query by string concatenation, you should use parameterized queries, as described in Give me parameterized SQL or give me death. The resulting code is easier to write, performs much faster, has no conversion errors and is not subject to SQL injection attacks,
Currently I simply don't allow apostrophe's at all (along with other character's as you can see) with this, reiterated for each field:
foreach(char c in Comments)
{
if(c=='\'' || c=='$' || c=='\"' || c=='&' || c=='%' || c=='#' || c=='-' || c=='<' || c=='>')
{
errorMessage = "You have entered at least one invalid character in the \"Comments\" field. Invalid characters are: [\'], [\"], [&], [$], [#], [-], [<], [>], and [%]";
}
}
I've been coding this for a while, and I am getting better, but the real problem is that, while I am sure there is a way to effectively "strip-out" or otherwise validate the user input, I am not sure which approach is best and probably wouldn't until a security crisis was imminent.
If I have to, I will settle on simply never allowing single quotes into the form at all (as it is now), however this may aggravate anyone named say... Bill O'Reilly for the name field, etc., etc.
There are probably other (well I don't know what to call them, 'plug-ins?' 'outside programs?') that would do the job for me, but that is virtually useless since not only do I have no idea how to integrate that, I would have no idea how to tailor it specifically to my web interface/database.
Is there any code that could help me detect a sql injection apostrophe (by the characters surrounding it maybe?) from a normal apostrophe? Keep in mind some of my fields can hold up to 500 characters (textareas) and one up to 1,000.
Thanks for any ideas or help!
No amount of input encoding/cleanup will be as safe as parametrized queries.
See SqlCommand.Parameters for details on parametrized queries.
string commandText = "SELECT * FROM Sales WHERE CustomerID = #ID;";
using (SqlConnection connection = new SqlConnection(connectionString))
{
SqlCommand command = new SqlCommand(commandText, connection);
command.Parameters.Add("#ID", SqlDbType.Int);
command.Parameters["#ID"].Value = customerID;
var reader = command.ExecuteReader();
//.....
}
SQL Injections is not a problem with the input containing specific characters, it's a problem with how you handle the input.
By disallowing certain characters you can stop the obvious ways to cause SQL injections, but it's virtually impossible to use that to stop all possible ways.
If encoded correctly, there are no character that causes problems. The best way of doing that for database calls is to use parameterised queries, so that the database driver takes care of encoding the correct characters according to the data type and the specific database.
Also, you need to encode the values correctly when you use them later on, like HTML encoding strings that are put in HTML code, URL encoding strings that are used in an URL (and both for strings that are put in an URL in the HTML code.)
You should use parameterised queries to prevent SQL Injection as other people have already said.
Alexei Levenkov provides a good example of using ADO.NET parameters, but more commonly, you will use the Database Helper when working with WebMatrix Razor pages (ASP.NET Web Pages Framework) where parameter handling is slightly different. The Database.Query method (Query(string commandText, params object[] parameters) takes a string representing the SQL to be executed, and an array of objects, representing the parameter values to be passed to the SQL. The Database helper expects parameter markers to start at #0, and increment by 1 each time e.g.
var sql = "SELECT * From MyTable WHERE TheDate > #0 AND ID > #1";
Then you pass actual values in the following manner:
var data = Database.Open("MyDb").Query(sql, Request["date"], Request["id"]);
Internally, the Database class takes care of matching values to placeholders and creating ADO.NET parameters for you.
So throughout my program I have probably 50 or so text boxes in various places. I know how to replace a single quote with something (in this case ' -> \'), but I am thinking there must be a better way to do this than go through and add specific code for every single text box. I have to do this because when this stuff is getting sent to the database, if there is a single quote, it gives an error. Is there a way to change the default TextBox control behavior so that all textboxes in the program automatically replace all single quotes with \'?
EDIT:
string statement = "select count(*) from users where username='#username'";
MySqlCommand command = new MySqlCommand(statement, conn);
command.Parameters.AddWithValue("#username", username);
if (Convert.ToInt32(command.ExecuteScalar()) == 1)
I have been playing with the paramerterized code and this is what I have right now. From how I understand it, the statement string is basically the same as before, but where I used to have the variable "username" I know use a parameter (which I called #username), then the command is created. Then in the parameters.addwithvalue, it replaces the parameter username, with whatever is in the variable username. Unfortunately, this is not working for me, and I don't really see how it helps because username is still just getting stuck in the command?
EDIT: Found the problem, in the statement you don't need to put single quotes around '#username'
so it should be:
string statement = "select count(*) from users where username=#username";
Don't use concatenation to build SQL queries. Use proper parametrized queries. This will make repeated queries a bit faster and will also eliminate input sanitizing code (replacing ' with \' for example) and SQL injection attacks.
You should be using parameterized queries, not only to resolve the problem you have, but also to reduce your exposure to SQL injection. When you use string concatenation to build SQL queries you are suseptable to SQL injection attackes.
U can use onKeyUp javascript function or asp.net OnTextChanged event to create function that will change quotes.
My program generates a list at runtime of values. I need to send a sql query that looks in a table for entries that have a column that contain one of the values in the list. I can't use the usual chain of OR's because I don't know how big the list will be. Is there a nice way to use an array or some IEnumerable to build a SQL statement that makes a big chain of OR's for me? Using C# BTW
I'm using SQL Server but I'd prefer something that works across all databases if such a thing exists.
Thanks!
Read up Erland Sommarskog's excellent Arrays and Lists in SQL Server article - he explains in great detail and with great insights what can be done in which version of SQL Server.
I also believe this is going to be database-specific, I don't see any approaches that would be ANSI SQL compliant or work on other databases, too - string and XML handling is just too specific for each database, I guess.
Try this:
SELECT * FROM table WHERE column IN (#param)
And make sure you turn #param into the form "'#p1, #p2, #p3'" by using your chosen language's implode function.
The query should be standard for all SQLs I know.
Alternatively if you want to do a LIKE comparison:
SELECT * FROM table WHERE #param LIKE '%' (COALLESCE) column (COALLESCE) '%'
#param is still a quoted string, but you need to use a different COALLESCE operator depending on your database (SQL Server: '+', MySQL: '.', Oracle: '|').
Example PHP implode code:
$ps = array('1', 'test', '323');
$param = implode(',', $ps);
Example C# "implode" code:
string[] ps = new string[] { "test", "blah", "boo" };
string param = string.Join(",", ps));
One thing you can try is table-valued parameters in stored procedures in MS-SQL:
http://www.sqlteam.com/article/sql-server-2008-table-valued-parameters
Not only is that unmessy since all you're going to do is add rows to your table-valued parameter for each value in your list, but it also executes quickly compared to the alternatives since the SQL DBMS can reuse its execution plan every time you run the query given that the number of arguments never changes.