In Day 4 and the first success I wrote about how Yubico.com responded and fixed the vulnerability I found in their web site. I have had other site owners respond and fix vulnerabilities. The vulnerabilities which have been fixed have all (1 exception) been fixed in less than a week. Receiving an externally reported security flaw caused the organization to execute a number of tasks as listed below. With that in mind 1 week is a reasonable upper bound.
Upon receipt of an externally reported security flaw the organization first need to find out who can handle the notification. Then they need to verify and if they so desire acknowledge to the reporter. Next is to asses the risk for the site and their users. Figuring out how to prevent the vulnerability without impacting the site is the next challenge. If the site isn’t filtering any data at all, it could be a non trivial task to implement filtering (this is probably why I frequently see corners has been cut, let’s save that for a future post).
Once a solution has been implemented (I assume all security bugs needs to be fixed) it has to go through the release process. A decision has to be made if they want to wait for a scheduled deployment or if they deem security important enough to deploy out of schedule. This part also depends on how agile the whole process is. Companies like flickr.com and etsy.com believes in continuous deployment, they would have no problem fixing a reported security problem in less than a day (depending on the complexity of the code change). While other companies may have bi-weekly or even rarer deployments. The latter companies would not cope well with an emergency push.
Lots of steps which apparently can take anything from less than a day to up to 9month (and counting). Today I am going to look at sites which has taken more than 1 week to handle a reported issue.
I already mentioned find.dk which so far has been the slowest of the slow. Issue was reported in April 2010. A competitor degulesider.dk fixed a less serious XSS where CSS was injected in a matter of days.
A search for “;alert(/embarrassing/);” trigger a “nice” alert dialog. 4 months later and the vulnerability is still there. I have reported this a couple of times to the site owner, the department for environment and trough other channels. I can only conclude that they have no intentions of fixing this issue. I had hoped government sites would lead the way. Perhaps they are just not in the direction towards making the web safer. If it’s any hope then all the web sites under the umbrella of the department for environment has the exact same vulnerability. That’s been reported 2 months ago, I have an automatic response to prove it
Yesterday I mentioned acm.org and their problem. They have been notified in October 2010 and nothing has happened, except perhaps they have taken a decision to not fix the issue. For a highly regarded association of computer professionals I expected something much much better than nothing.
In October of 2010 I let Reuters know about an XSS vulnerability in their search page. I don’t know exactly when they fixed it, because they have never engaged in any communication. Then in November 2010 I rechecked and found they had fixed the issue. I concluded they are able to read email and that they understand the importance of security. At the same time I noticed (and reported) another XSS, this time on their https “protected” commerce login page (for the paranoid here is a screen dump). Don’t let the little https lock icon in your browser to make you feel safe, it’s not going to help against XSS. Reuters have known about this issue since November 2010. More than 2 moths later it’s still not fixed. I think *face palm* is appropriate here. If you have connections inside Reuters tell them to fix this immediately.
If a site is serious about it’s brand and users, a security policy should be an integral part of the strategy for that brand/site. The security policy should amongst a lot of other items include how to respond to and handle external reports. Internally as well as externally reported and confirmed vulnerabilities should be handled in less than 1 week. A vulnerability reported on an https protected login page should make every developer drop whatever they are doing and start working on remediation. Reuters are you listening?
Todays letter is y
28 y’s one of them is found in safeway.com. They have a fun little onmouseover triggered XSS. Safeway automatic response claims they appreciate my business but other than that I haven’t heard anything.