This is a contrived example but: system( "touch file " $date ); where $date contained "01/01/2002|some nasty command" might cause trouble?
Yes, so don't do that. Do:
system "touch", "file", $date;
like every Perl security guide says.
And this just keeps illustrating the point. Yes, you can shoot yourself in the foot with Perl. But no amount of "generic data filtering" will help, because the most reasonable solution is user education and using the proper tools when you are performing potentially dangerous actions.
What you are asking for is the equivalent of "bullets that don't sink in to human flesh, but can still kill the bear coming at you". Ain't gonna happen. No. You send
the shooter to a safety class, where they learn never
to point the business end at anything they don't intend
to kill.
Every one of your stated problems is a gap in education.
Look, you learned how to type "p-r-i-n-t" somehow. If you learned just enough to be dangerous, then you
are getting the outcome you deserve. If companies are funding only enough to be dangerous (as in not doing
proper code review and security review), then they get an
appropriate outcome.
No amount of "filtering the data" will do anything more than just placating the idiots who don't place security
in the same ballpark as correctness and on-time delivery.
There are numerous security FAQs. There is a wealth
of knowledge about good programming techniques and
having a healthy distrust of data. It's not like any
of this is any secret kept locked up in a dark tower.
And when you can't
afford to do the research, you must afford to rent that skill instead, by bringing in specialists for verification. It's as important as getting it working in the first place.
Security is not something that can be "bolted on". It
has to be designed in. Hiring someone that doesn't
get that, is like hiring a Perl programmer who hasn't
discovered hashes yet. It's just plain ludicrous.
-- Randal L. Schwartz, Perl hacker | 