Analytics
4/15/2014
05:30 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Don't Blame It On The Web Programming Platform

New data shows no one Web development platform generates more vulnerabilities than another -- and website security is still a problem.

The web programming language you pick doesn't dictate your website's security: New data on website vulnerabilities shows that no one platform is more secure than another.

WhiteHat Security's 2014 Website Security Statistics Report published today concludes that .NET accounts for over 28% of websites, followed by Java (25%), and ASP (16%) among more than 30,000 websites. "No languages were more secure than others," says Gabriel Gumbs, a director in WhiteHat Security's solutions architecture group and the lead researcher for the report. Bottom line: There was no major difference in the number of vulnerabilities found among websites using the various languages.

.NET had an average of 11.36 vulnerabilities, followed by Java (11.32), ASP (10.98), Perl (7), and ColdFusion (6).

The report also shows that website security is not improving overall. While website operators are doing a better job at remediating flaws, their applications over time don't necessarily become more bug-free. "In the same breath, new applications are not showing any major improvements over the applications we see year over year. It's about the same, and that's moving backwards," says Gumbs. "The new stuff they are developing isn't necessarily more secure."

Gumbs says that could be the result of new functions or features that introduce complexity, and per usual, more security flaw possibilities.

Chris Eng, vice president of research at Veracode, says WhiteHat's report basically jibes with his company's own data on software vulnerabilities. Its numbers were similar when it came to remediating flaws, for instance, he says. "In our data, we see that certain categories [of bugs] are getting fixed reasonably quickly," says Eng, whose company scans vendors' and other developers' software code for flaws via a cloud-based service.

WhiteHat's Gumbs, meanwhile, says the report's data on legacy applications was most telling. "Their remediation rates were on par with all new applications," he says, pointing to the older ASP platform popular in the financial and insurance industries, according to WhiteHat data.

"A lot of applications you simply can't get rid of," he says.

The most prevalent vulnerability was cross-site scripting, which made a comeback to the top spot after losing its top ranking to information leakage last year. The other four in this year's top five (in order) were information leakage, content spoofing, HTTP response splitting, and predictable resource allocation.

"People are not picking languages based on security implications. That's true and will continue to be true. It's where developers have skillsets and what can get the functionality done," Eng says. "Security is going to be fifth or sixth on the list."

The full WhiteHat report is available for download here

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
GonzSTL
50%
50%
GonzSTL,
User Rank: Ninja
4/16/2014 | 10:06:34 AM
Re: It all starts with the C-Level
I would extend that notion to state that the C-suite must regard all of IT security as a vital part of their organization. If that is the case, then security becomes integrated in every aspect of the organization. Nothing breaks down barriers and objections faster than the knowledge that any initiative or idea is driven down from the top. The key is conveying the message to the C-suite that IT security is vital. There are many organizations that still treat IT security as an afterthought. Look at the breached companies and you will likely find that it is sadly, and frighteningly true.
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
4/16/2014 | 8:36:15 AM
Re: It all starts with the C-Level
What you said about the C-level suite not educating programmers on writing secure code is key, @anon6230542982. It's also a cultural issue among coders that somehow needs to be shaken up. As Chris Eng said, "People are not picking languages based on security implications. That's true and will continue to be true. It's where developers have skillsets and what can get the functionality done," Eng says. "Security is going to be fifth or sixth on the list."
anon6230542982
50%
50%
anon6230542982,
User Rank: Apprentice
4/15/2014 | 9:40:20 PM
It all starts with the C-Level
Anyone in this industry knows that the development language is not the issue, that it is the implementation is the issue, and it all starts with the C suite.

When it comes to secure software development most organizations do the minimal effort required to meet some industry compliance standard such as PCI. They don't do it because they are trying to develop better software.

The C suite cares about one thing and one thing only, short term ROI. They are worried about their quarterly numbers and lack a long term strategy. If they did then they would know secure software development is commitment the whole company has to embrace not just development teams. Its a cultural change in how they do business and write their software.

I have seen company after company think that by performing dynamic and/or static security scans of their software they have implemented a secure software development program that is going to fix their problems. Yet they don't staff the information security teams with people who can validate the findings. They don't educate their developers on how to write secure code. They have no corporate software development policies. Those that do, their CxO has never reviewed any of the development standards to see if they comply with the development policies. They don't audit the development processes to see if they comply with the standards. Developers are left up to their own means to do whatever they want and are never questioned because the C suite would rather claim ignorance, blame technology for their lack of leadership rather than be accountable for something and make a real difference.

If you don't have a C level person in your company who is actively involved with your software development program, setting policies and holding management responsible for cutting corners to get the next version of your product out the door just so they can make their quarterly numbers then you will continue to produce insecure software and it will never get better.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Threat Intel Today
Threat Intel Today
The 397 respondents to our new survey buy into using intel to stay ahead of attackers: 85% say threat intelligence plays some role in their IT security strategies, and many of them subscribe to two or more third-party feeds; 10% leverage five or more.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0485
Published: 2014-09-02
S3QL 1.18.1 and earlier uses the pickle Python module unsafely, which allows remote attackers to execute arbitrary code via a crafted serialized object in (1) common.py or (2) local.py in backends/.

CVE-2014-3861
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to inject arbitrary web script or HTML via a crafted reference element within a nonXMLBody element.

CVE-2014-3862
Published: 2014-09-02
CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to discover potentially sensitive URLs via a crafted reference element that triggers creation of an IMG element with an arbitrary URL in its SRC attribute, leading to information disclosure in a Referer log.

CVE-2014-5076
Published: 2014-09-02
The La Banque Postale application before 3.2.6 for Android does not prevent the launching of an activity by a component of another application, which allows attackers to obtain sensitive cached banking information via crafted intents, as demonstrated by the drozer framework.

CVE-2014-5136
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in Innovative Interfaces Sierra Library Services Platform 1.2_3 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.