{% else-1 %}
Обновить | Подписаться | Поднять тему
Чтобы выполнить действие авторизируйтесь или пройдите регистрацию на сайте.
1. [автор] (15 апр 2015, 16:39) [1/0] [1] [отв] [спам] [под] +1 | -1

Ещё одна статья по безопасности, которая в более обширном доступе не наблюдалась. Надеюсь многих заинтересует.

HTTP Parameter Pollution — это новый вид атак на веб-приложения, основным преимуществом которого является возможность обхода WAF (Web Application Firewall).

Концепт HPP был разработан итальянскими исследователями Luca Carettoni и Stefano di Paola и представлен на недавно прошедшей конференции OWASP AppSec EU09 Poland.

Несмотря на простоту, HPP является довольно эффективным способом. Его суть заключается в смешивании или дословно «загрязнении» границ HTTP-параметров.

Согласно RFC3986 параметрами HTTP-запроса являются пары, состоящие из ключа и значения, разделенные символом =. Границы параметров в свою очередь определяются с помощью символов & и ;. Однако тот же стандарт не запрещает многократное использование одинаковых имен в HTTP- запросах. Например:
POST /index.php?a=1&a=2
HTTP/1.0
Host: localhost
Cookie: a=3;a=4
Content-type: text/plain
Content-Length: 7
Connection: close
a=5&a=6

Различные веб-серверы обрабатывают такие запросы по-своему. Например вывод $_REQUEST[‘a’] на Apache/PHP вернет 3, а вывод Request.Params[«a»] на IIS6.0/ ASP.NET — 1,2,3,4,5,6. В связи с особенностями обработки запросов с одноименными параметрами возникают различные непредвиденные разработчиками ошибки и, как следствие, нарушение логики работы веб-приложений, что приводит к уязвимостям (SQL- injection, XSS, CSRF, Clickjacking (UI Redressing) и др).
Вызванные HTTP Parameter Pollution уязвимости подразделяются на категории серверных и клиентских.
Атаки на серверную часть
Одной из самых интересных особенностей HTTP Parameter Pollution является возможность обхода такого известного WAF как ModSecurity на IIS6.0 вкупе с ASP.NET. Ошибкой ModSecurity является то, что он анализирует запрос после того, как он был обработан веб-сервром, т.е. проверке подвергается каждый параметр независимо друг от друга. На самом деле, назвать это ошибкой было бы несправедливо, если бы IIS не производил бы конкатенацию параметров с одинаковыми именами с помощью запятой.
Кто здесь больше виноват ModSecurity или IIS сказать сложно, но в любом случае это приводит к обходу фильтрации(имеется в виду базовый набор правил ModSecurity). Эту уязвимость обнаружил Lavakumar Kuppan.
В качестве примера можно рассмотреть следующую SQL-инъекцию:
http://www.example.com/index.aspx?id=-1+UNION+SELECT+username,password+FROM+users — Такой запрос был бы отвергнут ModSecurity, однако с помощью HTTP Parameter Pollution возможен обход фильтрации:
http://www.example.com/index.aspx?id=-1+UNION+SELECT+username&id=password+FROM+users — В итоге Request.QueryString[ʺidʺ] будет содержать склеенные запятой части расщепленного параметра id.
IIS объединяет не только те параметры, которые относятся к query string, но также и те, которые присутствуют в POST и COOKIE. Кроме того, учитывая, что MSSQL, который чаще всего работает с ASP, а также и другие RDBS поддерживают многострочные комментарии /* … */, то становится возможным проведение еще более изощренной атаки:
http://www.example.com/index.aspx?id=-1/*&id=*/UNION/*&id=*/SELECT/*&id=*/username&id=password/*&id=*/FROM/*&id=*/users—
В результате SQL-инъекция будет успешно проведена, так как запрос будет корректным:
-1/*,*/UNION/*,*/SELECT/*,*/username,password/*,*/FROM/*,*/users--

Атаки на клиентскую часть
Основная суть атак на клиента заключается в добавлении дополнительных параметров к ссылкам, различным тэгам, имеющих атрибут src, и к формам (атрибут action).
Стандартный уязвимый код выглядит следующим образом:
<?php
$param = htmlspecialchars($_GET['param']);
echo "<a href=http://www.example.com/index.php?action=view&param={$param}>test</a>";
?>
От XSS подобное приложение будет защищено, но не от HPP:
http://www.example.com/index.php?param=hpp%26action=edit
<a href=http://www.example.com/index.php?action=view&param=hpp&amp;action=edit>test</a>
Реальным примером уязвимости является возможность непреднамеренного удаления жертвой всех своих писем на Yahoo! Mail, что было продемонстрировано Stefano di Paola. Эта уязвимость к настоящему времени уже исправлена разработчиками.
Вектор атаки был следующим:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete
Еще один пример, затрагивающий приложение массового использования, — это обход XSS Filter в IE8. Эта уязвимость также была своевременно пропатчена.
Атака была актуальна только для ASP.NET, где, как уже упоминалось, одноименные параметры объединяются в один. XSS Filter пропускал расщепленные параметры, и в HTML могло быть нечто вроде:
<script,src="...">
И, наконец, последний пример достойный внимания — это уязвимость в веб-приложении PTK. Когда администратор выбирает изображение веб-приложение вызывает скрипт:
/ptk/lib/file_content.php?arg1=null&arg2=107533&arg3=&arg4=1
При этом уязвимый код выглядит следующим образом:
<?php
$offset = $_GET['arg1'];
$inode = $_GET['arg2'];
$name = $_GET['arg3']; //filename
$partition_id = $_GET['arg4'];
$page_offset = 100;
/* ... */
$type = get_file_type($_SESSION['image_path'], $offset, $inode);
/* ... */
function get_file_type($path, $offset, $inode){
include("../config/conf.php"*;
if($offset== 'null'){
$offset= '';
}else{
$offset = "-o $offset";
}
if($inode == 'null') $inode = '';
$result = shell_exec("$icat_bin -r $offset$path $inode | $file_bin -zb -"*;
/* ... */
}
?>
Учитывая, что PHP воспринимает только последний встреченный параметр из группы одноименных, то файл с именем Confidential.doc&arg1=;CMD; приведет к исполнению указанных команд. Как подсунуть такой файл — это отдельный вопрос, но в итоге получается хранимая HPP.

Защита
Конкретных и универсальных способов защиты пока что не существует, но при разработке веб-приложений стоит уделять внимание особенностям поведения веб-сервера и окружения. В качестве защиты от атак на клиентов необходимо обрабатывать входящие данные, которые попадают впоследствии в ссылки, с помощью функции urlencode(), а не htmlspecialchars().

2.
VarrkaN * 0.35
(17 апр 2015, 18:45) [0/0] [0] [отв] [спам] [под] +1 | -1

Херасе, полезная статья, и не думал, и не гадал *

  • 1 из 1
Чтобы писать сообщения авторизируйтесь или пройдите регистрацию на сайте.
Подписаны: 1
Скачать тему | Файлы темы | Фильтр сообщений