It could be ANY page where you access your database without filtering input data for injection attempts. Instead of spending time looking for a specific page, lock down EVERYTHING now!

Is there any way to find out the page through which the values were inserted into the database

Any page that does this:

<input type="text" name="test">

....

echo "$_POST['test']"; // or $_GET, or $_REQUEST, whatever

Means your data is passing through unfiltered and vulnerable.

Another, substitute "test" for any valid form field in your scripts, and "scriptname" for any script.

http://www.example.com/scriptname.php?test=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22

If you get an alert "123" your scripts are also vulnerable to cross site scripting. Either can be a cause.

Anything that accepts input . . . needs to be examined.

Every user input is a potential hack. - Selena Sol

you might try checking your server access logs.
if the injection arrived through a GET request you should be able to see that pattern in the log.

Disallowed = "[]+=)(*&^%$#@!¦?><{}:;~`'\/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" & chr(34) & vbCrLf & vbTab

Private Function RemChr(byVal string, byVal remove)
Dim i, j, tmp, strOutput
strOutput = ""
for j = 1 to len(string)
tmp = Mid(string, j, 1)
for i = 1 to len(remove)
tmp = replace( tmp, Mid(remove, i, 1), "")
if len(tmp) = 0 then exit for
next
strOutput = strOutput & tmp
next
RemChr = strOutput
End Function

[edited by: dukelips at 10:06 am (utc) on Jan. 1, 2010]

Is this code enough to avoid sql injection

Please help

I think there is some confusion after you posted that script snippet. It looks like Visual Basic to me. Can you give some more information about the system you are running on, script language and version, SQL brand and version etc? It will make it easier to give directions to find the source of your SQL injection problem.

You should test input variables for what you expect, for example if the input should be a email address you check to see if it's valid email address instead of trying to block every exploit under the sun.

We are using ASP 3/ VB Script / SQL Server 2000 / Windows 2003 Enterprise

The function to filter the input is run on the server side

The problem with filtering input is there's always the possibility of an attack you haven't considered slipping through.

The best approach is to always use parameterised queries instead of dynamic SQL strings.

You should also validate all user input e.g. if your code requires an integer as input, check an integer is passed not a string; if it's not what you expect display error and abort or set to a default value.

ASP Example: SQL Stored Procedure with an Integer parameter:

Set cmd = Server.CreateObject("ADODB.Command")
With cmd
.ActiveConnection = cnn
.CommandText = "MyStoredProcedure"
.CommandType = adCmdStoredProc
.Parameters.Append cmd.CreateParameter("MyID", adInteger, adParamInput, 0, MyID)
End With
Set rs = cmd.Execute()

ASP Example: Parameterised SQL String with a varchar(50) parameter (question marks are used as placeholders for parameters):

sql = "SELECT * FROM MyTable WHERE MyField = ?;"
Set cmd = Server.CreateObject("ADODB.Command")
With cmd
.ActiveConnection = cnn
.CommandText = sql
.CommandType = adCmdText
.Parameters.Append cmd.CreateParameter("MyValue", adVarChar, adParamInput, 50, MyValue)
End With
Set rs = cmd.Execute()

More info: [owasp.org...]