Nick Brawn wrote: > > > Is there any specific reason why you are writing a simple CGI in c++? If > > > it is for learning, then I can see the point but this can easily be done > > > securely and efficiently in PERL or perhaps PHP(never had a chance to do > > > this). > > > > Whilst it's theoretically possible to write a secure CGI in Perl, it's > > a lot easier to get it right in a language such as C++ which: > > > > a) doesn't make extensive use of "in-band signalling" (i.e. > > subsitutions triggered by metacharacters), > > > > b) has (reasonably) strong typing, and > > > > c) tends to be legible. > > > > Scripting languages such as Perl are useful for quick hacks, but > > security-wise, they truly suck. Scan the BugTraq archives for > > references to CGI programs; I would guess that around 90% of > > vulnerabilities are due to the above. > > 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. -- Glynn Clements <glynn.clementsat_private>
This archive was generated by hypermail 2b30 : Thu Jun 21 2001 - 08:34:10 PDT