August 13, 2001 at 3:55 am
Is it possible to disable the semicolon (;) separator (i.e. disable the use of multiple SQL statements)?
August 13, 2001 at 5:03 am
Not directly. You could parse them out in your app I guess, but that will only work for that app, not all of them. Or use a COM piece to pass on the SQL statements after checking for multiple ones. Tricky because you have to make sure the semi colon is not part of the statement, just the delimiter.
Why do you want to disable it?
Andy
August 13, 2001 at 6:46 am
Thanks for your input. It confirmed my ideas.
I am using VBScript that gets a parameter called "ID" and then uses the parameter to build an SQL statement in a string. The string would be something like:
sql = "SELECT * FROM tbl WHERE id=" & ID
I realised that a malicious user could add a semicolon and - for example - a drop table statement after it. I was thinking if it was possible multiple statements that can result in a case like this.
As you said, input validation seems the best path to choose. I would be able to catch it out before any damage is done.
Cheers!
December 8, 2002 at 4:12 pm
This is the old 'SQL Injection' bug. You can avoid the possibility by doing a CLng(ID) in your VB code. Anything that is not numeric will fail the CLng() conversion.
I would also strongly consider using a stored proc and passing ID as a parameter. SPs over lots of advantages of dynamically generated SQL.
December 8, 2002 at 4:20 pm
This is the old 'SQL Injection' bug. You can avoid the possibility by doing a CLng(ID) in your VB code. Anything that is not numeric will fail the CLng() conversion.
I would also strongly consider using a stored proc and passing ID as a parameter. SPs over lots of advantages of dynamically generated SQL.
December 8, 2002 at 4:21 pm
This is the old 'SQL Injection' bug. You can avoid the possibility by doing a CLng(ID) in your VB code. Anything that is not numeric will fail the CLng() conversion.
I would also strongly consider using a stored proc and passing ID as a parameter. SPs over lots of advantages of dynamically generated SQL.
December 8, 2002 at 4:29 pm
This is the old 'SQL Injection' bug. You can avoid the possibility by doing a CLng(ID) in your VB code. Anything that is not numeric will fail the CLng() conversion.
I would also strongly consider using a stored proc and passing ID as a parameter. SPs over lots of advantages of dynamically generated SQL.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply