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

Making SQL 2005 Developer accept the connection string for SQL express edition

Hi, I have installed on my laptop SQL server 2005 Developer edition, I can change ANY of the settings of the SQL server and OS.

I am writing code with a team using continuous integration where the connection string is the following:
"Provider=SQLNCLI;Server=.\SQLEXPRESS;Database=Secret;Trusted_Connection=Yes;"

is there a way (create an alias,rename server, other?) to make my local dev SQL server accept the connection string above, as at the moment I have to rename the connection string every time before checking in code and after downloading the latest version from the code repository.

any advice or tips will be greatly appreciated

Thanks

JW.Hi,

setup an alias using the SQL Server Configuration manager. Configure a new alias to listen to .\sqlexpress and redirect to the installed dev server.

HTH; Jens K. Suessmeyer.

http://www.sqlserver2005.de

Making managed code calls inside SQL Server in context of the client

Dear all,

I am very new to the subject of writing CLR code inside SQL Server, so I apologise if my questions seem naive.

I have a requirement to populate an asp.net 2.0 GridView control with data columns, some of which are directly from a SQL Server 2005 database, but some of which are calculated by calling CLR methods passing the values from the database columns to those methods.

However, the methods I need to call only make sense in the process context of the client web site which is calling the stored procedure which I want to write to return the data columns.

In effect, I want to be able to make a remote procedure call from within the SQL Server CLR code to the methods available in the client process.

Is this possible? If so, could someone please refer me to an example of how to do it.

If it can be done, it opens up lots of very cool possibilities!

Thanks.

It's a much cleaner design if you can explicitly pass the client context information to the server-side CLR code rather than RPC back to the client. While you can do anything you want if you register the assembly as unsafe, I don't recommend that approach. It's better for both security and performance reasons to keep server-side processing on the server itself as much as possible.

|||

Dear BonnieFe,

Thanks for your suggestion. It would be a much cleaner design, if it was possible. Unfortunately, the data I need back changes for every row in the returned data, since it is obtained by passing a value from a returned data column to a method which has to be called in the context of the calling process.

I have now solved the problem by calling a web service in the calling web site from the CLR code inside SQL Server 2005. This seems to work fine, although it is bound to be slower than it would be if it used RPC back through the SQL connection.