UtanovTD_текстовая часть

Утанов Тимур Джураевич
Факультет электронной техники и приборостроения, 5 курс группа КИБ-51, очная форма обучения, защита дипломной работы
Тема «Автоматизация тестирования защищенности Web-приложений»
Дата защиты: 10.06.2012 г. Руководитель работы к.т.н., доцент кафедры ИБС Губенков Артем Александрович

Работа выполнена в текстовом редакторе MS Word 2007
Графическая часть работы выполнена с использованием среды MS Power Point 2007 пакета MS Office 2007.



































Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«Саратовский государственный технический университет
имени Гагарина Ю.А.»


Кафедра Информационная безопасность автоматизированных систем


ЗАДАНИЕ
на дипломную работу

Студенту учебной группы КИБ-51 факультета электронной техники и
(факультет)
приборостроения

Утанову Тимуру Джураевичу
(фамилия, имя, отчество)


ТЕМА РАБОТЫ:
Автоматизация тестирования защищенности Web-приложений






(Утверждена на заседание кафедры, протокол от «___»________2012 г. №___)




Начало проектирования «___» ____________ 2012 г.

Представление оформленной работы «___» ____________ 2012 г.

Дата защиты «___» _________2012 г.


Оценка защиты к.ф.-м.н., доцент Н.Ю. Хороводова
(уч. звание, фамилия секретаря ГЭК, роспись)



П.п.
Содержание расчётно-пояснительной записки
(перечень вопросов, подлежащих разработке)
Консультанты

1
Введение


2
Глава 1. Классификация веб-уязвимостей. Общая терминология.


3
Глава 2. Методы и средства обнаружения уязвимостей веб-приложений.


4
Глава 3. Обзор инструментов автоматизации поиска уязвимостей веб-приложений. Сканирование веб-приложений.


5
Глава 4. Экономическая часть


6
Заключение


7
Библиографический список




Основная рекомендуемая литература_____________________
1. Фленов, М.Е. Web-сервер глазами хакера/ М. Е. Фленов. – СПб.: БХВ-Петербург, 2007. – 288с.: ил.
2. Web Application vulnerabilities Detect, Exploit, Prevent/Michael Cross [etc.]
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·Руководитель дипломной работы:

доцент кафедры ИБС А.А. Губенков
(учёная степень и звание) (подпись)



Задание принял к исполнению «____» ________________ 2012 г.



Студент Утанов Т.Д.
(фамилия, инициалы) (подпись)



Целевая установка и исходные данные:

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







Исходными данными являются: классификация уязвимостей веб-

приложений, статистика уязвимостей, автоматизированные инструменты

тестирования защищенности веб-приложений.



п.п.
Перечень чертежей, подлежащих разработке
Формат,
количество

1
«Тема дипломной работы»
Power Point, 1

2
«Анализ Web-приложений»
Power Point, 1

3
«Уязвимость»
Power Point, 1

4
«Классификация веб-уязвимостей»
Power Point, 1

5
«Методы анализа Web-приложений»
Power Point, 1

6
«Средства тестирования защищенности веб-приложений»
Power Point, 1

7
«Этапы тестирования Web-приложений»
Power Point, 1

8
«Определение структуры тестового сайта с помощью IBM Rational Appscan»
Power Point, 1

9
«Обнаружение уязвимостей типа SQL-Injection»
Power Point, 1

10
«Пример использования уязвимости типа SQL Injection»
Power Point, 1

11
«Поиск скрытых каталогов»
Power Point, 1

12
«Обнаружение конфиденциальной информации»
Power Point, 1

13
«Обнаружение XSS-уязвимостей с помощью Acunetix Web Vulnerability Scanner»
Power Point, 1

14
«Реализация XSS в сообщениях форума»
Power Point, 1

15
«Извлечение информации из базы данных тестового сайта с помощью Havij»
Power Point, 1

16
«Итоги тестирования»
Power Point, 1

17
«Заключение»
Power Point, 1


Руководитель научной работы:

Губенков А.А.
(фамилия, подпись)





Приложение





к заданию на дипломное проектирование






УТВЕРЖДАЮ





Руководитель работы:







к.т.н., доцент Губенков А.А.____________





(уч. звание, фамилия, подпись)






« »
2012 г.










КАЛЕНДАРНЫЙ ГРАФИК

п.п
Разделы, темы и их содержание
По плану
Фактически
Отметка руководителя о выполнении



дата
объем %
дата
объем %


1
Введение
28.03.
2012
5
29.03.
2012
5


2
Глава 1. Классификация веб-уязвимостей. Общая терминология.
30.03.
2012
10
01.04.
2012
10


3
Глава 2. Методы и средства обнаружения уязвимостей веб-приложений.
10.04.
2012

10
10.04.
2012

10


4
Глава 3. Обзор инструментов автоматизации поиска уязвимостей веб-приложений. Сканирование веб-приложений.
16.04.
2012
10
15.04.
2012
10


5
Глава 4. Экономическая часть
21.04.
2012
10
21.04.
2012
10


6
Заключение
21.05.
2012
5
21.05.
2012
5


7
Плакаты
26.05.
2012
5
27.05.
2012
5


8
Оформление
30.05.
2012
20
02.06.
2012
20












Студент Утанов Т.Д.
(фамилия, инициалы) (подпись)
«____»______________________2012 г.

АННОТАЦИЯ
Пояснительная записка содержит 71 лист формата A4, 13 рисунков, 11 таблиц. Использован 21 литературный источник.
Ключевые слова:
ВЕБ-ПРИЛОЖЕНИЕ, УЯЗВИМОСТИ, SQL ИНЪЕКЦИЯ, МЕЖСАЙТОВЫЙ СКРИПТИНГ, УТЕЧКА ИНФОРМАЦИИ, ТЕСТИРОВАНИЕ БЕЗОПАСНОСТИ, СКАНЕРЫ БЕЗОПАСНОСТИ, АНАЛИЗ ЗАЩИЩЕННОСТИ.

