Allow each tool to have its own subdomain for browser sandbox/cookie isolation
Open, LowestPublic

Description

Lots of tool labs tools are of varying quality. It is highly like that many of them have XSS vulnrabilities. I think it might be prudent to give each one a separate domain (So instead of tools.wmflabs.org/tool-name do tool-name.tools.wmflabs.org). This would make it much more difficult to steal cookies, etc from other tools, if someone got an xss (Of course this doesn't eliminate everything (see e.g. https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-zheng.pdf but it does make exploiting that sort of thing that much harder. )

I have no idea how difficult a thing this would be to do

Bawolff created this task.Feb 2 2016, 10:27 PM
Bawolff updated the task description. (Show Details)
Bawolff raised the priority of this task from to Needs Triage.
Bawolff added projects: Security-Team, Toolforge.
Bawolff added a subscriber: Bawolff.
Restricted Application added a project: Cloud-Services. · View Herald TranscriptFeb 2 2016, 10:27 PM
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald Transcript
Bawolff set Security to None.Feb 2 2016, 10:28 PM
Bawolff added subscribers: csteipp, dpatrick.

It requires a *.tools.wmflabs.org ssl certificate, but otherwise there's no technical reason why this would not be possible.

As for other (non-tools.wmflabs.org) domains -- that's somewhat more involved, because it requires more than a single new certificate. See T122403 for that.

valhallasw renamed this task from consider making individual tools on tool labs have their own domain to consider making individual tools on tool labs have their own X.tools.wmflabs.org subdomain.Feb 2 2016, 10:31 PM

It requires a *.tools.wmflabs.org ssl certificate, but otherwise there's no technical reason why this would not be possible.

As for other (non-tools.wmflabs.org) domains -- that's somewhat more involved, because it requires more than a single new certificate. See T122403 for that.

I think tools is the project where this sort of thing would get the most benefit.

The only problem would be that we already have advertised in some places login.tools.wmflabs.org, but that can be moved.

I'll put in a procurement ticket for a new *. ssl cert.

scfc added a subscriber: scfc.Feb 3 2016, 12:43 AM

I think many (most?) tools are not coded in a way that they can be served from https://$tool.tools.wmflabs.org/ and https://tools.wmflabs.org/$tool/ at the same time, and I think that is impossible to correctly automatically map one to the other (e. g. fixing absolute links in the served pages themselves as well).

So if we go down this road, webservice should have a new option --with-subdomain (or a better name) that sets a flag in the proxy forward entry and the service.manifest file and uses a lighttpd configuration, etc. that expects subdomain URLs. The proxy would implement the logic:

  • https://tools.wmflabs.org/$tool/$path:
    • If --with-subdomain is set for $tool:
      • Redirect permanently to https://$tool.wmflabs.org/$path with an explanation why.
    • Else:
      • Serve as usual.
  • https://$tool.wmflabs.org/$path:
    • If --with-subdomain is set for $tool:
      • Serve as (then) usual.
    • Else:
      • Return an error page with information for maintainers on how to enable subdomain hosting for their tool.

We could potentially:

  • redirect //tools.wmflabs.org/$tool/$path to //$tool.tools.wmflabs.org/$tool/$path,
  • redirect //$tool.tools.wmflabs.org to //$tool.tools.wmflabs.org//$tool.

unless some flag is specified, but I'm also fine with making it fully opt-in.

scfc added a comment.Feb 3 2016, 6:46 PM

I do remember thinking about this last night/this morning and finding another issue that needed to be addressed, but I forgot what the issue was :-(. I believe it was something in the direction of Cross-origin resource sharing, i. e. if there are gadgets, etc. on wikis that are configured to be able to interact with tools.wmflabs.org, but not necessarily *.tools.wmflabs.org.

He7d3r added a subscriber: He7d3r.Apr 16 2016, 5:15 PM
valhallasw moved this task from Triage to Backlog on the Toolforge board.May 27 2016, 12:40 PM
valhallasw triaged this task as Lowest priority.
Krinkle renamed this task from consider making individual tools on tool labs have their own X.tools.wmflabs.org subdomain to Allow tools to have their own X.tools.wmflabs.org subdomain.Nov 30 2016, 1:50 AM
Krinkle renamed this task from Allow tools to have their own X.tools.wmflabs.org subdomain to Allow tools to have their own ".tools.wmflabs.org" subdomain.
Krinkle added a subscriber: Krinkle.Dec 2 2016, 2:43 AM

The only problem would be that we already have advertised in some places login.tools.wmflabs.org, but that can be moved.

Also checker.tools.wmflabs.org.

zhuyifei1999 added a parent task: Restricted Task.Feb 8 2017, 10:22 AM
Anomie added a subscriber: Anomie.Jun 8 2017, 1:32 PM
Krinkle removed a subscriber: Krinkle.
He7d3r awarded a token.Oct 2 2017, 4:36 PM

We own the domain toolforge.org and moving to that may be easier than using the existing tools.wmflabs.org root. Let's Encrypt wildcard certs are possible now: https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579

I would be very interested in a project to figure out how to use $TOOL.toolforge.org as the default hostname for webservices exposed from the Toolforge Kubernetes cluster. This could give us a chance to implement a better ingress for the cluster, make TLS required (T102367), and fix the URL namespacing issue all together.

bd808 renamed this task from Allow tools to have their own ".tools.wmflabs.org" subdomain to Allow each tool to have its own subdomain for browser sandbox/cookie isolation.Mar 14 2018, 5:43 PM
bd808 removed a project: Cloud-Services.
Bawolff edited projects, added Security; removed Security-Team.Sep 4 2018, 3:47 PM