As I recall, the original CGI::Vars function will separate values with an ASCII zero. By allowing ASCII zeroes into the data, you have two problems.
- Since we seperate data with an ASCII zero, what happens if we ever need to embed one? You'll not likely to run into one, but the one time you do...
- You run the risk of a security problem called "The Poison Null Byte". Go to this overview of CGI security and search for "Poison". That should take you right to a description of the problem.
Cheers,
Ovid
Vote for paco!
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
| [reply] |
Thanks. I've read your course before (very helpful, BTW), but I must have stopped remembering the poison null byte when I saw this line, "However, the real fix is to avoid letting user data near the shell."
This script will never, ever, let anyone pass a shell command (AFAIK; see next question). If this is the case, can I safely ignore said null byte, or should I strip it out just for fun? Also, see my reply above (directly below, the way this threading works) to tadman - I'm running with Taint on, and explicitly untainting every parameter I accept with a regex of "allowed" characters.
If I do decide to pass shell commands, is your 1-liner $data =~ s/\x00//g; sufficient to guard against this problem?
--
man with no legs, inc.
| [reply] |
No, you don't need a shell for nul bytes to be a security
problem. Lots of C APIs won't handle nul bytes. For
example:
open( X, "> test\0me.txt" )
will succeed and will create a file called simply "test".
And if you want to send something to a shell, you need
to decide what characters to allow, rather than what
characters to not allow. /(\w[-\w.]*)/ is
a good, generic starting point.
-
tye
(but my friends call me "Tye")
| [reply]
[d/l]
[select] |