Mike and all
I'm glad I tough exactly what you are saying in web
app security courses I've gave since some time ago.
IMO use of PreparedStatents-like solutions are not
only Sql-Injection proof but often provide better
performance.
I found (in my courses) use of on-the-fly query
building plus single quote escaping was a common
practice in attendants and some developers are not
willing to change already written code. So I was
looking for a proof of concept to encourage "positive"
validation rather than content filtering in
applications developed in past.
This was a failed one, but those are the most
illustrative trips. :)
Thank you all for your comments, talk to you in next
topic.
-JC
--- "Scovetta, Michael V" <Michael.Scovetta@ca.com>
escribió:
Juan et al,
The SQL injection thread seems to crop up every 6
months or so. From the last one, I think that most
people agreed that parameterizing the sql was the
best and most general choice (via something like
Java's PreparedStatement object)-- if you have a
good structure like that, then you don't have to
worry about injection. If not (and if you don't want
to build one), you need to check data-types on all
non-quoted datatypes, and escape quotes on all the
quoted ones. Then you have to make sure that you
account for all of the other encoding styles that
the underlying DBMS will handle, and deal with
those. Finally, use the principal of least privilege
so that the process that usually checks usernames
doesn't have authorization to drop tables, etc.
I've been waiting for someone to announce
cross-language (standard) API that mimic's
PreparedStatement. If anyone's looking for something
to do, it'd be a great help to the community...
Regards,
Michael Scovetta
Computer Associates
Senior Application Developer
-----Original Message-----
From: Juan Carlos [mailto:johnccr@yahoo.com]
Sent: Thursday, December 16, 2004 10:49 AM
To: Michael Howard; Adam Tuliper;
webappsec@securityfocus.com
Subject: RE: SQL injection (no single quotes used)
hum...
not sure about this, from a web application
perspective, all data is handled as plain text, I
mean, even if I encode the information in the URL
(for
example) my java web application (for example),
always
will get an ' character after calling getParamer.
How
can en encoded character "touch" the Web Application
Software? Does the DB manager does decoding as
well?.
Cheers
-JC
--- Michael Howard <mikehow@microsoft.com>
escribió:
From my experience, escaping is often never
enough,
because there a number of attacks that don't use
quotes (etc)
I'm not saying escaping quotes is bad, it's just
not
good enough on its own.
[Writing Secure Code]
http://www.microsoft.com/mspress/books/5957.asp
[Protect Your PC] http://www.microsoft.com/protect
[Blog] http://blogs.msdn.com/michael_howard
[On-line Security Training]
http://mste/training/offerings.asp?TrainingID=53074
-----Original Message-----
From: Adam Tuliper [mailto:amt@gecko-software.com]
Sent: Tuesday, December 14, 2004 11:30 AM
To: Juan Carlos Calderon;
webappsec@securityfocus.com
Subject: Re: SQL injection (no single quotes used)
Michael Howard (and David LeBlanc) has a nice
section in
"writing secure code" about encoding characters.
In
some
cases using char(0x27) as well as using entire
words
encoded via 0xXXXXXXXXXX can be used. Watching for
"'" is
not enough.
I think Michael is on this list.. any words
Michael?
On Thu, 9 Dec 2004 09:53:03 -0600 (CST)
Juan Carlos Calderon <johnccr@yahoo.com> wrote:
Hi all
While in Oracle escaping apostrophe (')
character
seems to be enough protection for Sql Injection
(I
think is not), this is not true for Sql Server.
Here a
little example I think many of you will find
useful.
For an on-the-fly query like:
Query = "select field1, field2... from table
where
id
= '" + FixSQL (FieldValue) + "'"
Where FixSQL will escape single quotes AKA
apostrophe,
the following value for "FieldValue" will be
effective:
FieldValue = "(NewLine)GO(NewLine)Desired Sql
Sentence(NewLine)GO"
Final result is:
select field1, field2... from table where id = '
GO
Desired Sql Sentence
GO
'
Here the MS Documentation for GO Keyword:
<snip>
SQL Server utilities interpret GO as a signal
that
they should send the current batch of
Transact-SQL
statements to SQL Server. The current batch of
statements is composed of all statements entered
since
the last GO, or since the start of the ad hoc
session
or script if this is the first GO
</snip>
So one sentence become three, sentences one and
three
will fail, but sentence two (the one of our
interest)
will execute successfully.
Hope you find this interesting
Cheers,
-JC
_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina,
en
Yahoo!
Noticias.
Visítanos en http://noticias.espanol.yahoo.com
---------------------------------------------------------------------
Web mail provided by NuNet, Inc. The Premier
National provider.
http://www.nni.com/
_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en
Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com
_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com
