Re: (Ovid) Re(4): CGI OO 'param' vs. hash

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.

Comment on Re: (Ovid) Re(4): CGI OO 'param' vs. hash

Replies are listed 'Best First'.
(tye)Re: CGI OO 'param' vs. hash by tye (Sage) on Jul 10, 2001 at 01:34 UTC
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]

Replies are listed 'Best First'.

(tye)Re: CGI OO 'param' vs. hash
by tye (Sage) on Jul 10, 2001 at 01:34 UTC

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

[reply]
[d/l]
[select]