XSS Twitter in minutes; Why you shouldn't store important data with 37signals

http://brian.mastenbrook.net/display/36

by antonovka • 17 years ago

156 60 17 years ago

brian.mastenbrook.net

snprbob863• 17 years ago

For all the horrible, terrible, awful things about Internet Explorer (namingly: standards support and UI) ... they are innovating heavily in security: http://www.microsoft.com/windows/internet-explorer/features/...

tsally6• 17 years ago

Microsoft is actually decent at security now. The AV they released for free was actually on par with a few commercial products out there (all AV at the moment is pretty bad though, if you're curious). The really difficulty with Microsoft and security is countering their reputation for bad security that they earned over the past several years.

snprbob863• 17 years ago

That's because Microsoft is good at anything that they throw resources at. Unfortunately, we haven't thrown enough resources at determining what to throw resources at.

tptacek13• 17 years ago

Where by "decent" we mean "leads the industry in". =)

oink• 17 years ago

You found a security exploit, feel special. Finding an exploit isn't a voucher to rant against the people responsible for it. The bottom line is that nobody can be 100% sure that their data is secure after they've put it in the hands of a third party.

bmastenbrook• 17 years ago

I think my point was a lot more nuanced than you give it credit for.

pvg4• 17 years ago

There's an interesting tangent towards the end -

"Web application security is still an immature field, and many of the layers are sufficiently poorly designed that issues like this will pop up for a good long while. Just like buffer overflows have been a weak spot for C security as long as the Internet has been around, escaping issues will continue to be a weak spot for web security for as long as we're afflicted with this particular architecture."

It seems like a field not only in its infancy but also oddly unglamorous and under-reported. There's no repository (that I know of, at least) of vulnerability reports of major web apps, for instance, yet it's easy to look up an exhaustive history of Flash vulnerabilities down to the seventeenth decimal sub-version. And yet the various XSS/CSRF/etc vulnerabilities are easily as dangerous and as exploitable. Twitter's dreams of a billion users and a new internet were not exposed by a buffer overflow, after all.

pvg4• 17 years ago

The author did not claim anybody can expect or provide 100% security. The write-up was (among other things) about something more important - how do companies respond when presented with an important security issue. 37signals responded fairly poorly and that's useful information. Interestingly, this is not the first report of a somewhat strange attitude they seem to have regarding possible exploits -

http://evilpacket.net/2009/jul/9/basecamp-one-wrong-click/

Adaptive• 17 years ago

I didn't read the post as a rant at all. If anything I think that the author has articulated an important factor in evaluating any third party provider's security infrastructure: attitude.

laktek• 17 years ago

Can someone help to compile a good security policy and guideline for web apps?

I guess every web app should have a page dedicated to security similar to privacy policy and terms of service.

What are the essential information should go there? Special email dedicated to report security issues? PGP key to encrypt emails? and What else?

lupin_sansei• 17 years ago

Don't trust any data that comes from outside your app (urls, querystrings, http request headers, databases, files) and you'll be right.

Perl's Taint Mode enforces this automatically. Don't know if any other languages have it? http://www.webreference.com/programming/perl/taint/

jrockway2• 17 years ago

I don't think taint mode is helpful for this. All data comes from outside of your program, but you somehow still have to display it. As we've seen recently, this is hard to get right. Escaping HTML is one thing, but what if you want to let a user type in a URL? Make sure to exclude javascript: URLs. Even if you whitelist only "http://... URLs, how do you know that a browser bug won't allow an attacker to inject JavaScript, compromising any account used by a user of that web browser?

Basically, web browsers need taint mode. The programming language that produces the web page is a whole other issue.

ewiethoff• 17 years ago

IIRC, Ruby lets you set taintedness Safe Levels with the -T command-line option or setting $SAFE per thread.

mncaudill2• 17 years ago

I read through the code, but I don't really know Ruby that well, so I'm not 100% sure of what the exploit was.

Looking at the patch, it appears that their "check for UTF-8" function wasn't perfect. Is this correct? If so, how is this exploitable?

antonovka3• 17 years ago

As I understand it, Rails' string escaping would treat an invalid byte sequence (eg, 0xFF, 0x1C) as a single multi-byte code point, and thus not filter it, even though 0x1C (which is '<') should have been escaped.

The browser, however, would correctly treat 0xFF as an invalid initial byte, and then interpret the next character point, 0x1C ('<') independently.

So, you could pass arbitrary characters through Rails' string escape functions by prepending an initial invalid byte sequence, and thus cause the browser to interpret arbitrary JS/HTML.

mncaudill2• 17 years ago

Thanks for the response. That does make sense.

tptacek13• 17 years ago

I'm usually the first person here to jump to 37s' defense. I know some of their people, they're hometown heroes, and I use and like their products.

This is hard to defend, guys.

It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them.

If you're selling accounts on a web app, you need:

* A security page * With a PGP key * And an email contact * of someone who will write back * who knows what a security vulnerability is * and who will write back quickly.

That's it. Do that, and you're not a punch line. If someone dumps zero-day about you onto Twitter, you're already two steps ahead in the PR war, because you had a reasonable process, and the researcher ignored it.

Bonus points --- things that are trivial to do, but that nobody's even asking you to do:

* You can assign special issue numbers to vulnerabilities, to make the researcher feel like an XSS disclosure isn't the same thing as a bug in your online help.

* You can thank researchers privately, and let them know that you'd really like them to keep disclosing thing to you --- you could even give them (wait for it) a phone number.

* You can do what every vendor with a real security team does, and keep a public web page thanking people who have discreetly disclosed vulnerabilities to you.

