A quick note as we’re getting started: we’ll be live-tweeting events at the 10th Annual CERIAS Information Security Symposium on the @cerias account. If you’ll be tweeting along with us, we encourage you to use the #cerias tag. Thanks!

If you’re at OSCON, and you love security, you may or may not enjoy my talk on PHPSecInfo, a security auditing tool for the PHP environment. I’m actually going to try to show some new code, so if you’ve seen it before, you can see it again – for the first time.

The talk is at 1:45pm Thursday, 07/24/2008.

• PHPSecInfo homepage
• PHPSecInfo code repository

Just a quick note that Eugene Spafford, Executive Director of CERIAS, will be giving testimony this morning at 10 a.m before the House Ways and Means Committee at a “Hearing on Employment Eligibility Verification Systems and the Potential Impacts on SSA’s Ability to Serve Retirees, People with Disabilities, and Workers.” You can view the broadcast live by visiting the hearing’s page and clicking on “Click Here to View Committee Proceedings Live.”

Lots of new papers added this week—more that we can list here. Check the Reports and Papers Archive for more.

CERIAS Reports & Papers

• "Cryptanalysis of Number Theoretic Ciphers"
• "Sums of Squares of Integers"
• "Secure Outsourcing of Sequence Comparisons"
• "Universal Accumulators with Efficient Nonmembership Proofs"
• "Dynamic Virtual Credit Card Numbers"
• "A Construction for General and Efficient Oblivious Commitment Based Envelope Protocols"
• "Scanner identification using sensor pattern noise"
• "Forensic classification of imaging sensor types"
• "A Survey of Forensic Characterization Methods for Physical Devices"
• "Lapped-orthogonal-transform-based adaptive image watermarking"

CERIAS Weblogs

• One of the Barriers to Computing Diversity
• Comment Spam Extortion

An interesting new kind of comment spam showed up in our moderation queue today:

Author : Anikrichard (IP: [redacted] , [redacted].com)
E-mail : [redacted]@mail.ru
Comment:
hello , my name is Richard and I know you get a lot of spammy comments ,
I can help you with this problem . I know a lot of spammers and I will ask them not to post on your site. It will reduce the volume of spam by 30-50% .In return Id like to ask you to put a link to my site on the index page of your site. The link will be small and your visitors will hardly notice it , its just done for higher rankings in search engines. Contact me icq [redacted] or write me [redacted](at)yahoo.com , i will give you my site url and you will give me yours if you are interested. thank you

A little “you scratch my back, I’ll scratch yours” arrangement, it seems. I wonder how many people will fall for this protection racket.

CERIAS Reports & Papers

• "Defense Science Study Group 2004-2005 Papers 1-11"
  30 April 2007, 7:00 pm
• "Using artificial neural networks for forensic file type identification"
  29 April 2007, 7:00 pm
• "Enabling Confidentiality of Data Delivery in an Overlay Broadcasting System"
  28 April 2007, 7:00 pm
• "Feasibility of DDoS attacks using P2P Systems and Prevention through Robust Membership ...
  28 April 2007, 7:00 pm

CERIAS Weblogs

• “Verified by VISA” Issues
  3 May 2007, 3:10 pm
• More on passwords
  1 May 2007, 1:11 pm
• Quicktime flaw on Macs brings out the crazies
  27 April 2007, 1:27 pm

I’ve spent some of my down time in the past couple weeks working with the NIST NVD data to get stats on PHP application vulnerabilities.  What follows is a breakdown of the 20 PHP-based applications that had the highest aggregate vulnerability scores (NIST assigns a score from 1-10 for the severity of each entry), and the highest total number of vulnerabilities, over the past 12 months.  Of the two, I feel that the aggregate score is a better indicator of security issues.

A few caveats:

• The data here covers the period between April 1 2006 and April 1 2007.
• This obviously only includes reported vulnerabilities.  There are surely a lot more applications that are very insecure, but for one reason or another haven’t had as many reports.
• I chose 20 as the cutoff mainly for the sake of making the data a little easier to swallow (and chart nicely). There are about 1,800 distinct apps in the NIST NVD that are (as far as I could determine) PHP-based.

Without further ado, here are the tepid Excel charts:

A couple notes:

