вопрос касался версий 1.5.х поэтому и путь system/logs, хотя дыра присутствует и в более поздних версиях
переименование файла смысла имеет действительно немного, т.к. инъекция позволяет переопределить назначение записи ошибок в "хоть-что.php", даже за пределами папки logs типа "../inc.php"
а тут, на свой страх и риск, можете воспользоваться конструкцией, которая запретит прямой вызов .php, в обход index.php и admin/index.php в верхнем .htaccess
<FilesMatch .*\.php$>
RewriteCond %{REQUEST_URI} !(^/(admin\/)?index*\.php|^/$)
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]
</FilesMatch>
и это не панацея, конечно - никто не мешает дописать свою хрень в уже имеющийся файл, например, startup.php и переименовать файл ошибок обратно, дабы не сломать весь сайт сразу, никто же не хочет ломать сайт, а всего лишь какое-то время пользоваться частью его ресурсов, большой частью, пока его не закроют
отключить показ ошибок в .htaccess
php_flag display_errors off
где-нибудь в config.php или в Log::__construct()
error_reporting(0);
насчет прав и прочего
тут в теории все относительно просто
1. на продакшене 1 сайт = 1 пользователь от которого работает веб-сервер для обслуживания данного сайта, права - папки 0700, файлы - 0600
2. ftp не должен иметь прямого доступа ко всем файлам сайта, только через mount к папкам картинок ну и прайсов каких-нибудь в своей домашней папке на dev, на продакшене ftp нет в принципе
3. ssh для пользователя с доступом по ключам, никаких паролей вообще, и он должен быть один такой, который имеет право пушить в мастер продакшена с мерджа веток опять-таки на dev-сервере
4. к dev-серверу нет доступа из мира, кроме нескольких vpn-серверов, через которые осуществляется доступ персонала, и наоборот - в мир, кроме как на прод через систему контроля версий
5. группа разработчиков всегда работает только с ветками на dev каждый под своим пользователем
6. доступ к админке на продакшене запретить совсем, и работать с данными только через api, что подразумевает его расширение
если пункты 1 и полвторого реализовать не сильно затратно, достаточно чуть поднастроить vps, то начиная с п.3 и далее цена реализации инфраструктуры начинает зашкаливать для среднего владельца магазина и ему дешевле будет плюнуть на зараженный сайт, а в худшем случае выбросить его в помойку, сделать ребрендинг и построить все заново
объяснение простое - первые пункты защитят от широкого гребня ботнетов, а далее начинается защита от злых на вас людей при деньгах
и дабы не иметь потенциальных дыр, никаких модулей с ионкубами, да и вообще никаких сторонних модулей, только свое, с одним исключением - обкатанные тысячами покупателей и вылизанные авторами модули от людей с репутацией полубогов, уровень которой вы сами для себя установите