Взлом сайта начинается с внедрения в запросы вредоносных управляющих строк, позволяющих в зависимости от цели атакующего реализовать такие сценарии как установка паразитного управляющего модуля (шелл), уничтожение базы данных, получение доступа к конфиденциальным сведениям, скрытое размещение рекламы, отрицательно влияющее на позиции в поисковике, получение доступов к серверу и т.п. Не секрет, что для осуществления этих атак все чаще используется специальный софт, позволяющий просканировать сайт на уязвимости и даже выполнить их эксплуатацию по заранее подготовленным сценариям. Все чаще атаки на коммерческие сайты приобретают массовый характер и затрагивают тысячи ресурсов по всему миру. К сожалению, не все уязвимости обнаруживаются и закрываются основной командой в самом динамично развивающемся движке, не говоря уже о модулях, подготовленных участниками коммьюнити.
Следовательно, для защиты интернет-магазинов на OpenCart необходимо разбирать фрагменты запросов от пользователей еще до того, как они попадут в любые компоненты системы, поскольку человеческий фактор в безопасности - один из решающих. Советы: Для защиты сайта можно прикрыть сервер с помощью сервисов вроде CLOUDFLARE, QRATOR, VIRUSDIE и т.п Выполняйте сканирование файловой системы сайта с помощью бесплатного антивируса Манул, других скриптов и утилит, имеющих возможности отслеживать появление новых неизвестных файлов и изменения в файлах существующих.
Это позволит вовремя заметить факт взлома. Но что делать, если в Вашем бюджете пока не предусмотрен Qrator, VirusDie или Cloudflare? Что делать, если у Вас нет ресурсов устраивать тщательный аудит кода на безопасность для каждого из модулей, которые Вы устанавливаете? Утилиты вроде Acunetix имеют дорогие лицензии, а ими надо еще научиться пользоваться. А безопасностью заниматься в наше непростое время надо как никогда.
Подобно тому, как операционные системы имеют несколько колец или слоев защиты, так и OpenCart нуждается в создании такого слоя, хотя бы в минимальном объеме защищающем от исполнения XSS и SQL инъекций. Эффективность разработки такого слоя может быть достигнута только при предположении, что движок и модули имеют незакрытые уязвимости.
Этот слой должен быть размещен между ядром системы и контроллерами и запросами.
Таким образом, идея состоит в том, что нельзя доверять ни сайту (может быть заражен или уязвим), ни запросам (могут быть вредоносными). Нельзя доверять разработчикам модулей, поскольку они концентрируют свои усилия на выполнении определенных задач и могут просто не заметить проблем с безопасностью своего кода.
Сам же слой должен быть настолько прост и лаконичен, насколько это вообще возможно, чтобы его собственная безвредность, соответствие требованиям и безопасность была очевидна. Он не должен опираться на остальные инструменты CMS и быть переносимым между разными CMS - CMS меняются, а безопасность остается.
Как мог бы выглядеть подобный слой:
Практический пример:
Сохраняем в корне сайта файл protection.php.
в файлах /index.php и /admin/index.php перед всеми инструкциями ставим первыми вызов защитной прослойки
Результат: теперь попытки отправить нам на сайт в запросе прелести вроде eval, script или drop database и т.п. будут пресекаться на корню. Он универсален и подойдет для любой CMS.
Код опубликован "как есть", без каких-либо гарантий с моей стороны.
Буду рад конструктивным предложениям по улучшению этого фильтра.
Если у Вас есть наработки и идеи по такого рода защите, если Вам что-либо известно об аналогичных модулях (возможно, в рамках других CMS), пожалуйста напишите об этом в этой теме или отправьте мне свои соображения на почту
[email protected].
Уверен, что всем в той или иной степени интересна тема повышения безопасности OpenCart.
Пишу здесь, поскольку не уверен, что кто-либо из core/kernel team будет это когда-либо имплементировать, рефакторить или развивать, с учетом своеобразного характера персонажей вроде Daniel Kerr.
Желаю всем растущих продаж, отличной конверсии и 100% аптайма :-)
