Separate sessions after all?
-
So I mentioned this briefly elsewhere but I'd like some actual opinions from people whose opinion on practicality and security I respect and not some forum randos who have a distinct agenda in 1) toeing the community line and 2) don't question how anything actually works.
Scenario:
- I have a user area and an admin area
- admins will do stuff in the user area (customisation of settings and previewing in the user area for sure, but they'll also spend time in the user area in general)
- user area includes potential for rich HTML content
- with the best will in the world I intend to remove scripting but I'm going to assume that some users might be smarter than me
There will be some mildly destructive actions in the user area (content editing, content deletion), but so far nothing is planned to be permanently destructive there.
I looked at what comparable platforms in the industry do and while all of them let users log in with the same username/password to the user and admin areas, nearly all of them separate the admin area off into its own session.
It cannot be a coincidence that platforms do this, and I can only reason that the point of doing it is to protect against request forgery on the assumption that users will potentially figure out a chain of exploits to make that happen.
The hivemind I spoke to is all 'don't try to do this, you're doing it wrong, all you need are permissions' (well, yes, I know I need permissions; not everyone gets access to admin, duh) but they were all basically asserting that I either shouldn't bother at all about trying to additionally secure the admin area against abuse, or at that best I should do something around an elevated session for a period of time and renew that (say, hourly).
Am I going mad here or am I legitimately trying to address a risk that is appropriate to the situation? Assume that in this case the brief can't be moved to water down the content types being added by users; competition in its weight class proactively lets them have any HTML in user facing content, up to and including script tags. The only reason there aren't more issues with abuse is because the audience at large is far too stupid to really notice.
-
I've generally gone with the separate sessions route. I can't say I've done a deep analysis of the alternatives, but I haven't had any strife that I recall. I think the hairiest things can get is if someone already logged in as one wants to switch to being logged in as the other.
Part of my thinking is that "users" and "admins" really are different entities, even if the roles are being played by the same actor wearing different hats. If the content of the session data varies with role, then being able to distinguish "this is a user session" from "this is an admin session" from the outset could save a lot of other more specific checks to see whether content is present or not.
-
I kinda do this implicitly I think in ConCrescent; if you're not an admin, your token simply doesn't have any permissions, and the admin side will reject you full stop if you try hitting any of the endpoints that need admin-level access to do things.
Naturally an admin token it totally allowed to do user things too (unless flagged for explicitly disallowing such, currently not implemented), but admin tokens can be cut down (in theory, never tried it in practice) to a user-area-only token if desired.
It sounds like you're trying to prevent the scenario where an admin switches over to the user area, viewing content that is able to execute and thus (having a session with admin privs) can potentially be used to jack the session, so you're looking for a solution to make that impossible, right?
This should be totally doable depending on how your toggle logic works, where visiting the user area will transparently hand in its admin token and trade it in for a user-area-only token (with a flag that says you can also be admin so it shows the "Back to Admin" UI or whatever) and vice-versa. Obviously this would happen before finalizing the load into the new area.
Seems reasonable enough to me, assuming my assumptions are the intended assumptions.
-
@Arantor separate sessions, coupled with separate subdomains and proper CORS config, will protect admin cookies from XSS attacks. But that's not the reason you see it in every competitor - that one really is a coincidence (well, as much as the same architects designing those systems for different companies and everybody ripping off everybody can be called coincidences).
-
@Tsaukpaetra yes and no. I expect admins to be in the user area generally, and for them to be there with long-life tokens (1 month plus) because I expect them to be of the kind where they just say “remember me” because users love themselves some convenience.
So I expect what will be happening is that they’ll go into admin occasionally and have two (or more, potentially) sessions running, and going into admin definitely shouldn’t log them out of going into userland.
I’m just trying to be extra careful about admin privileges being jacked, more than usual because I want to give out quite a bit of leeway, but knowing that enough of the audience isn’t smart enough to take their security seriously and there are people in the audience who absolutely are smart enough to abuse it and will do just it if they find a chink in the armour.
-
@Gustav this is generally what I’d figured although I do have to take a couple of specific steps in Laravel to make it actually work this way.
I did wonder about the various competition, and generally about web apps. It strikes me as funny how platforms like Moodle and WP don’t give a shit and just have everyone use the same login and session regardless (though IIRC Moodle does at least do some “this session is elevated” stuff so that you don’t immediately log in and fully have an admin session, even though so much of Moodle has rich text editors everywhere in the user facing space, and… questionable security for that)
But community platforms, the place that historically least needed it, generally go the whole hog (at least in PHP land), fully separate sessions etc. even where they don’t generally accept any HTML because that’s what bbcode is for.
There are a few that don’t fully separate the session and they do a time limited elevation with re authentication but in practice this tends to be annoying and inconvenient because you can lose what you were doing if you don’t refresh your session. (Worse, certain of these platforms try to be helpful meaning that they carry through the action you were trying to perform when booted, meaning that it’s not impossible at all to get something bad to happen with a bit of social engineering.)
So I assumed, in lieu of anyone actually explaining the rationale that this was why they did it - they’re fully monoliths (usually) so no subdomain/CORS protection, and they still go out of their way to fully separate the sessions. It’s an annoying amount of work to do and they wouldn’t do it without a strong reason, but the reasons appear to be mostly lost to time.
-
@Arantor Unless you disallow being logged in as admin and as user at the same time—which would be extremely user-unfriendly—, separate sessions don't really solve anything. Only having a subdomain for the admin section does. Which kind of forces you to having separate sessions, because you'll need separate cookies.
And I don't think being a monolith prevents you from having an admin subdomain. Every web server supports virtual hosts, so you can have one server with one big installation, but two virtual hosts assigned to it and some endpoints only available on one and other endpoints on the other.
Also I would delegate the authentication to a separate service¹. But then still separate domains means separate cookies, and then you'd use different tokens (separate “applications”, or “audiences” in OIDC terminology) while having separate tokens on the same domain won't really help much.
¹ You can still install your own Dex or KeyCloak if you don't want to delegate to the likes of Google or Microsoft, but it gives you the options.
-
@Bulb and yet the off the shelf packages don’t work that way - none of them are set up to support separating the admin to a different subdomain. Mostly because actually doing it on commodity hosting is surprisingly painful.
In my case I’m actually looking at setting up isolated tenants, such that site1.domain.com would exist, its admin would be admin.site1.domain.com but both served off the same set of physical files and whatnot. I’m not planning on giving out actual SFTP or direct server access so it seems to me that I can reasonably safely support multiple physical installs on a single server.
As for auth, going down that road is more complex than the broad userbae can deal with. They generally won’t want to connect their account to anything. It’s a weird niche I’m trying to fill.
-
@Arantor Yeah, we switched all hosting to containers in kubernetes here and there's always a reverse proxy in front of them, which makes adding subdomains simple. But whether you want to go that route … it might be an 0verkill.
-
@Bulb the environment I have in mind lets me script changes to nginx so I can do vhosts without too much pain. I’m basically aiming to head towards a small scale hosting service that is never going to be a wildly sustainable business but as long as it covers its costs I’m fine with that.
I am both a user and an admin in this scenario, after all. And I’m trying to be practical with security, not full on paranoid.
I suspect the target audience is already going to shit bricks when I tell them their HTML actually has to be something approaching valid, as they already figured out they could just invent tags and they’d basically just work as style targets without any inherent semantic meaning.
-
@Arantor said in Separate sessions after all?:
as they already figured out they could just invent tags and they’d basically just work as style targets without any inherent semantic meaning
What's wrong with
<div class="bflmpsvz">? I guess it's more typing…
-
@Bulb yes but why bother when you can just use <x> for approximately a div content container? I’ve also seen people do things like <memberlist> on the theory that it’s not a real tag (and it’s not getting rewritten by Vue or similar) but it lets them clearly indicate what it is (to themselves) and style it appropriately.
I have seen some crazy shit.
Edit: note, I don’t mean fully fledged custom elements a la https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements (aside from the Chrome/Edge requirement), this is way out of the league I’m thinking.
-
@Arantor In a sense with most html elements being fully defined by their default css, one could say it is meant to be (ab)used like that.
And then any damage they can do with unknown elements, they can do with div too, so there isn't much point in prohibiting them.
Instead, try to make any templating support structural rather than textual. E.g. the way vue or angular or genshi do it (the last one is a server-side python library that existed for quite a while). That way anything they'll produce will at least always be well-formed.
@Arantor said in Separate sessions after all?:
with the best will in the world I intend to remove scripting but I'm going to assume that some users might be smarter than me
Your best bet is setting content security policy (CSP) to disallow inline scripts, only allow scripts from your domain and approved external providers, and then not serve anything user-provided with the
text/javascripttype. That should be fairly robust.
-
@Bulb I should add, the target demographic includes a collection of people who found their current platform of choice sufficiently wanting for certain features so they just mashed a whole bunch of client side shit together to half-ass approximate it. (And in some cases, quarter-ass approximate it, e.g. by abusing forum topics as a backing store because they don’t have access to change the actual platform they’re using, which is genuinely toxic hellstew from the early 2000s with a bit of fluff to make it nicer) - because they’re shit-scared of installing even phpBB and doing it themselves.
I think there’s a reasonable case for letting instance owners add things but regular users should be blocked good and proper from things.
No doubt even that will come with gnashing and wailing of how unfair I’m being.
-
@Arantor it's all fun and games until you get
fa-spunlogged out by aGETrequest.
-
@boomzilla Logouts are already POST only and have a CSRF token in them.
-
@Arantor said in Separate sessions after all?:
@boomzilla Logouts are already POST only and have a CSRF token in them.
I'm
. Logging out is currently implemented by simply forgetting the token.Yes this is horrible. No I'm not going to fix it when much nicer nice-to-have features are still in the list.
-
@Tsaukpaetra said in Separate sessions after all?:
I'm
. Logging out is currently implemented by simply forgetting the token.Technically a logout is just telling the server to forget the token.
-
@dkf said in Separate sessions after all?:
@Tsaukpaetra said in Separate sessions after all?:
I'm
. Logging out is currently implemented by simply forgetting the token.Technically a logout is just telling the server to forget the token.
Yeah. At present my user tokens aren't persistently stored whatsoever. I'm considering adding it, but so far there hasn't been a need to indicate tokens so storing them is at the moment superfluous.
