Re: SQL injection, php and queueing multiple statement

On Sat, Apr 12, 2008 at 11:06:42PM +0200, Ivan Sergio Borgonovo wrote:
> But what about already written code that use pg_query?

If you rewrite the database interface then it doesn't matter, the calls
to pg_query will end up being calls to prepare/execute underneath so
you'll have their protection. If you mean that you're calling compiled
code that is already statically linked to a library that calls pg_query
then you may get some mileage out of modifying some proxying software
(which you'll probably be using anyway if you're doing any web based
stuff) to rewrite all the calls rather than doing it between PHP and the
driver. Anyway I'm not sure if this'll help you much, you have to put
trust in your code somewhere. It's just a question of where.

> Is it that terrible or nonsensical to hope to have a switch that will
> enable/disable multiple statements for each call to pg_query?

I agree that it will close some, probably small, attack vectors, but
that in general it's not going to help much. I can't help but think
that you're trying to solve what's formally known as the "Halting
Problem" (or originally the Entscheidungsproblem) which was shown to be
impossible in the 30s.

Even if you did close this hole, what's to stop the attacker from
exploiting another bug in your code and causing your code to misbehave
in some other way. About the only tool known by software engineering
that will solve this problem is that of formally methodology. You have
to sit down and spend a long time modelling your problem, then you
have to prove (formally, i.e. in some logic system) that your model is
correct, then you write the code based on the model, then you prove that
your code is true to the model. This is a *lot* of work and is only
done for very high assurance stuff at the moment, aeroplane control
software being one place it's used.

If you want an easier way of getting close to a good solution then you
want tools that will check that the code you've written is correct as
early as possible. I personally think, and there's a lot of research
saying the same thing, that statically-typed and safe languages with
formally defined semantics are good tools here. PHP is a tool for
writing code quickly, not for writing high assurance code.

Sam