Can anyone supply me with ONE SINGLE example of how anyone could use
SQL injection in a dynamic SQL statement when the system is programmed
to remove : "single quotes", "semi-colon", and "double dashes" in all
input parameters passed to the SQL syntax?
I can't seem to find one example of SQL injection that does not
require the use of these SQL delimiters...
Thanks for any response.
wrote on 06 mei 2006 in microsoft.public.inetserver.asp.db:
> Can anyone supply me with ONE SINGLE example of how anyone could use
> SQL injection in a dynamic SQL statement when the system is programmed
> to remove : "single quotes", "semi-colon", and "double dashes" in all
> input parameters passed to the SQL syntax?
That would be telling! ;-)
> I can't seem to find one example of SQL injection that does not
> require the use of these SQL delimiters...
Perhaps in this moronic piece of code?
==================
sql = "Delete from myTbl Where " & delimClean(request.form("what"))
........
> Can anyone supply me with ONE SINGLE example of how anyone could use
> SQL injection in a dynamic SQL statement when the system is programmed
> to remove : "single quotes", "semi-colon", and "double dashes" in all
> input parameters passed to the SQL syntax?
>
> I can't seem to find one example of SQL injection that does not
> require the use of these SQL delimiters...
>
> Thanks for any response.
It's draconian to just remove these characters from text based inputs.
After all Mr O'Reily would get pretty annoyed if you kept sending
correspondance to Mr OReily. There a valid uses of ; and -- in text fields
also.
You can replace one ' with two which eliminates an attempt to close a string
literal prematurely. In this case ; and -- can also pass. For other field
types more stringent validation ought to be in place anyway. For example
placing CLng around a value destined for a field of Int type.
However, there is a second level to SQL Injection problems. This would be
where a stored procedure builds SQL from field values then uses the EXEC
command to execute the SQL.
In this case it possible for SQL code to get passed the input phase and just
end up as text in record field values. Then that code can become active
with concatenated by a stored procedure building SQL to EXEC.
SPs that build SQL should be avoided if possible but if unavoidable then
should be written defensively with the possibility that any concatenated
string value may contain malicious SQL. In fact the possibility that a
string field could contain a valid ' would mean that some precautions would
be necessary.
Anthony.
g--g@. wrote:
> Can anyone supply me with ONE SINGLE example of how anyone could use
> SQL injection in a dynamic SQL statement when the system is programmed
> to remove : "single quotes", "semi-colon", and "double dashes" in all
> input parameters passed to the SQL syntax?
>
> I can't seem to find one example of SQL injection that does not
> require the use of these SQL delimiters...
>
> Thanks for any response.
These articles describe a couple possibilities
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection. pdf
And even if you do manage to plug the holes described in these articles,
another technique is sure to arise.
You will wind up spending a good deal all your time attempting to massage
your data in order to allow it to be safely inserted into your database,
time that would be better used for other tasks. The best defense against sql
injection is:
1 Validate user input before attempting to use it, _rejecting_ any
potentially malicious requests instead of trying to modify them in an
attempt to allow them to be _safely_ entered into your database. After all,
why would you want to allow crappy data containing injection attempts to be
entered into your database? And why would you want to have to deal with the
errors raised when injection attempts cause errors such as data mismatches,
etc? Remember, raising errors is expensive in terms of cpu and resources.
2 Never show users the real error messages returned by your database
provider or the vbscript engine. Instead, log the errors and return a
generic, less informative messge such as: "Sorry, a problem was encountered
that I hadn't planned for. Either check your inputs and try again or, if the
problem persists, contact our help desk at ... "
a. Optionally, security experts Duane Laflotte and Patrick Hynds
recommend "punishing" blatant injection attempts. For example, if your
validation procedure finds sql keywords in what was supposed to be numeric
input, this is a blatant injection attempt that, in their words ... well,
you can read them for yourself:
http://www.patrickhynds.com/default.aspx?date=2005-09-07
3 Use parameters instead of concatenation, just in case your validation
procedure misses anything
4 Avoid using dynamic sql in stored procedures, but if it cannot be avoided,
see Erland Sommarskog's excellent articles about dynamic sql and dynamic
search conditions that can be found here: http://www.sommarskog.se/
HTH,
Bob Barrows
--
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"
Anthony Jones wrote on 06 mei 2006 in
microsoft.public.inetserver.asp.db:
> You can replace one ' with two which eliminates an attempt to close a
> string literal prematurely.
In names of persons and locations,
changing the ' [apostrofe] to a ` [grave accent] and back is a nice
alternative for me instead of the above doubling, also preventing a change
in char-count.
Any nonrejecting validation should consider an "unvalidation" upon reading
_from_ the db.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)