I watched the video some time ago and what bothers me is that the author pretends to have hacked Perl while in fact he just found that some people are using a commonly used Perl module (DBI) the wrong way whereas the right way is well documented. A similar thing would be to blame PHP for allowing SQL injections through unescaped user input: I am sure it happens a lot, but who would blame PHP.
Until recently, blaming PHP was the popular approach. :)
Well, every time I meet someone and they say they use PHP for their living my inter monologue is "Don't be a jerk and don't bash PHP, its a fine choice." I usually have to make sure I don't talk with them long and move along. I am a jerk either way.
Shrugs, it pays the bills and has improved radically since 4 and even 5.
It wouldn't be my first choice but there is plenty of reasonable paying work around.
Actually, he breaks examples from the manual. I think his point was that programmers inherently write exploitable Perl code as they assume certain types are secure.
The types point is actually meh. The real hilarious part is the combination of the ARGV <> "feature" and the open("...|") "feature". What. The. Fuck.
Yeah, and I discovered C is horrible because buffer overflows.
Is it really Perl best practice to assume all non-scalar data types are trusted?
Definitely not. At $work, we use Params::Validate as a standard way to normalise and validate the incoming parameters.