An effective way to treat Web 2.0 vulnerabilities

An effective way to treat Web 2.0 vulnerabilities

Summary: I'm personally a huge fan of the Matasano blog, and have a lot of respect for their group.  I took a peek over at their blog today and noticed an article by Dave Goldsmith that deals with "Vulnerability Reporting in a Web 2.

TOPICS: Browser, Security

I'm personally a huge fan of the Matasano blog, and have a lot of respect for their group.  I took a peek over at their blog today and noticed an article by Dave Goldsmith that deals with "Vulnerability Reporting in a Web 2.0 World Continued".

In this article, Dave recounts personal experiences dealing with a PITA vendor that treated his vulnerability report as if it was a feature request.  That sounds crazy right?  Have a look at Dave's original communication chain with the vendor:

Step #1: I send in a vulnerability report. I explain the vulnerability in a concise email and include repro steps.

They reply:

Thanks for the tip, David. It’s been noted.

I reply:

Can you give me some guidance on your response guidelines to security vulnerabilities? Is there a timeframe that you try and have vulnerabilities fixed by?

They reply:

Hi David,We’re always looking for new ideas and fixes to roll out in future updates but as as rule we don’t comment on possibilities or timeframes.

I reply:

How will I know when this vulnerability is fixed?

They reply:

Actually, they don’t reply at all.

Nice.  I've been there before myself with a few vendors.  This creates an interesting conundrum for the researcher.

 Your ethics should probably say (assuming you're ethical):

  1. I'd hate to blast out a vulnerability that will be exploited
  2. I'd hate to allow a vulnerability that I know about to be exploited

It's a difficult situation to be in.  Dave actually noted a blog post by the company that his original advisory targeted, 37signals, where they discuss how to say no to a feature request.  From the 37signals blog post:

    1. The Hard No. If the feature is not aligned with the direction of the product, just be direct and say so.
    2. The Soft No. If it is something you might pursue in the future, but you don’t want to commit, say: thank you for the idea, we will consider it for a future version.

Interesting.  So Dave got a soft no and a hard no (in the form of ignoring him) from the 37signals guys.

This is a problem.  This is NOT an acceptable way of handling a vulnerability.  I got to thinking the other day of how vulnerabilities should really be handled by a company.  The problem of course is I'm saying how the companies should handle them, and I have no authority at any of these places, save people actually valuing my ideas.  Personally, I've done some development in the past, and there was the concept of defects.  Your bonus would depend on how many defects were in your application at delivery time.  These were feature-based defects, but shouldn't vulnerabilities be considered defects as well?

Many companies out their count security as one of their business objectives, well, time to step up.  Count vulnerabilities as defects.  Programmers understand that for sure.  Of course, you can't leave it all on them, because secure code development is not exactly taught in school (even today unfortunately), so go out and get them some training.  Give them some lead in time to understand security vulnerabilities.  Create a Secure SDLC process for your company that guides direction.

You know what?  Be progressive.  Don't just ding your developers for defects (security vulnerabilities), reward them handsomely for extended time periods without flaws, security assessments that point out no flaws, etc.

Just my thoughts, but something has to change.


[poll id=8]

Topics: Browser, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • It does work!

    Hi Nate,

    I couldn't agree more! We changed our approach to application security around 1 year ago and one of the core changes was that security is as much of a defect as a functional issue.

    It really has made a world of difference for us!
  • Writing it right is an investment.

    It might be really laborious - it might double the time it takes to produce the end result, but in an environment where security is supposed to matter, its going to be cheaper and better in the long run to have it in there from the ground up.
  • Flaws no ratings yes!

    It boils down to program goals. Thinking about it most simply: What task was the program designed to accomplish? In which case security would be an important "feature", but a feature nontheless. That being said, I strongly believe in assessing, rewarding, and supporting progams and program team members in a manner similar to that suggested in your article. Rate and enphasize security separately.
    • I disagree that security is a feature

      You see, that's actually a problem. If it's an app that does not have critical data, then maybe security can be a feature, but in the real world, this mentality IS the problem.

      Security is now a REQUIREMENT, just like any other business requirement, and therefore should NOT be treated as a feature.

  • RE: An effective way to treat Web 2.0 vulnerabilities


    It only works if management gives a damn. Not going to happen on a "features" based corp. culture. Doing it right the first time would be ideal...
    • Very true, but...

      Perhaps this article can put some thought to an organization to change their culture.

      Is this my good friend Helio Vogel? If so, hit me up sometime. I'll be at Black Hat and DEFCON this year if you'll be there.

  • RE: An effective way to treat Web 2.0 vulnerabilities

    Nate! Yes, it's Helio. I will be starting a new job on Aug.4, but I will check if defcon will be possible as it's also a networking company.

    Anyways, great blog!