System is insecure during installation about coderr.server

[gauffininteractive]

The regular site is turned off when the installation wizard is activated and it's not possible to login unless the configured appkey has been changed. Once the appKey have been changed to true the installation wizard is inaccessible.

Only one admin account can be created during the installation. So if an attacker gains access to the URI and manages to create an account before the real admin it's noticeable. In that case the real admin should delete that account and create it's own. I could add a text which highlights that something is wrong if an account exists and if it has not been created by the admin itself.

The attacker can however not access the site with the created admin account since only the installation wizard can be accessed.

But now when I think about it. The attacker can change the SMTP settings and by doing so gain access to the activation links and by doing so get an account. However, the default installation allows anyone that know the URI to create an account.

An installation account is a nice approach but is a bit more complicated since no authorization parts have been configured when the installation wizard is run.

Another approach is to add a installationRemoteHostFilter appKey which must be set when configuring. Add your own ip/remotehost. localhost would be allowed per default

what do you think?

[RyanONeill1970]

It was the initial admin run I was thinking of, not the regular site. To prevent any external access except by the person setting up the box.

For example, a deploy from source may leave it unattended for some time during which it can be discovered and someone else can claim ownership. If it was dependent on a key being set in web.config by the owner then this value would be required to initiate setup. After setup, it would be ignored.

I don't think the localhost filtering would work for me as local access to a hosted Azure instance is not possible via a web browser and for many, putting their IP into source so it gets deployed might be problematic too.

If you'd rather leave it, I understand. It is just a limited window of opportunity, I was thinking that secure by default would be useful.

[gauffininteractive]

My suggestions was also for the installation wizard. The initial idea was that the server was installed in the company network and that the FW only is opened once the server is configured. That's why it's designed like it is.

But as you say. If OTE is deployed in azure additional measured need to be taken. My suggestions was for that specific case. Maybe the easiest approach is to configure an admin account in the config file.

I also agree that secure by default is great.

[RyanONeill1970]

I'm happy to create a pull request for setting an installation password in the app config. I would not put a fixed / known password in though, instead I would force the admin to set one otherwise it will go into the master list of default passwords available here.

However, if this does not sit well with your design goals, please just close this issue. I won't be offended.

[gauffininteractive]

A pull request would be awesome

[onetrueerror]

corrected in the next commit

[onetrueerror]

The installation wizard now have a simple input field that must match a new appSettings key on the first page.