Like forbidding anything which looks like an env-function.

That's what my regex does in a generic way, ie erasing magic values starting with () { .

You are free to combine it with further defense measures.°

But I doubt you can efficiently realize an individual validation for each string format (like PATH, HOST, IP, USERNAME, ...)

°) something like (untested)

 local %ENV = map { $_ => kill_func $ENV{$_} } @whitelist

ww posted an article that comes to similar conclusions to yours. I'm definitely more inclined toward a whitelist than a blacklist, but I'd much prefer a hard-coded environment for my child process. The original intent of my query was really intended to find out why a scorched earth approach might be problematic. In the kind of code I end up running in these types of situations, there's no reason to not take the draconian approach (PDF generation, numerics, ...). I also try to avoid single-argument system and exec, but that's mostly because I don't trust my escaping talents.

In any case, I'll be using your regex for any values I have to pass through, and I appreciate your thoughts on the matter.

---

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

> ww posted an article that comes to similar conclusions to yours.

CAUTION! DON'T

While the explanation in the article is good, the regex is not.

While I disable ALL function definitions to avoid any eval, this one tries to disable only those containing injected code after the functions body.

In other words it tries to parse the function, but similar to "only Perl can parse Perl" this is doomed to fail.

I've already seen shellshock exploits where the injected code was somewhere within the body. ¹

If you wanna play save disable all unknown function definitions like I did and allow only some where you have full control!

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

¹) parsing complexity is the reason why there are so many patching attempts to fix this