Re: Yet another reason to use DBI placeholders

I agree with everything you've just said.

I also believe in the due diligence required of coders to know where their data came from and where it's going. Too often I get the impression that programmers are taught that if they simply use place holders, then they've practiced safe data and they have nothing to worry about. Next thing you know, your application is performing evals on strings pulled from databases.

Place holders are an important part of the process, but by themselves they only protect your databases, not your application.

Comment on Re: Yet another reason to use DBI placeholders

Replies are listed 'Best First'.

Re^2: Yet another reason to use DBI placeholders
by mr_mischief (Monsignor) on Dec 13, 2008 at 04:11 UTC

Performing evals on strings pulled from a database isn't necessarily bad, so long as you're the one who populated the database. It's a good thing to mention, though. Using eval() on user-supplied data or data pulled from another source you don't control enables all kinds of attacks. Even writing user-supplied data out for another user, like the Perlmonks site does, can cause at least three widely publicized types of security flaws for the client end that have no need of SQL injection to work. That's why there's so much effort to limit the HTML and CSS that is accepted in nodes here, and why so many legitimate sites are in the news lately for attacking web user's computers through browsers.

Placeholders require such a small effort for such big strides in the security process, though, that they definitely should be part of that process whenever databases are involved.

[reply]


Perl: the Markov chain saw
	PerlMonks