Hi Joerg & all, (I just subscribed by mail to this list, but I'm replying here by GMANE, so hopefully everything will do the Right Thing.)
I'm one of the maintainers of storm.debian.net, along with Clint. Moreover I'm one of the upstream authors of Sandstorm. Thanks for being willing to try something I've been working on. On Fri, 23 Oct 2015 09:57:50 +0200, Joerg Jaspert wrote: > On 14102 March 1977, Laura Arjona Reina wrote: > >>> The main point that makes it entirely unusable is its usage of a new >>> subdomain for serving the javascript FOR EVERY NEW REQUEST. This is >>> beyond stupid and disallows any kind of javascript blocker in your >>> browser, unless you allow it to trust the whole debian.net domain, >>> which is way too far fetched. >> I understand. Would adding storm.debian.net to the white list do the >> trick? >> I've done it in my Iceweasel with NoScript and it seems to work but I'm >> not totally sure. > > Only if JS gets served from there. The two anti-js things i tested for > chromium either want to trust all of debian.net for full domain, or just > the host, ie they dont want to allow "everything below this subdomain". > :/ I just tested NoScript for Firefox/Iceweasel, and when I whitelist storm.debian.net (or rose.sandcats.io, the UI for my personal install) it seems to effectively whitelist all subdomains. That isn't one of the options presented in the immediate UI, but when I go into * Noscript -> Options * Whitelist "You can specify which websites are allowed to execute scripts" * Enter rose.sandcats.io into "Address of website", then click "Allow", then click "OK" When I reload rose.sandcats.io, the dashboard works and so do all the web apps within that host. The same works for me for storm.debian.net. I can try with a Chromium-based script blocker and help provide configuration details that work for it. Which one are you using? > In any sensible setup there isnt the need for it. :/ Unfortunately I can't agree with that. You're probably familiar with the idea that each app should be on its own domain. Otherwise, apps can typically steal user cookies frome each other, and then one compromised app can exploit a bug in another one: * DSA-3338 <https://security.debian.org/security/2015/dsa-3338> - SQL injection vulnerability in graphs.php (cacti) If two apps share a domain, then one compromised app can be used to steal the CSRF token (or session ID cookie) another app on the same domain. That situation could lead to successfully exploiting bugs like this. But Sandstorm goes a bit further, with a temporary subdomain, unique to this (user, app instance, session) triple. I wrote about the security benefits in the Sandstorm docs https://docs.sandstorm.io/en/latest/ administering/wildcard/ but I can also summarize: Predictable domain names enable attacks where evilsite.com crafts POST or GET requests to the well-known hostname, which results in your browser sending a request to the well-known hostname with your login cookies for that hostname. One name for this is cross-site request forgery. Depending how vulnerable the app is, this can work even without Javascript enabled; mere IMG tags can do the job. These vulnerabilities are very common against web apps (free and non- free), so Sandstorm uses this one-time-use domain name measure as an extra hardening against them. Here are some recent Debian Security Advisories that are mitigated by the Sandstorm one-time-use domain name feature. * DSA-3346 <https://security.debian.org/security/2015/dsa-3346> - Cross- site Request Forgery - Form API - Drupal 6 and 7 * CVE-2015-3439 within DSA-3250 <https://security.debian.org/ security/2015/dsa-3250> and CVE-2015-3429 in DSA-3328 <https:// security.debian.org/security/2015/dsa-3328> - WordPress ships bundled files that created cross-site scripting bugs. Since no user knows another user's temporary, per-session, per-user Sandstorm subdomain, they can only use this to attack themselves. * DSA-3291 <https://security.debian.org/security/2015/dsa-3291> - Unvalidated redirect. Since no user knows another user's temporary, per- session, per-user Sandstorm subdomain, they can't realistically attack each other. * DSA-3241-1 <https://security.debian.org/security/2015/dsa-3241> Path traversal vulnerability allows file disclosure (Elasticsearch) - I can't tell if this requires being logged in or not, but if it doesn't require being logged in, then Sandstorm's one-time-use domain name means that an external user can't guess what hostname to use to reach the buggy app. * DSA-3227 <https://security.debian.org/security/2015/dsa-3227> - Movable Type has a format string injection vulnerability that requires knowing the hostname of the app. But Sandstorm won't give you the app's hostname unless you are authorized to access the app, so remote unauthenticated attackers can't exploit this. Those are from my reviewing Debian Security Advisories from the past 6 months or so. And there are some Etherpad bugs that Sandstorm mitigates through the per (user, app instance, session) temporary subdomains. Here's two. * CVE-2015-3297 <http://www.openwall.com/lists/oss-security/2015/04/12/2> - Read arbitrary file from filesystem - only usable by authenticated users, within Sandstorm (further mitigated by filesystem namespaces but that's a separate thing) * CVE-2015-2298 <https://security-tracker.debian.org/tracker/ CVE-2015-2298> - Etherpad will disclose a list of all pads, erasing all pad security since Etherpad's only security mechanism is secret pad names. One-time-use subdomains means that an attacker can't find the URL to a valid Etherpad instance unless they're authorized. (Also Sandstorm runs one Etherpad document per app instance so it's further hardened, but that's separate.) So I hope that helps explain why Sandstorm does that weird constantly- rotating hostnames thing. As a sidenote, I ran into the whitelisting UI problem with NoScript myself -- when I visited https://rose.sandcats.io/ (my personal server's Sandstorm interface), I was offered the ability to whitelist sandcats.io. But that's a bug in NoScript, in my opinion -- sandcats.io is a dyndns service, listed in the Public Suffix List <https://publicsuffix.org/>, so rose.sandcats.io should be what NoScript offers me to whitelist. I'll see if I can read the NoScript code and figure out if they could use the nsIEffectiveTLDService Gecko API and then present a more reasonable prompt. Hope that helps explain why Sandstorm does what it does. Let me know if I can be of further use. In particular I'd love to know what Chromium addon you're using so I can document how to whitelist storm.debian.net appropriately. -- Asheesh. _______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
