In current scenario, where any person can steal your password with one single click to a link, using secured programming languages is a daunting task. Various languages and frameworks are used to make the site as secured as possible. Give it a reality check — every other framework/language has some loopholes which the hackers find fascinating to get through. Every language seems to be vulnerable in some way or the other.
The techie world has been gung-ho about the WhiteHat Study made on 20,000 websites, focusing mainly on widely used programming languages/frameworks. It gave way to a plethora of discussions and debates at various forums, with each developer defending his/her favorite language. That apart, the study has really been an eye-opener of sorts to more naïve techie-to-be people. It proves that the security of the websites comes down to the programming language used.
Providing a secured environment for the clients has always been challenging to the developers. They often dab their hands at many languages/frameworks. So, if a single programming language can be so much insecure, think of a site written with many languages/frameworks. The vulnerabilities multiply.
.NET seems to be the most widely used framework for web applications. Information Leakage is its #1 vulnerability. XSS takes up the #2 place. It clearly shows that the most popular languages are not always secure. The need for security measures to be taken are always on the rise.
A contemplation gives rise to many contradictions. Of course, as we all know, .NET and ASP are not programming languages. They are used as frameworks. There is also one voice stating that security is not with the programming languages but with the run-time checks. But developers fall back on languages whenever a vulnerability occurs.
So it all depends upon the language. But when something is developed, the architecture and design are always given importance. Security is always queued to the last. There are many vulnerabilities out there — XSS, CSRF, e-Mail Injection, SQL Injection etc., Not every language is tried and tested to solve all these vulnerabilities. A developer who is not familiar with his/her programming language and uses difficult constructs makes way for the vulnerabilities. Using well-known language/framework and testing it in every stage of development with security check as the priority, will make the sites more secure.
Security is a process to be achieved and it cannot be done overnight. The software architecture must be developed with security to be the ultimate aim. The developers must use security constraints to prevent the clients from dangers. Vulnerabilities, if found, should be managed ASAP and kept away from the sites for good. There are many frameworks to help avoid vulnerabilities — VIEWSTATE (for .NET), Rails (anti-CSRF) and so on.
All said, the security lies with the developer. Only by using a language in which the developer is comfortable with, he/she can plunge deep into the code and introduce various ways to keep his/her site downright secure.
The WhiteHat Security Report researches how secure the programming languages are. Some notable statistics obtained are:
Widely used programming languages –
.NET – 28.1%
Java – 25%
ASP – 16%
PHP – 11%
ColdFusion – 6%
Perl – 3%
.NET – 31%
Java – 28%
ASP – 15%
PHP – 15%
ColdFusion – 4%
Perl – 2%
Average of vulnerabilities per slot –
.NET – 11.36
Java – 11.32
ASP – 10.98
Perl – 7
ColdFusion – 6
SQL Injection Vulnerabilities –
ColdFusion – 11%
ASP – 8%
.NET – 6%
ColdFusion — 96% of SQL Injection
100% of Abuse of Functionality
87% of Insufficient Transport Layer Protection
Perl — 85% of Cross-Site Scripting (XSS)
18% of SQL Injection
.NET — 89% of SQL Injection
Java — 89% of SQL Injection
Average number of days vulnerabilities remained open –
ASP — 139 days
PHP — 129.5 days
Java — 90.9 days
(You can get the entire report in pdf here — https://info.whitehatsec.com/Website-StatsReport.html?utm_source=pressrelease&utm_medium=pressrelease-2014statsreport&utm_campaign=pressrelease)
(All the statistics stated above are from the report and the excerpts of the report found at http://www.net-security.org/secworld.php?id=16694)