XSS is not a feature
evilpacket.net
evilpacket.net
We now also have a dedicated email address and public key for reporting any similar issues. See http://37signals.com/security.
This is a lack of filtering of a search input on the search page, not the bug they submitted - that one included injecting HTML/JS by logged in users onto "internal" pages. Conflating the two is disingenuous, at best.
Good news is that a fix for this vulnerability -filtering the search box's inputs- will take about 30 seconds for someone familiar with the code base and ~5 minutes for a brand new intern.
other vulnerabilities would probably require that one has a basecamp account to be able to post messages to the site or something, but they allow privilege escalation and need to be fixed just the same.
37signals' response that users should be trusted is just stupid. think of a customer logging into their vendor's basecamp site, being able to take over the vendor's account and then see all of their other customers.
users (and their input) should never be trusted. even if you trust the users, you can't always guarantee that the trusted user is the one in control of their web browser.
Especially when you're still required to churn out new features in parallel.
Sounds like a customer I don't want. Money is great and all, but if a customer is going to hack my Basecamp account, then I don't want to work for them anymore.
I don't think "your users should be trusted" is a ridiculous way to look at things. Technology can't solve some problems.
It can solve this one, though.
but this is xss, not csrf/xsrf. in the video he directs the user to a search page with a query containing javascript. the javascript runs in the basecamphq scope and changes the contents of the page to hide everything else and just show the image, which presumably has an onclick or something that pulls in the xsrf token and when clicked, forces the user to change his login data.
since rails has built-in xsrf protection i find it hard to imagine a 37signals site is still vulnerable to blind xsrf attacks. if they are still allowing arbitrary javascript to run and are putting the xsrf token in a javascript variable somewhere (which is commonly needed for ajax operations that post), then the protection doesn't do them much good. they need to stop allowing arbitrary javascript to be executed.
i can't think of a good reason why they need to allow the full set of html tags and javascript to run on their user sites. they should be sanitizing all of the output and only allowing a whitelist of tags and attributes that can't do any harm.
a) csrf: Basecamp search results page could reject input that didn't originate from the respective search box. But it's useful to be able to send someone a link that will perform a search - it isn't a state changing operation after all. So everyone allows that.
b) xss: the main problem of course is that the search results page prints the search input without any filtering...
It's not a silly discussion, but it is academic. The vulnerability should be fixed.
All XSS holes are automatically CSRF holes, since XSS can be used to work around all forms of CSRF protection.
Who's to say the javascript he posted doesn't exist somewhere in the account where other members are now going to pull it up, thereby running it on their own accounts, creating a bigger mess.