in reply to Security issue and solution for terminal command accessed by public user

Consider if someone enters this as the 'number': 1 foot' 'inches'; rm -rf /; echo '

You could sanitize the input by making sure the number is really a number -- only digits and decimal point, that kind of thing (though that's trickier than it sounds, if you want to allow commas/underscores in long numbers, scientific notation, etc.). You can make the user choose from a selection of unit types, and verify that they selected a valid one from a list (because it's trivial to circumvent browser restrictions on that kind of thing). It would also help to open a pipe to/from units (with no command-line arguments) and pass the values to it in interactive mode, where bad inputs shouldn't be as dangerous as they can be on the command line.

Or you can use one of the conversion modules suggested above. Of course, then you're counting on those modules to handle dangerous inputs properly, so you should probably still sanitize your data as much as possible.

Aaron B.
Available for small or large Perl jobs; see my home node.

Replies are listed 'Best First'.
Re^2: Security issue and solution for terminal command accessed by public user
by keenlearner (Acolyte) on Jul 07, 2012 at 05:08 UTC

    Hi,

    Thanks, that Pipe mode and interactive mode is a great answer. I think it solve most of the problem. The units does have the interactive mode.

      I would, if you decide to go that route, carefully comment why you're doing it that way, so someone doesn't later come along and decide it would be more "efficient" to change it to
      system "$unaltered_user_input";
      and open you up to the security issues again.

      I might also ask, will you really need every conversion that units can do? Or do you have a small set of conversions that can be encapsulated in a few dozen lines at the most? The investment in a bit of conversion code that is definitely safe, versus a security problem waiting to happen, is probably worth it.