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.
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.
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?
Yeah. "We let Twitter (via Kevin Rose) know about this before it went live but we think somebody saw the Test!" is a total numbnuts disclosure policy.
If one finds a vulnerability, follow the rfpolicy[1] or similar. Send an email to security@example.com, not Kevin Rose. (Seriously—Kevin Rose? What the hell does he have to do with Twitter's security response team?)
I agree that it was irresponsible for him to use his knowledge and disclose a vulnerability to the public before giving a heads up to the entity in which the vulnerability impacts. Infact, I am for non-disclosure of vulnerabilities due to the fact that this is how script-kiddies thrive.
I go a step further and assert that due to his marketing background, he used this stint for his own marketing purposes - I guess this can best be summed: to each his own.
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.