Эксплуатируемые функции PHP

Вам нужно будет сканировать для include ($ tmp) и require (HTTP_REFERER) и * _once. Если эксплойт script может записывать во временный файл, он может просто включить это позже. В основном двухэтапная оценка.

И даже можно скрыть удаленный код с обходными методами, например:

 include("data:text/plain;base64,$_GET[code]");

Кроме того, если ваш веб-сервер уже скомпрометирован, вы не всегда увидите незарегистрированное зло. Часто оболочка эксплойта кодируется gzip. Подумайте о include("zlib:script2.png.gz"); Здесь нет eval, все тот же эффект.

Это не ответ как таковой, но здесь что-то интересное:

$y = str_replace('z', 'e', 'zxzc');
$y("malicious code");

В том же духе call_user_func_array() может использоваться для выполнения запутанных функций.

Я удивлен, что никто не упомянул echo и print как точки безопасности.

Скрипты между сайтами (XSS) - это серьезный эксплойт безопасности, поскольку он даже более распространен, чем эксплойты выполнения на стороне сервера.

В частности, я хочу добавить unserialize() в этот список. Он имел долгую историю различных уязвимостей, включая произвольное выполнение кода, отказ в обслуживании и утечку информации о памяти. Его никогда не следует вызывать по предоставленным пользователем данным. Многие из этих vuls были зафиксированы в релизах в течение последних лет росы, но в настоящее время все еще сохраняется пара неприятных ударов в настоящее время.

Для получения дополнительной информации об уродливых функциях/использовании php смотрите Закаленный PHP-проект и его советы. Также недавний Месяц безопасности PHP и 2007 Месяц ошибок PHP проекты

Также обратите внимание, что при проектировании неэтериализация объекта приведет к выполнению функций конструктора и деструктора; еще одна причина не называть его предоставленными пользователем данными.

Мой VPS установлен для отключения следующих функций:

root@vps [~]# grep disable_functions /usr/local/lib/php.ini
disable_functions = dl, exec, shell_exec, system, passthru, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid

PHP имеет достаточно потенциально разрушаемых функций, которые могут быть слишком большими для вашего списка. Например, PHP имеет chmod и chown, которые могут быть использованы для простого деактивации веб-сайта.

EDIT: возможно, вам захочется создать bash script, который ищет файл для массива функций, сгруппированных по опасностям (функции, которые плохи, функции, которые хуже, функции, которые никогда не должны использоваться) а затем вычислить относительность опасности, которую файл накладывает на процент. Затем выведите это в дерево каталога с процентами, помеченными рядом с каждым файлом, если это превышает 30% опасности.

Также имейте в виду класс "уязвимостей прерывания", которые позволяют читать и записывать произвольные ячейки памяти!

Они влияют на такие функции, как trim(), rtrim(), ltrim(), explode(), strchr(), strstr(), substr(), chunk_split(), strtok(), addcslashes(), str_repeat ( ) и более. Это в значительной степени, но не исключительно, из-за функции переадресации вызова по времени на языке, который устарел на 10 лет, но не отключен.

Для получения дополнительной информации см. статью Стефана Эссерса об уязвимостях прерывания и других проблемах с низким уровнем PHP в BlackHat USA 2009 Slides Paper

В этой статье/презентации также показано, как dl() может использоваться для выполнения произвольного системного кода.

Специфичные по Plattform, но и теоретические векторы exec:

• dotnet_load()
• новый COM ( "WScript.Shell" )
• новая Java ( "java.lang.Runtime" )
• event_new() - в конечном итоге

И есть еще много методов маскировки:

• proc_open является псевдонимом для popen
• call_user_func_array ( "exE".chr(99), array ( "/usr/bin/damage", "--all" ));
• file_put_contents ( "/cgi-bin/nextinvocation.cgi" ) && & & CHMOD (...)
• PharData:: setDefaultStub - еще одна работа по проверке кода в файлах .phar
• runkit_function_rename ( "exec", "innocent_name" ) или APD rename_function

Помимо конструкции языка eval существует еще одна функция, которая позволяет выполнять произвольный код: assert

assert('ex' . 'ec("kill --bill")');

Один источник интересных эксплойтов не упоминался. PHP позволяет содержать строки 0x00. Базовые (libc) функции рассматривают это как конец строки.

