https://discord.umbraco.com logo
#help-with-umbraco
GOD Mode in Umbraco showing Connection String
# help-with-umbraco
u

.jonroberts

02/08/2024, 10:31 AM
@dandiplo in God mode - a CMS user can see the Connection String to the database. Our client who has performed a Pen Test on the CMS has flagged this as a Security issue. Are you aware of this?
k

kdxperbol

02/08/2024, 11:24 AM
Surely nothing is hidden from God. 🙏 Can't Umbraco user access restrictions be applied here? Or can they only control the ootb sections?
u

.jonroberts

02/08/2024, 12:58 PM
To be honest I think the Pen tester is taking his job a bit too serious
k

kdxperbol

02/08/2024, 2:57 PM
Godmode falls under the Settings section, and I can't see a way in Umbraco to allow/disallow parts of the same section to users when editing an access level. Forms (for example) solves this by creating its own section, so that would probably work for G0dm0d3 as well. But you could argue that Settings contains sensitive data anyway, since the log file could contain anything. So, don't give access to Settings without enabling 2FA etc, then it should be no problem.
d

d_inventor

02/08/2024, 6:57 PM
I asked this same question recently as well. I personally find it at least questionable to expose application secrets, even in a protected backoffice section. It removes all layers of security except the Umbraco login. It's still protected, but so much less...
Not to mention it's completely unnecessary to show the entire database connectionstring. Could easily strip off the secret parts
s

Sebastiaan

02/09/2024, 1:02 PM
Maybe not necessary but anyone with access to the Settings section can edit a template and do the exact same thing. Yes, the package makes it easier, but not THAT much easier. moral of the story: if someone doesn't actively require access to the Settings section on a production site then don't give it to them (I would go so far as to say nobody should need it).
d

d_inventor

02/09/2024, 5:05 PM
Huh, I never thought of it that way
s

Sebastiaan

02/09/2024, 5:46 PM
IMHO the Runtime Mode
Production
should enforce that the Settings section is not available to anyone at all. 😅
m

mwillebrands

02/09/2024, 6:55 PM
I agree and as additional layer of security, just make use of managed identifies (if running in Azure) then there's no sensitive data in the connection string
e

eagle_f90

02/09/2024, 11:01 PM
What about needing to get to the Log Viewer to see errors, or to run a Health Check on the site, or access the the Examine Management, or clearning cahce? I can see real world uses for having access to these in production.
s

Sebastiaan

02/10/2024, 11:59 AM
Yes those are fair points. I usually run with just the 1 admin account who could do any of those, nobody else gets access to that. I did just realize that I **believe **in
Production
mode the templates editor is read-only. But again, here's some good things to make security scans turn up problems: the log viewer might have all kinds of info in there that shouldn't be exposed, constantly rebuilding examine indexes or rebuilding caches is also an attack vector. With great power.... 🙂
e

eagle_f90

02/10/2024, 12:13 PM
I did notice that in production mode for v13 the templete editor was read-only. Which annoyed me when I needed to temporarly add a google verification meta tag....
c

craig100

02/10/2024, 1:05 PM
Being able to do that used to be VERY handy. I guess it won't work now due to everything being in a Razor class 😦
s

skttl

02/10/2024, 7:13 PM
You can just have the site running in backoffice development mode if you need to be able to edit views from the backoffice. Not recommended - but possible.
e

eagle_f90

02/10/2024, 9:48 PM
Running a production site in dev mode? No thanks but it would have been nice to be able to make such a small change and then remove it without having to do two deploys to production causing downtime.
u

.jonroberts

02/12/2024, 11:27 AM
Is there a way to hide the connection string in God mode?
j

Jason

02/12/2024, 11:45 AM
If done properly, logging will also get audited specifically to prevent leaking of sensitive info while keeping them open for developers.
I've got a big security sensitive client (I'm not allowed to tall you who) where we operate on a zero-knowledge/zero-trust basis and every deployment goes through their SecOps team. This kind of thing isn't about attack vectors, it's about who has access to what data. GDPR and PCI are very clear about having strong separations of concerns. In our case, developers (and Ops) need access to settings to do everyday Umbraco stuff, but they shouldn't automatically be able to see the connection string. In production mode they can't write code any more so that solves the *big * problem Umbraco used to have. I see there's tangentially a related issue: https://github.com/DanDiplo/Umbraco.GodMode/issues/41 a PR that fixes this would solve the problem. The other alternative is simple - not using god Mode on sites where Settings section users shouldn't be able to see the connection string.
s

Sebastiaan

02/12/2024, 12:17 PM
Just noticed I have a PR for a very similar issue on my own package: https://github.com/nul800sebastiaan/Cultiv.EnvironmentInspect/pull/2 Solving it with a config setting is pretty nice.
k

kdxperbol

02/12/2024, 5:45 PM
I still think a separate section for G0dm0d3 would be the easiest solution. Obviously only superadmins with MFA should have access to that section. But it's also kind of pointless since Settings already gives you godlike powers.
j

Jason

02/13/2024, 12:17 PM
Not in the production runtime mode though, so not necessarily only "superadmins". Even if we do assume only "superadmins" should have access, it doesn't necessarily follow that the said superadmin, one of those two people on the infrastructure team that is allowed to know the SQL Server password, is actually allowed to have access the CMS itself. This is a very normal situation in govt. financial services, critial infrastructure, etc. I've worked on a lot of sites/systems where nobody is allowed to be a "super" admin by design.