Предыстория вопроса:
Популярные CMS, написанные на PHP, хороши тем, что при низких бюджетах на проект позволяют выдавать сайты с требуемым функционалом. Тебе просто не надо бОльшую часть функционала писать т.к. часто он уже написан в виде какого-нибудь дополнения.
Вместе с тем - как быть с проектами, где безопасность играет ключевую роль и которые 100% кто-нибудь (весьма квалифицированный) заморочается и начнет ломать (банки, сайты знакомств, проекты с биллингами, обменники и т.д.). Примеров сайтов, требующих повышенную безопасность может быть масса.
Опять же - бюджеты низкие, особенно на старте, а безопасность нужна высокая, а в некоторых случаях параноидальная. Хотя, разумеется, банки не попадают под категорию "низких бюджетов на старте".
Возможно, не следует использовать CMS, а тем более на PHP??
Казалось бы еще не так давно SECL GROUP рапортовала: Более трети российских банков предпочитают «1С-Битрикс»
Хотя публикация и не свежая, но пробежавшись по списку, действительно можно обнаружить, что на Битриксе работают до сих пор:
Вместе с тем, посмотрев исходный код страничек сайтов других банков из этой публикации - можно увидеть, что к настоящему времени они перешли на другие технологии - Node.js или что-то еще.
Подавляющее число взломов - из-за чего?
Из моего опыта складывается, что чаще всего ломают из-за недостаточной фильтрации данных. SQL-инъекции соответственно сюда же. Поправьте меня, если это не так.
Показателен пример уязвимости в библиотеке PHPMailer, которую использует WordPress, описанный летом.
Или знаменитый фейл Iqitcommerce - именитого разработчика Warehouse для PrestaShop (в сети есть инфа). Была дыра, через которую тебе одновременно несколько хакеров лили всё, что хотели)) Тогда под раздачу и я попал.
Перечислять обнаруженные и описанные дырки можно до бесконечности. И сколько еще не обнаружено.
Собственно, что делать??
Как максимально обезопасить какую-то CMS с кучей библиотек, модулей, плагинов, когда ты не знаешь где именно "прорвет"??
1. Пришла в голову мысль изменить структуру CMS (какой-то) так, чтобы в корне был только index.php и папки со статикой с минимальным набором прав, а всю структуру со скриптами размещать выше корня и роутить соответственно с index.php по дереву выше. Если грубо , идея состоит в том, что если где-то и есть уязвимость, то по крайней мере до нее нельзя будет дотянуться из адресной строки. Или это плохая идея и я чего-то не учел??
2. Не менее "гениальная мысль" - файлы, которые льет юзер - запретить их запрос с домена, на котором исполняется PHP, а сделать что-то вроде cdn (без PHP - только статика) и при попытке любого доступа к папке uploads с основного домена - перенаправлять на cdn.domain.ru через nginx, apache (без разницы). Понятно, можно запретить выполнение скриптов в данной папке, как это везде делают - достаточно ли одного этого?
3. Не размещать админа в таблице со всеми юзерами, как это в Joomla. Вообще не размещать админа в БД. Наверное лучше?
4. Для nginx - в сети много фильтров SQL-инъекций... Но! Это, как понимаю, только для GET-запросов? Как быть с POST? Перебирать всё куда может прилететь POST и ставить дополнительные проверки?
5. Ваши мысли... ))))
Популярные CMS, написанные на PHP, хороши тем, что при низких бюджетах на проект позволяют выдавать сайты с требуемым функционалом. Тебе просто не надо бОльшую часть функционала писать т.к. часто он уже написан в виде какого-нибудь дополнения.
Вместе с тем - как быть с проектами, где безопасность играет ключевую роль и которые 100% кто-нибудь (весьма квалифицированный) заморочается и начнет ломать (банки, сайты знакомств, проекты с биллингами, обменники и т.д.). Примеров сайтов, требующих повышенную безопасность может быть масса.
Опять же - бюджеты низкие, особенно на старте, а безопасность нужна высокая, а в некоторых случаях параноидальная. Хотя, разумеется, банки не попадают под категорию "низких бюджетов на старте".
Возможно, не следует использовать CMS, а тем более на PHP??
Казалось бы еще не так давно SECL GROUP рапортовала: Более трети российских банков предпочитают «1С-Битрикс»
Хотя публикация и не свежая, но пробежавшись по списку, действительно можно обнаружить, что на Битриксе работают до сих пор:
- Корпоративный сайт управляющей компании Сбербанк;
- Россельхозбанк;
- Банк Россия;
- Банк Траст;
- Московский Индустриальный Банк;
- Кредит Европа Банк;
Вместе с тем, посмотрев исходный код страничек сайтов других банков из этой публикации - можно увидеть, что к настоящему времени они перешли на другие технологии - Node.js или что-то еще.
Подавляющее число взломов - из-за чего?
Из моего опыта складывается, что чаще всего ломают из-за недостаточной фильтрации данных. SQL-инъекции соответственно сюда же. Поправьте меня, если это не так.
Показателен пример уязвимости в библиотеке PHPMailer, которую использует WordPress, описанный летом.
Или знаменитый фейл Iqitcommerce - именитого разработчика Warehouse для PrestaShop (в сети есть инфа). Была дыра, через которую тебе одновременно несколько хакеров лили всё, что хотели)) Тогда под раздачу и я попал.
Перечислять обнаруженные и описанные дырки можно до бесконечности. И сколько еще не обнаружено.
Собственно, что делать??
Как максимально обезопасить какую-то CMS с кучей библиотек, модулей, плагинов, когда ты не знаешь где именно "прорвет"??
1. Пришла в голову мысль изменить структуру CMS (какой-то) так, чтобы в корне был только index.php и папки со статикой с минимальным набором прав, а всю структуру со скриптами размещать выше корня и роутить соответственно с index.php по дереву выше. Если грубо , идея состоит в том, что если где-то и есть уязвимость, то по крайней мере до нее нельзя будет дотянуться из адресной строки. Или это плохая идея и я чего-то не учел??
2. Не менее "гениальная мысль" - файлы, которые льет юзер - запретить их запрос с домена, на котором исполняется PHP, а сделать что-то вроде cdn (без PHP - только статика) и при попытке любого доступа к папке uploads с основного домена - перенаправлять на cdn.domain.ru через nginx, apache (без разницы). Понятно, можно запретить выполнение скриптов в данной папке, как это везде делают - достаточно ли одного этого?
3. Не размещать админа в таблице со всеми юзерами, как это в Joomla. Вообще не размещать админа в БД. Наверное лучше?
4. Для nginx - в сети много фильтров SQL-инъекций... Но! Это, как понимаю, только для GET-запросов? Как быть с POST? Перебирать всё куда может прилететь POST и ставить дополнительные проверки?
5. Ваши мысли... ))))
Последнее редактирование:
