Page 1 of 8

[VOTING] XH 1.6.10

Posted: Tue May 30, 2017 12:25 pm
by cmb
Hi everybody!

I've started the voting on CMSimple_XH 1.6.10 (which is supposedly the last version of the 1.6 branch, which has its EOL on 2017-06-30).

Tickets for voting.

Voting ends as usual after 18 days on 2017-06-17. Thanks in advance for participating in the vote!

Re: [VOTING] XH 1.6.10

Posted: Wed Jun 14, 2017 1:40 pm
by cmb
A gentle reminder:
cmb wrote:Voting ends as usual after 18 days on 2017-06-17.

Re: [VOTING] XH 1.6.10

Posted: Wed Jun 14, 2017 9:08 pm
by Tata
If it won't be a big issue, I think that a security function could be included into this version.
The idea is not to allow upload an installation to the server until the login is modified.
While working on localhost, it's OK to use any password, or even no passworrd. But uploading an installation to the server may be dangerous. I also often forgot to change passwords in my test installation.
The function should tes the paths and block access to admin functions if there is the old "test" password. It means the only access in admin area would be the "Change Password".
What's your opinion?

Re: [VOTING] XH 1.6.10

Posted: Wed Jun 14, 2017 11:29 pm
by cmb
Tata wrote:If it won't be a big issue, I think that a security function could be included into this version.
[…]
The function should tes the paths and block access to admin functions if there is the old "test" password. It means the only access in admin area would be the "Change Password".
What's your opinion?
CMSimple_XH 1.6 has its end of life in a few weeks, by which time CMSimple_XH 1.7.0 is supposed to already have been released. Therefore I don't think that there will be (m)any fresh installs of XH 1.6.10 (opposed to updates), so this feature would not really be helpful for XH 1.6 anymore, but it likely would cost us a relatively high amount of development work.

Doing it for CMSimple_XH 1.7 might be prudent, although we already added a system check for the default password – what should be good enough, but probably isn't. Maybe we should consider adding an install/first run script that requires the webmaster to enter a new password (and perhaps some other information/configuration) like it's done by many other systems. OTOH, I'm not sure whether such install/first run scripts are really a good idea. Consider the webmaster is uploading the software to the server and takes a break – in the meantime an attacker might be able to take over the installation; in the worst case in a way that the webmaster won't even notice. :?

Your suggestion is also nice, but it has the same issues: an attacker might intercept the installation, set a password, log in, install a backdoor, and restore the site to be "unitialized". Note that anybody who has admin access to a CMSimple(_XH) website can do pretty much anything, as long as they can execute arbitrary PHP code on the server (for instance, via the template) – changing that would take away a lot of CMSimple(_XH)'s power. Actually, it appears that preventing unauthorised admin access should be prevented the best we can, so I agree that we should improve in this regard, for CMSimple_XH 1.7.0, or maybe better for 1.7.x.

Anyhow, I've put it on the roadmap.

Re: [VOTING] XH 1.6.10

Posted: Thu Jun 15, 2017 6:11 am
by Tata
cmb wrote:Consider the webmaster is uploading the software to the server and takes a break – in the meantime an attacker might be able to take over the installation; in the worst case in a way that the webmaster won't even notice. :?
That's true.Would it be then be possible to check - the sever - if the uploaded config.php has new password. If it's not, block any further manipulation,editing, saving etc. with a warning that a new config file shall be uploaded. This way probably any attacker would have any access to the installation.

Re: [VOTING] XH 1.6.10

Posted: Thu Jun 15, 2017 10:15 am
by cmb
Tata wrote:Would it be then be possible to check - the sever - if the uploaded config.php has new password. If it's not, block any further manipulation,editing, saving etc. with a warning that a new config file shall be uploaded.
That would require that users somehow prepare their CMSimple_XH installation on a local machine, what surely is unacceptable for many users.

Re: [VOTING] XH 1.6.10

Posted: Thu Jun 15, 2017 11:02 am
by Tata
cmb wrote:That would require that users somehow prepare their CMSimple_XH installation on a local machine, what surely is unacceptable for many users.
Are there anyworking from scratch directly only online? Even if so, the very first access should be the passowrd change. It would be very dubious coincidence if whoever would try the site at the same time with bad intention.
I still can imagine some ".htaccess" trick (some other ".file" ?)where the admin can store some question/answer or some code for authorisation on first login.

Re: [VOTING] XH 1.6.10

Posted: Sun Jun 18, 2017 11:11 am
by cmb
Voting has ended. Thanks to all participators.

I'm going to implement the agreed items and release CMSimple_XH 1.6.10 as soon as possible.

Re: [VOTING] XH 1.6.10

Posted: Mon May 18, 2020 2:28 pm
by frase
Tata wrote:
Wed Jun 14, 2017 9:08 pm
If it won't be a big issue, I think that a security function could be included into this version.
The idea is not to allow upload an installation to the server until the login is modified.
While working on localhost, it's OK to use any password, or even no passworrd. But uploading an installation to the server may be dangerous. I also often forgot to change passwords in my test installation.
The function should tes the paths and block access to admin functions if there is the old "test" password. It means the only access in admin area would be the "Change Password".
What's your opinion?
https://www.cmsimple.org/forum/viewtopi ... 3162#p3156

Re: [VOTING] XH 1.6.10

Posted: Sun May 24, 2020 4:08 pm
by cmb
Tata wrote:
Wed Jun 14, 2017 9:08 pm
The function should tes the paths and block access to admin functions if there is the old "test" password. It means the only access in admin area would be the "Change Password".
What's your opinion?
I've made a quick patch for this, but I still think this is not quite right, because that leaves room for an attacker to effectively taking over the installation (see my comments above). Also it's ugly for local installations, especially for development.
It seems to me this solution has it somehow backwards. I mean, you have to upload (move) a script, to enforce the password change; if you don't, the installation still runs with a default password (although not "test", but it is still a default password).

The typical solution would rather be, that after uploading, the software runs some setup script, which finally offers to download a configuration file, which has to be uploaded to the site; only afterwards, the software can be used. If an attacker would intercept before the configuration file has been uploaded, they could run the setup, but would not be able to upload the resulting configuration script afterwards, so nothing bad could happen.