Re^2: Using Regexp Patterns as Variables

You just allowed arbitrary code to be placed in the url. Considering the code appears in a CGI script, that doesn't seem to be a good idea.

If you want a template (that's what '$1' is here), use a template, not eval EXPR!!!

Comment on Re^2: Using Regexp Patterns as Variables Download Code

Replies are listed 'Best First'.
Re^3: Using Regexp Patterns as Variables by Rodster001 (Pilgrim) on Mar 18, 2009 at 16:51 UTC
It's an admin function. I fully trust the source of where these rules are created. Regular users cannot do this and the function is well protected. Think of it like giving them root access. If root wants to do an "rm -rf /" that's the power of root. With great power comes great... well, you know.	[reply]
Re^4: Using Regexp Patterns as Variables by Anonymous Monk on Mar 18, 2009 at 17:49 UTC
Turn on taint `#!/usr/bin/perl -T--` just the same.	[reply] [d/l]
Re^3: Using Regexp Patterns as Variables by kyle (Abbot) on Mar 18, 2009 at 16:48 UTC
That's why I wrote this: I can't say I recommend that, however, especially if you don't trust the source of your real `$out`.	[reply] [d/l]
Re^4: Using Regexp Patterns as Variables by ikegami (Patriarch) on Mar 18, 2009 at 16:56 UTC
There's no "if". `$ENV{REQUEST_URI}` is controlled by remote users. Even ignoring the evident trust issues, `eval` is simply not the right tool.	[reply] [d/l] [select]
Re^5: Using Regexp Patterns as Variables by Rodster001 (Pilgrim) on Mar 18, 2009 at 17:06 UTC
Correct. However, since the regex patterns are stored in the DB, put there by trusted users, it is effectively the same as hard coding them (without having to). $ENV{REQUEST_URI} can be mucked with without any security issues (the replacement will just fail).	[reply]