|
Re: Homegrown Pseudo-Tainting
by grep (Monsignor) on Mar 15, 2002 at 07:58 UTC
|
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 |
| [reply] |
Re: Homegrown Pseudo-Tainting
by MZSanford (Curate) on Mar 15, 2002 at 09:33 UTC
|
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 | [reply]
[d/l]
[select] |
Re: Homegrown Pseudo-Tainting
by dws (Chancellor) on Mar 15, 2002 at 06:55 UTC
|
• 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.
| [reply] |
|
|
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)
| [reply] |
|
|
| [reply] |
Re: Homegrown Pseudo-Tainting
by Juerd (Abbot) on Mar 15, 2002 at 07:35 UTC
|
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
| [reply] |
Re: Homegrown Pseudo-Tainting
by ChOas (Curate) on Mar 15, 2002 at 09:36 UTC
|
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!,
print "profeth still\n" if /bird|devil/; | [reply]
[d/l] |
|
|
| [reply] |
Re: Homegrown Pseudo-Tainting
by oubiwann (Sexton) on Mar 15, 2002 at 15:30 UTC
|
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 ;-) | [reply] |