Это позволяет использовать ситуации, когда (плохо реализовано) проверка работоспособности в PHP может быть обманута, например. в ситуации вроде:

/// note: proof of principle code, don't use
$include = $_GET['file'];
if ( preg_match("/\\.php$/",$include) ) include($include);

Это может включать любой файл, а не только те, которые заканчиваются на .php, путем вызова script.php?file=somefile%00.php

Таким образом, любая функция, которая не будет соответствовать длине строки PHP, может привести к некоторой уязвимости.

Как насчет опасных синтаксических элементов?

" variable variable" ($$var) найдет переменную в текущей области по имени $var. При неправильном использовании удаленный пользователь может изменить или прочитать любую переменную в текущей области. В основном слабее eval.

Ex: вы пишете код $$uservar = 1;, тогда удаленный пользователь устанавливает $uservar в "admin", в результате чего $admin будет установлено в 1 в текущей области.

Думаю, вы не сможете найти все возможные эксплойты, проанализировав исходные файлы.

• Также, если есть действительно большие списки, представленные здесь, вы можете пропустить функцию, которая может быть использована

• там все еще может быть "скрытый" злой код, подобный этому

$myEvilRegex = base64_decode ('Ly4qL2U =');

preg_replace ($ myEvilRegex, $_POST ['code']);

• Теперь вы можете сказать, я просто расширяю свой script, чтобы также соответствовать этому

• но тогда у вас будет этот mayn "возможно, злой код", который, кроме того, вне контекста

• чтобы быть (псевдо) безопасным, вы действительно должны писать хороший код и читать весь существующий код самостоятельно

Добавьте в список pcntl_signal и pcntl_alarm.

С помощью этих функций вы можете обойти любое ограничение set_time_limit, созданное int php.ini или в script.

Этот script, например, будет работать в течение 10 секунд, несмотря на set_time_limit(1);

(Кредит принадлежит Себастьяну Бергманнсу твит и gist:

<?php
declare(ticks = 1);

set_time_limit(1);

function foo() {
    for (;;) {}
}

class Invoker_TimeoutException extends RuntimeException {}

class Invoker
{
    public function invoke($callable, $timeout)
    {
        pcntl_signal(SIGALRM, function() { throw new Invoker_TimeoutException; }, TRUE);
        pcntl_alarm($timeout);
        call_user_func($callable);
    }
}

try {
    $invoker = new Invoker;
    $invoker->invoke('foo', 1);
} catch (Exception $e) {
    sleep(10);
    echo "Still running despite of the timelimit";
}

Я знаю, что move_uploaded_file упоминается, но загрузка файлов в целом очень опасна. Просто наличие $_FILES должно вызвать некоторую озабоченность.

Вполне возможно встроить PHP-код в любой тип файла. Изображения могут быть особенно уязвимы с текстовыми комментариями. Проблема особенно затруднительна, если код принимает расширение, найденное в $_FILES данных как есть.

Например, пользователь может загрузить действительный файл PNG со встроенным PHP-кодом как "foo.php". Если script является особенно наивным, он может фактически скопировать файл как "/uploads/foo.php". Если сервер настроен на выполнение script исполнения в каталогах загрузки пользователей (часто это случается и ужасный надзор), вы сразу можете запускать любой произвольный PHP-код. (Даже если изображение сохранено как .png, возможно, код будет выполнен с помощью других недостатков безопасности.)

A (неисчерпывающий) список вещей, которые нужно проверить при загрузке:

• Обязательно проанализируйте содержимое, чтобы убедиться, что загрузка является типом, который, по его утверждению, является
• Сохраните файл с известным безопасным расширением файла, который никогда не будет выполнен
• Убедитесь, что PHP (и любое другое исполнение кода) отключено в каталогах загрузки пользователей

Оператор Backtick Backtick в руководстве php

Эти функции также могут иметь некоторые неприятные эффекты.

• str_repeat()
• unserialize()
• register_tick_function()
• register_shutdown_function()

Первые два могут исчерпать всю доступную память, а последние сохраняют усталость...

Существует множество эксплойтов PHP, которые могут быть отключены настройками в файле PHP.ini. Очевидным примером является register_globals, но в зависимости от настроек также возможно включать или открывать файлы с удаленных компьютеров через HTTP, которые могут быть использованы, если программа использует имена файлов переменных для любой из функций include() или обработки файлов.

PHP также допускает вызов функции переменной путем добавления() в конец имени переменной - например, $myvariable(); будет вызывать имя функции, указанное переменной. Это можно использовать; например, если злоумышленник может заставить переменную содержать слово "eval" и может управлять параметром, тогда он может делать все, что захочет, хотя программа фактически не содержит функцию eval().

Я боюсь, что мой ответ может быть слишком негативным, но...

ИМХО, каждая отдельная функция и метод там могут использоваться для гнусных целей. Подумайте об этом как о влиянии нецензурности: переменная присваивается пользователю или удаленному вводу, переменная используется в функции, возвращаемое значение функции, используемое в свойстве класса, свойство класса, используемое в файловой функции, и так далее. Помните: поддельный IP-адрес или атака "человек-в-середине" могут использовать весь ваш сайт.

Лучше всего трассировать от начала до конца любой возможный пользовательский или удаленный вход, начиная с $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file) (if allow_url_fopen включен), все другие функции/классы, относящиеся к удаленным файлам и т.д. Вы программно создаете профиль трассировки стека для каждого пользовательского или удаленного значения. Это можно сделать программно, получив все повторяющиеся экземпляры назначенной переменной, а также функции или методы, в которых она используется, а затем рекурсивно компилирует список всех вхождений этих функций/методов и т.д. Изучите его, чтобы убедиться, что он сначала проходит надлежащую фильтрацию и проверку функций по отношению ко всем другим функциям, которые он затрагивает. Это, конечно, ручное исследование, в противном случае у вас будет общее количество переключателей case, равное числу функций и методов в PHP (включая определенные пользователем).

