On Mar 28, 12:52 pm, "Leandro Pinto Fava" wrote:
> In the past (1999-2000?) we suffered an attack of SQL Injection on one
> of our web application. The app was made using Ingres-ICE and the
> database was Ingres II (I dont need tell you that we dont use Ingres
> ICE anymore, grrrr).
>
> The attack was "half" well succeeded. We discovered immediatally when
> the system started report to us about an infinity of lock timeout
> messages raised in errlog. The attacker get some info from our
> database, but not so much in special.
>
> Well, we needed to stop that app ASAP until a new one was developed or
> an workaround were made. The new app should be developed using another
> tool/technology, because the way we made that app with Ingres-ICE
> (using Report Writer to generate pages) didnt had a good solution in a
> few time.
>
> So, before the new app were developed, we could make an workaround (in
> a few hours after the occurrence) using some "non conventional"
> methods. Something like a "man-in-the-midle" solution to detect such
> attacks and prevent them.
It would be interesting to learn more specifics about the attack, and
the application in question. The more we share about these things the
better we can protect our data/applications.
Every SQL injection attack I've seen has *always* boiled down to code
like this:
sprintf(sql_str, "SELECT ...... %s .....", a, b, c....);
execute_sql(sql_str);
or
sql_str = "SELECT ......'" +a+"' %s ....."
etc.
There are usually 1 or 2 reasons for code like this:
1) inexperience with SQL injections attacks and protecting against
them. These days there are a number of articles on the subject (this
was not the case in 2000, I'm not sure I saw an article before 2000)
but I still see a lot of new SQL/database users who have not had
formal training taking this approach. Generating SQL queries is
attractive and easy to understand.
2) Lack of support for bind parameters. Clearly this is NOT an issue
for Ingres, all Ingres drivers use real bind parameters if the
application requests them. For some DBMS vendors they added bind
parameter support later in life and/or the underlying driver ended up
doing the "sprintf" like above even if the application did "the right
thing".
If you use bind parameters with Ingres you will not suffer from an SQL
injection causing unexpected query results, for example an INSERT
ending up doing a drop table, obligatory
http://xkcd.com/327/
reference
Bind parameters prevent the injection of SQL queries into the expected
SQL.
I.e. if you have user input for queries my recommendation is always
use bind parameters, Python example:
instead of:
# bad!
sql_query = "SELECT email_addr from my_table where user_id = '%s'"
% user_id
c.execute(sql_query)
do:
# better
sql_query = "SELECT email_addr from my_table where user_id = ?"
bind_params = (user_id, )
c.execute(sql_query, bind_params)
As well as avoiding injection, this tends to perform better. Ingres
will cache queries with bind param markers. It is also easier to write
code using bind parameters.
If an application has a genuine need to create SQL queries on the fly,
it is still possible (and recommended) to use bind parameters when
dealing with user input.
There is a lot more to application/DBMS security than just using bind
parameters but it is the first thing to do. User input should always
be sanitized, the nice thing about using bind parameters is that
Ingres does the SQL query text protection piece for you.
Chris
>> Stay informed about: Why inject when it already sucks? :-) 
FAQ
Search
Profile
Private Messages
Log in
