Web 2.0 Vulnerability Reporting Continued

Dave G. | June 25th, 2008 | Filed Under: Industry Punditry

37signals had an interesting blog post entitled “Ask 37signals: How do you say no?”. The post advises readers on how to respond to feature requests that you are not interested in pursuing (at least in the short term). The short synopsis is to answer in one of two ways:

  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.

For the Soft No, they gave a quick example of language to use:

“Thanks for sending the suggestion over. While we can’t guarantee we’ll be adding this feature, we can promise you we’ll review it and possibly consider it for a future version.”

About a year ago, I posted a tidbit about reporting a security issue to a vendor who didn’t seem to take the issue seriously. Here is how they responded:

“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.”

As you can probably guess, 37signals was the previously anonymized vendor. After getting the Soft No, I had two of my emails ignored, one on May 21, 2007 and one on June 6, 2008.

Some memorable comments from our readers include:

“What we need is disclosure 2.0 guidelines for web 2.0 software. Dave did the right thing by informing the software company. The software company did the wrong thing by treating this as a bug. Perhaps there should be a “hall of web 2.0 shame” for companies that don’t fix vulnerabilities reported to them in a timely way.” — chrisw

“This company didn’t treat the vuln report as a bug. They treated it as a FEATURE REQUEST.” —tqbf

“Those of us who tend a little more towards the punitive end of the spectrum would tend to say that at this point, you name the company (if not the vuln.)” — Ryan Russell

“So maybe you should “vote with your wallet” and look for an alternative application. If you don’t consider the vulnerability serious enough to not use the application, why should they think it is serious enough to expend resources to fix?” — stacy

“Try contacting their funding source or, better yet, their lawyers. These days, those folks understand the words “risk to brand”, etc.” — Money and Lawyers

Vulnerability reporting should not be handled in the same way that you manage feature requests.

Treat them as defects that get in the way of your users utilizing your software. For example, this flaw isn’t so serious that we wouldn’t use the software at all, but it is serious enough that we had to limit how we used the software. From a technical perspective, it is downright boring and unimpressive. I am not interested in revealing the details of the flaw, I am simply interested in getting it fixed.

I have the utmost respect for 37signals both as a business and as professionals that engage, influence and contribute to our community. The goal here isn’t to put users at risk or to make 37signals look bad, but rather to get a better understanding about how our vendors manage security issues (e.g. Are there other security issues that aren’t getting addressed?), get a timeline of if/when it will be fixed, and hopefully to raise awareness about how organizations can better manage security vulnerabilities.

Viewing 13 Comments

    • ^
    • v
    Some organizations classify bugs by category (typically more feature-driven); others by severity. It's important to know which model they work with if you're going to get anywhere with them.

    If you are limiting "how" you use the software, then it sounds like a workaround exists -- and therefore the criticality of the bug is lower. Most critical bugs are seen as interrupting work, cause data to be inaccurate/incorrect, or cause crashes/freezes. Bugs that destroy, change, or conceal data should technically be lower on the list to fix than the above issues. Again, your problem limits your use -- but does not prevent it.

    I prefer to find ways to explain how the bug affects cost, as bugs with `$' priority are obviously considered more critical. If you can explain it in dollars, then you're more likely to see a quick turnaround on the issue.

    I wonder if you would be more successful at trying to make waves with one developer. Buy them a copy of `Ajax Security' or `Hacking Exposed Web 2.0'. Demonstrate a worse bug in a similar/competitor application (in a generic way if possible), and how it affects your decision to use that application. Of course, if you can somehow show that having a more defensive strategy is also a competitive advantage, then it's an easier sell.

    I don't know what else to say. Web 2.0 is moving so fast, and in a word where, "Don't worry, be crappy" is the motto for success, we're all at a loss as to how to explain the advantage of securing these sorts of applications.
    • ^
    • v
    It's hard for me to understand how any company could treat a potential threat to their customers as "yet another feature request." If I went to my car maker and said, "I'd really like more cup holders in the next model", a "soft no" would be appropriate. If I said, "According to my research, my car, and all cars like it, will catch on fire and explode", they would pay more attention. And if they didn't, then someone else -- the government, consumer advocacy groups, etc -- would. How this doesn't apply to the software world is beyond me.
    • ^
    • v
    why was a reply accepted that recommended a book in the hacking exposed series?
    • ^
    • v
    Because we don't moderate comments, which is also why yours was accepted.
    • ^
    • v
    Also, totally not the same book or even remotely related, but I really like "The Web Hackers Handbook", even though it does have the word "Hacker" in the title, and "Hack the planet" on the back. Good for taking on the Gibson.
    • ^
    • v
    @some loser:

    Hi Frank!

    No doubt there are at least two or three good paragraphs in Hacking Exposed Web 2.0. I'll find a torrent somewhere and get back to you.

    @the topic at hand:

    This is why for public web apps folks end up disclosing eventually. I agree with Andre that another potential route might be to get the VC and other influential folks up in arms.
    • ^
    • v
    I think we can all agree that vendors misinterpreting vulnerability disclosures as feature requests and then giving a "soft no" on them is pretty universal :-(. I had a NAS vendor do it about 10 times in a row to me a few months ago. I organized the masses on their support forums into believing the company didn't care about security and then there were enough feature requests to push it through :-D.
    • ^
    • v
    What you are encountering is structured indifference to security issues reported by researchers. Specializing staff and process to vulnerability reporting takes time and money - and with the barebones support teams that many Web 2.0 companies have, it's going to be the same people handling the problem at the end of the day. So why specialize your response to security reports that aren't incidents?

    You might reply, "Because it might result in an issue at some point?"

    Give the product management a choice of (1) adding a new feature that generates revenue or keeps an existing customer happy, (2) making the product more stable, or (3) fixing a security bug that probably hasn't been exploited and they will choose (1) or (2) every time.

    Until... an incident occurs. Then they may re-evaluate their approach to risk management and the importance of security. However, my experience is that you have to be burned before you stop dancing in the flames.

    We hope that people will be proactive and that lessons will be learned as the industry progresses. I have seen individual developers and managers at Web 2.0 companies who have stealthily injected code security programs and threat modeling in their applications without making too big of a fuss or creating too much overhead. Cheers to them.

    Software 1.0 companies are still going through this realization now - why would we expect Web 2.0 companies to be there already? I can name several vendors of large enterprise products that still only accept security vulnerability reports via a customer support portal (only with authentication and support contract in place even).
    • ^
    • v
    A factor not usually discussed lies in the ability of the individual who receives the message. For them to classify 'feature request' in place of 'security problem' speaks volumes.

    --hsm
    • ^
    • v
    Hugh --- yes. YES. Spot on. This was so easy for them to get right. Nobody needed them to cut a dot release or even schedule a fix on the spot. We just needed a human being to say "we know what a security problem is, you are (right|wrong), and we will get back to you with a status update when we figure out how to handle it".

    Their response in this case was *literally* "we can't help you".
    • ^
    • v
    I like to think of it in simpler terms. Most all companies learn through pain to properly deal with vulnerability reports.

    Pain. Is there anything it can't do?
    • ^
    • v
    if you dislike the status quo then disclose details already. this is the surest way to get the vulnerability fixed. what could be more responsible than that?
    • ^
    • v

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus