Холдинг Modesco — это более 300 инфосайтов и 5 крупных Интернет-сервисов. Проекты регулярно покупаются и продаются. Как вы понимаете, поддерживать качество кода на высоком уровне в данной ситуации физически невозможно. Да и основное внимание программистов, как правило, сосредоточено на самих сервисах. Взломы, shell, заражения сайтов прочими вредоносными штуками… Все это наносит ощутимый вред пользователям и компании. Чтобы избежать этого, частенько приходится искать довольно нестандартные способы для уменьшения рисков.  Это не означает, что все опасные функции срочно надо запретить. Как и не означает, что, запретив их, вы точно обезопасите себя от всех PHP-shell. Большинство этих функций могут абсолютно безопасно использоваться в вашем приложении, Framework или библиотеках. К каждому приложению стоит подходить индивидуально. Безопасность — процесс построения глубоко эшелонированной обороны, и выключение опасных функций в данном случае всего лишь одна из возможных линий этой обороны. Список таких функций вполне может являться помощником для поиска подозрительных файлов. PHP-shell может быть очень хитро спрятан — отличным примером обфускации служит статья на habr Статья основана на записи stackoverflow и собственном опыте разбора огромного множества PHP-shell. Было бы неплохо выключить некоторые опасные функции для PHP-fpm (или другое). Оставьте возможность для их исполнения только через PHP-cli. Появление других функций стоит мониторить в файлах. К третьим следует относиться более аккуратно и не позволять попадать неочищенным или строго не провалидированным строкам в аргументы. Эти функции стоит выключить в первую очередь. Если они вам нужны в PHP-fpm, то вы делаете что-то не так. Эти функции позволяют выйти из окружения указанном в open_basedir. Выключения только части функций будет недостаточно. Например, любимый многими shell WSO в поисках возможностей для исполнения кода перебирает функции. Их тоже стоит выключить. Например proc_open встречается в WSO. Да и не место таким функциям в окружении PHP-fpm. Daemon должны запускаться через PHP-cli. Эти функции раскрывают информацию о вашей системе и могут значительно облегчить осуществление атаки на другой софт. А также могут стать источником утечки конфиденциальных данных, например в symfony рекомендуется хранить подключения к БД в ENV. Поэтому желательно запретить выполнение этих функций, кроме тех, которые используются в вашем приложении. Стоит проверять их наличие в загружаемых файлах и проводить регулярные проверки текущих файлов. Помимо eval существуют другие способы выполнить PHP код. Например, можно выполнить include специально сформированного JPG файла. Однако большинство framework и приложений используют эти функции — отключать их нельзя. Поэтому важно крайне аккуратно относиться к ним при использовании. Shell может из себя представлять всего лишь одну строку: Эти функции могут использоваться для вызова других функций через передачу строкового параметра. Стоит применять их аккуратно и не допускать попадания сырых данных в аргументы функции. Ведь они также могут послужить для маскировки shell. Пример самого простого shell с использованием этих функций выглядит так: Эти функции часто применяются для маскировки уже известных PHP-shell от антивирусов и от чужих глаз. Проверяйте на их наличие загружаемые файлы, проводите регулярные проверки в текущих файлах. Пример скрытия shell: Эти функции могут быть применены для загрузки файлов или для раскрытия информации о системе — стоит с осторожностью их использовать. Многие PHP-shell умеют загружать сторонние файлы через ftp. Простой PHP-shell для загрузки произвольного файла выглядит так: С этими функциями тоже нужна осторожность, а некоторые из них лучше запретить. Например, mail может применяться для рассылки спама зараженным сайтом. Если ваше приложение не предполагает использования этих функций, то отключите их. Следующая конструкция не внушает страха, но это один из самых маленьких PHP-shell: Отключение небезопасных PHP-функций — это один из способов уменьшения рисков при нехватки ресурсов. Если вашим проектом займутся люди со "специфическими знаниями" — он, вероятнее всего, падет. Особенно хорошо такая защита показала себя на сайтах на CMS — их заражают, как правило, вредоносные сети в автоматическом режиме. Если сканирующий бот не сможет запустить команду или залитый PHP shell, он, скорее всего, перейдет к следующему сайту. Надеюсь, новичков эта статья сподвигнет более внимательно относится к фильтрации, экранированию и валидации данных, полученных от пользователя. Статья не претендует на уникальные знания — в том или ином виде данный материал уже встречался в Рунете. Текст является обобщенным и систематизированным материалом, призывающим к привлечению внимания к проблеме. Быть может, кого-то он сможет мотивировать на написание комплексного материала по безопасности Wordpress, ну или другой CMS.