Безопасность Opencart

[RHCk]

Приветствую!

 

После прочтения этой статьи появилось несколько вопросов:

1. По этому пункту понятно, периодически меняю все пароли.

2. Понятно. Путь имелся в виду /system/storage/logs? Ещё переименовываю файл, куда ошибки пишутся. Возможно пользы от этого не много, но зато не по дефолту

3. Тут было бы неплохо подробнее написать каким каталогам какие права (хотя бы для OC в стоке)

4. +

5. Про хлам подробнее бы. Что и откуда убирали

6. Тут вопрос, если ИМ работает в СНГ (РФ, Украина, РБ и т.д.), может быть со старта включать сюда диапазоны IP не относящиеся к стране, на которую рассчитан ИМ (понятно, что периодически будет необходимо корректировать)?

7. Чуть подробнее бы

8. +

9. В настройках после установки делать нужно (написать бы где, красным по белому, или по умолчанию в сборке сделать).

 

Всё что было ниже - понятно.

 

С уважением.

[savage4pro]

вопрос касался версий 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 и далее цена реализации инфраструктуры начинает зашкаливать для среднего владельца магазина и ему дешевле будет плюнуть на зараженный сайт, а в худшем случае выбросить его в помойку, сделать ребрендинг и построить все заново

объяснение простое - первые пункты защитят от широкого гребня ботнетов, а далее начинается защита от злых на вас людей при деньгах

 

и дабы не иметь потенциальных дыр, никаких модулей с ионкубами, да и вообще никаких сторонних модулей, только свое, с одним исключением - обкатанные тысячами покупателей и вылизанные авторами модули от людей с репутацией полубогов, уровень которой вы сами для себя установите

[RHCk]

Спасибо!