Статьи Проверка надежности Web-приложений. Часть Третья

Tecklord, по материалам SecurityFocus

В первой части этого цикла статей мы ознакомились с общей теорией безопасности Web-приложений и акцентировали вопрос на вводе данных. Во второй части речь шла о нескольких категориях уязвимостей Web-приложений и методах их обнаружения. Данная статья является заключительной в этой серии и будет посвящена исследованию безопасности сессий и файлов куки, переполнению буфера и логическим ошибкам программистов. Мы также укажем источники полезной информации для дальнейшего ознакомления с проверкой надежности web-приложений.

Файлы куки – это средство хранения постоянных данных на клиентской стороне HTTP обмена. Они не являются частью HTTP спецификации, но в то же время являются стандартом de-facto для браузера. Файлы куки представляют собой ответы на HTTP заголовки, и служат для установления определенного значение на клиентской стороне и передачи его серверу. Значение присваивается, используя заголовок 'Set-Cookie' и возвращается с помощью запроса 'Cookie'. Следующий пример иллюстрирует работу куки. Клиент запрашивает ресурс и получает ответ в виде заголовков:

Set-Cookie: PASSWORD=g0d; path=/; expires=Friday, 20-Jul-03 23:23:23 GMT

При обращении клиента к ресурсу по адресу «/» -- сервер отвечает:

Cookie: PASSWORD=g0d

Браузер отвечает за хранение и получение значений куки. В Internet Explorer и Netscape это реализовано с помощью маленьких временных файлов; безопасность такой реализации хранения данных не является темой данной статьи, мы попробуем сосредоточить наше внимание на проблеме самих файлов куки.

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

Файлы куки должны рассматриваться разработчиком как другая форма ввода данных пользователем и подвергаться подобной проверке. Существует множество примеров SQL-инъекции и других уязвимостей, которые можно использовать посредством манипуляции значений файлов куки. (Пример уязвимости: Webware WebKit cookie overflow)
Безопасность сессии и ID

Большинство современных языков программирования для WEB включают в себя средства для управления сессиями. Это означает возможность установить значение таких переменных, как права доступа, настройки локализации, которые будут относится к каждому диалогу между пользователем и web-приложением до окончания сессии. Это реализуется web-сервером путем присвоения клиенту псевдо-уникальной строки – ID сессии. Затем сервер ассоциирует элементы данных с этим ID, а клиент сообщает ID каждый раз во время запроса к приложению. ASP и PHP имеют встроенную поддержку сессий. (PHP работает с переменными запросов GET и файлами куки, ASP только с файлами куки).

Поддержка значений переменных сессии посредством запроса GET в PHP считается не самой лучшей реализацией, но поддерживается из-за того, что не все браузеры работают с куками, и не все пользователи принимают куки. Этот метод реализован посредством передачи GET запросом переменной PHPSESSID. PHP автоматически изменяет все ссылки в реальном времени, добавляя к ним PHPSESSID. Это не является единственной уязвимостью (поскольку ID сессии является частью ссылки), такой подход упрощает реализацию атаки: исследование логов прокси-сервера, просмотр истории браузера или социальная инженерия (просьба пользователя дать ссылку в том виде, в котором он это видит, включая PHPSESSID). Совмещая переменные сессии GET и межсайтовый скриптинг, можно расшифровать ID сессии. Этого можно достичь, внедрив javascript, который будет отсылать URL документа на удаленное аутентифицирующее приложение, таким образом позволяя атакующему собирать ID сессий.

Метод с файлами куки работает точно так же, за исключением переменной PHPSESSID (или ID сессии в случае с ASP), использование которой предпочтительно в фалах куки, а не посредством GET запроса. На уровне протокола, это так же опасно, как и метод GET, так как ID сессии может быть записано, повторено или добыто путем обмана(социальная инженерия). И все же, намного труднее получить ID сессии, так как оно не является частью ссылки. Комбинация куки, сессий и межсайтового скриптинга небезопасна постольку, поскольку атакующему нужно всего лишь вставить свойство document.cokie на страницу аутентификации и получить ID сессии. Добавим, что как средство удобства для пользователя, ID сессии часто устанавливается на использования куки с неограниченным срока годности или без его указания. А это означает, что такой файл будет всегда существовать на клиентской стороне, и возможность заполучить его возрастет.

