I've been told my scipts would be insecure, and to fix that.
Figured i might rethink some parts of my coding style, meanwhile i tried to write an additional catcher.
As i am completely inexperienced with the topic of 'code injection' - or how to protect a script from such - i'm quite happy with the above code.
Though, the "$(hostname)" didnt raise an issue, but i guess that is something one cannot catch on that level.
Is this code snippet 'usable'?
Any thoughts / suggestions / advice / improvements?
@ Corona: Just to be sure, backticks are ` ~= $(cmd) ?
@ Chubler: Not yet, break_on_injections will be my first 'general parsing of input' of passed strings within all (most at least) my tui-commands.
From the perspektive of a local user, i'm not aware of injection problems causing more trouble than the local access to the machine anyway.
The main reason i'm currently at this, is because of a feedback when passing strings from a webpage to some (unnamed) tui-command.
In the combination, i hope to keep up the current functionality, and make it more secure.
What i figured so far, and what Rudic confirmed, was that regular strings (quoted inside " ), work as expected, but if using hardcoded strings (quoted inside ' ) will 'trigger' the break_on_injections.
To my understanding, such strings (when passed from a webpage - which tui was not thought/coded for) would (should?) be passed as hardcoded strings, or get properly escaped before passing the the tui-command, using the 'php escape functions' as proposed on the linked wiki page from the first post.
What i thought of was:
1) Make the function available to all the commands, eg: place it in a file that is source anyway.
2) Call the function before the (string-)arguments are processed any further
3) If 'injections' are found, abort with failure.