Many things which are insecure are perfectly acceptable programming practices for situations that are known to be secure. For example, Shell. Shell is a great tool for sysadmins, but I would never put any program that uses it on the web - it's a security risk.

Security isn't about programming language - it's about process. It's about assessing the risks vs. the benefits and making a decision accordingly.

SQL Injection attacks are impossible to do against a Perl application ... so long as you use DBI's placeholders.

Hmm... Let's rephrase that a tad...

Buffer overflow attacks are impossible to do against a C application ... so long as you use malloc and free properly.

...

Ruby is the exact same way - there's even a section on it in the Ruby on Rails book. It says (and I paraphrase) "Use DBI placeholders to make SQL Injection attacks impossible."

But Ruby and SQL don't take a language level approach to security, right? I'm only wondering if there is any evidence to back up the OP's claim that security isn't a language issue (which I read as "security can't be a language issue"). Maybe you can pinpoint your stance on the issue...
1. Security hasn't been incorporated into a popular lanugage yet, so it must be hard or impossible (let's ignore things like Java applets for now).
2. Language based security isn't possible for theoretical reasons X, Y, and Z. (As found out by the creators of lanugages Foo, Bar, and Baz when they crashed and burned. See their research papers).
3. Language based security is possible, but it is really hard or makes a language cumbersome to use (See also the experiences from the Foo Project)
4. Language enabled security is too expensive for some reason. It is almost always cheaper to fix it when it breaks.
5. Other
...of course, I pretty much think that any idea could be made into a language issue, if so desired. See also: The Role of the Study of Programming Languages in the Education of a Programmer.

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:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Security is a process. Many things that help security can become language features. You've mentioned memory management. You go on to mention some of the benefits of capability designs. But even if you have all of those, you don't necessarily have any security.

In this case the fundamental problem was addressed in part 5 of Dan Berstein's description of what he did to make qmail secure. Don't parse!

The Perl bug that the webmin discussion uncovered was due to how Perl parses printf strings. SQL injection attacks are due to Perl programmers unsafely constructing SQL for a database to parse. In short any interface where one side sends formatted text for the other side to parse and do something with is a complex interface that is very vulnerable to bugs if the one side allows slightly wrong data across that interface. And bugs properly exploited lead to security holes.

Capability systems do not change this fundamental fact. What they are better at is making it more difficult to escalate bugs into serious security violations. That is not completely true. It is possible to take a capability system and build an insecure piece of software. If you want, you have the tools to do it right. But having good tools does not guarantee success. As an example I'll point out that one can build a POSIX subsystem out of a capability-based system, use that to port standard Unix software, and then despite your capability based roots you're back to the normal Unix situation. Admittedly only for the data that is in the POSIX subsystem, but if that is the data that you care about, that is a cold comfort.

So one message that you could walk away from this with is that any language that really cares about security should avoid parsing. However if you're going to interact with existing systems, you're quickly going to find yourself having to interact with existing interfaces that are text-based. For instance databases, email, HTTP, and flatfiles. So the natural APIs to build will involve parsing. And that isn't a question of the language that you're using - it is about the legacy systems that you're interacting with.

Now you can build wrappers around those APIs to avoid parsing. People do - for instance they use Class::DBI instead of writing SQL. (A major issue with this kind of thing is that you can then only access features that the API has exposed. If you need more sophistication, then you need to go to the underlying API...) People can also find options to make the parsing interface simpler - for instance using placeholders instead of dynamically constructing SQL. However at some point you have to accept that there is a programmer responsibility to understand the issue and do things right.

Perl offers tools, eg taint mode, to make it easier to do things right. Perl could do more. But no matter what, some of the responsibility must belong to the programmer.

If you are making the point that human made creations will never be perfect, I'm in 100% agreement. But with some (minor? major? moderate?) effort we could reduce the incidence and severity of bugs by factors of thousands if not millions. In my view, that seems like a goal worth striving for. Along with capabilities, and memory management, we can employ better testing strategies and static typing and other lightweight formal methods. Here, I'll mention some of Les Hatton's publications. I'm only railing against the notion that we're already doing a good job at security. We're not. We need all the help we can get. And better languages will make it a lot easier.

Let's do a little rewording...

Concurrency is not a language issue for the same reason that it is not a checkbox that you can put on a feature list. Correctly implementing concurrent program is a process. Many things that help concurrency can become language features.

Would you agree? I for one disagree. Shared state parallelism (threads) is a huge bucket of worms. Humans really aren't smart enough to use it correctly. What we need are new languages to help us manage concurrency. Erlang and Oz spring to mind. To my mind problems like that scream out language issue. Same goes for security.

I interpreted "language issue" to mean "something that you solve at the language level", in which case both statements are correct.

Apparently you interpret "language issue" to mean "something that you can address at the language level", in which case both statements are absurd.

What I meant should have been clarified by my second paragraph.

If you assume that concurrency and security are equivalent issues, then you're absolutely correct. Except, they're not. It's easy to demonstrate - concurrency can cause security issues. Security cannot cause concurrency issues. QED

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

dragonchild is doing an excellent job, certainly more cogently than I will be able to do. (Thank, you dragonchild).

There is a lot more to security than a language's (say) memory access model or potential race conditions. Many very serious examples of security problems have absolutely nothing to do with software: trusted users doing improper actions which are, nonetheless, well within their security profiles (sysadmins may have legitimate need to get into the bank's account database), careless disposal or loss of hardware with confidential information, users putting their impossible-to-memorize passwords on PostIt™s stuck on their monitors, et al.

Restricting my comments to software: There is no way language selection can prevent something like

&transfer_all_money_from(cat => \$user) if($user eq 'theMice' and &is_
+away('cat'));
[download]

I don't see how E, CaPerl, etc could prevent this.

There is no way language selection can prevent something like

&transfer_all_money_from(cat => \$user) if($user eq 
'theMice' and &is_away('cat'));
[download]

Capability-based Financial Instruments

Abstract: Every novel cooperative arrangement of mutually suspicious parties interacting electronically --- every smart contract --- effectively requires a new cryptographic protocol. However, if every new contract requires new cryptographic protocol design, our dreams of cryptographically enabled electronic commerce would be unreachable. Cryptographic protocol design is too hard and expensive, given our unlimited need for new contracts.

If you don't want to read the papers, check out the video.

I repeat: there is no way a language can prevent illicit activity if it is within the user's security profile, especially if the user has access to the source code and authority to change it: DBA's need to be able to read and write databases, sysadmins need to be able to read and write user account information.

And what is the implementation language behind E, CaPerl, etc? I would bet a fair amount of money it's C; is hiding C's vulnerabilities behind a "secure" language front-end really secure? Or is it just papering over a problem?

emc

Netlib

Many very serious examples of security problems have absolutely nothing to do with software

Just because you can't fix all problems, does that mean we should try to fix any? You can also say seatbelts in cars are potentially dangerous. The buckle could fail to latch, causing a false sense of security. You could potentially strangle someone with the belt. Also, in some instances, the buckle might jam, causing the passenger to be trapped in a burning vehicle.

I don't see how E, CaPerl, etc could prevent this.

That's why links were provided, so you could study up! If nothing else, the next time this topic comes up, you'll be in a position to say "I've read some of the revalent literature and I don't agree, because...". That's a much stronger position to argue from instead of professing a failure of imagination.