Существует также много форм управления сессиями пользователей. Одна из них – это вставка строки ID сессии в тег <input type="hidden"> элемента <form>. Вторая – использование строк ID сессий, определяемых вебсервером Apache, для выявление пользователя и как средство аутентификации. Проект Apache никогда не подразумевал использование этих данных в иных случаях, кроме как выявления пользователя и статистических данных; алгоритм построения такой строки основан на взаимосвязи известных элементов данных на стороне сервера. Подробности о брутфорсе ID сессии и криптографическом алгоритме хешировании не рассматривается в этой статье. (Для желающих изучить этот вопрос подробно, можно воспользоваться этим документом).

ID сессии являются ахиллесовой пятой web-приложений, поскольку они просто используются для управления структурой HTTP – по существу бесструктурной технологии. Пен-тестер должен особо тщательно изучить механизм, который используется для генерации ID сессии, способ создания ID и его взаимосвязь с ошибками на клиентской стороне (например, межсайтовый скриптинг), и возможность атак.
Логические ошибки

Логические ошибки – это большая категория уязвимостей, окружающая большинство уязвимостей, которые не подпадают под другие категории. Логическая ошибка – это ошибка в логике web-приложения правильно обрабатывать некоторые данные или обеспечивать безопасность. Примером служит следующий скрипт:

<?php
$a=false;
$b=true;
$c=false;
if ($b && $c || $a && $c || $b)
echo "True";
else
echo "False";
?>

Выше приведенный код пытается удостовериться в том, что две из трех переменных принимают значение до того, как возвращается true. Логическая ошибка состоит в том, что заданное до этого значение переменной $b=true приведет к успешному завершению условия if. Это можно исправить, изменив условие if на следующее:

if ($b && $c || $a && ($c || $b))

if ($b && $c || $a && $c || $a && $b)

Логические ошибки очень трудно обнаружить, используя метод «Черного ящика». Они обычно дают о себе знать при проверке другого вида уязвимости. Тщательный аудит кода является самым лучшим средством от логических ошибок, примером которых может послужить SudBox Boutique login bypass vulnerability
Бинарные атаки

Web-приложения, написанные на языках, использующих статические буферы (например C/C++) могут быть уязвимы к таким традиционным бинарным атакам, как переполнение буфера. Также часто встречаются манипуляция кодом и содержимым (SQL-инъекции и PHP-инклудинг).

