> Ultimately I think that scripting languages encourage the construction > of programs which are "99% correct", i.e. they work fine unless their > input contains unexpected characters (e.g. language metacharacters). The same applies to any piece of software, regardless of the way of execution. Program behaviour depends on how careful is non-trusted input examined and treated. Moreof, languages with special text processing features have (potentially!) more chances to detect malformed input than others, more `general' ones. > This thread started with a question about a "secure" popen() function. > What's insecure about popen() itself is the fact that it passes its > input to a script interpreter (/bin/sh). Nothing, I think. Even if user input contains nasty sequences of shell commands, everything is piped to recipient's stdin and it's not interpreted by shell. Care must be taken to make sure that shell really calls `valid' recipient, but that seems to be more the matter of system administration than programming. > The real issue is a) above. Scripting languages, by their nature, make > heavy use of "in-band signalling", where language constructs are > embedded within data. Unless care is taken to prevent the problem, the > risk is that user-supplied "data" can effectively become user-supplied > code. I must admit that I'm kinda lost here and would appreciate any, however quick and dirty, example related to the problem being discussed. -- ÌĤ¯Ç¤ÏÁͤòÊá¤é¤Ì
This archive was generated by hypermail 2b30 : Thu Jun 21 2001 - 20:22:15 PDT