Let me rephrase. Yes, you can incorporate security into a language as features. For example, buffer overflows are impossible to do in Perl. But, integrated memory management wasn't incorporated into Perl for security reasons - it was added for programmer productivity. As a side benefit, an class of security issues is now avoided.
Many security issues, such as SQL injection and cross-site scripting, have to do with the interfaces between components. SQL injection occurs when a legitimate SQL statement is hijacked to do something that is legal and often useful SQL, but disastrous for the application depending on that SQL. The bug isn't in the database, SQL, or the application. The bug is in how the application constructs SQL based on user input. The same goes for cross-site scripting for how the application constructs URLs based on user input.
I would put forward that 90% of all security issues are in how one deals with outside input. SQL injection, XSS, and buffer overflows all fall into that category. Dealing with outside input isn't a language issue, it's a design (or process) issue. Language features can help (tainting, automated memory management, placeholders, HTML escaping, etc), but not only can every safety feature be disabled, but they have to be used to be of benefit.
Or, put another way, a computer language cannot be designed to safely deal with all outside input, in large part due to the Halting problem. I would love to see an argument against that statement, but I don't think one can be made.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Well, since the E language has been mentioned above, I'll instead ask what you think of CaPerl and Safer Scripting Through Precompilation.
CaPerl is a system that implements capability discipline in Perl. It does this by introducting a few extra language constructs, and by restricting what untrusted code is allowed to do. The CaPerl language is compiled into standard Perl which can then be run by a completely standard Perl interpreter. However, untrusted code is prevented from doing anything its trusted (or untrusted) wrapper did not intend it to do.
...also these papers on capabilities, etc. might be of interest.
| [reply] |
Very interesting. I don't think it will work in Perl5, but I just suggested adding it into Perl6.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
