Twitter knew about onmouseover flaw a month ago | Hacker News Reader

Twitter knew about onmouseover flaw a month ago

github.com

141 pointsrythie12 comments

"We discovered and patched this issue last month. However, a recent site update (unrelated to new Twitter) unknowingly resurfaced it. "

http://news.ycombinator.com/item?id=1713391

That's the second major bug in 24 hours that simple regression testing would have found.

What's the root cause of these issues? Did older test sets somehow get recovered or something like that?

It depends why it regressed. Even if the text processor library didn't regress, the dependency may have reverted to an older version somehow.

Knew and published publicly without fixing? Oops.

I'm taking this at face value admittedly, since I don't know the provenance behind this github account or even whether it is related to production code.

The code in that github account is linked directly from the Twitter open source page:

http://twitter.com/about/opensource

twitter-text.gem - Text processing routines for Tweets.

Since twitter does contribute to open source software, it is highly likely that the source is related closely to production code.

Actually maybe the attacker was watching commits in github and spotted an XSS fix :) Free vulnerability!

Made me wonder about a similar fix 2 weeks earlier:

http://github.com/mzsanford/twitter-text-rb/commit/c5bb5d45f...

It seems they fixed it by now so I can't check.

They were also told about this a while back:

http://www.davidnaylor.co.uk/massive-twitter-cross-site-scri...

Not quite the same flaw but very similar - caused by unescaped URLs

I wonder to what extent not fixing it in the production version was a "conscious" business decision, and to what extent it was just overlooked.

And my extremely cynical side would like to point out that that by many measures this incident benefits twitter as a company; they get free headlines, they are seen publicly fixing a problem in a timely manner, and they get more loyal followers. Not that there is some machiavellian plan at work, but there may be reasons beyond time poverty and careless software engineering that explain why something like this might not have been fixed even though some people may have been aware it was broken.

I'd bet against this being a strategic decision to allow this exploit to remain in the wild. They've already managed to build a popular business around convincing people to trust clicking obfuscated URLs from people they don't necessarily know. I highly doubt they'd trade free press in exchange for unleashing a self-propagating JavaScript exploit on their own network.

I don't think it's that conscious, it's just that the cost of preventing such incidents is perceived to be greater than the cost of responding to them after the fact. It's worked quite well for Microsoft, Oracle and others to be reactive rather than preventive. And as I pointed out above, there are incentives for that sort of behavior that do exist.

http://news.ycombinator.com/item?id=1713404

Reply on news.ycombinator.com