Homegrown Pseudo-Tainting

[oubiwann]

Here's the scenario:

• You have to use CGI
• You have to make system calls with parameters passed from the url
• You can't use -T

(*chuckles* this is going to be fun)
What do you do now? My fellow Perlsuers of Wisdom, what would be some of your favorite ways of preventing piped,"&&ed","||ed",";ed", etc. commands?

[grep]

There is a module geared to exactly what you want CGI::Untaint.

But back to point of not being able run -T in production, I once was in a situation like this and a great workaround (me being paranoid) was to set up an enviroment where I could run taint to develop and test it there. This will eliminate to need of running -T in a production enviroment.

And how could I forget to promote Ovid's CGI::Safe module, for your other non-taint related cgi security concerns.



grep

grep> cd /pub grep> more beer

[MZSanford]

    I agree with dws,Juerd and grep, if you are writting code that is Taint-safe, then the <cod>-T</code> is just to keep you in check. I understand from your reply to dws that you are looking for things other monks have used when working with Tainted data, and i just wanted to say that i am a huge believer in the list versions of system() and exec(), and even feel a need to shamelessly promote this node about the diffrence.
    Other than that, if you know your data, you will know your un-taint-o-rator. If you are using things like $bad_data =~ m/^(.*)$/; $bad_data=$1, then you have missed what tainting is about. I shy away from catch-all un-tainting, but, if you are looking for common idioms, i only usually use things like \d+ and such, though, i don't do much CGI, so i don't have the largest frame of reference :/.

just my €0.02

---

from the frivolous to the serious

[dws]

• You can't use -T ... What do you do now?

You do the same thing you would do it you could use -T. You scrub incoming data before using it for anything potentially risky.

[oubiwann]

Right, that's what I'm talking about - what are your favorite regex's or other methods for protecting your shell from user input? (sorry, I should have been more explicit)

[dws]

what are your favorite regex's or other methods for protecting your shell from user input?

Test for exactly what I expect, and reject anything else. The test depends on the data.

[Juerd]

What do you do now? My fellow Perlsuers of Wisdom, what would be some of your favorite ways of preventing piped,"&&ed","||ed",";ed", etc. commands?

It all depends on how it's going to be used. If it's going to be a part of something that will be evaluated by a shell, take every precaution you can (although quotemeta often is enough). When using system calls, use the list forms of system, exec and IPC::Open2::open2 and IPC::Open3::open3.

Custom tainting can be done using Taint, but I have yet to find out how that works myself.

U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

[ChOas]

Just to add to all the posters above, who focus more on
untainting the data, perldoc perlsec gives this example
to beforehand check if the data is actually tainted:


sub is_tainted {
 return ! eval {
  join('',@_), kill 0;
  1;
 };
}


GreetZ!,

ChOas

print "profeth still\n" if /bird|devil/;

[gellyfish]

Except that will only do what you want when you have used the '-T' switch. And as the person who asked the question said they can't use '-T' ..

/J\

[oubiwann]

This is great input, guys! I hope this has been/will be as useful to others as it is to me :-)

I might just have to go back and look at some old projects that executed remote shell commands in a "trusted" CGI environment...

Thanks again ;-)