Дипломная работа посвящена автоматизации тестирования защищенности веб-приложений. Рассмотрена общая терминология уязвимостей веб-приложений, методы и средства их обнаружения. Приведен обзор инструментов автоматизации анализа защищенности веб-приложений. В результате описана общая схема тестирования безопасности веб-приложений, приведены примеры уязвимостей, найденных при помощи автоматизированных инструментов анализа защищенности.
THE ABSTRACT
The expla
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·ies scanners. As a result general scheme of web-application security testing were presented, examples of web-vulnerabilities found by security scanners were shown.
РЕФЕРАТ
Пояснительная записка к дипломной работе состоит из 4 глав, заключения и списка использованных источников.
В главе 1 проведен обзор общей терминологии веб-уязвимостей, описаны типичные примеры.
В главе 2 рассмотрены методы и средства обнаружения уязвимостей веб-приложений.
В главе 3 осуществлен обзор современных инструментов тестирования защищенности веб-приложений. Реализован анализ защищенности тестовых веб-приложений, на основе выбранных инструментов анализа.
В главе 4 проведен анализ современных подходов к оценке экономической эффективности анализа защищенности веб-приложений путем использования автоматизированных инструментов, расчет затрат на разработку схемы реализации тестирования, представлены основные экономические показатели.
В заключении изложены основные результаты дипломной работы.
В списке использованных источников указано 21 наименование литературных источников и электронных ресурсов удаленного доступа, использованных при написании дипломной работы.
Текстовая часть дипломной работы выполнена в текстовом редакторе Microsoft Office Word 2007. Рисунки созданы в графическом редакторе Paint.
СОДЕРЖАНИЕ
Введение.................................................................................................................11
1. Классификация веб-уязвимостей. Общая терминология..............14
1.1. «Abuse of Functionality» (Злоупотребление Функциональностью)...14
1.2. «Brute Force Attack» (Атака перебором)..15
1.3. «Cross-site Scripting» (Межсайтовое выполнение сценариев)...16
1.4. SQL Injection...17
1.5. XML Injection..22
1.6. Information Leakage (утечка информации)...24
1.7. Directory Indexing (индексация каталогов)..25
2. Методы и средства обнаружения уязвимостей веб-приложений.27
2.1. Метод получения идентифицирующей информации о web-приложении28
2.2. Метод статического анализа.29
2.3. Метод динамического анализа..29
2.4. Метод тестирования на проникновение..31
3. Обзор инструментов автоматизации поиска уязвимостей веб-приложений...38
3.1. Nikto38
3.2. IBM Rational Appscan39
3.3. HP WebInspect40
3.4. Acunetix Web Security Scanner..41
3.5. Burp Sui
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·Сканирование веб-приложений...46
4.1. N-Stealth HTTP Security Scanner...46
4.2. IBM Rational Appscan - demo.testfire.net.50
4.3. Acunetix Web Vulnerability Scanner - testasp.vulnweb.com58
4.4. Использование поисковых систем для поиска уязвимостей72
5. Экономическая часть...75
5.1. Расчет затрат на разработку программы75
5.2. Сравнительный анализ разработки
с имеющимися программами-аналогами.. 79
5.3. Расчет капитальных вложений...83
5.4. Расчет эксплуатационных затрат потребителя..84
5.5. Определение экономического эффекта..84
5.6. Сводные экономические показатели..85
Заключение..87
Библиографический список...89 Введение
В современных информационных системах широкое распространение получило использование web-приложений. Веб-приложения обладают такими важными достоинствами, как простота и привычность интерфейса, возможность удаленной работы через Интернет, быстрота разработки приложения. Вместе с этим веб-приложения создают большое число проблем, связанных с обеспечением информационной безопасности, ведь приложение становится доступным через Интернет не только для пользователей, но и для злоумышленников.
Уязвимости позволяют злоумышленникам похищать конфиденциальную информацию, проводить несанкционированные изменения данных, нарушать доступность приложения.
Как показывает многолетний опыт в области проведения работ по тестированию на проникновение и аудитов информационной безопасности - уязвимости в Web-приложениях по-прежнему остаются одним из наиболее распространенных недостатков обеспечения защиты информации. Другие часто встречающиеся проблемы - это низкая осведомленность сотрудников в вопросах ИБ, слабая парольная политика или повсеместное ее несоблюдение, недостатки в процессах управления обновлениями ПО, использование небезопасных конфигураций, и как это может показаться парадоксальным, не эффективное межсетевое разграничение доступа.
Несмотря на то, что уязвимости Web-приложений неоднократно описаны в «научно-популярной» и специализированной литературе, достаточно редко встречаются превентивные защитные механизмы, снижающие риски эксплуатации различных уязвимостей в них. Проблема защищенности Web-приложений усугубляется еще и тем, что при разработке Web-приложений, зачастую не учитываются вопросы, связанные с защищенностью этих систем от внутренних и внешних угроз, либо не достаточно внимания уделяется данному процессу. Это в свою очередь порождает ситуацию, в которой проблемы ИБ попадают в поле зрения владельца системы уже после завершения проекта. А устранить уязвимости в уже созданном Web-приложении является более расходной статьей бюджета, чем при его разработке и внедрении, при этом не стоит забывать о необходимости тестирования созданного продукта, для чего требуются квалифицированные специалисты непосредственно в области защиты информации. Тем временем, простота протокола HTTP позволяет разрабатывать эффективные методы автоматического анализа веб-приложений и выявления в них уязвимостей. Это значительно упрощает работу нарушителя, позволяя ему обнаружить большое число уязвимых веб-сайтов, чтобы затем провести атаку на наиболее интересные из них[1].
Кроме того, уязвимости некоторых типов допускают не только автоматическое выявление, но и автоматическую эксплуатацию. Именно таким образом производится массовое внедрение в веб-ресурсы вредоносного кода, который затем используется для создания бот-сетей из рабочих станций обычных пользователей сети Интернет. Возможность использования веб-приложений в качестве платформы для атаки на рабочие места пользователей сама по себе делает эти приложения привлекательной целью для нарушителя. Таким образом, при подготовке атаки на информационную инфраструктуру, например, какой-нибудь компании нарушители в первую очередь исследуют ее веб-приложения.
Недооценка серьезности риска реализации угроз ИБ с использованием Web-приложений, доступных со стороны сети Интернет, возможно, является основным фактором текущего низкого состояния защищенности большинства из них.
В наше время множество компаний и специалистов в области информационной безопасности стараются исследовать возможные уязвимости в веб, и разработать общую концепцию по защите веб-ресурсов глобальной сети Интернет. Ни для кого не секрет, что технологии не стоят на месте, с каждым годом человечество делает шаг вперед, в частности, разработчики сайтов уже знают многое о том как устранить ту или иную уязвимость, но и возможности злоумышленника всегда расширяются некими изящными техниками проникновения. Для того чтобы обеспечить безопасность своего веб-приложения, необходимо быть в курсе всех возможных слабых мест[2].
Далее, речь пойдет, как раз, об исследованиях в области анализа защиты веб-приложений, всевозможных уязвимостях веб-ресурсов, а так же методов и средств автоматизации их обнаружения.
Классификация веб-уязвимостей. Общая терминология
Перед тем как обращаться к всевозможным инструментам тестирования веб-приложений на вопрос безопасности и средствам обнаружения брешей в их защите, уделим внимание общей классификации веб-уязвимостей. Результатом работы членов Web Application Security Consortium является документ, содержащий общую классификацию уязвимостей (можно найти на официальном сайте проекта в открытом доступе http://projects.webappsec.org/w/page/13246927/FrontPage). Классификация делится на две части: описание атак (Attacks) и описание Слабых мест (Weaknesses). Рассмотрим ряд терминов и их описаний, представленных на сайте[3].
«Abuse of Functionality» (Злоупотребление Функциональностью)
Abuse of Functionality – техника, которая использует функции веб-сайта и его функциональность, для реализации атаки. Эти атаки имеют различные последствия, такие как потребление ресурсов, обман средств управления доступом или утечка информации. Примером реализации может являться злоупотребление функциональностью почтового клиента. Веб-приложения, предоставляющие услуги электронной почты, должны делать все возможное, чтобы пользователь не мог получить полный контроль над заголовками сообщения. Если атакующий может управлять каждой из частей отправляемого письма, (параметры «От», «Кому», «Тема», Тело сообщения) и нет никаких средств ограничения доступа к ним, почтовые функции могут быть превращены в механизмы спам рассылки.
Злоупотребление потоками восстановления пароля. Потоками восстановления пароля можно воспользоваться для выяснения данных учетных записей, которые обычно секретны. Хотя имена пользователей на многих веб-сайтах – общеизвестны и ничем не защищаются, остается много сайтов, таких как онлайновые банки, которые не показывают имя пользователя никому, кроме владельца учетной записи. Некоторые потоки восстановления пароля выполняют следующие шаги:
Запрос у пользователя имя пользователя/электронную почту
Оповещение пользователя, что сообщение было отправлено на его аккаунт
Передача пользователю ссылки, позволяющей изменить пароль
В этих потоках может быть утечка информации между первым и вторым шагом - подтверждение, что пользователь ввел допустимый адрес электронной почты и/или имя учетной записи. Этого можно избежать при наличии универсального обмена сообщениями на этом этапе или при реализации запроса более определенной информацию об учетной записи прежде, чем послать электронное письмо со ссылкой на сброс/смену пароля[4].
«Brute Force Attack» (Атака перебором)
Brute Force – метод атаки, с помощью которого пытаются определить неизвестное значение, путем автоматизации процесса перебора большого количества возможных значений. Атака использует в своих интересах факт, что энтропия значений меньше чем предполагается. Например, в то время как у 8 символьных алфавитно-цифровых паролей может быть 2.8 триллиона возможных значений, много людей выберут свои пароли из намного меньшего подмножества, состоящего из общих слов и последовательностей символов. Наиболее распространенный тип атаки перебором в веб-приложениях – «брут форс» учетных данных. Так как пользователи должны помнить пароли, они часто выбирают легкие для запоминания наборы символов (слова или фразы) в качестве паролей, тем самым делая атаку перебором при помощи словаря реализуемой. Это атака, в режиме которой злоумышленник пытается войти в систему, используя большой список слов и фраз как потенциальные пароли. Потенциальные пароли могут также включать изменения слов, характерных для паролей, таких как замена "o" с "0" и "i" с "1".
Если атакующему известно имя учетной записи, то он мог бы фиксировать его и выполнить итерации через список возможных паролей. Так же возможна фиксация пароля и выполнение итераций через список возможных имен пользователей. Второй метод, названный обратной атакой перебором, может только получить учетные данные случайного пользователя, но полезен, когда атакованная система блокирует пользователей после многих неудачных попыток авторизации.
«Брут форс идентификаторов сессии». Так как HTTP - протокол без сохранения информации о состоянии, чтобы поддерживать работу с веб-приложением, оно должно убедиться в том, что идентификатор сеанса отправлен браузером с каждым запросом. Идентификатор сеанса обычно сохранен в cookie HTTP или URL. Используя атаку перебором, атакующий может раскрыть идентификатор сеанса другого пользователя. Таким образом, атакующий сможет исполнять роль пользователя, получая персональные данные и выполняя действия от имени пользователя. На этом виды атак перебором не заканчиваются, их множество, разница заключается в том, что именно пытается подобрать злоумышленник, будь то код кредитной карты, имя удаленного файла (доступ к которому можно получить при знании его точного названия), или ответ на секретный вопрос пользователя в режиме восстановления пароля[5].
«Cross-site Scripting» (Межсайтовое выполнение сценариев)
Cross-site Scripting - метод атаки, в режиме выполнения которой в браузер жертвы включается код, разработанный злоумышленником. Экземпляр веб-клиента может быть стандартным клиентом веб-браузера, или объектом, встроенным в программный продукт, такой как браузер в пределах Winamp, читателя RSS, или почтового клиента. Сам код обычно пишется на HTML/JavaScript, но может быть написан и на VBScript, ActiveX, Java, Flash, или другой поддерживаемой браузером технологии. Когда атакующий спровоцирует браузер пользователя выполнить вредоносный код, то код будет запущен в пределах контекста защиты веб-сайта. С этим уровнем привилегий у кода есть возможность считать, изменить и передать любые уязвимые данные, доступные браузеру.
Различают три типа атак с использованием кросс-сайтовых сценариев: нестойкий, персистентный и на-основе- DOM. Нестойкие атаки и атаки на-основе- DOM требуют, чтобы пользователь посетил специальным образом обработанную ссылку, куда внедрен вредоносный код, или посетил веб-страницу, содержащую веб-форму, при работе с которой пользователь подвергнется атаке. Персистентные атаки реализуются путем внедрения вредоносного кода на веб-сайт, где он хранится определенный период времени. Примеры излюбленных объектов для внедрения вредоносного кода: сообщения доски объявлений (часто встречаются на сайтах), почтовые сообщения, веб-чат утилиты. В процессе реализации атаки, пользователь не обязан взаимодействовать с любым дополнительным сайтом/ссылкой, достаточно обычного просмотра веб-страницы, содержащей вредоносный код.
Пример 1: много веб-сайтов содержат доски объявлений, где зарегистрированные пользователи могут публиковать всевозможную информацию, которая сохранена в базе данных. Зарегистрированный пользователь обычно отслеживается системой, при анализе cookie ID сеанса, в результате чего, разрешается работа с объявлениями. Если злоумышленник выложит объявление, содержащее вредоносный JavaScript, то у пользователя, читающего это сообщение, могут быть похищены cookie, учетный данные.

Пример 2: атаки на основе DOM не требуют, чтобы веб-сервер получил вредоносный код XSS. Вместо этого атакующий использует режим выполнения, встраивая свои данные на сторону клиента изнутри страницы, поданной веб-сервером. Рассмотрим веб-страницу HTML, которая встраивает предоставленный пользователем контент на сторону клиента, то есть в браузер самого пользователя. Это очень распространенная практика. Например, у страницы HTML может быть код JavaScript, который встраивает Location/URL загруженной страницы на саму страницу. Этим URL может частично управлять и атакующий.
Например: Предположим что URLhttp:// www.vulnerable.site/welcome.html содержит следующий контент:

Welcome!
Hi


Welcome to our system

Эта страница будет использовать значение параметра "name" следующим способом. http://www.vulnerable.site/welcome.html?name=”Joe”. В этом примере код JavaScript встраивает часть документа (положение страницы) в страницу (которая отобразиться в браузере пользователя), без любого контроля безопасности.
Атакующий может воспользоваться этим, внедрив ссылку следующего содержания http://www.vulnerable.site/welcome.html?name=. Таким образом, злоумышленник сможет получить содержание документа cookie в обычном выпадающем сообщении (alert).
SQL Injection
Еще один распространенный в наше время вид атаки. SQL инъекция - метод атаки веб-приложений, в режиме которой создаются SQL- запросы на основе введенных пользователем данных. Когда атака доступна, злоумышленник получает возможность менять логику SQL-операторов, выполняемых в базе данных. Язык структурированных запросов (SQL) является специализированным языком программирования для того, чтобы отправлять запросы базам данных. Приложения часто используют предоставленные пользователем данные для создания SQL-операторов. Если приложение не в состоянии должным образом создать SQL-операторы, то атакующий получает возможность изменить структуру оператора и выполнить незапланированные и потенциально враждебные команды. Выполнение таких команд происходит под контекстом пользователя, определенного приложением, это позволяет атакующему регулировать все ресурсы базы данных, доступные под данным пользователем.
Пример 1: Инжекция SQL с использованием Динамических Строк.
Предположим, веб-форма аутентификации создает командную строку SQL, используя следующий метод:
SQLCommand = "SELECT Username FROM Users WHERE Username = '"
SQLCommand = SQLComand & strUsername
SQLCommand = SQLComand & "' AND Password = '"
SQLCommand = SQLComand & strPassword
SQLCommand = SQLComand & "'"
strAuthCheck = GetQueryResult(SQLQuery)
В этом коде разработчик комбинирует ввод от пользователя, strUserName и strPassword, с логикой SQL-запроса. Допустим, что атакующий для входа в систему представляет следующие данные:
Username: foo
Password: bar' OR ''='
Далее, система генерирует следующий запрос к базе данных, на основе введенных параметров:
SELECT Username FROM Users WHERE Username = 'foo'
AND Password = 'bar' OR ''=''
Этот запрос возвратит все строки из базы данных пользователей, независимо от того, является ли "foo" реальным именем пользователя, или "bar" - валидным паролем. Это происходит из-за оператора ИЛИ (OR), добавленного к условию ГДЕ (WHERE). Сравнение c''='' будет всегда возвращать "истинный" результат, делая условие ГДЕ (WHERE)истинным для всех строк в таблице. Если приведенные в пример параметры будут использоваться в целях аутентификации, то атакующий часто будет зарегистрирован как первый или последний пользователь в таблице Users.
Пример 2: Инжекция SQL в Хранимых процедурах.
Реализация SQL инъекции может происходить посредством внедрения параметризованных переменных, которые передаются к хранимым процедурам. Следующие примеры иллюстрируют потребность контролировать сами хранимые процедуры и средства, которыми они вызываются.
SQLCommand = "exec LogonUser '" + strUserName + "','" + strPassword + "'"
Использование хранимой процедуры не подразумевает, что оператор вызывает её в безопасном режиме. Злоумышленник может предоставить системе следующие входные данные, в целях реализации атаки:
Username: foo
Password: '; DROP TABLE Users--
Сгенерированный SQL запрос будет таким:
exec LogonUser 'foo',''; DROP TABLE Users--'
На SQL-сервере Microsoft, вышеупомянутая команда строки SQL выполнит два оператора: первый, вероятно, не идентифицирует пользователя для входа в систему, а второй удалит таблицу пользователей из базы данных.
Поиск возможности SQL Инъекции и Эксплуатация.
Есть два широко известных метода идентификации атаки с использованием SQL кода: SQL Инъекция и Слепая SQL Инъекция. Первый метод основан на анализе информации, предоставляемой в ошибках системы, сгенерированных во время тестирования. Эти ошибки часто включают текст уязвимого SQL-оператора и детали нарушения работы. Такая информация очень полезна, для реализации корректной SQL Инъекции. Пробуя различные комбинации данных, атакующий может протестировать систему на доступ к различным таблицам базы данных:
http://example/article.asp?ID=2+union+all+select+name+from+sysobjects
Сервер базы данных может возвратить ошибку, например такую:
Microsoft OLE DB Provider for ODBC Drivers error
'80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]All
queries in an SQL statement containing a UNION
operator must have an equal number of expressions
in their target lists.
Эта ошибка сообщает атакующему, что структура запроса была некорректной, но запрос будет успешен, если количество колонок запроса будет совпадать с исходным количеством.
Рассмотрим пример слепой SQLинъекции, которая обычно применяется, если сообщения об ошибках не предоставляют достаточное количество информации атакующему.Чтобы реализовать инъекцию данного типа, информация собирается иными способами. Один их типичных примеров- это анализ поведения системы, при передаче параметров, которые приводят к ложному или истинному результату SQL-оператора.
Если на сайте есть уязвимость, связанная с SQL Инъекцией, то при выполнении следующего запроса:
http://example/article.asp?ID=2+and+1=1
Должна возвратиться веб-страница:
http://example/article.asp?ID=2
Так как условие 1=1 всегда истинно. Тогда выполнение следующего запроса к веб-сайту:
http://example/article.asp?ID=2+and+1=0
Спровоцирует сайт вернуть ошибку или пустую страницу, так как условие 1=0 ложно. Как только атакующий определит, что сайт восприимчив к слепой SQL Инъекции, эксплуатация может продолжиться на основе других методов.
XML Injection
XML Инъекция является методом атаки, реализуемым в целях управления логикой XML приложения или службы. Инъекция непредназначенного контента (разработанного злоумышленником) в XML сообщение системы может изменить логику приложения. После чего, XML Инъекция может стать причиной вставки злонамеренного контента в итоговое сообщение/документ.
Рассмотрим следующий код в качестве примера:



joepublic
r3g
0
[email protected]


janedoe
an0n
500
[email protected]


Если атакующий желает ввести следующие значения для нового пользователя 'tony':
Username: alice
Password: iluvbob
E-mail: [email protected]Hackerl33tist0[email protected]_evil.net
Значит, итоговый документ будет иметь следующий вид:

·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
В этом примере новый пользователь (Hacker) будет введен в таблицу с идентификатором пользователя 0. Во многих случаях XML приложений, второй экземпляр идентификатора пользователя перекроет первый. В результате, атакующий получает нового пользователя Hacker, зарегистрированного с userid=0 (который часто используется в качестве администраторского uid – userid).
Другой тип XML Инъекции связан с использованием элементов CDATA, чтобы. Примером может служить XML код, где CDATA передает полезные нагрузки, вследствие чего поле CDATA, может использоваться, для ввода недопустимых символов, которые буду проигнорированы синтаксическим анализатором XML.

]]>

