Re: a stored procedure ..with integer as the parameter

On 24 Oct 2005 22:00:55 +0200, Harald Fuchs <hf0923x(at)protecting(dot)net> wrote:
>
> In article <33c6269f0510241144s680be862pfdc0c59dcba06eee(at)mail(dot)gmail(dot)com>,
> Alex Turner <armtuk(at)gmail(dot)com> writes:
>
> > 1. ( ) text/plain (*) text/html
> > As sort of a side discussion - I have postulated that quoting all
> incomming
> > numbers as string would be an effective defense against SQL Injection
> style
> > attacks, as magic quotes would destory any end-quote type syntax:
> > in_value=1
> > select * from table where my_id='$in_value';
> > as an example for PHP - Postgres will silenty perform an atoi on the
> string to
> > make it a number, but it would prevent:
> > in_value=1; delete * from user;
> > select * from table where my_id=$in_value
> > Am I just smoking crack here, or does this approach have some merit?
>
> The former :-)
> The correct defense against SQL injection is proper escaping, not quoting.
> How about $in_value = '1''; delete from user'?

This would be escaped by magic_quotes resulting in:
select * from table where my_id='\'1\'\'; delete from user \'', which would
result in an error, and a failed attack would it not, which would be a good
thing?

I tried to create this scenario, but in a trasactional environment, it
executes, but blew the transation so the data never committed as the select
query generated an error with the insert on the end because the return type
was no longer a result set, but a status in PyGresql:

AttributeError: 'long' object has no attribute 'ntuples'

So maybe there isn't an easy way to create a SQL injection attack in a
xactional environment that will actualy work?

Alex

---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>