> So instead of some PHP script generating query like
> "select * from table where text='some text' or id=1",
> some malicious user could make it generate "select *
> from table where text='some text' or id=1;delete from
> table"
You're approaching this from wrong direction. Neither client part, nor
interface should be prohibited to run multiple queries in a single call.
As to your example, first of all, you can't disclose your tables and let
anyone to enter raw SQL statements and sleep tight. UI must be only allowed
to take parameters, and build the queries on its own, or pass the params
for further processing to another level.
Again, if `some malicious user could make [some PHP script]' generate a
dangerous query, the problem is with the script. Read the params, wipe out
all control octets, including URLencoded ones, escape all potentially
dangerous chars, like ' " and ; Enclose query params for non-numeric fields
in ' restrict params' content to known good values whereever possible. All
the job must be done by UI or underlying level. DB i/f must receive
perfectly valid queries.
On the other hand, DB interface can _never_ rely upon the fact that it
will always receive valid params. Additional checks must be performed,
because bypassing restrictions applied on visitor's side is as easy as
telnetting to port 80. Bypassing CGI restrictions is not as easy, but still
very possible.
Last not least. This is not a recipe, let alone a panacea. Always watch
your back and never trust the trust.
G'luck
Ed
--
Well I tried to be meek
And I have tried to be mild
But I spat like a woman
And I sulked like a child
I have lived behind the walls
That have made me alone
Striven for peace
Which I never have known
Dire Straits, Brothers In Arms, The Man's Too Strong (Knopfler)
