Евгений Борисов

Да, структуру знать нужно.

Утилит для конвертации не встречал.

За чей счёт банкет?)) да и какой смысл проверять только при приемке. Очередное обновление и новая дырка…

На мой взгляд каждый второй компонент сейчас должен выпускать обновления с припиской
— добавлена дополнительная фильтрация данных форм перед обработкой

Эффект от allow_tv_eval почти тот же. Но там и без @EVAL хватает операторов

Для аудита мне еще ни разу не попадался сайт с Fenom. Поэтому ничего не могу сказать

Какого года?

Вот ТОП-10 IP с которых долбились на разные сайты в попытках взломать через последную уязвимость. И дальше что? Это не значит, что за всеми этими IP стоит один и тот же человек.

94.23.196.14
192.99.35.121
192.99.35.135
212.129.61.154
37.187.132.5
46.118.112.85
123.30.235.19
178.137.88.27
51.15.146.39
77.72.83.79

А есть еще куча однотипных шеллов. Но это тоже не значит, что управляет этим зоопарком один человек. По большей части многие шеллы качаются из паблика и потому просто друг на друга похожи…

Лично я минус поставил, т.к. вы слишком преувеличили значимость проблемы. Лечение сайта это не только проверка айболитом и обновление сайта до последней версии.

А объяснить клиентам необходимость этого будет сложно

Если ваши клиенты вам платят за поддержку, то это ваша головная боль. Если клиенты в свободном плаванье, то рекомендация обновиться и подчиститься по причине массовых взломов воспринимается как забота о клиенте и ответственный подход к работе.

Да и вообще, инициатива часто наказуема))

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

Вот кейс из моей практики. Когда на хабре была опубликована первая статья с предупреждением, что Google Chrome будет помечать http сайты как не безопасные, я всем своим клиентам (даже те, которые не находятся в поддержке) скинул ссылку на этот поиск. Мол подумайте над тем, чтобы совершить переход на https. Вы не поверите, но в течении всей следующей недели эта задача стала приоритетной у всех клиентов. Кто-то меня попросил заняться этим вопросом, кто-то привлек своих программистов, а кто-то даже заказал выпуск платных сертификатов.

А знаете почему? Потому, что клиент должен заниматься развитием своего бизнеса, а не вниканием в технические нюансы обслуживания сайтов и слежением за тенденциями в вебе. Когда клиент начинает вас учить делать сайты или считает, что вы его разводите на бабки, то тут 2 варианта:
— Либо вы не достаточно компетентны, чтобы адекватно аргументировать необходимость того или иного действия
— Либо с бизнесом у клиента не все в порядке

Без обид, но в вашем случае я склонен думать, что причина не в компетентности. Банально, у вас стоит ISPManager, где можно без лишних усилий подключить Let's Encrypt. Но до сих пор это не сделано. Чего уж там говорить про обновление и вирусы.

Беглый осмотр. Сразу же выявил XSS в поиске. В общем удачи в борьбе с хитрым вирусом.

Чтобы внедрить такое на сайт не обязательно быть знакомым с системой на 100%. Встречаются вариации, когда просто где-то в index.php/config.inc.php зашивают серверную часть, которая рандомно себя проявляет + параллельно проверяя USER_AGENTS или даже IP посетителя на предмет вхождения в подсеть сотовых операторов.

Так же никто не исключает возможность взлома вашего сервера через Exim или какие-то другие службы с устаревшим софтом, а не через CMS. При этом нельзя исключать вариант того, что был получен root доступ к серверу, где размещен ваш сайт (довольно часто это бывает, когда сайт обновляют, а про серверное ПО забывают)

В общем давно бы уже заказали аудит у профессионалов, раз сами не можете справиться с проблемой.

Boolean-based SQL Injection

SELECT * FROM users WHERE 1 = (SELECT 1) # Все данные из таблицы
SELECT * FROM users WHERE 1 = (SELECT 0) # Ничего

Естественно вложенный запрос SELECT 1/0 может быть любым вида

SELECT IF(count(*) > 1000, 1, 0) FROM content

1. Если используете сырые запросы, то посмотрите в сторону биндинг привязок.
2. Если работаете с моделями через getObject/getCollection и т.п., то используйте ассоциативный массив во втором аргументе для передачи параметров вида ключ-значение, а не просто значение.
3. Если строите выборку через newQuery, то проверьте насколько доверенные данные вы передаете в where и другие методы

Это общие рекомендации. В любом случае начать нужно с документации к xpdo и pdo

Нет:-)

Т.е. не кеш-менеджер работает через файловый менеджер, а наоборот

А чтобы воспользоваться кеш-манагером, нужно еще и доступ к БД подтянуть

require_once 'core/xpdo/cache/xpdocachemanager.class.php';
require_once 'core/xpdo/xpdo.class.php';
$xpdo = new xPDO('mysql:');
$cache = new xPDOCacheManager($xpdo);
$flag = $cache->writeFile(__DIR__. '/filename.txt', 'Текст');

Именно! Ну а раз так, то рано или поздно найдутся уязвимые компоненты. Возможно даже в ядро движка что-то просочится. Поэтому запасаемся попкорном:-)