Darren Reed wrote:
Prolog isn't a 4GL (it was invented in 1972 ). In Ravi Sethi's _Programming Languages: Concepts and Paradigms_ (2nd ed1996) he defines some of the paradigms of programming languages; on pp 12-13, he provides a family tree. This book is classic (for those who don't know this is the 'S' in RSA, co-author of the famous 'Dragon Book' on compiler design etc.) but doesn't list Perl or PHP or Java -- but the concepts are the same. I'm summarizing various pieces of the book's summary here and only listing the noteworthy parts:In functional programming languages (think 4GLs like prolog),
In brief you have 3 basic paradigms (more could be invented later; PHP and Perl aren't inventing new paradigms): *Imperative - these are the descendants of FORTRAN and ALGOL: Pascal (and its descendants Modula-2 and Ada), C, C++, Java, etc. *Functional e.g. LISP and its descendants ML, Scheme, and Haskell (a descendant of ML and Scheme).
*Logic e.g. PrologObject-Oriented is an extension found in imperative (C++, Java, etc.)and somewhat in functional (viz., CLOS); it has its origins in Simula and Smalltalk.
Building PHP on top of BLISS or assembler wouldn't help. C has its place as a "portable assembler". As has been noted, there aren't so many vulnerabilities in the PHP language parser. Design defects that encourage poor programming practices, sure. But you can write bulletproof PHP. Also note that "externally supplied input" is a broad range of things. As I originally stated in my previous post, use of type-safe languages goes a long way toward fixing these things but isn't a cure all (as you mention shell escapes and the like). Buffer overflows, now that's a defect in the design of the runtime library and perhaps the language. It simply should not be possible to overrun a buffer. Either the language auto-extends the buffer (Perl) or it should fail the operation if not abort the program. Yes, in C you can blithely write past the end of an array and thereby smack the stack. You're supposed to do the work of bounds checking in your code so that in the cases where you KNOW that the input fits in the array (e.g. initializing an array from a constant; esp. when you malloc (strlen("foo")) you don't incur the bounds checking overhead on assignment. If you don't put in bounds checking where its needed that's your bug not the compiler's.rather than functional programming languages (2 and 3GL - C/Pascal/perl/etc), the ability of a programmer to do something that exposes a security problem is greatly diminished (if we exclude "shell escapes", etc.) Where do 9 out of 10 security problems with applications arise from? Dealing poorly with externally supplied input. This is the crux of nearly *all* PHP security bugs. Maybe our problem is that PHP, perl, etc, are all built on top of C and in such a manner that the origin and trustworthiness of data is lost and can no longer be delt with in an appropriate fashion.
SQL injection attacks don't attack PHP. They don't even crash your PHP program. They attack the dbms and your application system (or 'stack'). I don't believe I've seen any SQL injection attacks gain system privileges (only idiots run the dbms as root; I have some of those at work and they are fighting with me to thwart my knocking them out of root...come Solaris 10 deployed in our production, I won't care I'll lock them in a container they will see nothing they're not supposed to and have access only to their own stuff not the system and finally the DBAs will stop crying that they want to run top all the time -- and if they DO run top they'll only see their own stuff...they aren't getting anywhere near the global zone). Rather they do something nasty to steal your data (e.g., username/passwords, credit card info and so on) or to put their own stuff in (html to load a virus or trojan horse etc.).
When you look at vulnerabilities you have to also look at the impact. Remote privilege escalation is different from having your data stolen.
You keep misusing functional when you mean imperative. Have you seen any mention of vulnerabilities in LISP/ML/Scheme/Haskell recently? Mind you Scheme is all over the place because of Gnome project. Have you read _Building Secure Software_ by Viega and McGraw? Have you looked at switching to ML?So maybe there isn't a "secure" functional language yet but I can't see why we can't develop one.
Darren