« Test::Class::DBIx::Class Reboot | Main | Would you use this Catalyst Action Role? »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Gabor Szabo

[this is good] Before trying to offer a solution - or at the same time, I think we need to help companies evaluate the business value in the changes we suggest. Many companies don't upgrade perl or Apache or some library, nor do they improve their code base as they only see the expense and the risk in doing so. If we want companies to make changes we need to show the risk and possible cost in NOT doing anything. This research might help us in this but we probably also need to find some numbers on the possible costs for security breaches in those web applications.I would think of a white paper showing the potential problems and the potential solutions. Then we could offer an audit of the application and a better evaluation of the current risks and the cost of upgrading so the company can make a more educated decision.Of course for this we'll need to find the web sites and the companies behind them that have the issue.

brian d foy

As you guess, the information they present is statistical crap. They evaluate a website and assign it to a group based solely on the extensions they find in a URL. I can't recall any websites I've had to work on that used .pl in the URL. Indeed, those that actually care about security obfuscate the technology, change the server identification in the headers, and other things to throw off automated vulnerability scanners. That a "security" company would choose to ignore the sites that use these good practices undermines their position. Indeed, they are trying to scare people into buying their services.

The Vox login thing ate the nice post I made before, but basically Whitehats is lying with statistics. Although I know most people don't handle statistics correctly, I also know many people don't even try when they find a number that gives them the answer that they want. They can get away with this because their target audience, which isn't techies, don't understand statistics either. If you actually look at their own conclusions, specifically the vertical analysis, you see that the websites they assign to the PL group are mostly in line with the vulnerability for other platforms.I really don't think there's any more that a web security community can do to help people. There are books and websites and conferences devoted to all of this stuff. If you don't have the information it's because you don't want to have.Here's the link to their sales pitch:http://www.whitehatsec.com/home/assets/WPstats_spring10_9th.pdf


Most of those "vulnerabilities" are probably them doing a simple search for "formmail.pl" and nothing further.The simple fact that they're ranking perl as highest, with no mention of php, strongly implies that they're talking out their backside, either to come to a conclusion that fits whoever paid them *cough* I mean, provided funds to "enable" the study, or to sell the consulting services.These companies have a vested commercial interest in spreading FUD, whatever kind they feel will fit their target market. Just like anti-virus companies, their "white papers" and "studies" are invariably extremely thinly-veiled marketing press releases.I'd say the same if their findings were reversed and said ASP was more vulnerable. (And you probably don't have to look far to find either this company or another saying it either.)Upgrading perl applications can be seen as a problem, but I think that's often more to do with the "duct-tape" role of perl. There are proportionally very very very few "off-the-shelf" perl applications in my experience, as compared to other languages: upgrading a bespoke application is always hairier than an off-the-shelf one, where someone else has done the hard work of migration testing (in theory).Add that to the fact that in most installs, upgrading the perl interpreter involves upgrading it for _all_ your perl applications, it becomes an all-or-nothing task rather than one you can easily do piecemeal with incremental benefits.Getting co-existing installs of different perl versions (and sets of modules) working in a standard fashion is probably one of the biggest things that perl could do to make the lives of company sysadmins easier IMO.It _can_ be done, but it's messy and clunky and doesn't inspire confidence in its robustness.

Patrick Donelan

@Illusori: running per-app perl installs is quite pleasant thanks to App::Perlbrew (or local::lib if you just want different module versions).


In fact the article explicitly mentions Perl as having:

"he highest average number of vulnerabilities found

historically by a wide margin".

I wonder how they came up with such statement. TheCommon Vulnerabilities and Exposures(CVE) database has the following data instead:

Smalltalk:0 entries

Lisp:6 entries

Ruby:54 entries

Python:70 entries

Perl:154 entries

ASP:266 entries

Java:591 entries

PHP:4363 entries

One should note that the entries above also include modules and apps created with those languages. The fact that a given language comes before or after another could be related to popularity or time in the market or developer quality or analysis interest or any number of factors.Correlation does not imply causation, no matter what language youfavor.

So, once again: lies, more lies, and statistics ;-)

The comments to this entry are closed.