in reply to Re: Re (tilly) 2: Opinions needed on CGI security
in thread Opinions needed on CGI security

Along merlyn's lines, an easy way to ensure that the user remains within your bounds is to imagine what Apache does when one specifies Order deny, allow If the input doesn't meet your guidelines, reject the whole thing on sight of the first mistake. Yes, simply return to the user "no dice". It's simply not worth trying to make replacements which need to be concurrently checked. In the example above, if one wants to reject certain data, then reject the whole shebang if any "evil hacker stuff" is included. That means, first clearly define which tags ARE acceptable. If ANYTHING else is used, reject the entire input asking for user clarification. That's not exactly what this site does, but PM does restrict tags along these lines.

The other way is just too hazy. From CGI pod (I've always found this entertaining):

If you import a function name that is not part of CGI.pm, the module will treat it as a new HTML tag and generate the appropriate subroutine. You can then use it like any other HTML tag. This is to provide for the rapidly-evolving HTML "standard." For example, say Microsoft comes out with a new tag called <GRADIENT> (which causes the user's desktop to be flooded with a rotating gradient fill until his machine reboots). You don't need to wait for a new version of CGI.pm to start using it immediately:

use CGI qw/:standard :html3 gradient/; print gradient({-start=>'red',-end=>'blue'});
If you only filter script tags, then you're missing this DoS HTML tag. On the other hand, if you know which tags are good and ignore all others, you're set for life without trying to track down new exploits.
AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.