Making strings safe for SQL?

I'm writing some general SQL functions to save time later and one of the
functions I'm looking for is something to make strings "SQL Friendly".
What I need to know is, what should I be watching out for?
At this point, I'm assuming that everthing is safe, once the following is
applied to a string:
Any " is changed to ""
Any ' is changed to `
...what else is there to worry about?Noozer wrote:
> I'm writing some general SQL functions to save time later and one of the
> functions I'm looking for is something to make strings "SQL Friendly".
> What I need to know is, what should I be watching out for?
> At this point, I'm assuming that everthing is safe, once the following is
> applied to a string:
> Any " is changed to ""
> Any ' is changed to `
> ...what else is there to worry about?
Can you explain a bit about what you are trying to do. Why do you need
a SQL function to do this? If you pass strings as parameters then all
this is taken care of for you. No special handling is required for
quote characters unless you are constructing dynamic SQL code.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||>> What I need to know is, what should I be watching out for?
> Can you explain a bit about what you are trying to do. Why do you need
> a SQL function to do this? If you pass strings as parameters then all
> this is taken care of for you. No special handling is required for
> quote characters unless you are constructing dynamic SQL code.
Ya.. I guess I should have been a bit more specific.
: )
I'm writing some ASP code that builds SQL commands and queries dynamically.
...and now, thinking about this, I really should build functions to ensure
that numbers are really numbers, etc...|||> I'm writing some ASP code that builds SQL commands and queries
> dynamically.
> ...and now, thinking about this, I really should build functions to ensure
> that numbers are really numbers, etc...
The Best Practice for security is to build parameteritized SQL statements:
Hope this helps.
Dan Guzman
SQL Server MVP
"Noozer" <dont.spam@.me.here> wrote in message
news:%23%23ROjAgZGHA.3848@.TK2MSFTNGP05.phx.gbl...
>
> Ya.. I guess I should have been a bit more specific.
> : )
> I'm writing some ASP code that builds SQL commands and queries
> dynamically.
> ...and now, thinking about this, I really should build functions to ensure
> that numbers are really numbers, etc...
>|||Noozer (dont.spam@.me.here) writes:
is
>
> Ya.. I guess I should have been a bit more specific.
>: )
> I'm writing some ASP code that builds SQL commands and queries
> dynamically.
> ...and now, thinking about this, I really should build functions to ensure
> that numbers are really numbers, etc...
You are barking up the wrong tree entirely. As Dan says, you should
use parameterised strings and never interpolate values into the
SQL. This is easier, safer, and far more performant. (Because the plan
for parameterised query is cached, and can be reused for other
parameter values.)
Here is one sample of a parameterised query using ADO and VB6:
Set cmd = CreateObject("ADODB.Command")
Set cmd.ActiveConnection = cnn
cmd.CommandType = adCmdText
cmd.CommandText = " SELECT OrderID, OrderDate, CustomerID, ShipName " & _
" FROM dbo.Orders WHERE 1 = 1 "
If custid <> "" Then
cmd.CommandText = cmd.CommandText & " AND CustomerID LIKE ? "
cmd.Parameters.Append
cmd.CreateParameter("@.custid", adWChar, adParamInput, 5, custid)
End If
If shipname <> "" Then
cmd.CommandText = cmd.CommandText & " AND ShipName LIKE ? "
cmd.Parameters.Append _
cmd.CreateParameter("@.shipname", adVarWChar, adParamInput, 40,
shipname)
End If
Set rs = cmd.Execute
And here is one for VB .Net and SqlClient:
cmd.CommandType = System.Data.CommandType.Text
cmd.CommandText = " SELECT O.OrderID, SUM(OD.UnitPrice * OD.Quantity)" & _
" FROM dbo.Orders O " & _
" JOIN dbo.[Order Details] OD ON O.OrderID = OD.OrderID" & _
" WHERE O.OrderDate BETWEEN @.from AND @.to" & _
" AND EXISTS (SELECT *" & _
" FROM dbo.[Order Details] OD2" & _
" WHERE O.OrderID = OD2.OrderID" & _
" AND OD.ProductID = @.prodid)" & _
" GROUP BY O.OrderID"
cmd.Parameters.Add("@.from", SqlDbType.Datetime)
cmd.Parameters("@.from").Value = "1998-02-01"
cmd.Parameters.Add("@.to", SqlDbType.Datetime)
cmd.Parameters("@.to").Value = "1998-02-28"
cmd.Parameters.Add("@.prodid", SqlDbType.Int)
cmd.Parameters("@.prodid").Value = 76
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Best bet is to research SQL Injection techniques and change your approach.
There are so many ways for a hacker to get into the system if you use
concatenation...
Some basic info (which you seem somewhat familiar with judging by your
question):
http://www.sqlservercentral.com/col...ectionpart1.asp
http://www.sqlservercentral.com/col...qlinjection.asp
Some advanced dangers:
http://www.nextgenss.com/papers/adv...l_injection.pdf
http://www.nextgenss.com/papers/mor...l_injection.pdf
Parameters are really the way to go.
"Noozer" <dont.spam@.me.here> wrote in message
news:uP9m4ffZGHA.1192@.TK2MSFTNGP03.phx.gbl...
> I'm writing some general SQL functions to save time later and one of the
> functions I'm looking for is something to make strings "SQL Friendly".
> What I need to know is, what should I be watching out for?
> At this point, I'm assuming that everthing is safe, once the following is
> applied to a string:
> Any " is changed to ""
> Any ' is changed to `
> ...what else is there to worry about?
>sql