

Twitter knew about onmouseover flaw a month ago - rythie
http://github.com/mzsanford/twitter-text-rb/commit/cffce8e60b7557e9945fc0e8b4383e5a66b1558f

======
Anon84
"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>

~~~
jacquesm
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?

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

------
kingofspain
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.

~~~
barkingcat
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.

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

------
vanschelven
Made me wonder about a similar fix 2 weeks earlier:

[http://github.com/mzsanford/twitter-text-
rb/commit/c5bb5d45f...](http://github.com/mzsanford/twitter-text-
rb/commit/c5bb5d45fbf5f17c6788334af4346a7ce5e0c719)

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

------
rahoulb
They were also told about this a while back:

[http://www.davidnaylor.co.uk/massive-twitter-cross-site-
scri...](http://www.davidnaylor.co.uk/massive-twitter-cross-site-scripting-
vulnerability.html)

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

------
olefoo
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.

~~~
uptown
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.

~~~
olefoo
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.

