Не банальный create_function(). Смотрите habrahabr.ru/post/215139/, я перечислил как минимум
1. eval
2. create_function
3. косвенный вызов функций вида $a($b)
4. assert
5. preg_replace с модификатором «e»
6. вызов через функции, принимающие callable (хэндлеры, работа с массивами и т.п.)
Причем для тех, кто занимается поиском вредоносного кода на сайте очевидно, что конструкции №3 и №6 наиболее сложно найти, так как они характерны для нормальных скриптов. А вот eval, assert, preg_replace(/.*/e) ищутся очень быстро. Если хакер не школьник и не лентяй, он все-таки код свой банальным eval'ом не будет «палить».
Да и потом, какой смысл наворачивать сложную логику подготовки кода для выполнения, если в конце концов обычная замена eval на echo распечатывает результирующий исходный код, который легко проанализировать.
Все бы ничего, но код легко «палится» любым сканером и ищется «ручками» из-за банального eval(). А анализ того, что будет выполнено, делается простой заменой eval на echo.
Сейчас функции запрещают в настройках suhosin (настройки suhosin.executor.func.blacklist, suhosin.executor.eval.blacklist), можно даже мофификатор /e запретить (http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.disable_emodifier). Ну либо отключать функции через disable_functions в php.ini, лишь бы доступ к нему был на хостинге.
Я уже больше месяца активно пользуюсь enum авторизацией. Да, она неудобна, да, она требует внимания (особенно, когда заполняется форма для получения кода оплаты), но она надежнее просто блокировки по IP или хранения ключей на сменном носителе (потому что в случае кипер классика достаточно украть файл <ваш WMID>.init + пароль от кипера, который кеширует весь environment и ключи не понадобятся). Так что я как в анекдоте «мыши кололись, плакали, но продолжали жрать кактус»
Абсолютно разумное замечание — много не хранить на счету. Но это совет для тех, кто просто оплачивает покупки на ozon.ru или получает $100 за написание статей. А если вы занимаетесь серьезным бизнесом в сети (например, продаете программное обеспечение, в моем случае это sale.qpl.ru/, получаете доход от рекламы и т.п.), где оборот большой, то на счет приходят значительные суммы, которые сразу снимать ни к чему, поскольку часть из них используется для расчета с субподрядчиками, оплаты различных сервисов и пр. Суммы в этом случае намного превышают 150 WMZ. Так что здесь единственный вариант — «укреплять линию защиты» ))
Да, теперь я работаю с отдельного ноута. Поставил туда Dr. Web, ключи загрузил в Enum Storage, поставил на все операции Enum авторизацию. Хотя, уверен, и это на 100% не гарантирует неуязвимость кипера. Увы, исторически сложилось так, что я работаю с Кипер Классиком, есть лайт, но большинство кошельков «забито» в различных системах именно со старого «классика».
Подготовка к защите диссера по трудозатратам примерно равна трем годам написания диссера. Человек, который кормит семью, не всегда может позволить себе посвятить науке много времени.
1. eval
2. create_function
3. косвенный вызов функций вида $a($b)
4. assert
5. preg_replace с модификатором «e»
6. вызов через функции, принимающие callable (хэндлеры, работа с массивами и т.п.)
Причем для тех, кто занимается поиском вредоносного кода на сайте очевидно, что конструкции №3 и №6 наиболее сложно найти, так как они характерны для нормальных скриптов. А вот eval, assert, preg_replace(/.*/e) ищутся очень быстро. Если хакер не школьник и не лентяй, он все-таки код свой банальным eval'ом не будет «палить».
Да и потом, какой смысл наворачивать сложную логику подготовки кода для выполнения, если в конце концов обычная замена eval на echo распечатывает результирующий исходный код, который легко проанализировать.
(кстати, я музыку к этой игре написал :-)
www.greg.su/2010/02/kak-tratit-na-rabotu-menshe-vremeni/
www.greg.su/2010/01/parallelnaya-zhizn/
Подготовка к защите диссера по трудозатратам примерно равна трем годам написания диссера. Человек, который кормит семью, не всегда может позволить себе посвятить науке много времени.