В этом примере приложение XML/HTML может быть подвергнуто атаке XSS, так как содержание элемента CDATA не подвергается анализу, и поэтому любой код внутри него будет пропущен схемами валидации.
Information Leakage (утечка информации)
Information Leakage - уязвимость приложения, при котором раскрываются важные данные, такие как технические детали веб-приложения, среда разработки или уникальные данные пользователей. Уязвимые данные могут использоваться злоумышленником в целях реализации атаки. Разумеется, утечка уязвимых данных должна быть ограничена или предотвращена, когда это возможно. Чаще всего утечка информации происходит из-за каких-либо ошибок обработки информации от пользователя, недочетов в организации разграничения доступа к компонентам веб-ресурса. Отказ обработки HTML/Script может привести к утечке чувствительной информации, такой как структура каталогов сервера, структура SQL-запроса. Всевозможные комментарии разработчиков в коде приложения, так же являются предметом защиты, и проще всего ликвидировать такие данные до выхода приложения в работу.
Пример.
Данный пример показывает, как некорректная реализация обработки ошибок дает возможность злоумышленнику изучить структура SQL запроса. Следующий текст ошибки был возвращен веб-приложением при введении апострофа в поле имени пользователя:
An Error Has Occurred.Error Message:
System.Data.OleDb.OleDbException: Syntax error (missing operator) in query expression 'username = ''' and password = 'g''. at System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling ( Int32 hr) at System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult ( tagDBPARAMS dbParams, Object& executeResult) at.
В данном случае раскрываются параметры SQL запроса, отрабатывающего на сервере и дает толчок к подготовке SQL-Injection атаке.
Directory Indexing (индексация каталогов)
Автоматическая функция веб-сервера, listing/indexing, которая перечисляет все файлы в требуемом каталоге, если запрашиваемый объект не найден (index.html/home.html/default.htm/default.asp/default.aspx/index.php).
Примером может служить обычное обращение к директории типа http://www.example.com/admin/, в результате чего, пользователь/злоумышленник сможет увидеть подкаталоги (разумеется, если уязвимость присутствует), на которые сам сайт в рабочем режиме не ссылается. Соответственно, злоумышленник, вероятно, сможет получить доступ к чувствительным данным.
Следующая информация может быть получена на основе каталога, индексирующего данные: файлы резервных копий - с расширениями, такими как .bak, .old или.orig; временные файлы - это файлы, которые обычно очищаются с сервера, но по некоторым причинам все еще доступны; скрытые файлы; именованные каталоги - атакующий может идентифицировать схему присвоения имен, которую использует веб-сайт, чтобы определить названия каталогов или файлов; содержание конфигурационных файлов - эти файлы могут содержать данные управления доступом и иметь расширения, такие как .conf, .cfg или.config[6].
2. Методы и средства обнаружения уязвимостей веб-приложений
На сегодняшний день согласно исследованиям OWASP (The Open Web Application Security Project, знаменита, например публикацией документа OWASP Top Ten, который содержит десятку самых распространенных веб-уязвимостей, членами проекта являются различные эксперты в области безопасности со всего мира, которые делятся своим опытом) наиболее эффективным способом обнаружения уязвимостей web-приложений является экспертный анализ исходных кодов web-приложения (code review). Этот способ весьма трудоемок, требует высокой квалификации эксперта и не защищен от ошибок эксперта. Поэтому активно развиваются методы автоматического обнаружения уязвимостей web-приложений.
Методы автоматического обнаружения уязвимостей web-приложений можно разделить на две основные группы: 1) методы, анализирующие работу развернутого на стенде web-приложения без обращения к исходным кодам web-приложения; 2) методы, анализирующие исходные коды web-приложения и конфигурационные настройки.
Первая группа методов рассматривает web-приложение с точки зрения внешнего пользователя, то есть потенциального злоумышленника. В эту группу входят следующие методы:
Метод получения идентифицирующей информации о web-приложении и выявления его уязвимостей с помощью бюллетеней безопасности (security advisory).
Метод тестирования на проникновение.
Вторая группа состоит из следующих методов:
Метод статического анализа исходных кодов web-приложения.
Метод динамического анализа исходных кодов web-приложения.
Для разработки web-приложений применяются разнообразные инструментальные средства и языки программирования. Наиболее популярными среди них являются PHP, Perl, Python, Ruby, Java/JSP, .Net/ASP. Стоит отметить, что возможности, предоставляемые этими средствами, существенно различаются, ограничивая применение тех или иных методов анализа[7].
2.1. Метод получения идентифицирующей информации о web-приложении
Метод получения идентифицирующей информации о web-приложении основан на посылке от имени обычного пользователя web-приложению набора HTTP-запросов, ответы на которые позволят сделать вывод о том, на каком web-сервере работает приложение, с помощью какой технологии оно разработано, какие версии программного обеспечения использует, какие стандартные компоненты оно использует и т.д. Для определения типа и версии web-сервера используется техника finger print, которая основана на том, что каждый web-сервер по-своему обрабатывает HTTP-протокол, в результате чего можно с высокой степенью вероятности определить тип и даже версию web-сервера путем посылки серверу набора корректных и некорректных запросов и анализа соответствующих ответов.
Для определения остальных параметров используется анализ HTTP-ответов и HTML-страниц средствами поиска регулярных выражений. Шаблоны для поиска задаются экспертом. Например, использование расширения .jsp в URI может свидетельствовать о том, что web-приложение было разработано с использованием технологии JSP.
Возможность получения идентифицирующей информации пользователем приложения является потенциальной уязвимостью в виду следующих причин: в сети Интернет накоплены огромные объёмы данных по уязвимостям программных продуктов с указанием версий программ, методов реализации а так ежедневно публикуют отчёты о новых найденных уязвимостях. Эта информация предназначена для администраторов и специалистов в области информационной безопасности, в тоже время она доступна через сеть Интернет всем желающим. Администраторы информационных систем часто не устанавливают обновления безопасности вовремя. В результате становится возможным взломать информационную систему путем использования всем известной уязвимости, которую администратор не закрыл установкой соответствующего обновления. В последние годы на хорошо известные и незакрытые уязвимости операционных систем было проведено большое количество атак, вызвавших широко известные эпидемии Интернет-червей.
Метод получения идентифицирующей информации о web-приложении и выявления его уязвимостей с помощью бюллетеней безопасности получил широкое практическое применение при проведении атак ввиду своей простоты и доступности. При этом сам метод не позволяет найти новые уязвимости web-приложения, а его полезность для обнаружения уязвимостей новых приложений состоит в том, что он позволяет указать на саму возможность утечки информации о web-приложении[8].
2.2. Метод статического анализа
Метод статического анализа исходных кодов web-приложения не предусматривает реального выполнения web-приложения. Вместо этого производится построение графов управления и зависимостей поданным и обнаружение уязвимостей посредством анализа этих графов.
Метод статического анализа исходных кодов web-приложения позволяет обнаруживать уязвимости, связанные с неустойчивостью web-приложения к некорректным входным данным. Другие классы уязвимостей данный метод обнаруживать не позволяет. Метод специфичен для каждой технологии создания web-приложений и требует от программиста аннотирования функций проверки корректности входных данных.
2.3. Метод динамического анализа
Метод динамического анализа исходных кодов web-приложения по своей сути аналогичен методу статического анализа исходных кодов за исключением того, что анализ производится в процессе выполнения web-приложения без построения графов программ. Вместо этого в процессе выполнения программы (т.е. неявно сформирован один из путей в графе управления) для каждой переменной производится вычисление типа безопасности, а для каждой размеченной функции сравниваются типы безопасности параметров со спецификацией, указанной в разметке.
Метод динамического анализа позволяет осуществлять обнаружение уязвимостей для широко применяемых при создании web-приложений динамических языков, как, например, Perl, PHP, Python, Ruby. В настоящее время для интерпретируемых языков web-приложений метод динамического анализа часто интегрируется в интерпретатор языка, например, Perl Tainted Mode для языка Perl, PHPrevent для языка PHP и Ruby’s Tainted Mode для языка Ruby.
Метод динамического анализа, в отличие от статического анализа, позволяет осуществлять обнаружение уязвимостей в генерируемом на лету коде. В тоже время, метод динамический анализирует лишь один из возможных графов выполнения программы и не позволяет сделать вывод об отсутствии уязвимостей во всей программе.
По данным статистики от компании Positive Technologies вероятность обнаружения уязвимостей в одном Web-приложении (т.е. эффективность оценки защищенности) при его детальном анализе выше, чем при автоматическом сканировании на 26%. Таким образом, можно сделать вывод, что анализ исходного кода и выполнение ручных проверок позволяет добиться лучших результатов, чем при автоматизированном сканировании. В работах по исследованию Web-приложений ручным способом применяются методы проверки приложений на основе системных журналов, исходных кодов, что увеличивает охват API системы, и как следствие, позволяет получить более объективную оценку защищенности исследуемых систем. Следовательно, ручной анализ исходных кодов более эффективен, однако не может быть применен при значительных объемах исходных кодов в связи с большими затратами времени.
Главная часть анализа исходного кода состоит в выполнение анализа транзакции. Приложение получает некие исходные данные и выдаёт другие выходные данные. Прежде всего, нужно определить все входные данные. Например такие как:
Данные полученные с браузера (HTTP);
Cookies;
Файлы;
Другие источники.
Так как входные данные изменяют состояние приложения, то с помощью входных
данных атакуют web-приложения. Анализ транзакции включает в себя не только данные полученные от пользователя, а так же данные передаваемые между клиентом и сервером.
Метод динамического анализа, аналогично статическому анализу специфичен для каждой технологии создания web-приложений.
Автоматизировать процесс анализа исходного кода веб-приложения поможет ряд утилит, который регулярно обновляется. Примером может служить инструмент Pixy, Ounce 6, Coverity Prevent Static Analysis или же RATS - Rough Auditing Tool for Security, предназначенный для кодов С++, PHP, Python, Ruby. Суть работы у большинства сканеров схожа, остается только выбрать подходящий по платформе и языкам исходников. Разумеется, знание языка исходного кода так же поможет[9].
2.4. Метод тестирования на проникновение
Метод тестирования на проникновение (penetration testing) рассматривает web-приложение с точки зрения внешнего пользователя, то есть потенциального злоумышленника. При этом считается, что злоумышленник обладает такими же возможностями, как и обычный пользователь, т.е. не имеет доступа к исходным кодам web-приложения, конфигурационным настройкам и т.п. Метод предусматривает тестирование работающего на стенде web-приложения путем посылки запросов, которые эмулируют пользовательскую активность, включающую, в том числе, и некорректные запросы, соответствующие действиям злоумышленника.
При поиске уязвимостей в web-приложении методом тестирования на проникновение возникают три основные задачи:
Получение и анализ структуры web-приложения.
Построение набора тестовых HTTP-запросов на основе построенной структуры web-приложения.
Прогон тестового набора с анализом ответов web-приложения для выявления уязвимостей.
Задача получения и анализа структуры web-приложения состоит в том, чтобы построить полный список URI web-приложения (URI = URL + URN.URL  (англ. Uniform Resource Locator) это часть URI, которая определяет адрес хоста сетевого ресурса. URN  (англ. Uniform Resource Name), это часть URI, которая определяет имя ресурса на хосте в локальном пространстве имён, и, соответственно, в определённом контексте),методов доступа к ним и списков их параметров, выделить URI, защищённые аутентификацией. Данная информация необходима для построения набора тестовых запросов к web-приложению. Для автоматического получения структуры web-приложения используются сетевые роботы (web crawlers). В случае статических HTML-страниц работа робота сводится к обходу всех доступных ссылок web-приложения, а в случае наличия форм и скриптов – к заполнению форм и извлечению гиперссылок из скриптов. Получение полной структуры web-приложения возможно не во всех случаях – основные проблемы возникают при заполнении web-форм и интерпретации скриптов.
Web-формы делятся на две категории: формы, содержащие только элементы с ограниченными областями значений (select, option ит.д.) и формы, содержащие элементы с неограниченными областями значений (например, text area). Обход страниц, связанных с посылкой форм первого типа осуществляется последовательным перебором всех комбинаций значений полей формы. Для переходов, связанных с заполнением текстовых полей, возможны два способа обхода: ручной или автоматизированный. При ручном способе управление процессом передаётся человеку, а при автоматизированном способе применяются
эвристические методы заполнения текстовых полей, основанные на словарях. Для форм, содержащих элементы с неограниченной областью значений, автоматизированный обход не гарантирует нахождения всех URI приложения.
Для автоматического обхода страниц, содержащих ссылки, формируемые средствами скриптовых языков, необходима возможность не только интерпретации скриптового языка, но и эмуляции действий пользователей для формирования тех или иных событий, например, onClick, onMove. Существующие средства интерпретации скриптовых языков не гарантируют выявления всех гиперссылок. Задача построения тестового набора запросов к web-приложению состоит в том, чтобы по исходным данным (список URI приложения, методы доступа, принимаемые параметры) подобрать запросы так, чтобы было обнаружено как можно больше уязвимостей. Существующие способы построения таких запросов рассмотрены ниже.
Построение запросов по базе ресурсов подразумевает, что существует база ресурсов, которые потенциально могут встретиться в структуре web-приложения. Наличие в web-приложении того или иного ресурса из базы свидетельствует об уязвимости, связанной с возможным доступом к этому ресурсу. Например, в web-приложении присутствуют имена известных уязвимых CGI-сценариев и имена конфигурационных файлов web-серверов. Поиск ресурсов происходит по всей структуре web-приложения. В каждом каталоге (из структуры web-приложения) по очереди запрашиваются все имена, представленные в базе ресурсов. Способ построение запросов по базе ресурсов полностью автоматический и опирается на накопленную информацию о характерных уязвимостях web-приложений. Таким образом, данный способ имеет ограничения, аналогичные рассмотренным выше в методе получения идентифицирующей информации, но в тоже время позволяет выявить новые уязвимости web-приложения, основанные на типовых ошибках разработчиков и администратора.
Генерация запросов по шаблону с типизированными параметрами состоит в том, что для каждого URI задаётся шаблон, параметры которого типизированы, после чего происходит автоматическая генерация запросов по заданному шаблону со случайным выбором значений конкретных параметров. Значения параметров могут задаваться регулярными выражениями. Данный способ используется для обнаружения ошибок проверки корректности введенных пользователем данных. Критерий наличия уязвимости вводит пользователь – если ответ web-сервера соответствует некоторому заданному регулярному выражению, то делается вывод об уязвимости приложения. Описанным способом также реализуются переборы паролей. Данный способ требует привлечения эксперта и тонкой настройки, так как необходимо для каждого ресурса web-приложения составить наборы значений параметров. При этом данный способ не зависит от технологии, на которой разработано web-приложение, так как работает только в терминах протокола HTTP.
Анализ настроек каталогов web-приложения заключается в том, что по структуре web-приложения проверяются типовые уязвимости, связанные с неправильным конфигурированием web-приложения и web-сервера. Сюда относятся проверка возможности автоматического построения индекса каталога, выполнения HTTP-методов PUT и DELETE, возможность обращения к ресурсам из областей аутентификации напрямую, возможность получения исходных кодов web-приложения.
Задача прогона тестового набора и анализа ответов сервера состоит с том, чтобы сделать правильный вывод о том, демонстрирует ли данный HTTP-запрос наличие уязвимости в web-приложении или нет. Данная задача тесно связана с задачей построения тестового набора, а основная проблема состоит в определении критериев наличия уязвимости. В настоящее время для решения этой задачи применяется метод, в котором распознавание осуществляется регулярными выражениями, задаваемыми экспертом. Таким образом, данный метод также требует тонкой настройки экспертом, при этом метод работает в терминах протокола HTTP и не зависит от технологии, на которой разработано web-приложение.
Метод тестирования на проникновение существенно меньше зависит от технологии разработки web-приложения, чем другие методы. Данный метод позволяет накапливать знания эксперта в виде набора правил построения запросов и набора шаблонов для анализа HTTP-ответов. Этот метод получил широкое распространение для выявления уязвимостей разработанных web-приложений, когда необходимо оценить наличие хотя бы типовых ошибок при разработке и настройке web-приложения. Достоинством данного метода является то, что метод позволяет оценивать развернутое и настроенное web-приложение, выявляя не только ошибки кодирования, но и ошибки конфигурирования web-сервера и web-приложения[10].
Таким образом, в области тестирования программного обеспечения существует целый раздел под названием Penetration Testing (Тестирование на проникновение). Penetration Testing - метод оценки безопасности компьютерных систем или сетей средствами моделирования атаки злоумышленника, чаще всего именуемого хакером. Процесс включает в себя активный анализ системы на наличие потенциальных уязвимостей, которые могут спровоцировать некорректную работу целевой системы, либо полный отказ в обслуживании. Анализ ведется с позиции потенциального атакующего и может включать в себя активное использование уязвимостей системы. Результатом работы является отчет, содержащий в себе все найденные уязвимости системы безопасности, а также может содержать рекомендации по их устранению.
При проведении теста на проникновение решаются задачи:
оценка текущего состояния системы защиты информации ИС;
выявление уязвимостей информационной системы;
использование обнаруженных уязвимостей для получения несанкционированного доступа или осуществления несанкционированного воздействия на информацию для демонстрации наличия уязвимостей и существования высоковероятных угроз информационной системе;
выработка рекомендаций по повышению эффективности защиты информации в ИС.
Существует два основных подхода в тестировании на проникновение:
Blackbox (черный ящик)
Whitebox (белый ящик)
При выборе уровня BlackBox исполнителю известен лишь диапазон внешних IP-адресов. Данный подход максимально приближен к действиям хакера, данные о тестируемом объекте будут собираться при помощи открытых источников, социальной инженерии и т.д. В режиме WhiteBox доступная исполнителю информация значительно шире. В этой ситуации специалистам может быть предоставлены документация, исходные коды, структура сети, а также полный доступ к тестируемому объекту.
Стоит заметить, что услуги тестирования на проникновение предлагают множество компаний (DigitalSecurity, Positivetechnologies, Trustwave, Информзащита и другие), то есть процесс проверки контролируется сторонней организацией, что обуславливает появление двух видов режима проведения такого рода тестирования, - это режим BlackHat и WhiteHat.В режиме BlackHat о проведении работ знают только руководители службы ИБ. В таком случае удается проверить уровень оперативной готовности к атакам сетевых администраторов и администраторов ИБ.В режиме WhiteHat исполнители работают в постоянном контакте со службой ИБ заказчика, ИТ-специалисты заказчика не препятствуют выполнению необходимых тестов, и основная задача сводится к обнаружению возможных уязвимостей и оценке риска проникновения в систему[11].
Для тестирования могут использоваться специальные инструменты (ряд из них доступен бесплатно), некоторые из них будут рассмотрены ниже.
3. Обзор инструментов автоматизации поиска уязвимостей веб-приложений
3.1. Nikto
Nikto - это известный сканнер веб-уязвимостей, способный сканировать удаленные хосты и проводить сложные тесты безопасности. Предназначен для платформ Windows и Unix. В базе программы имеется информация об более чем 3500 уязвимых сценариев. Информация об уязвимостях обновляется в виде специальных баз, подключаемых к программе как плагины. Увы, последний апдейт приложения был еще в далеком 2007 году, но базы с уязвимостями по-прежнему обновляются. Программа даже поддерживает автоматическое обновление баз[12].
Инструмент написан на языке Perl, поэтому вся работа осуществляется из командной строки. Помимо поиска уязвимых сценариев, Nikto позволяет определять версию веб-демона, отыскивать файлы с открытыми паролями, а также выполнять и многие другие проверки. Полноценная поддержка прокси (с возможностью авторизации), а также SSL-соединения при правильном подходе гарантируют безопасность проверяющего. Правда, о незаметном сканированию придется забыть. С самого начала разработчики сделали упор на скорость сканирования, не ломая голову над разработкой stealth-методов. С другой стороны, Nikto поддерживает ряд методик для обмана IDS, реализованных в библиотеке LibWhisker, но, увы, они по большей части устарели.
Возможности:
Сканирование хоста по определенному порту;
Сканирование хоста по набору портов в течение одной сессии;
Сканирование набора хостов в течение одной сессии (для этого можно создать отдельны текстовый файл, где будет указаны адреса хостов и порты, через которых будет необходимо осуществлять сканирование);
Сканирование через прокси сервер;
Вывод отчетов в формате CSV, HTML, SML, NBE.
Поддерживает ряд интерактивных функций, такие как отчеты по ошибкам, режим отладки, переключение по хостам, пауза и другие.
3.2. IBM Rational Appscan
Маститый коммерческий продукт под Windows, который изначально разрабатывался авторитетной компанией Watchfire, а потом был куплен IBM. Rational Appscan предназначен для аудита WEB-приложений и содержит не один десяток эвристических методов для корректного изучения каждого узла. Поиск уязвимостей осуществляется автоматически, главное - правильно задать все параметры сканирования с помощью специального мастера. На выходе специалист получает отчет о проделанной работе сканера, с помощью которой воссоздается, структура сайта, а также список возможных уязвимостей. Appscan конкретно указывает вредоносные сценарии, распределяя слабые места в соответствии с категорией уязвимостей. SQL Injection, Cross-Site Cripting, Posion Null Byte Files Retrieval, HTTP response splitting, parameter tampering, hidden field manipulation, backdoors/debug options, buffer overflows – это еще малая часть списка[13].
Список возможных брешей впечатляет: если взять SQL Injection, то в отчете можно легко найти разделы с возможными слепыми инъекциями, инъекциями с помощью cookies, инъекции и на странице авторизации и т.д. Сам сканнер может показать, какой именно параметр можно эксплуатировать. Одна из немаловажных особенностей - это сканирование сложных приложений, содержащих обилие JavaScript / AJAX - кода, Adobe Flash вставок. Специалистам по информационной безопасности Appscan полезен еще и тем, что содержит 40 готовых отчетов о соответствии требованиям, включая требования стандартов безопасности данных PCI, ISO 17799, ISO 27001, Basel II, SB 1386 и PABP Payment Application Best Practices), что не может не радовать.
3.3. HP WebInspect
Этот сканнер, который теперь принадлежит компании HP, также ранее разрабатывался другой командой security-специалистов, а именно SPI Dynamics. Весь процесс сканирования сопровождается интерактивным отчётом, что позволит быстро войти в курс дела. Так же, разработчики позаботились о том, чтобы максимально заточить его для выполнения тестов на проникновение.
Объектом исследования могут быть всевозможные скрипты, динамически обновляемые сервлеты и фреймворки. WebInspect позволяет выявлять большинство существующих уязвимостей, которые наиболее часто встречаются на сайтах. WebInspect отлично справляется с анализом сложных Web 2.0 сайтов, построенных на современных JS-фреймворках и повсеместным применением Ajax. Также как и Appscan, продукт умеет декомпилировать SWF-файлы, т.е. элементы сайта на Flash и анализировать Action Script код. Причем помимо непосредственно сканнера, в продукт входит дюжина вспомогательных утилит: для создания дампа базы данных, используя SQL-инъекцию, брутфорс форм, редактор, снифер HTTP запросов и т.д.
Совсем недавно компания HPпредставила свою новую разработку - HP WebInspect Real-Time. Продукт является программным решением для динамического тестирования безопасности приложений, которое анализирует программный код приложения в режиме реального времени, тем самым обеспечивая наибольшую точность при поиске уязвимостей. HP WebInspect Real-Time «вторгается» в приложение путем запуска внешних автоматизированных тестов безопасности. Затем программа анализирует «поведение» кода приложения в условиях внешней атаки и собирает внутреннюю информацию о приложении, в том числе данные на уровне кода. Такое взаимодействие технологий в режиме реального времени обеспечивает более точное обнаружение опасных уязвимостей и предоставление имеющихся способов снижения угроз, пояснили разработчики[14].
3.4. Acunetix Web Security Scanner
Acunetix Web Security Scanner представляет собой полностью автоматизированный сканнер уязвимостей. Сначала программа исследует и формирует структуру сайта, обрабатывая все найденные ссылки и собирая информацию обо всех обнаруженных файлах. Затем приступает к тестированию всего веб-приложения, моделируя ввод данных с использованием фаззера, использованием подстановок различных параметров и сниппетов (небольшой фрагмент исходного кода или текста), которые могут помочь обнаружить брешь в защите. Среди доступных для обнаружения уязвимостей есть множество видов SQL injection, Crosssite scripting, CRLF injection и т.д.
Немного о термине «фаззер». Термин Fuzzing появился еще в 1988 году в работе "The Fuzz Generator", опубликованной Бартом Миллером. Именно ему впервые пришла идея подсовывать программе заведомо некорректные и зачастую вообще случайные данные, отлавливая ситуации, когда та не сможет их обработать и вылетит. Таким образом, в нашем случае фззингом является составление и отправка всевозможных запросов к веб-приложению в надежде найти его уязвимости.
Рассматриваемый сканер содержит в своем арсенале уникальную функцию AcuSensor. Стандартные методы сканирования основываются на анализе ответов, которые возвращает веб-приложение на различные запросы, AcuSensor же позволяет провести намного более глубокое тестирование при условии, что у тестирующего на руках есть исходный код приложения. В этом случае можно комбинировать стандартные механизмы сканирования с глубоким анализом кода. В итоге есть возможность получить не просто информацию о возможной уязвимости, но и конкретный кусок кода, где она найдена, включая номер строки, трейс стека и содержанием SQL-запроса, который при этом отправляется серверу базы данных. Таким образом, пользователь получает возможность обнаружения уязвимостей, которые невозможно обнаружить при обычном сканировании. На текущий момент технология AcuSensor доступна для PHP и .NET приложений. На сайте разработчика можно найти краткое описание работы технологии AcuSensor, а так же познакомиться с примерами результатов сканирования. Детальный отчет сканирования удобен для просмотра, в pdfформате, и содержит достаточную информацию – общую статистику найденных уязвимостей, характеристики самого сканирования (время, целевой узел, используемый профиль настроек, технологии, ОС), описание каждой из найденных уязвимостей[15].
3.5. Burp Suite
Из названия видно, что это не одна утилита - а целый комплекс инструментов для Penetration теста. Самая главная часть программы является Burp Proxy, который устанавливается в качестве локального веб-сервера и перехватывает весь HTTP/HTTPS трафик, после чего будет возможность подкорректировать трафик, направленный к приложению. Другие утилиты, а именно Spider, Intruder, Scanner, Repeater, Sequencer, Decoder и Comparer связаны как с этой самой прокси, так и между собой. Например, часть перехваченных Burp Proxy параметров можно протестировать на предмет проверки со стороны сервера. Для этого достаточно отправить его в Burp Intruder. Последний заслуживает особенное внимание, потому как именно с его помощью можно отыскать и SQL-инжекции, и XSS уязвимости - и много чего еще. На вход утилите передается объект проверки, задаются параметры, которые будут изменяться (на основе специально сформированных шаблонов) и выбирается тип атаки. Большая часть пакета предназначены не для автоматического взлома, а для помощи пентестеру. Зато утилита Scanner, доступная в Pro-версии, представляет собой полностью автоматизированный сканнер, способный самостоятельно обнаруживать уязвимости в веб-приложениях. Любопытным представляется режим "Live scanning", который проверяет на уязвимости именно те сайты, к которым идет обращение в данный момент времени.

