1. 34

  2. 28

    Am I the only one who thinks this article got it backwards? We had userdirs, and then Javascript arrived. According to Wikipedia, JS arrived with Netscape 2.0, which introduced some nasty XSS vulnerabilities, and then we got SOP with 2.02 - ie., it was a hasty patch. SOP introduced a strange heuristically-based definition of an “origin” that wasn’t really indicative of a true origin. The title really should be “Javascript is (still) dangerous” after 25 years, because it made incorrect assumptions about what an origin is, which aren’t easy to fix.

    Although the article doesn’t call it out, cookies can be thought of the same way. I’m assuming people reading this article are already aware of it, but note that SOP has other very brave assumptions about an origin - is “b.a” a selectable origin, or is “c.b.a”? The answer depends on the value of “a.” Clearly the people defining this knew it was imperfect and prone to breaking as new TLDs get defined. The “solution” was to create a giant list of what domains are considered “public” at any point in time (see https://publicsuffix.org/list/public_suffix_list.dat .)

    It’s interesting reading other comments here too talking about how this could be fixed, where web servers could indicate via headers additional restrictions to impose on what an “origin” is. I’ll jump on that and add that DNS could also do the same thing, eliminating the need for that giant list and allowing correct configurations to be specified with each new domain or subdomain. But we’re hostage to the policies introduced in a .02 security update which have become entrenched and nobody wants to fundamentally reexamine.

    1. 15

      I agree with the your complaint in the context of your overall write-up, but you do mention that

      So what does that mean? You probably should not use userdir URLs for anything except hosting of simple, static content - and probably not even there if you can avoid it.

      I shudder as I ask… where do you ever see userdirs used outside the hosting of simple, static content? We understood this in 1995 and allowed no server side automation of any kind on userdir content way back then, much to the chagrin of more than a few of our (academic, generally themselves quite trustworthy) users. We held firm.

      Have scripts (or any kind of “application” as opposed to a fileshare) in userdirs become a thing?

      1. 14

        Here’s someone with a wordpress blog on a University userdir: https://www.math.columbia.edu/~woit/wordpress/

        Here’s a CMS of a large german research institution: https://www.pik-potsdam.de/ Which uses userdirs on the same host: http://www.pik-potsdam.de/~willner/

        1. 3

          Wow. I had no idea that was a common practice. Is that what inspired the write up?

        2. 4

          JavaScript is enough to cause trouble here.

          1. 4

            I don’t think I qualified “here” appropriately.

            Suppose I’m running a user file server at home.example.com and on there I let users share their own files over https as home.example.com/~user/. I don’t run any of the example.com applications there. Those are run on mail.example.com, www.example.com, etc. home.example.com is for users to share files. Yes, those files may include javascript, but that javascript would not be coming from any origin that I serve an application from, and there’s no server side dynamism on users.example.com.

            Can you characterize the problem that javascript causes in that scenario? I’m asking in a half-academic sense; I would not personally deploy anything new this way because subdomains are easy enough and constitute their own origins. But the only places I ever see userdirs used are approximately what I just described. I haven’t yet seen a javascript problem urgent enough to force a migration from that, and I’m wondering if others have or are aware of a theoritical one. (Because I wouldn’t be entirely unhappy to force a migration… :) )

            1. 2

              Most JavaScript will actually be fine; and you’re also vulnerable with some JS-free backend code which sets a cookie on example.com for authorisation.

              In other words, the problems are mostly when you want to restrict access, using any method, since that often relies on domain-level same-origin policy (although it doesn’t have to be, and there are ways around it, such as the cookie path, but you need to be very careful with this).

          2. 3

            @hanno Maybe you should amend the last paragraph to stress why Github moved from “username.github.com” to “username.github.io” for those who don’t remember, it totally fits the theme but it’s not clear unless you know.

            1. 3

              Apache doesn’t, with HTTP, say “userdirs are enabled, so the origin of this resource should be /~username rather than /”, and Firefox doesn’t say “the URL path starts with /~, so set an origin just to be safe.” Ah, oh well.

              Isn’t this fundamentally an in-band signalling problem?

              1. 4

                Apache doesn’t, with HTTP, say “userdirs are enabled, so the origin of this resource should be /username rather than /”, and Firefox doesn’t say “the URL path starts with /, so set an origin just to be safe.” Ah, oh well.

                Isn’t this fundamentally an in-band signalling problem?


                Apache doesn’t say the origin is anything; it is Firefox which makes the decision what the origin is by looking at the URL, a few infrequently-updated databases shipped with Firefox, and a complex set of rules for applying the two together.

                1. 2

                  There is no such feature in the web stack. That’s not how it’s supposed to work. The concept of the origin is universally defined, and can’t be changed on per-response basis.

                  At best the server could lock things down with CSP headers, but even CSP itself thinks in origins.

                  1. 1

                    Well yes, because the concept of the Origin is fundamentally broken, and was from the beginning. Userdirs existed before JS, so JS has to be changed, not userdirs.

                2. 2

                  This issue can be somehow mitigated with Suborigins, unfortunately only supported in Chrome right now.

                  Another issue, a counter-example: letting people register subdomains under a domain you control can lead to subtle issues like being able to provide OpenPGP keys for the root domain: https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-09#section-3.1 (imagine Mallory registering name openpgpkey under example.com and being able to intercept all requests for keys in example.com domain).

                  1. 2

                    I’m looking forward to seeing what the tildeverse has to say about this. I expect it will be entertaining.

                    1. 2

                      tildeverse mostly has static content, so I don’t see that it’s going to be much of a problem. There could be vulnerabilities if the sign-on portals are not locked down with a good CSP, though.