RE: [Nms-cgi-devel] NMSView base code available...

[Wizard <wi...@ne...>]

> Yes, I think that's better.  /e is fine - it just makes the code on the
> right hand side of the replace act as code, the same as code elsewhere
> in your script.  You'd be right to be nervous of user input anywhere
> neat /ee though, because that's really a string eval.
That's fine. Consider it done.

> In that case, it might be better to have some sort of non-alpha
> delimiter, e.g.
>   '<a href="/new_path[% NMS_CFG_ITEM %]_wwwpost_url">Try the new list</a>'
I thought of that, but the problem I see is what universal delimeter won't
be munged by any of the HTML editors (I suspect that this is what most of
our users will use)? Anything not A-Z, a-z, _, !, ? or - may very well get
transformed. Also, anything like "<!-- -->" may be invisible on some
editors, confusing the user. Any suggestions are welcome.

> The scripts are all scripts, but not every module in CGI::NMS:: is
> associated with a particular script, e.g. CGI::NMS::Charset under /v2
> in the CVS tree.
Ok, that's valid. CGI::NMS::Script::Data* it is.

> You read the config filename from a CGI input, and call open() on it
> with no checking, so a 'cfg' value of "|`rm -rf /`" would cause the
> command 'rm -rf /' to run.
Yes, that's what I pointed out.

>   # check if 'cfg' is set via the URL query_string, if so use that.
>   my $cfg_input = $cgi_data->param('cfg');
>   if ( defined $cfg_input ) {
>     $cfg_input =~ /^([\w\-]{1,100})$/ or die "bad cfg value [$cfg_input]";
>     $def_cfg = "./conf/$1.cfg";
>   }
This isn't quite what I had planned but I understand what you are saying. I
had hoped not to limit config files to any specific directory. What I was
planning was to limit the path to specific characters ('.', '/', '\', ' ',
'-' and \w). Is this not enough?
There is also another option which I've used in past projects that specifies
a separate list of config locations, i.e., "cfg_1 = ./nms.cfg", where the
script is passed the index of the configuration file (&cfg=1). Is this a
safer or better way to go?

> Also, in the open in CGI::NMS::Config you should add a '<' to the front
> of the filename so that the open can't act as a piped open and run
> commands even if an attacker gets something past the checks.
Yup, I'll do that.