3.6. Paros Proxy
Для того чтобы найти уязвимость нужно, как минимум, иметь перед собой картину того, что передается между сервером и клиентом по протоколу HTTP/HTPPS: запросы, кукисы, поля форм. Вдвойне здорово, когда такой HTTP-снифер изначально рассчитан на поиск уязвимостей. Paros Proxy ты не просто можешь на лету изменить сходящие HTTP/HTTPS запросы, логировать собственный трафик, но и использовать встроенные сканнеры, с помощью которых тут же проверять сценарии на наличие уязвимостей SQL Injection и XSS. Сам Paros Proxy работает в виде прокси-сервера, собирая всевозможную информацию во время твоего серфинга. Различные виды сканирования осуществляются за счет плагинов, которые в принципе можно писать саму.
3.7. Wapiti
Консольная утилита для аудита веб-приложений. В основе лежит принцип черного ящика (blackbox), когда анализируются не исходники приложения, а ответы сервера на запросы исследователя с измененными параметрами. Для этого утилита сначала анализирует структуру сайта, ищет доступные сценарии, параметры, а затем включает свой fazzer. Сейчас в арсенале программы - методики для определения инъекций в базы данных (включая HP/JSP/ASP SQL и XPath инъекции), XSS (крос-сайтовый скриптинг), LDAP инъекции, CRLF баги (HTTP Response Splitting), ошибки в обработке файлов, возможность выполнения команд. В отличие от ряда других сканеров уязвимостей, которые используют базу сценариев, которые могу нарушить безопасность веб-приложения, Wapiti настроен на поиск неизвестных уязвимостей. Скачать продукт можно на официальном сайте производителя, там можно познакомиться с командами и познакомиться с примером в
·

Приложенные файлы

  • doc 26564850
    Размер файла: 699 kB Загрузок: 1

Добавить комментарий