Manfred2• 17 years ago

Actually it's pretty easy to defend.

I never used to have travel insurance but after my first intercontinental flight my suite-case broke and I learned the importance of having one.

In a perfect world your support team would be able to distinguish between someone rambling about bytes and an actual security issue. That's hard without a lot of technical knowledge.

I believe that's why the Rails security team responded rather quickly and 37 Signals support team didn't. I'm sure they will do better in the future.

tptacek13• 17 years ago

The problem isn't that 37S tech support doesn't know how UTF-8 works. The problem was that security reports were routed to tech support in the first place. Again, the solution to this problem is a single web page with just a couple pieces of information on it.

pvg4• 17 years ago

It would be easy to defend if being an airline passenger is even vaguely analogous to being an application service provider who charges money and promises you your data is secure -

http://37signals.com/security

Compare this to what your airline likely promised you in the event of damage to or loss of your luggage -

http://en.wikipedia.org/wiki/Warsaw_Convention

nikc• 17 years ago

its more like finding out the airline doesn't have insurance after a plane crash.

ericwaller• 17 years ago

Sorry if this is a stupid question, but why the PGP key?

akirk• 17 years ago

So that you can send your information to them encrypted via e-mail. For example if you have to provide sensitive information to reproduce the problem.

imbriaco• 17 years ago

You're exactly right, Tom. We dropped the ball on having the security@37signals.com account setup before this issue so reports went to our normal support team. A specific email address with an associated GPG key has since been added to our security page and there is a person who is tasked to respond. This was added on August 23rd when the problems with the process around the previous XSS problem were discovered.

jrockway2• 17 years ago

I think what we've really learned from this is that the current JavaScript security model is not good for what people are using the web for these days.

We really need something like a "<without-scripts>" block, where anything inside could never use JavaScript (including links that are to javascript: URLs). This would make life a lot easier for web developers.

antonovka3• 17 years ago

Then XSS attacks would insert </without-scripts> before <script></script> =)

What we need is literal separation of control statements (eg, <script>) from content such that neither can be easily misinterpreted, but that would be a significant departure from existing design.

tptacek13• 17 years ago

That shouldn't work for the same reason that you can't escape a bound SQL query parameter in a pre-parsed query.

tlrobinson• 17 years ago

Ironically applications that bypass HTML entirely and use JavaScript to build up the DOM (e.x. Cappuccino apps) are largely immune to XSS attacks (as long as you avoid innerHTML and such)

Manfred2• 17 years ago

It's probably better to disable the JavaScript engine based on certain heuristics, for instance when there is invalid character encoding in attributes.

tptacek13• 17 years ago

That won't work, because too much "safe" user-controlled content will contain invalid utf8.

jeremykemper• 17 years ago

Brian, I'm on the receiving end of security@37signals.com and @rubyonrails.org. I read your post with great dismay, to put it mildly. You're understandably pissed: we whiffed on our response to you by changing venue to Rails security without keeping you in the loop.

This is my fault. I identified it as a Rails issue and requested that you forward your findings to the Rails security team so we could investigate in concert.

Craig here at 37s narrowed down a root fix with Michael, Rails' security ombudsman, who then enlisted Manfred's help to track down and repair the root cause. What you see today is the end result of those efforts. The security process worked, but you only saw the Rails arm of it. The apparent 37signals arm of it amounted to runaround. Completely not OK.

We now have a security-only email and PGP key at http://37signals.com/security. Next time, no runaround.

moomins• 17 years ago

There are still a couple of issues Brian brought up you haven't addressed.

The main one being the hubris of the copy on your security page. Declaring users data to be uncompromisable then justifying this by listing mostly physical restrictions to the datacenter seems to ignore rather the larger security issues for web-based applications. A firewall and latest security patches do not make one immune.

His other peeve seems to be the perceived bullshit of your support team saying they replied to his initial complaint when it appears (at least to him) that they had not, then putting the blame for this on his spamfilters.

jasonfried• 17 years ago

I can assure you we're looking into this entire busted chain of communications. The way this was handled (by us) was completely unacceptable. I am not a happy man this morning.

We will make this right.

tptacek13• 17 years ago

He addressed your second point, and your first point isn't reasonable. Product "security" pages don't need to read like SEC disclosures.

Compare their security page to:

* http://www.salesforce.com/company/security.jsp

* https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/Marketing/g...

* http://www.apple.com/macosx/security/ (heh)

* http://www.webex.com/pdf/wp_security_overview.pdf

* http://www.netsuite.com/portal/infrastructure/main.shtml

Don't ask 37s to meet a standard that nobody else meets. It's just muddying the real issue, which they're clearly trying to address.

This comment, btw, isn't about 37s. It's about the singularly bad advice that web startups should have a fully-transparent conservative "security" page that talks about cross-site scripting and CSRF attacks, when their competitors have pages about "state of the art firewall security". To normal people (ie, customers), the "state of the art firewall security" people sound like they know what they're doing.

ashleyw• 17 years ago

@tptacek:

Second Google result for "apple security": http://www.apple.com/support/security/

cpr• 17 years ago

Funny, but I've always thought the 37signals team was bipolar.

On one hand, they're pretty much "our way or the high way" about any support concerns/feature requests.

But, once caught out in public about any issue, they're all over it.

I suggest a very strong dose of self-administered humility for their founders would go a long way. That doesn't mean being un-opinionated; it just means being realistic about human nature and its vagaries as it applies to themselves.

XSS Twitter in minutes; Why you shouldn't store important data with 37signals

Related Stories