В качестве альтернативы для обработки только пользовательского ввода, статический класс контроллера инициализируется в начале всех сценариев, которые 1) проверяют и сохраняют все введенные пользователем входные значения в виде белого списка разрешенных целей; 2) стирает этот входной источник (т.е. $_SERVER = null). Вы можете видеть, где это получает немного Назиске.

Недавно было обсуждено это на security.stackexchange.com

которые могут использоваться для выполнения произвольного кода

Ну, это немного уменьшает область видимости, но поскольку "печать" может быть использована для ввода javascript (и, следовательно, воровских сессий и т.д.), она все еще несколько произвольна.

не следует перечислять функции, которые должны быть внесены в черный список или иным образом запрещены. Скорее, я хотел бы иметь список grep-able

Это разумный подход.

Подумайте о том, чтобы написать собственный синтаксический анализатор, хотя очень скоро вы поймете, что подход на основе grep выходит из-под контроля (awk будет немного лучше). Довольно скоро вы тоже начнете желать, чтобы вы внедрили белый список!

В дополнение к очевидным, я бы рекомендовал помечать все, что включает include, с аргументом чего-либо, кроме строкового литерала. Следите за __autoload() тоже.

Большинство атак в коде используют несколько источников доступа или несколько шагов для выполнения. Я бы искал не только код, либо метод с вредоносным кодом, но и все методы, выполнение функции или ее вызов. Наилучшая безопасность также будет включать в себя кодирование и проверку данных формы, когда она приходит и выходит.

Следите также за тем, чтобы определить системные переменные, после чего они могут быть вызваны из любой функции или метода в коде.

Вот список функций, которые мой провайдер отключает для целей безопасности:

• Exec
• дл
• show_source
• apache_note
• apache_setenv
• closelog
• debugger_off
• debugger_on
• define_syslog_variables
• escapeshellarg
• EscapeShellCmd
• ini_restore
• openlog
• PassThru
• pclose
• pcntl_exec
• POPEN
• proc_close
• proc_get_status
• proc_nice
• proc_open
• proc_terminate
• shell_exec
• Syslog
• система
• url_exec

Вы можете найти постоянно обновляемый список чувствительных приемников (эксплуатационные функции php) и их параметры в RIPS/config/sinks.php, a статический анализатор исходного кода для уязвимостей в PHP-приложениях, которые также обнаруживают PHP backdoor.

Несколько переполнений буфера были обнаружены с использованием 4-битного символов, которые интерпретируют текст. htmlentities() htmlspecialchars()

были наверху, хорошая защита - использовать mb_convert_encoding() для преобразования в одиночный кодирование до интерпретации.