4 ms·

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 j

by dougp 17y ago

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 http://en.wikipedia.org/wiki/Cross-site_request_forgery There are lots of sites that are vulnerable to this.

there 17y ago
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.
- daremon 17y ago
  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...
- tptacek 17y ago
  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 17y ago
    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.
dpcan 17y ago
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.

by dougp 17y ago

there 17y ago

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.

daremon 17y ago
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...
tptacek 17y ago
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 17y ago
  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.

dpcan 17y ago

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.