Re: DBI Parameter Security

When you use DB placeholders you're protected from that kind of sillyness. All that will happen with your example query is that it will look for rows where the bar col contains ; DROP TABLE big_important_one. Its only when quoting by hand in a query that you have to worry about that kind of attack. DB calls using placeholders are one of the few places that you can generally trust that maliciously malformed user data won't be able to cause harm.

Note: if your DB does not support placeholders, and the DBD simulates them for you; you could still get into trouble if its not done properly. However, I don't know of any DBD that does this...

Comment on Re: DBI Parameter Security

Replies are listed 'Best First'.
Re: Re: DBI Parameter Security by pileswasp (Monk) on Jul 13, 2001 at 21:29 UTC
Thanks for the reply. That's what I expected for that particular example, but - excusing the naiive example above as only a 'for instance' - does anyone know of a way that, without extra checking on the part of the developer, such a statement could be passed into the d/b.	[reply]
Re: Re: Re: DBI Parameter Security by lhoward (Vicar) on Jul 13, 2001 at 21:31 UTC
As long as you're using placeholders (and the DBI layer doesn't shortcut them), tehre is no way that data will leak through as commands to the database. Turning on DBI tracing you can see exactly what is happening `<- prepare('select * from foo where bar=?' CODE)= DBI::st=HASH(0x81a25 +74) at testph.pl line 11. <- execute('plugh' CODE)= 1 at testph.pl line 12.` [download] You can from the trace see how the commands are passed to the database seprately from the data (using mySQL in this example). The DB is smart enough to not treat data as executable sql code.	[reply] [d/l]


laziness, impatience, and hubris
	PerlMonks