Day 6: Why can’t you fix an XSS in less than a week?

By | February 7, 2011

In Day 4 and the first success I wrote about how 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 and 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 which so far has been the slowest of the slow. Issue was reported in April 2010. A competitor fixed a less serious XSS where CSS was injected in a matter of days.

In late September of 2010 I notified the most expensive (150mill DKK) web site in Denmark about a vulnerability caused by including an untreated input variable into a JavaScript section:

<script type="text/javascript">
	 var searchWord = "";alert(/xss/);""; 
	 var numberOfHits = "0";

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 ;)

Of public web sites I think I can only claim a single success so far, and that’s They have taken more than 1 months (they are the exception I mentioned in the introduction) to fix their untreated JavaScript variable and they didn’t do anything until I also reported the issue to For a couple of weeks the fix was to disable search completely!!! Seriously was it really that difficult to fix? And why take the search down? Did someone exploit the vulnerability? Anyway thanks govcert for motivating DSB to fix the issue.

Yesterday I mentioned 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 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.

Todays TLD is pn

Famous from Mutiny on the Bounty Pitcairn Islands is also last on the list of countries by population.

Todays disclosures

3 thoughts on “Day 6: Why can’t you fix an XSS in less than a week?

  1. Philip Tellis

    A friend of mine who does contract work with some .dk sites tells me that they don’t have much interest in security. Whenever he’s brought up the issue, the response he gets is something to the effect of: “why would anyone do that? it’s not nice. people are good and don’t do bad things.”

  2. Pingback: Tweets that mention Day 6: Why can’t you fix an XSS in less than a week? « Ugens udflugt… --

  3. paranoid Post author

    It’s a similar message I have got from a few start-ups. It reinforces my opinion that the internet would be a better place if some of these problems had been solved in the languages/frameworks a long time ago.

Leave a Reply

Your email address will not be published. Required fields are marked *