Hi All,

Our website (developed by a 3rd party) was recently hit by an Sql

injection attack and I have been going through and hardening the

code. It uses asp and talks to a sql server 2000 backend for a bunch

of the page content.

I have been switching over to using parameterized queries by creating

Command Objects etc, and this has been straightforward for the most

part, but I have a piece of code that uses a recordset Update command

to take some form info and put it into the database. I am struggling

to find a solution for this.

The code is of the following form:

Set cConn = getDatabaseConn()

Set cRS = Server.CreateObject­("ADODB.RecordSet")

cRS.Open "PageContent",cConn­,2,2

cRS.AddNew

cRS("PageName") = request.form("itemN­ame")

cRS("Category") = request.form("categ­ory")

cRS("Content") = Request.Form("pageB­ody")

cRS.Update

cRS.Close

closeDatabaseConn(c­Conn)

If this was a Sql statement like "Update Table Set Field = ?, where

id =?", I would construct a parameterized query with a command object.

Is there a way of doing this with a recordset update command?

This parameterization should already be occurring behind the scenes. You

can confirm by using SQL Profiler to run a trace, but I'm pretty sure

that a recordset update will not be prone to sql injection.

Hi All,

Our website (developed by a 3rd party) was recently hit by an Sql

injection attack and I have been going through and hardening the code.

It uses asp and talks to a sql server 2000 backend for a bunch of the

page content.

I have been switching over to using parameterized queries by creating

Command Objects etc, and this has been straightforward for the most

part, but

I have a piece of code that uses a recordset Update command to take

some form info and put it into the database. I am struggling to find a

solution for this.

The code is of the following form:

Set cConn = getDatabaseConn()

Set cRS = Server.CreateObject­("ADODB.RecordSet")

cRS.Open "PageContent",cConn­,2,2 cRS.AddNew cRS("PageName") =

request.form("itemN­ame")

cRS("Category") = request.form("categ­ory")

cRS("Content") = Request.Form("pageB­ody")

cRS.Update cRS.Close closeDatabaseConn(c­Conn)

If this was a Sql statement like "Update Table Set Field = ?, where id

=?",

I would construct a parameterized query with a command object.

Is there a way of doing this with a recordset update command?

Thanks for any assistance.

Hi All,

Our website (developed by a 3rd party) was recently hit by an Sql

injection

attack and I have been going through and hardening the code. It uses asp

and

talks to a sql server 2000 backend for a bunch of the page content.

I have been switching over to using parameterized queries by creating

Command Objects etc, and this has been straightforward for the most part,

but

I have a piece of code that uses a recordset Update command to take some

form

info and put it into the database. I am struggling to find a solution for

this.

The code is of the following form:

Set cConn = getDatabaseConn()

Set cRS = Server.CreateObject­("ADODB.RecordSet")

cRS.Open "PageContent",cConn­,2,2

cRS.AddNew

cRS("PageName") = request.form("itemN­ame")

cRS("Category") = request.form("categ­ory")

cRS("Content") = Request.Form("pageB­ody")

cRS.Update

cRS.Close

closeDatabaseConn(c­Conn)

If this was a Sql statement like "Update Table Set Field = ?, where id

=?",

I would construct a parameterized query with a command object.

Is there a way of doing this with a recordset update command?

Thanks for any assistance.

As others have said, if you take a look with the SQL-Server Profiler,

you will see that ADO use parameterized queries to execute these

commands.

Practically, the only way that you can be hurt by SQL injection

attack is when you are dynamically building your one sql strings. For

alphanumeric string values - that are to be enclosed between

single quotes - all you have to do is to replace any enclosed single

quote with two single quotes by using the replace command. Very easy

to do. Of course, if you are using double quotes as the string

delimiter then these are those that you must double using the replace

command.

Sylvain Lafontaine wrote:

This is not enough. There are several documented techniques for hackers to

use to get around this simplistic strategy. SQL can be injected without a

single quote character involved. In fact, the recent worm attack that hit

so many websites in the last month used one of those techniques.

If parameters are possible, forget attempting to excape strings: use

parameters. If dynamic sql is necessary, validate data against a list of

acceptable entries, rather than attempting to outthink the bad guys.

--

Microsoft MVP - ASP/ASP.NET

Please reply to the newsgroup. This email account is my spam trap so I

don't check it very often. If you must reply off-line, then remove the

"NO SPAM"

Sylvain Lafontaine wrote:

This is not enough. There are several documented techniques for

hackers to use to get around this simplistic strategy. SQL can be

injected without a single quote character involved. In fact, the

recent worm attack that hit so many websites in the last month used

one of those techniques. If parameters are possible, forget attempting

to excape strings: use parameters. If dynamic sql is necessary,

validate data against a list of acceptable entries, rather than

attempting to outthink the bad guys.

As far as know, the recent work attack used a standard method for

injecting javascript into an HTML page via an IFrame and was easily

defeated with the simple use of the Server.HTMLEncode method()

Sylvain Lafontaine wrote:

No, that was the second stage of the two-stage attack; in the first stage

the bot used sql injection to declare and open a cursor to update every

"string" field in the database, appending its js payload to the current

contents:

http://blogs.techne­t.com/neilcar/archiv­e/2008/03/15/anatomy­-of-a-sql-injection-­incident-part-2-meat­.aspx

--

Microsoft MVP - ASP/ASP.NET

Please reply to the newsgroup. This email account is my spam trap so I

don't check it very often. If you must reply off-line, then remove the

"NO SPAM"

First, thanks for the info. Second, even in this case, the sql portion

of this attack would have been easily defeated by using the replace

method for the embedded single quotes.

--

Sylvain Lafontaine, ing.

MVP - Technologies Virtual-PC

E-mail: sylvain aei ca (fill the blanks, no spam please)

"Bob Barrows [MVP]" <reb01501@NOyahoo.S­PAMcom> wrote in message news:%23ArDT%23i8IH­A.4988@TK2MSFTNGP04.­phx.gbl...