
Massive Twitter Cross-Site Scripting Vulnerability - byrneseyeview
http://www.davidnaylor.co.uk/massive-twitter-cross-site-scripting-vulnerability.html
======
thorax
Just a public service announcement-- for those of you looking to validate your
own site for XSS exploits, you'll find that this list is particularly good at
giving you "problem" strings to test against:

<http://ha.ckers.org/xss.html>

We honestly thought we secured XSS with common libraries on every field for
one of our sites, but we paid a contractor to go through and use those strings
in various unexpected places and they found a few special and unobvious spots
that fell between the cracks.

Don't think you're immune just because you use all the right frameworks and
input sanitation tricks. Even the best web developers are going to mishandle
things from time to time.

If you think it's irresponsible for Twitter to miss some XSS vulnerabilities,
you better be doing this testing on your sites, too, before someone else does
and calls you out on it. If you're not testing at least the easy user input
exploits, you don't really know how protected you are.

~~~
axod
This is good advice, but OTOH, I do think it's going about things the wrong
way to a certain extent.

Testing your site with certain strings isn't a complete way to determine if
it's safe or not. You should "prove" to yourself it's safe against _all_
attacks. Not just the ones you know about.

Definitely worth trying the "problem" strings as a simple sanity check though.

For example js code:

a). myNode.innerHTML = someUserInput;

b). myNode.appendChild(document.createTextNode(someUserInput));

It's clear from the source that a) is vulnerable, whilst b) is not. I think
programmers just need to be trained to have massive alarm bells go off in
their head when they see some external string used in the output/markup in an
unsafe way.

~~~
thorax
My point is exactly yours, but with added testing:

    
    
      * Do the Right Engineering(TM) to guarantee no XSS
      * Followed by having someone else confirm your certainty.
    

If you only do the first step, I'm nearly certain your site will eventually be
vulnerable simply because we're all human and it's so easy to make mistakes in
user input handling.

Otherwise you can wait until someone else proves that you missed something
(using similar easy tests). Maybe they'll be nice people who will tell you
about it. Maybe they'll be mean and will make you look like a fool publicly.
Or maybe they'll be evil and exploit your users without you ever finding out.

Trust, but Verify.

~~~
axod
Sure, point taken. I just wanted to emphasize the first ;)

------
stephenjudkins
I would assume Twitter is using conventional ERB templates since their front
end is written using Rails.

The ERB templates used by rails don't escape HTML by default--you have to
write <%= h user_provided_value %> instead of <%= user_provided_value %> to
mitigate cross-site scripting attacks such as this. It's pretty easy to miss,
even if you know you should always escape user-provided data.

Django's template engine, for instance, automatically escapes strings (though
I think this can be disabled). To not escape HTML, you must either specify it
or a method producing said string can mark it as "safe".

Though ERB is great in that it's incredibly versatile--we use it to generate
several types of configuration files--I would very much prefer for it to
escape HTML by default when asked to render a string in the context of an HTML
page generated by a Rails app. Form helpers and methods such as "render" could
be modified to mark Strings that contain HTML you wouldn't want escaped as
"unescapable", much like Django does.

The way it works now invites problems like this, even from competent
programmers.

~~~
grandalf
I think Rails 3 does escaping by default, no?

~~~
al3x
They're working on it.

------
tdavis
Such blatant incompetence astounds me. They can't even validate a field when
they know the exact format of the content it should contain?

~~~
al3x
See my other comment. The engineer who wrote this code did take the time to
validate, but his validation was incorrect.

Call it "blatant incompetence" if you like, but I'm guessing you've written a
buggy validation or regex once or twice in your life.

~~~
blasdel
Except that using validation at all in this case is a mistake, especially
writing it yourself for a narrow case, much less using regexes to do it.

Escaping, damnit.

~~~
al3x
Yes, I agree. That's why we've tried to assist Rails Core in reviewing a more
comprehensive string tainting model. I've said for some time now that security
needs to be institutionalized in frameworks in order for developers to be
unable to make stupid mistakes like this one.

------
al3x
A fix for this is being deployed as I type.

For those interested in the details: the vulnerability was caused by
inadequate invalidation of URLs submitted by users when registering OAuth
applications. There was a validation routine on those fields, but the very end
of the regex used in that validation allowed any number of arbitrary
characters. The test coverage included a variety of invalid URLs, but none
that simply put a space after the URL and started a <script> tag.

Just goes to show that you can validate, test, and still not be safe. It took
another set of eyes to catch this one.

Unfortunately, the publisher of this blog post did not responsibly disclose
the vulnerability to us in advance. We found out about it through other
channels.

We would have had the fix live earlier, but as several people noticed in the
comments, we had a brief outage.

~~~
mrkurt
It's odd that you count completely on validation to catch problems like this,
rather than escaping the output as well. Writing regex validations to prevent
malicious input seems like a seriously error prone thing to be doing.

~~~
qeorge
Agree. Not trying to give you guys a hard time, but Twitter has had several
vulnerabilities caused by unescaped user supplied data being output without
sanitization.

Obviously I'm on the outside looking in, but IIRC rendering user pages is not
particularly taxing on Twitter, to the point that they aren't cached. Would
adding a simple sanitization routine have significant impact?

------
raghus
Twitter seems to be down now (1:45 PM Pacific)

~~~
TrevorJ
Yep, it's 503'd for me at the moment. Just thinking of all those poor people
who now have news and no place to post it.

 _Edit_ Looks to be back.

------
ashishk
if this is true, i hope they fixed it by now.

------
defied
Good thing this did not end up in the wrong hands or we might have ended up
with a giant Twitter Worm :)

~~~
axod
How do you know we haven't had one already? :/

------
onreact-com
It still works: <http://news.ycombinator.com/item?id=786924>

