The informative and instructive posts on this blog about programming in the R Programming Language, and a colleague’s recent suggestion that I use F# for a particular task, got me thinking about the current proliferation of programming languages.
As a working college student, I designed and implemented a couple of programming languages and modified the compilers for others. In some cases, the goal was to get work done more quickly. For others, the goal was to minimize the use of resources. I modified a FORTRAN compiler, for instance, to make the specification of octal and hexadecimal constants easier. I also created a stack-oriented language (a la Forth) to make efficient use of RAM in some small microcomputers. Not a single language or “improvement” I did was for the purpose of cyber security!
There are far more languages now. I want to encourage you to make informed choices when using languages for various projects. Of course, you can’t choose just any language for any situation. While it may exist, I haven’t seen a version of APL that runs in a browser. That’s probably very good!
It would be more like a textbook and less like a blog post, to discuss what programming languages to use and where. Instead, I’d like to take a brief look at the security of programming languages, or rather encourage you to do so yourself.
There are many aspects to doing this and many ways to approach the analysis. For instance, if the application uses the web as its interface, is the code browser-based or server-side? Since different languages may be used at each end, we need to be careful to look at each language, its use, the network interaction, etc., and then to assign risk levels to each. It’s really not easy. And of course algorithm design and implementation are big factors in the security of a particular application.
UpGuard posted the results of a study by WhiteHat Security. Despite the title, “Which Web Programming Language Is The Most Secure?”, they don’t give a specific answer, mostly for reasons I noted above. But they do report on the study’s interesting analysis of languages used and vulnerabilities found.
Continued searches resulted in papers that told programmers how to do some things securely, but no real references to what languages have security issues. A search on Amazon produced a similar result. Wikipedia found two related programming languages designed for security: E and Joule. While it doesn’t list Ada there, it has many features for secure programming and is designed to prevent programmers from doing tasks insecurely.
As a programmer, I love languages such as Perl, which let me do a particular task in many different ways. Perl programmers describe that as “TIMTOWTDI” (pronounced “Tim Tody”) which stands for “There Is More Than One Way To Do It.” Some ways may be more secure than others. As a security professional, I wish the insecure ways were not allowed.
Disallowing insecure constructs can be done in multiple ways: removing them from the language (thus probably creating yet another one!), requiring a programmer to explicitly enable their use (consider taint in Perl), or potentially by using external controls such as aspect-oriented approaches, or isolate code in containers. It would be difficult to list all the tools available for securing programs. There are countless tools from Microsoft and third-party vendors for Windows platforms alone. It is a daunting landscape.
So what’s the bottom line? The bottom line is that you may not be able to pick a particular language for its security, so you’ll have to learn to program securely and use external mechanisms. As I wrote earlier, the software education industry is finally addressing this directly. We each need to address it individually, too. We discuss the fundamental issues in Learning Tree’s System and Network Security Introduction. It is a good starting point for learning about cyber security for programmers and non-programmers alike.
Let us know in the comments below about your experiences in secure programming.
To your safe computing,