Re: Script & Interpreters
Curtis, I just don't know how you would replace the implied security of a compiled program. That raises the bar so much because you have to have so much inside info, plus usually an elevated security level to even place a compiled program on a server. When you can just feed source code in from client and force it to run, how would you protect from that?
Just think of the simple barrier a mainframe and i5 library list place on hacker. You can look at the client code and see the program being called, along with parameters you are feeding it. But that is all you can manipulate. You don't know what program is doing or where it lives.
When you combine that with some decent session control (block CGI spoofing), none of the popular hacks are going to work. No SQL injection, no XSS, no buffer overflow and inject your own code. If edits are poorly done, you could implement a kind of DoS hack by forcing HTTP jobs to crash. But you aren't going to be stealing data.
PHP guys will tell you, and it is probably true, that a server locked down properly for PHP use is secure. The problem is very few people know how to do that. If at server side you use compiled objects, it's near impossible to screw security up.
If I'm not looking at this right, please correct me. I use an IBM i5 (formally AS400). No common hacks will work if using stored procedures or compiled RPG/COBOL at backend. To use PHP, which a lot of i5 people do, you have to essentially run UNIX shell on top of i5 o/s to use PHP, which kills the native security model. So now you better understand both UNIX and i5 security. How many programmers are that good, especially at small companies?