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.
send9
· 1 year ago
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.
some loser
· 1 year ago
why was a reply accepted that recommended a book in the hacking exposed series?
Thomas Ptacek
· 1 year ago
Because we don't moderate comments, which is also why yours was accepted.
Thomas Ptacek
· 1 year ago
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.
Statler and Waldorf
· 1 year ago
@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.
Dan Guido
· 1 year ago
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.
cscott
· 1 year ago
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).
Hugh S. Myers
· 1 year ago
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
Thomas Ptacek
· 1 year ago
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".
Ryan Russell
· 1 year ago
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?
drrr
· 1 year ago
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?
All Comments
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.
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.
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).
--hsm
Their response in this case was *literally* "we can't help you".
Pain. Is there anything it can't do?
BURSA SOHBET
ISTANBUL CHAT
ISLAMI CHAT
IZMIR CHAT
ANKARA ARKADAS
ALMANYA CHAT
TURKEY CHAT
MYNET
SITENE EKLE
VIDEO KLIP IZLE
YEMEK TARIFLERI
VIDEO MUSIC