• There are 25 entries in the top “20” by vulnerability count, due to matching vulnerability counts.
• I’d never even heard of MyBulletinBoard, the top entry in both lists.  It hasn’t had any vulnerabilities in the NVD since September of 2006, which says something about how numerous and severe the entries between April and September 2006 were.  This appears to be the same product as “MyBB,” so perhaps the situation has improved, as MyBB only has one NVD entry in the entire period (CVE-2007-0544).
• Wordpress has had a bad start to 2007, with numerous vulnerabilities that significantly increased its ranking.  March 2007 was particularly bad, with 7 new vulnerabilities reported.
• Bulletin board/forum software is by far the most common type of application in the top 20.  A couple forum apps that have very low numbers of vulnerability reports: Vanilla and FUDForum.

I do intend to keep this data up-to-date if people find it interesting, so let me know if you’d like me to do so, or if you’d like to see other types of analysis.

[tags]php, security, application security, vulnerabilities, nist, nvd, statistics[/tags]

CERIAS News

• Registration Open: Columbus Incident Response Workshop (CCIR)
  27 February 2007, 8:15 am

CERIAS Weblogs

• Do Open Source Devs Get Web App Security?  Does Anybody?
  27 February 2007, 11:01 am
• PHPSecInfo v0.2 now available
  26 February 2007, 2:28 pm

CERIAS Hotlist

• heise Security UK - computer security news, information and services
  23 February 2007, 7:05 am

Note: I’ve updated this article after getting some feedback from Alexander Limi.

A colleague of mine who is dealing with Plone, a CMS system built atop Zope, pointed me to a rather disturbing document in the Plone Documentation system, one that I feel is indicative of a much larger problem in the web app dev community.

The first describes a hole (subsequently patched) in Plone that allowed users to upload arbitrary JavaScript.  Apparently no input or output filtering was being done.  Certainly anyone familiar with XSS attacks can see the potential for stealing cookie data, but the article seems to imply this is simply a spam issue:

Clean up link spam

Is this a security hole?
No. This is somebody logging in to your site (if you allow them to create their own users) and adding content that can redirect people to a different web site. Your server, site and content security is not compromised in any way. It’s just a slightly more sophisticated version of comment spam. If you open up your site to untrusted users, there will always be a certain risk that people add content that is not approved. It’s annoying, but it’s not a security hole.

Well, yes, actually, it is a security hole.  If one can place JavaScript on your site that redirects the user to another page, they can certainly place JavaScript on your site that grabs a user’s cookie data and redirects that to another site.  Whether or not they’ll get something useful from the data varies from app to app, of course. What’s worrisome is that it appears as if one of Plone’s founders (the byline on this document is for Alexander Limi, whose user page describes him as “one of Plone’s original founders.”) doesn’t seem to think this is a security issue. After getting feedback from Alexander Limi, it seems clear that he does understand the user-level security implications of the vulnerability, but was trying to make the distinction that there was no security risk to the Plone site itself.  Still, the language of the document is (unintentionally) misleading, and it’s very reminiscent of the kinds of misunderstandings and excuses I see all the time in open-source web app development.

The point here is (believe it or not) not to pick on Plone.  This is a problem prevalent in most open source development (and in closed source dev, from my experience).  People who simply shouldn’t be doing coding are doing the coding—and the implementation and maintenance.

Let’s be blunt: A web developer is not qualified to do the job if he or she does not have a good understanding of web application security concepts and techniques.  Leaders of development teams must stop allowing developers who are weak on security techniques to contribute to their products, and managers need to stop hiring candidates who do not demonstrate a solid secure programming background.  If they continue to do so, they demonstrate a lack of concern for the safety of their customers.

Educational initiatives must be stepped up to address this, both on the traditional academic level and in continuing education/training programs.  Students in web development curriculums at the undergrad level need to be taught the importance of security and effective secure programming techniques.  Developers in the workforce today need to have access to materials and programs that will do the same.  And the managerial level needs to be brought up to speed on what to look for in the developers they hire, so that under-qualifed and unqualified developers are no longer the norm on most web dev teams.

The newest version of PHPSecInfo, version 0.2, is now available.  Here are the major changes:

• Added link to “more info” in output.  These lead to pages on the phpsec.org site giving more details on the test and what to do if you have a problem
• Modified CSS to improve readability and avoid license issue with PHP (the old CSS was derived from the output of phpinfo())
• New test: PhpSecInfo_Test_Session_Save_Path
• Added display of “current” and “recommended” settings in test result output
• Various minor changes and bug fixes; see the CHANGELOG for details

-Download now

-Join the mailing list