Переполнение буфера возникает вследствие попытки программы записать в статический буфер больше данных, чем предусмотрено. Дополнительные данные переписывают и повреждают соседние блоки в памяти и могут дать возможность атакующему контролировать выполнение и внедрять произвольные инструкции. Чаще всего переполнение буфера находят в приложениях, написанных на C/C++(программы на языке C# является защищенным от такого вида атаки, так как в C# существует дополнительная защита стэка от невнимательного разработчика). Частыми примерами такой уязвимости служат в web-приложениях mnoGoSearch и Oracle E-Business Suite.

Переполнение буфера может быть обнаружено во время проверки методом «Черного ящика» путем ввода слишком большого количества данных в форму, заголовок или поле куки. В случае с ISAPI приложениями, сообщение об ошибке №500 (или тайм аут) в ответ на ввод длинной строки может говорить об ошибке сегментации на стороне сервера. Поскольку переполнение буфера более характерно для скомпилированных выполняемых файлов, чем для скриптовых приложений, окружение должно быть сперва протестировано для выяснения, является ли язык разработки уязвимым к атакам переполнения буфера. Обратим внимание, что наиболее популярные языки программирования для web (Java, PHP, Perl, Python) являются интерпретированными языками, в которых интерпретатор отвечает за распределение всей памяти.

Атаки форматированной строкой возможны, когда определенная функция C обрабатывает ввод данных, содержащий символы форматирования (%). Известно, что функции printf/fprint/sprintf, syslog() и setproctitle() некорректно работают с этими символами. В некоторых случаях, это может привести к тому, что атакующий получит контроль над потоком выполнения программы (Примером использования этой уязвимости в web-приложении служит PWC.CGI vulnerability)
Полезные утилиты для тестирования.

Некоторые приложения изначально разрабатывались в помощь тестирующему методом “черного ящика” для обнаружения уязвимостей в web-приложениях. Хотя и анализ программного вывода, возможно, лучше всего выполнять вручную, большая часть методики тестирования может быть автоматизирована скриптами.

AtStake WebProxy

WebProxy работает между браузером клиента и web-приложением, перехватывает и декодирует запросы, чем позволяет разработчику анализировать действия пользователей, и измениять запросы на лету.

Download: http://www.securitylab.ru/tools/31039.html

SPIKE Proxy

SPIKE proxy функционирует как HTTP/HTTPS прокси сервер и позволяет тестирующему автоматизировать некоторые тесы на уязвимость web-приложений (включая SQL инъекцию, обход катлога и брутфорс)

Download: http://www.securitylab.ru/tools/30119.html

Xspider

Xspider содержит набор уникальных тестов, способных определять тип используемого ПО на Web сервере, определять уязвимости SQL инъекции в GET и Post переменных, XSS уязвимости и т.п. Все эти функции доступны только в зарегистрированной версии программы.

Download: http://www.ptsecurity.ru



KSES - это фильтр безопасности HTML написанный на PHP. Он фильтрует все “опасные” элементы формы и может защитить от SQL инъекции и XSS.

Download: http://www.securitylab.ru/tools/41029.html

Mieliekoek.pl

Эта утилита, написанная roelof@sensepost.com, анализирует страницы и скрипты на предмет потенциально возможных SQL-инъекций.

Download: http://www.securitylab.ru/tools/41031.html

Sleuth

Sleuth – это коммерческое приложение для обнаружения уязвимостей в безопасности web-приложений. Она включает элементы прокси сервера и возможности web-спайдера.

Download: http://www.securitylab.ru/tools/39412.html

Webgoat

Целью проекта OWASP Webgoat является создание интерактивной среды обучения безопасности web-приложений. Она обучает разработчиков, используя практические упражнения, азам безопасности web-приложений и ошибкам дизайна. Она написана на Java и инсталляция возможна под *nix и Windows системы.

Home Page: http://www.owasp.org/development/webgoat

AppScan

AppScan – это коммерческая утилита для проверки безопасности web-приложений разработанная Sanctum Inc. Она включает возможности проверки кода, оффлайн анализа и сканирования по расписанию.

Home Page: http://www.securitylab.ru/tools/41033.html
Заключение

Web-приложения становятся стандартным средством связи клиент-сервер по Интернету. Поскольку все большее количество приложений являются доступными для web, возрастет количество вопросов по безопасности web приложений; традиционные уязвимости локальной системы, такие как возможность обхода каталога, переполнения буфера, становятся открытыми новому спектру атак. Ответственность за безопасность чувствительных систем будет скорее возлагаться на web-разработчика, а не на производителя ПО или системного администратора.

Мы надеемся, что в этой серии статей мы подчеркнули важность контроля над вводом данных пользователя и продемонстрировали, как основная часть вопросов по безопасности web-приложений связана с этой концепцией. Лучшая защита от атак, заключающихся в манипуляции ввода данных – это контроль над вводом данных и соблюдение правила: «Что четко не разрешено - запрещено». Легче будет справится с жалобами пользователей на запрещение ввода некоторых символов, нежели исправить последствия инцидента безопасности из-за непроверенного ввода данных.