One question that several people have asked me over the years is this “Which is the most secure development platform/programming language in the world?” It is an honest question. It is quite pertinent, given the state of application security across the globe. However, it is akin to asking the question “Which language allows me to speak the best?” The answer to that question is “all of them” or “none of them”. Today, on the web, we have several languages/platforms/frameworks vying for attention. All of these languages have their disciples and zealots. Yes, you even find them for languages like Perl (to be taken in the right spirit). Nevertheless, I would like to provide a glimpse into the current state of security of these programming languages and platforms, to give the most suitable response that I can provide for the question that most people ask me.Firstly, let me start off by saying this. In my opinion, programming languages and platforms are like tools. A skilled and security-conscious developer can do amazing things with these languages and platforms. I can safely say that a developer who is aware of security requirements and their impact on an application, is truly the best defense against attacks. However, that is not the purpose of this article. For this article, I will divide my analysis into two segments, they are:
The Established Order
The Established Order consists of languages and frameworks that have been used since the inception of web platforms. I am principally referring to Java, ASP.NET and PHP. I am going to ignore CGI and Perl simply because, I believe that most modern development across companies that I encounter do not depend on.
Lets start with PHP. PHP is a security tester’s dream. I have seldom found a secure PHP application that I have truly respected for its security implementation, which is scary because PHP is an extremely prevalent programming language on the interwebs. In addition, the simplicity of the language and the sheer number of PHP products (Wordpress, etc) dominate the world of the web. An established PHP developer told me that the reason that PHP is so widely maligned from a security standpoint is that the language is splintered and distributed (a claim that I am not entirely sure of). Nevertheless, I find a rash of vulnerabilities with PHP applications and I can safely generalize that I find most of the highly vulnerable applications developed on PHP. Having said that, newer implementations of PHP that use frameworks like Zend and CakePHP seem to have handled several issues that we used to encounter on a routine basis.
Java has gotten a status of being an “enterprise platform/language”. I have seen Java either being used by Banks and Financial Institutions or established internet companies like Amazon and Google. I have observed that while Java devs seem to have handled Authentication issues, session management implementations with great comfort, I have seen several failings in Direct Object Reference attacks and Cross Site Scripting. The good thing with Java is that you have a great deal of code examples, lessons and tutorials on securing Java Apps, however, I still find that XSS and Direct Object Referencing issues are pervasive across most Java Apps that we test at we45. Java provides great strength with reference to Crypto and I find that log4j single-handedly simplifies Logging and Log Management for Java. However, more programmatic security issues still persist with older Java web apps. Today, we have some great Java web frameworks like Spring, Play and Vaadin that handle several security issues right out of the box.
ASP.NET is a surprise on the web platform front. It is also an extremely popular and powerful platform that has been used extensively in several applications that I run into. Although one might scoff at Microsoft for its security flaws (in the OS), they have done great work with promoting and promulgating security features into the platform. I see very few issues with XSS, SQL Injection, Session Management, etc with DotNET, However, I still see Business Logic, Direct Object Reference and Authorization Flaws with the platform. I also find that DotNET Developers are more aware of security issues and impact as they seem to have several security references in their reference materials and API Documentation.
The New(er) kids on the Block
In this section, I focus on languages/platforms like Python (Django), Ruby on Rails, Angular, Node and so on. While some of these languages are not exactly “old”, I have seen some modern applications and new-age product companies use these platforms and frameworks in their products.
Let’s start with my personal favourite, Django (Python). I love Django. It is extremely simple and abstracts away all of the niggling security-related issues that you see requiring explicit attention with other platforms. Django pretty much solves XSS, Password Encryption, SQLinjection, Session flaws, Auth flaws, XSRF and Host Header Injection right out of the box. Its less verbose and highly effective to be used even for apps with massive scale (we45 ’s own apps VMA and SecuritySlate are 100% Django and scale like nobody’s business). However, all this security sometimes dulls developers into thinking that they are invulnerable and they make serious errors in Business Logic Flaws, Direct Object Reference and other flaws. In addition, Django does not directly allow the use of Indirect Object maps, which makes fixing Direct Object reference flaws, a little cumbersome to say the least.
Ruby on Rails has made some impressive strides in security. However, some of you might remember that Github had massive security failures due to some insecure implementations of ActiveRecord and Mass Assignment in Ruby on Rails. Ruby on Rails devs also had some security nightmares in 2013 (read CVE-2013-0156). However, in my opinion things have been rather quiet on the Ruby security front since then. Ruby also enjoys some great APIs and apps that really make a developer’s life easy when implementing security. Apps like Brakeman and Codesake are highly used and appreciated by the Ruby Dev community. Rack is a middleware component that enjoys massive usage for its inbuilt security protections.
Angular JS and Node JS are definitely new kids on the block as they are used by the latest apps. They are usually used in conjunction with NoSQL Databases. I find that NoSQL databases are implemented in a very in-secure manner and thus we (at we45) find issues with these applications. We also see CSRF Issues and Web Services Auth Bypass issues with these apps. We also see HTTP Parameter Pollution with AngularJS Apps implemented with NoSQL quite often. Of course, we see some XSS attacks as well.
I think by now you would have understood that languages/platforms and their frameworks can facilitate security and its implementation. As I mentioned earlier, the most important defence against an application’s attacker is a skilled and security-conscious developer and an organization that has planned, implemented and tested security extensively across the lifecycle. No language/platform or framework can serve as a defence against negligence and lack of awareness.