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] |