Комментарии 20
НЛО прилетело и опубликовало эту надпись здесь
Топоры нужно запретить, ими можно наносить увечья людям
Подход «бешеного принтера» не работает. Тут подход такой — вот перечень опасных предметов, для работы с ними надо ознакомить персонал с ТБ. В ТБ описаны опасности при работе с инструментами, а часть вещей запрещено явно, например жонглировать бензопилами и кидать коллеге топор.
Вот есть контейнер с WP (полный дырок и «дверей»). Ну запрети ему в runtime функции исполнения команд и функции управления процессами.
Вот есть контейнер с WP (полный дырок и «дверей»). Ну запрети ему в runtime функции исполнения команд и функции управления процессами.
Если есть возможность установить расширение PHP, то полезным будет переименовать опасные функции в какое-то другое имя с помощью runkit_function_rename() или rename_function(), например добавив префикс. После этого можно объявить свою функцию с именем оригинальной. И там уже на что фантазии хватит — логировать места вызовов, по белому списку мест вызовов пробрасывать вызов в переименованную оригинальную и тп.
Несколько несвязанных мыслей:
1) непонятно зачем нужно запрещать trim или substr, если они запрещены, их можно написать самому, надо ли запрещать ещё и такую возможность?
2) include, require, goto и некоторые другие — не функции, а конструкции языка;
3) не увидел упоминание backtick;
4) зачем в «print_r(call_user_func_array($_POST['functie'], array($_POST['argv'])));» использовать call_user_func_array и преобразовывать параметр в массив? Досточно поменять вызов на call_user_func. Я бы вообще написал так: print_r($_POST['functie'](...$_POST['argv']));, не нужны никакие левые функции и параметров можно больше одного.
5) вы там функции для работы с файловой системой запрещаете, но как будто не подозреваете о наличие тех же функций в SPL;
В общем, странная статья — не до конца понятно зачем это всё блокировать, да ещё и ломается это всё на раз.
1) непонятно зачем нужно запрещать trim или substr, если они запрещены, их можно написать самому, надо ли запрещать ещё и такую возможность?
2) include, require, goto и некоторые другие — не функции, а конструкции языка;
3) не увидел упоминание backtick;
4) зачем в «print_r(call_user_func_array($_POST['functie'], array($_POST['argv'])));» использовать call_user_func_array и преобразовывать параметр в массив? Досточно поменять вызов на call_user_func. Я бы вообще написал так: print_r($_POST['functie'](...$_POST['argv']));, не нужны никакие левые функции и параметров можно больше одного.
5) вы там функции для работы с файловой системой запрещаете, но как будто не подозреваете о наличие тех же функций в SPL;
В общем, странная статья — не до конца понятно зачем это всё блокировать, да ещё и ломается это всё на раз.
1. Весь список опасных функций не надо запрещать.
2. Да.
3. Кавычки это синтаксический сахар для system или exec. Отключите их и кавычки не будут работать
4. Такой shell для примера попался. Там по ссылке с примерами shell очень много странных решений.
5. Ага. Можно еще многими методами записать файл. Но главная задача — сломать шаблоны действий.
Как там и написано — все блокировать не надо. Достаточно заблокировать пару секций, что бы сломать работу типовых shell и привычные шаблоны действий. Остальное больше для ознакомления, поиска вставок кода и т.д. А если что-то надо делать ручками, то большинству сайт становится не интересен.
2. Да.
3. Кавычки это синтаксический сахар для system или exec. Отключите их и кавычки не будут работать
4. Такой shell для примера попался. Там по ссылке с примерами shell очень много странных решений.
5. Ага. Можно еще многими методами записать файл. Но главная задача — сломать шаблоны действий.
Как там и написано — все блокировать не надо. Достаточно заблокировать пару секций, что бы сломать работу типовых shell и привычные шаблоны действий. Остальное больше для ознакомления, поиска вставок кода и т.д. А если что-то надо делать ручками, то большинству сайт становится не интересен.
Автор, скажи тогда, как без exec (и подобного) сделать вызов серверного приложения из php?
Допустим тотже jpegoptim или optipng?
Допустим тотже jpegoptim или optipng?
А если просто запретить исполнение php там где загружается файлы?
require_onceUpd: вы предлагаете запрещать исполнение функций вместо того, чтобы запрещать загрузку шеллов.
Примерно как знаете, оставить открытой дверь в квартиру, но налить везде суперклея и вывернуть лампочки — чтобы незваный гость точно прилип и точно шагу сделать не мог.
Странное решение, крайне странное!
А «запрещать загрузку шеллов» это не более странное? Это вообще как? Как в том мультике кричать «воришка не воруй» и он перестанет воровать?
Вот список функций, вот определенный контейнер с известным нам приложением. Прописываем правила, что приложение не может в runtime запускать эти и эти функции. А другое приложение эти и те.
Более того, у большинства РКН головного мозга — вам всё запретить хочется. Статья называется «небезопасные функции», а не «функции php, которые надо запретить немедленно». И в самой статье русским по белому написано «Это не означает, что все опасные функции срочно надо запретить».
Это статья:
1. Предупреждение. На что стоит обращать внимание при поиске дыр или что стоит использовать более аккуратно.
2. Помощник при поиске shell
3. Помощник при настройке более безопасного контейнера для приложения (что можно выключить в php-fpm если не нужно)
Вам дали «справочник с лекарствами», не пейте их все разом.
Вот список функций, вот определенный контейнер с известным нам приложением. Прописываем правила, что приложение не может в runtime запускать эти и эти функции. А другое приложение эти и те.
Более того, у большинства РКН головного мозга — вам всё запретить хочется. Статья называется «небезопасные функции», а не «функции php, которые надо запретить немедленно». И в самой статье русским по белому написано «Это не означает, что все опасные функции срочно надо запретить».
Это статья:
1. Предупреждение. На что стоит обращать внимание при поиске дыр или что стоит использовать более аккуратно.
2. Помощник при поиске shell
3. Помощник при настройке более безопасного контейнера для приложения (что можно выключить в php-fpm если не нужно)
Вам дали «справочник с лекарствами», не пейте их все разом.
Скорее всего под «запрещать загрузку шеллов» — имеется в виду настроить на сервере доступ на запись для скриптов строго в одну директорию, в которой запретить исполнение кода.
И это не решает проблемы дырок, когда файл можно загрузить куда угодно. Например в результате недавней дырки в php-fpm
А правильнее будет и запретить исполнение кода и выключить некоторые функции.
А правильнее будет и запретить исполнение кода и выключить некоторые функции.
Эмм, не понял. Если в директорию запрещена запись от пользователя от которого запущен php-fpm, то ничего вы в неё не запишите.
Отключение же функций никак не поможет от уязвимости на которую вы дали ссылку, непонятно зачем это здесь.
Отключение же функций никак не поможет от уязвимости на которую вы дали ссылку, непонятно зачем это здесь.
Допустим с какой-то дыркой (мало ли их) вы запишите файл в нужную директорию. И как там права на какую-то директорию повлияют? А в статье есть ссылки на shell, попробуйте их запускать с разными ограничениями — 2 отключенные секции функций и большинство shell перестают нормально работать.
Большинство CMS ломают не через загрузку файла через интерфейс, а через дырки позволяющие выполнить произвольный код (обычно в популярных плагинах). И как помогут права на директорию вообще не понятно.
Большинство CMS ломают не через загрузку файла через интерфейс, а через дырки позволяющие выполнить произвольный код (обычно в популярных плагинах). И как помогут права на директорию вообще не понятно.
Давайте по-порядку.
У пхп-скрипта нет доступа на запись в директорию, т.к. доступ ограничен системой.
Если вы сможете записать в эту директорию, то эта дырка называется повышение привилегий, которая и без того позволит вам в системе сделать всё что угодно даже без PHP. Ограничение функций не поможет вообще ничем.
У пхп-скрипта нет доступа на запись в директорию, т.к. доступ ограничен системой.
Если вы сможете записать в эту директорию, то эта дырка называется повышение привилегий, которая и без того позволит вам в системе сделать всё что угодно даже без PHP. Ограничение функций не поможет вообще ничем.
Автор просто заново изобрёл safe mode, который в 5.4 уже удалили :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Небезопасные функции PHP