Security Company Says NASDAQ Waited Two Weeks To Fix XSS Flaw 61
alphadogg writes "A Swiss security company said the NASDAQ website had a serious cross-site scripting vulnerability for two weeks before being fixed on Monday, despite earlier warnings. Ilia Kolochenko, CEO of the Geneva-based penetration testing company High-Tech Bridge, said he repeatedly emailed NASDAQ and warned of the XSS flaw. 'I can basically say I have spammed them,' Kolochenko said in an interview. A NASDAQ spokesman did not have immediate comment. NASDAQ.com lets users create accounts and build a profile to monitor stocks and news."
Who cares? (Score:5, Insightful)
So, it's the NASDAQ website. Who goes the NASDAQ website? You can't trade stocks there. Financial information was not leaked, so BFD. This is fairly common on any website. Sounds to me like a single security research got butthurt because they didn't acknowledge his finding quickly enough.
Re:Very difficult. (Score:5, Insightful)
For the unaware: this is serious sarcasm. Fixing XSS is usually pretty trivial; just apply output encoding (usually HTML entity encoding, but there are other valid approaches) to the user-supplied data before reflecting it into the page. Even in weird edge cases, like where the user is explicitly allowed to insert their own HTML (Slashdot, for example) you can get around the problem by whitelisting certain elements and parameters, and rejecting (or removing, though this must be done carefully) anything which doesn't conform. It's A long-ago solved problem that some people still have incredible difficulty with.
Doing security work myself, I've seen XSS fix times ranging from "within the hour" to "three weeks or so", and the median is probably about two days. I always wonder what the hell is up with the companies on the long end of that scale.
Re:NASDAQ web site != NASDAQ trading system (Score:3, Insightful)
good process is not trivial (Score:2, Insightful)
Its called process.
Product Owner is sent notice of vulnerability.
Operation or QA tries to reproduce the issue.
Upon confirming the vulnerability, Product Owner tells business analyst and dev. manager about issue: change request is created.
Dev team picks up ticket, and does more analysis.
Geek reproduces issue locally.
Geek writes failing, automated test that reproduces the error.
Geek fixes error, automated test is passing.
Geek has code reviewed by team members, and probably infosec.
Geek hands code off to QA.
QA checks first does a check to see the vulnerability, then tests that code is really fixed, also validating that Geek's script isn't broken. Then does regression test to make sure that code isn't broken.
QA schedules time with operations to meet and discuss deployment plan.
Code is deployed to stage environment and tested some more.
Operations then deploys the fixed code.
Re:Sounds like a fast response... (Score:5, Insightful)
No, taking the time to
(1) evaluate the problem,
(2) determine the best approach for a fix,
(3) weight the time commitment against any other critical activities going on,
(4) assign the best person to code it,
(5) review the code,
(6) rebuild and deploy it up through various testing environments,
(7) test the hell out of it in each environment, and
(8) deploy it into production
in a mere 10 work days is excellent, given the importance of the system. That's what Enterprise System timelines are often like.
If a major financial system like NASDAQ had managers run into the developer area and shouting "ZOMG someone fix this and slam it into Production now now now!", then I'd be more concerned.
Re:Sounds like a fast response... (Score:4, Insightful)
There is such a thing as too much process, this would be an example.
Besides all those steps should take a couple days tops.