I get the impression the coder assumed checking HTTP_REFERER made the email address, et. al, safe, since they must have come from the right form.
Learning to string together working Perl is one thing. In fact, it's pretty easy. Learning the ins and outs of HTTP and how to prevent easy exploitation is another thing.
| [reply] |
Learning the ins and outs of HTTP and how to prevent easy exploitation is another thing.
dragonchild asked how many security holes can you find?. He then goes on to mention bugs -- not using strict/warnings/tainting are all bugs/security holes.
| [reply] |
Not running taint checks is clearly a security flaw. On the other hand, I can't really entertain the idea that not running with strictures and warnings is a bug.
Turning off warnings in CGI scripts can stop your logs blowing out. I agree that a warning should be acted upon at the earliest opportunity and I ensure that all my programs are warning-free, but a warning is just that, a warning. On the other hand running out of space on your logging device is catastrophic. You have to make a tradeoff between paranoia and pragmatism.
And remember that strict.pm guards against three things: symbolic references, bareword "poetry" subs and undeclared variables. I think most people just 'use strict' to help them make sure they always use lexical variables. People rarely use package variables these days and even less people use symbolic references (by accident or otherwise).
So while I always use strict in my programs, I do not consider a program that doesn't as being inferior. Doing so is not a bug.
| [reply] |
While NOT using Taint in a CGI script is a potential security hole, not using Warnings and Strictures is neither a security hole nor a bug.
Warnings and Strictures should only be used during development. They don't really serve a useful purpose in production code. If you're relying on them to catch errors in live CGI scripts then it could have disastrous effects *. CGI scripts are a special entity and knowing that if the worse can happen it will, coding for those kind of eventualities, so that scripts report and handle errors safely, can save a lot of grief. In fact leaving use warnings and use strict uncommented in a CGI script can be an unnecessary drain on your webserver.
Tainting doesn't necessarily require you to have -T at the top of your script. However, it does mean you should code assuming anything coming from the outside world is harmful.
* I have been witness to several sites exposing their DB access username/password once a fatal error occurs.
--
Barbie | Birmingham Perl Mongers | http://birmingham.pm.org/
| [reply]
[d/l]
[select] |