I see where you're coming from to increase security, however I don't think that removing the database backup option will do it. I only see it as an inconvenience for admins who do use that feature. And a minor inconvenience for those who might try to use it to take a copy of the database. (And crazy as this sounds, at least if they go through the database backup section a log is made of it in the ACP... Going through injected PHP or cPanel/PHPMyAdmin may not make a log. So admins may not even figure out anything has happened.)
The github incident only really served to illustrate why having software "dial home" can be a bad idea. I mean how many people wouldn't have been affected if the software didn't check back home in the first place?
So, again, following logic does that mean because someone could potentially use that avenue to attack again that it should be scrapped? (How far are we willing to go for security? How many features do we sacrifice? I mean a person determined enough to gain access is going to get in. We've seen that with companies as large as Sony or Google who have much larger teams working on security.)
Plus if someone uses a method like that Github check to inject/execute PHP... removing the database backup feature likely won't stop them from getting a copy of the database. They'll just use a different bit of code and the result will be the same.
Personally I'd like to keep that functionality too.
On some of our servers (especially intranets) we are not installing any panel or phpmyadmin but MySQL only. It'd be very inconvenient to do MyBB backups before upgrading these boards without the ACP option.
And installing third party software like PHPMyAdmin might open up even more security issues then the MyBB database backup file in this case.
I wouldn't like to remove a useful feature like this either, but I would like to add the possibility to encrypt the backups using an admin defined encryption key or something and the ability to change the path where the backups are stored on the server (e.g.: outside the web root).
(2015-06-06, 03:50 PM)Euan T Wrote: [ -> ]I wouldn't like to remove a useful feature like this either, but I would like to add the possibility to encrypt the backups using an admin defined encryption key or something and the ability to change the path where the backups are stored on the server (e.g.: outside the web root).
+1 for this.
I'd also like to see a reminder / direct option to download the encrypted backup at the upgrading process. That might also be helpful for noobs as they tend to forget backups before upgrading.
(2015-06-06, 04:20 PM)Lennart Sauter Wrote: [ -> ] (2015-06-06, 03:50 PM)Euan T Wrote: [ -> ]I wouldn't like to remove a useful feature like this either, but I would like to add the possibility to encrypt the backups using an admin defined encryption key or something and the ability to change the path where the backups are stored on the server (e.g.: outside the web root).
+1 for this.
I'd also like to see a reminder / direct option to download the encrypted backup at the upgrading process. That might also be helpful for noobs as they tend to forget backups before upgrading.
Yes, that would be a fairly useful option I agree.
(2015-06-06, 03:50 PM)Euan T Wrote: [ -> ]I would like to add the possibility to encrypt the backups using an admin defined encryption key or something and the ability to change the path where the backups are stored on the server (e.g.: outside the web root).
The ability to change the backup location should definitely be included. On that note, encryption would effect in more problems than benefits as access to that directory is limited either way (403 or out of root). Performance would get degraded and the the system needs to store the key somewhere (prompting for it every time would make bad UX and most users have no idea how to set up asymmetric encryption).
(2015-06-06, 04:20 PM)Lennart Sauter Wrote: [ -> ]I'd also like to see a reminder [...] at the upgrading process
Yes, there could be a link/button leading to the backup creation page in the ACP.
Also, it would be nice to see a possibility to remove the backup module without creating dead links in the control panel.
(2015-06-06, 04:48 PM)Devilshakerz Wrote: [ -> ] (2015-06-06, 03:50 PM)Euan T Wrote: [ -> ]I would like to add the possibility to encrypt the backups using an admin defined encryption key or something and the ability to change the path where the backups are stored on the server (e.g.: outside the web root).
The ability to change the backup location should definitely be included. On that note, encryption would effect in more problems than benefits as access to that directory is limited either way (403 or out of root). Performance would get degraded and the the system needs to store the key somewhere (prompting for it every time would make bad UX and most users have no idea how to set up asymmetric encryption).
(2015-06-06, 04:20 PM)Lennart Sauter Wrote: [ -> ]I'd also like to see a reminder [...] at the upgrading process
Yes, there could be a link/button leading to the backup creation page in the ACP.
Also, it would be nice to see a possibility to remove the backup module without creating dead links in the control panel.
As we're using Laravel, it has easy encryption built in. Performance would be degraded slightly for the backup feature, but it would be entirely optional and the advantages would outweigh this slight slowdown of a rarely used feature. Only the actual SQL output would need to be encrypted, and would require only a single line of code:
$encrypted = Crypt::encrypt('secret');
I got a question. If my domain got suspended for violating something, I already backed up the database on Cpanel or Phpmyadmin. Then after having a new domain + hosting, i will import that database and everything seems to be okay. But example when I click at the subforum, ir will auto redirect me to the old domain link which contained that link. And I don't want it happen cuz everything now has just been broken by that backup. Why don't we keep it with the encryptions key for database before accessing backup instead of removing this features? Now I lost everything.
I'm late to this, but I agree with Euan on this one.
Why remove a useful tools from admin, just because it could be used against him in a breach? Every single tool in the ACP can be used against them in the event of a breach. Should we take all of them away? No.
People need to get a grip on the fact that inside the ACP, there is a different set of rules about what is considered a security risk. Injection is about people that you don't know trying to hack INTO your forum; NOT about people that you ALLOW into your ACP.
If someone "hacks" into the ACP, then the issue isn't how many bad things that they can do once they are inside. The issue is that they were able to get there in the first place.