> > Is the reason for the large number of vulnerabilities in perl-based > > CGI's due to the language? This is what you appear to be saying. > > That is basically what I'm saying. It applies to scripting languages > generally, but Perl is arguably an extreme case. > > > My thought is that because perl is easier for entry-level programmers > > to program in, those programmers will use it for developing web and other > > applications. > > > > Less-experienced programmers generally make more mistakes (or poor > > design choices) than more-experienced programmers. > > That's an issue, but I don't think that it's the only issue. In many > respects, BASIC would be less problematic than Unix-style scripting > languages, as it doesn't generally use textual substitution in the way > that scripting languages do. > > 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). > > 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). > > 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. > > Note that similar issues do occasionally occur with C; most notably > regarding printf() format strings (which have also become a recurring > theme on BugTraq). However, here the problem is with a few specific > functions. With scripting languages, it's at the core of the language. so following your line of argument we should abandon C and C++ since 90% of the buffer overflows are found in the programs written in those 2 languages? i don't think so. (btw, i don't see any way how C++ strings class is going to protect you from buffer overflows if you incorrectly manipulate your strings). It's too bad that the majority of people who write insecure CGI programs (and buffer overflow ridden programs) are either clueless or are not security aware. Perl offers security mechanisms far superiour to those of C/C++/Java when it comes to writing secure CGI programs, it's the people who screw up (duh). http://www.perl.com/pub/doc/manual/html/pod/perlsec.html
This archive was generated by hypermail 2b30 : Thu Jun 21 2001 - 20:29:40 PDT