Всем привет. При исследовании различных WEB-приложений без наличия исходных кодов поиск уязвимостей осуществляется только с белого входа - страниц сайта которые обрабатывают различные запросы от пользователя с параметрами GET, POST, Cookie, Headers, это может быть как и главная страница, так и Ajax запрос, запрос от Flash-приложения где кстати может использоваться не только HTTP и т.п. В большинстве случаев все параметры тщательно проверяются и уязвимостей просто нет, однако довольно часто и особенно в крупных приложениях существует черный вход - страницы, к которым обращается сервер и парсит из них нужную ему информацию. Конечно не секрет, что многие скрипты поступают таким образом, но если у нас нет никакой информации о том, что делает сервер достаточно проблематично найти какую-либо уязвимость. В этой теме возможно собрать различные методы исследования из вне таких приложений, типах уязвимостей о которых в данном случае разработчики не осведомлены, далее можно попробовать рассмотреть какое-либо приложение, использующие эту технологию. Основные сложности здесь в том, что обычно мы не можем получить какой-либо информации о использовании данных, ошибок и т.п. особенно если действия выполняются в фоне. Некоторые вариации уязвимостей в других источниках были названы SSRF (Server-Side Request Forgery) но это не совсем корректно - подделки запросов здесь нет, нам будет удобнее просто рассматривать действия с содержимым страницы на стороне . Начнем. A. DoS - Самая простая атака в нашем случае, цель - отказ в обслуживании. Стандартная ситуация, приложение VK загружаемое в ифрейме, к которому передается некоторые параметры: PHP: app.php?api_url=http://api.vk.com/api.php&api_id... Как видим приложению передается api_url на тот случай если адрес скрипта(old_api.php) или домен изменится(vkontakte.ru vs vk.com), далее сценарий приложения подсоединяется к этому серверу и предположим сохраняет информацию о пользователе себе в файл. Если мы передадим ссылку на сервер с большим файлом, да несколько раз обновим страницу, канал сервера будет полностью забит да и места на диске рано или поздно не останется. Это самое простое, что можно придумать но я не советую так поступать. Другие методы основаны на разборе данных сервером, что мы сейчас и и рассмотрим, цель - передать скомпрометированные ответы с некоторой информацией, которая может использоваться ... B. Уязвимости можно разделить на 3-категории - уязвимости в парсере, уязвимости в обработчике запросов и туннельные уязвимости где благодаря наличию нескольких уязвимостей предыдущих типов мы можем построить через них туннель до требуемой нам операции. 1. Уязвимости в парсере весьма стандартны - данные не проходят соответствующею фильтрацию и используются далее - в SQL-запросах, запросах к файлам, небезопасным вычислениям, нужно лишь узнать, что используется и каким образом методом проб и ошибок. Здесь имеет место определить зависимость использования соединения во время парсинга, к примеру в фоновом процессе мы можем иметь инъекцию типа: PHP: SELECT * from `news` WHERE id = [SQL_CODE] и если фоновый процесс разрывает соединение после выполнения запроса мы можем определить время парсинга которое включает выполнения данного запроса. Если данные используются для вывода, нужно проверить возможность XSS и XXE, последняя из которых возникает при разборе многофункциональными парсерами XML документа, как некоторые советуют использовать на форумах: PHP: <?php $data = '<?xml version="1.0"?> <!DOCTYPE forum [ <!ENTITY data SYSTEM "/etc/passwd"> ]> <forum> <antichat>&data;</antichat> </forum> '; $doc = new DOMDocument(); $doc->loadXML($data); echo $doc->getElementsByTagName('antichat')->item(0)->textContent; Не будем на них останавливаеться - к информации о них лучше обращаться по мере надобности, тем более она доступна в свободном доступе. 2. Уязвимости в обработчике запросов. I. fsockopen: fsockopen - Самая простая обертка, за исключением tcp и udp доступны tls, ssl, sslv2 и sslv3 а так-же udg, unix с помощью которых вохможно использовать локальные сокеты, такие как /dev/log но использовать простые файлы невозможно. После изучения исходников практически не нашел за что можно зацепится, единственное - 4-ый параметр функции отдающий ошибку, которая в будущем может быть занесена в php-файл, БД и т.д. Есть несколько методов возможности передачи текста с нашим содержимым в него, но лишь некоторые позволяют передать спецсимволы: PHP: ... //Приоритет имеет первый параметр, к примеру если нужно использовать порт 0 для unix-сокетов это пригодится @fsockopen("tcp://abc.ru:80", 803, $errorNo, $errorSTR); //PORT <= 0 @fsockopen("tcp://<b s='\"'>abcd</b>", 0, $errorNo, $errorSTR); //int(0) string(43) "Failed to parse address "<b s='"'>abcd</b>" //Однако передачей порта в первом параметре это не осуществить, но так-же нужно заметить что возможно передавать цифровые значения в других системах счисления. ... @fsockopen("tcp://abc.com", 9223372036854775808, $errorNo, $errorSTR);//В 64-bit системах такой вариант тоже вызовет ошибку с выводом параметра ... var_dump($errorNo, $errorSTR, (int)9923372036854775089, intval(9923372036854775089), (9923372036854775089 > 1)); //Отрицательное число в PHP может быть больше одного, возможно при обходе фильтров это поможет ... @fsockopen("tcp://[abc.com", 80, $errorNo, $errorSTR); //Вывод в ошибку при разборе IPv6 адресов /* Возникновение таких ошибок имеется и в других сетевых функциях php. */ ... II. Разбор после использования cURL. cURL - очень злая штука, во многом благодаря тому, что самолично принимает решения. При её использовании программист обычно забывает про её опасность и клепает ПО из различных примеров. К примеру задание 33 было основано на этом: https://forum.antichat.ru/thread363372.html PHP: function open ($url, $data) {// $this->ch = curl_init(); curl_setopt($this->ch, CURLOPT_URL, 'http://'.$url.'/data.php'); curl_setopt($this->ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($this->ch, CURLOPT_POST,1); curl_setopt($this->ch, CURLOPT_POSTFIELDS, array('post' => 'true', 'testdata' => $data)); return curl_exec($this->ch); //CURLOPT_URL, CURLOPT_POST - Это обычные цифорвые константы, различающиеся от версии к версии. } В функции допущена большая ошибка - при наличи в переменной $data строки @/etc/passwd на сервер $url отправилось бы содержимое этого файла. Читать мы можем только доступные файлы: PHP: if ((type = php_memnstr(postval, ";type=", sizeof(";type=") - 1, postval + Z_STRLEN_PP(current)))) { *type = '\0'; } //А вот этого в документации нет, используется при указании имени файла: f ((filename = php_memnstr(postval, ";filename=", sizeof(";filename=") - 1, postval + Z_STRLEN_PP(current)))) { *filename = '\0'; } /* safe_mode / open_basedir check */ if (php_check_open_basedir(postval TSRMLS_CC) || (PG(safe_mode) && !php_checkuid(postval, "rb+", CHECKUID_CHECK_MODE_PARAM))) { RETVAL_FALSE; return 1; } Пожалуй мы добралиь до атак, которые можно назвать SSRF. Смысл этого заключается в том, что cURL при недостаточной обработке адреса сайта или включенной опции CURLOPT_FOLLOWLOCATION может применить свою интеллектуальность и весьма-корректно обрабатывать запросы на получение локальной или внутри-сетевой информации: PHP: file:///etc/passwd (file:// + /etc/passwd) Здесь есть некоторые исследования: http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html При анализе проекта нужно посмотреть на ответ сервера при различных видах переадрестации, неправильного ответа сервера, выдаче данных неопределенной длины, больший файлов, MIME-типов. III. Экзотические функции - анализ DNS записей, WHOIS - Не могу сейчас сказать, что возможно, но это интересная тема для анализа. Это - краткий обзор, тут не следует делать кучу примеров, интересные темы можно будет рассмотреть далее, прямо здесь, возможно попробовать что-то использовать на практике, ведь каждое ПО - уникальное. Возможно я что-то забыл упомянуть. Предлагайте свои функции, возможно данные возможности используются в некоторых CMS или существуют некоторые сервисы использующие внешние запросы, однако не желательно устраивать здесь взломы.
Поправь разметку. HTML: [COLOR=DarkOrange]B.[/COLOR] [/SIZE]Уязвимости можно разделить на 3-категории ...[/INDENT] на HTML: [/INDENT][COLOR=DarkOrange]B.[/COLOR] [/SIZE]Уязвимости можно разделить на 3-категории ...
