Лабораторный практикум по основам анализа защищенности веб-прил. Практикум по основам анализа защищенности вебприложений
 Скачать 1.08 Mb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ РОССИЙСКОЙ ФЕДЕРАЦИИ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Д.Н. Колегов ЛАБОРАТОРНЫЙ ПРАКТИКУМ ПО ОСНОВАМ АНАЛИЗА ЗАЩИЩЕННОСТИ ВЕБ-ПРИЛОЖЕНИЙ Учебное пособие Томск 2014 УДК 004(075.8) ББК 32.973-018.2я73 K60 Колегов Д.Н. К60 Лабораторный практикум по основам анализа защищенности веб-приложений : учебное пособие. – Томск : Издательский Дом Томского государственного университета, 2014. – 59 с. В учебном пособии приводятся теоретические сведения по основам анализа защищенности современных веб-приложений, рассматриваются методы поиска недостатков и уязвимостей, описываются методики выполнения лабораторных работ. Для студентов вузов, обучающихся по специальностям в области информационной безопасности и по специальности 10.05.01 «Компьютерная безопасность», преподавателей и специалистов в области защиты информации. УДК 004(075.8) ББК 32.973-018.2я73 Рецензенты: Г.П. Агибалов, доктор технических наук, профессор, заведующий кафедрой защиты информации и криптографии ТГУ; В.В. Кочетков, ведущий специалист по анализу защищенности веб-приложений ЗАО «Позитив Текнолоджис» © Д.Н. Колегов, 2014 ©Томский государственный университет, 2014 3 ПРЕДИСЛОВИЕ В настоящее время веб-приложения являются неотъемлемой частью информационно-телекоммуникационных и компьютерных технологий. Современные веб-приложения решают задачи сбора, хранения, обработки и анализа данных и широко используются в СМИ, электронной коммерции, АСУ ТП и т.д. При этом не только коммерческие компании создают и развивают собственные веб- приложения: государственный сектор также активно включается в процесс развития веб-сервисов, обеспечивающих предоставление онлайн-услуг. В связи с этим задача анализа защищенности веб- приложений является одной из самых актуальных в практической компьютерной безопасности. Учебное пособие представляет собой набор лабораторных ра- бот по основам анализа защищенности веб-приложений. Целью лабораторного практикума является развитие научно- образовательного обеспечения в области безопасности информа- ционно-телекоммуникационных и компьютерных технологий. Ос- новной задачей лабораторного практикума является получение обучающимися практических знаний и навыков поиска уязвимо- стей веб-приложений, ручного анализа результатов работы скане- ров безопасности веб-приложений и оценки эффективности специ- ализированных средств защиты. Предполагается, что обучающиеся к моменту начала выполне- ния лабораторного практикума прослушали курс «Компьютерные сети» или аналогичный ему, а также имеют базовые представления об используемых в современных веб-приложениях технологиях (HTTP, SSL/TLS, HTML/CSS, JavaScript/AJAX/DOM). При подготовке некоторых работ лабораторного практикума использовались материалы образовательной программы «Практи- ческая безопасность» ЗАО «Позитив Текнолоджис». Учебное пособие будет полезно студентам вузов, обучающихся по специальностям в области информационной безопасности, пре- подавателям и специалистам в области защиты информации. 4 ЛАБОРАТОРНЫЕ РАБОТЫ ПО АНАЛИЗУ ЗАЩИЩЕННОСТИ ВЕБ-ПРИЛОЖЕНИЙ В соответствии с теорией компьютерной безопасности реализа- ция угроз является возможной вследствие наличия уязвимостей в компьютерной системе. Одним из методов обеспечения безопас- ности компьютерных систем является анализ защищенности, по- нимаемый как процесс поиска (идентификации) недостатков и уязвимостей. Лабораторный практикум состоит из двух частей. В первой ча- сти обучающийся должен самостоятельно выполнить все лабора- торные работы. Он должен не просто механически выполнить каждый шаг той или иной работы, а детально исследовать все опи- санные в работе протоколы и технологии, добиваясь полного по- нимания выполняемых действий. В рамках второй части практи- кума обучающийся выполняет поиск уязвимостей в реальных веб- приложениях в рамках программ «Bug Bounty» или «Responsible disclosure». Обучающемуся необходимо найти и сообщить о 3-х любых уязвимостях в веб-приложениях, входящих в перечни [1, 2]. Лабораторный практикум включает следующие лабораторные работы по основам анализа защищенности веб-приложений: 1. Сбор информации о веб-приложении. 2. Тестирование защищенности транспортного уровня. 3. Тестирование защищенности механизма управления досту- пом. 4. Тестирование защищенности механизма управления сессия- ми. 5. Тестирование на устойчивость к атакам отказа в обслужива- нии. 6. Поиск уязвимостей к атакам CSRF. 7. Поиск уязвимостей к атакам XSS. 8. Поиск уязвимостей к атакам SQL-injection. 9. Поиск уязвимостей к атакам RCE. 10. Сканирование уязвимостей веб-приложений. Описание каждой лабораторной работы состоит из следующих элементов: название, цель, краткие теоретические сведения, по- 5 становка задачи, последовательность действий обучаемого, вопро- сов и дополнительных заданий. Для обеспечения условий выполнения лабораторных работ ис- пользуется следующее программное обеспечение: среда виртуализации VMWare Player; дистрибутивы Backtrack Linux или Kali Linux; среда выявления и эксплуатации уязвимостей Metasploit Framework; среда тестирования защищенности веб-приложений Burp Suite; среда эксплуатации уязвимостей веб-приложений BeEF; небезопасные веб-приложения проекта Web Goat; образы небезопасных веб-приложений проекта PentesterLab; online и offline небезопасные веб-приложения (см. приложе- ние); современные веб-браузеры (Internet Explorer, Google Chrome, Mozilla Firefox); программные средства инструментального анализа защищенно- сти XSpider или MaxPatrol ЗАО Позитив Текнолоджис, а также специализированные сканеры уязвимостей веб-приложений (например, Acunetix, AppScan, Burp Suite Pro, W3AF). Все необходимые для выполнения работ материалы (литерату- ра, информационные ресурсы, задачи повышенной сложности) приведены в приложениях. Сбор информации о веб-приложении Цель работы Целью лабораторной работы является обучение методам и средствам сбора информации об анализируемом веб-приложении. Краткие теоретические сведения Одним из первых этапов анализа защищенности любой компь- ютерной системы является сбор информации. В зависимости от используемой методологии анализа защищенности веб- приложения могут применяться различные методы и средства сбо- ра информации. Стоит отметить, что сбор информации, как прави- 6 ло, не характерен для методологии инструментального анализа защищенности (сканирования), а характерен для методологии те- стирования на возможность проникновения. Методы сбора информации делятся на активные и пассивные. Активные методы требуют непосредственного взаимодействия с исследуемым приложением путем отправки ему запросов и анали- за соответствующих ответов, а пассивные методы используют ин- формацию, отправляемую сервером веб-приложения его клиентам (например, HTTP-заголовки X-Frame-Options, Strict-Transport- Security и т.д.) без отправки запросов. При анализе веб- приложений, как правило, используются только активные методы. Активные методы делятся на методы с подключением к прило- жению (например, идентификация веб-сервера с помощью сканера Httprint) и методы без подключения (например, сбор информации о приложении поисковыми роботами, сканерами Интернет, и т.д.). В результате проведения сбора информации о веб-приложении могут быть получены: имена и IP-адреса сетевых узлов, на которых размещены веб- приложение и его компоненты; логины и пароли технологических учетных записей; комментарии разработчиков; данные о системном и прикладном ПО, применяемых средствах защиты и конфигурации веб-приложения; адреса электронной почты разработчиков приложения; исходный код серверной части веб-приложения; конфиденциальные файлы. Программными средствами получения необходимой информа- ции являются: поисковые системы (например, Google, Shodan, Bing); специализированные сканеры уязвимостей Интернет (напри- мер, http://un1c0rn.net/); инструментальные средства анализа защищенности сетей обще- го назначения (Nmap, Xprobe2, XSpider); инструментальные средства анализа защищенности сетей веб- приложений (AppScan, Acunetix, Burp Suite, ZAP, W3AF и т.д.). 7 Постановка задачи Выполнить сбор информации об анализируемом веб- приложении www.test.app.com Последовательность действий Будем рассматривать сбор информации на примере веб- приложения с условным именем www.test.app.com Шаг 1. В адресной строке браузера перейти по адресу www.test.app.com/robots.txt . Проанализировать содержимое файла. Сделать выводы о наличии «скрытых» директорий. Шаг 2. В адресной строке браузера перейти по адресу http://www.test.app.com/crossdomain.xml и, затем, по ад- ресу http://www.test.app.com/clientaccesspolicy.xml Проанализировать содержимое файлов. Сделать выводы о кор- ректности конфигурации политики междоменного взаимодействия RIA [3]. Шаг 3. Перейти по адресу http://www.google.com . Задать поисковые запросы, определяемые анализируемым приложением, например: site:www.test.app.com filetype:docx confidential site:www.test.app.com filetype:doc secret site:www.test.app.com inurl:admin site:www.test.app.com filetype:sql site:www.test.app.com intext: "Access denied" Проанализировать логику запросов и полученные данные. По- строить свои запросы, используя примеры из базы запросов [4]. Шаг 4. Перейти по адресу http://www.shodanhq.com . Задать следующий поисковый запрос: hostname:www.test.app.com Построить свои запросы для приложения www.test.app.com Шаг 5. Данный тест выполняется только для приложений, раз- мещенных в лабораторной сети. С помощью сетевых сканеров Nmap и Xprobe выполнить идентификацию ОС веб-сервера: # nmap –O www.test.app.com –vv # xprobe2 www.test.app.com 8 Шаг 6. Подключиться к веб-серверу, используя утилиту Netcat: # nc www.test.app.com 80 Отправить следующий GET запрос GET / HTTP/1.1 Host: www.test.app.com \r\n По заголовкам Server и X-Powered-By определить программ- ное обеспечение, реализующее веб-сервер и фрэймворк веб- приложения. В браузере установить расширение Wappalyzer, перейти по ад- ресу веб-приложения и проанализировать информацию о компо- нентах веб-приложения полученное через Wappalyzer. Шаг 7. С помощью сканера веб-серверов Httprint (дистрибутив Backtrack) или Httprecon (ОС Windows) выполнить идентифика- цию веб-сервера: # cd /pentest/enumeration/web/httprint/linux # ./httprint –h www.test.app.com –s signatures.txt С помощью сканера Wafw00f проверить наличие у веб- приложения подсистемы WAF: # cd /pentest/web/waffit # python ./wafw00f.py http://www.test.app.com # python ./wafw00f.py https://www.test.app.com Шаг 8. Выполнить тесты по идентификации поддерживаемых веб-сервером HTTP-методов. Для этого необходимо отправить с помощью Burp Suite или Netcat запрос следующего вида: OPTIONS / HTTP/1.1 Host: www.test.app.com \r\n 9 Проверить, поддерживает ли сервер обработку запросов с произ- вольными методами: DOGS / HTTP/1.1 Host: www.test.app.com \r\n Если веб-сервер поддерживает метод TRACE, то это может приве- сти к уязвимости к атаке Cross-Site Tracing (XST). Для проверки поддержки веб-сервером методы TRACE отправить запрос TRACE / HTTP/1.1 Host: www.test.app.com \r\n Веб-сервер поддерживает метод TRACE и потенциально уязвим к атаке XST, если получен ответа вида HTTP/1.1 200 OK Connection: close Content-Length: 39 TRACE / HTTP/1.1 Host: www.test.app.com Вопросы и задания 1. Найти административные интерфейсы коммуникационного и сетевого оборудования (видеокамеры, коммутаторы ЛВС, до- машние Wi-Fi маршрутизаторы, и т.д.), подключенные к сети Ин- тернет. 2. Известно, что адрес веб-интерфейса системы VMWare Horizon View HTML Access содержит строку portal/webclient/views/mainUI.html. Найти такие системы, доступные из сети Интернет. 3. Оценить количество коммутаторов Cisco Catalyst с админи- стративным веб-интерфейсом, подключенным к сети Интернет. 10 Тестирование защищенности транспортного уровня Цель работы Целью лабораторной работы является обучение методам и средствам тестирования защищенности служб SSL/TLS. Краткие теоретические сведения Защита транспортного уровня веб-приложения основана на использовании протоколов семейства SSL/TLS, имеющих значительное количество механизмов, функций и параметров защиты, реализация и конфигурация которых определяет в конечном итоге уровень защищенности веб-приложения. Несмотря на то, что в настоящее время известно много автоматизированных средств тестирования защищенности SSL/TLS (например, сервис www.ssllabs.com, программы SSLscan и SSLyze), детали их реализации, как правило, неизвестны или требуют дополнительного исследования, что иногда не позволяет полностью доверять результатам их работы. Одним из низкоуровневых и надежных средств тестирования защищенности служб SSL/TLS является клиент OpenSSL. Постановка задачи Выполнить тестирование защищенности служб SSL/TLS веб- сервера www.test.app.com. Последовательность действий Шаг 1. Выполнить базовые проверки SSL/TLS. Установить по- следнюю версию пакета OpenSSL. Запустить сетевой анализатор Wireshark. Выполнить тестовое подключение к серверу: # openssl s_client –connect www.test.app.com:443 Просмотреть трассировку установки соединения в Wireshark. Определить следующие параметры: версию протокола SSL/TLS, используемый криптографический набор (cipher suite), длину от- крытого ключа сервера, включение механизма сжатия данных. От- 11 править следующий HTTP-запрос и убедиться в получении ответа от сервера: GET / HTTP/1.1 Host: www.test.app.com Проверить поддержку сервером механизма «Sever Name Indica- tion» (SNI): # openssl s_client –connect www.test.app.com:443 –servername www.test.app.com Просмотреть трассировку установки соединения в Wireshark в этом случае. Поддержка расширения SNI идентифицируется путем установки соединения с опцией SNI и без нее. Если в ответ полу- чены различные сертификаты, то SNI поддерживается сервером. Если указанное в опции SNI имя неизвестно, то клиент выводит сообщение об ошибке или предупреждение. Шаг 2. Идентифицировать все поддерживаемые протоколы SSL/TLS, выполнив последовательно команды: # openssl s_client –connect www.test.app.com:443 –ssl2 # openssl s_client –connect www.test.app.com:443 –ssl3 # openssl s_client –connect www.test.app.com:443 –tls1 # openssl s_client –connect www.test.app.com:443 –tls1_1 # openssl s_client –connect www.test.app.com:443 –tls1_2 Просмотреть трассировку сканирования. Найти отличия в структуре сетевых сообщений для разных версий протокола. Шаг 3. Идентифицировать криптографические наборы (cipher suite), поддерживаемые сервером. Для получения всех поддержи- ваемых клиентом криптографических наборов выполнить команду 12 # openssl ciphers -v Для проверки поддержки, например, набора AES256-SHA выпол- нить следующую команду: # openssl s_client –connect www.test.app.com:443 –cipher AES256-SHA Проверить поддержку криптографического набора, содержащего шифр RC4: # openssl s_client –connect www.test.app.com:443 –cipher RC4-SHA Проверить, что при установке защищенного соединения крип- тографический набор выбирается в порядке, определяемом настройками сервера, а не клиента. Для этого из списка поддержи- ваемых сервером криптографических наборов выбрать три произ- вольных и выполнить команды, например: # openssl s_client –connect www.test.app.com:443 –cipher 'AES256-SHA256,AES128-SHA,DES-CBC-SHA' # openssl s_client –connect www.test.app.com:443 –cipher 'AES128-SHA256,AES256-SHA,DES-CBC-SHA' # openssl s_client –connect www.test.app.com:443 –cipher 'DES-CBC-SHA,AES128-SHA,AES256-SHA256' При корректной настройке во всех случаях должен быть выбран набор AES256-SHA256. Проверить поддержку сервером Forward Secrecy на основе DHE и ECDHE: # openssl s_client –connect www.test.app.com:443 –cipher 'ECDHE—RSA-AES256-SHA384' # openssl s_client –connect www.test.app.com:443 –cipher 'DHE—RSA-AES256-SHA256' 13 Шаг 4. Для определения поддержки сервером механизма «Ses- sion Resumption» выполнить команду # openssl s_client –connect www.test.app.com:443 –reconnect или ее менее информативный вариант # openssl s_client –connect www.test.app.com:443 –reconnect | grep 'New\|Reuse' Шаг 5. Для идентификации механизма «Secure Renegotiation» выполнить команду # openssl s_client –connect www.test.app.com:443 | grep 'Secure Renegotiation' Просмотреть трассировку сканирования и убедиться в под- держке данного механизма. Поддержка механизма «Secure Renego- tiation» сервером определяется по наличию расширения «renegotia- tion_info» в сообщение ServerHello или путем просмотра вывода команды # openssl s_client –connect www.test.app.com:443 –tlsextdebug Для идентификации поддержки сервером механизма «Client- Initiated Renegotiation» необходимо подключиться к веб-серверу по SSL/TLS с помощью клиента OpenSSL # openssl s_client –connect www.test.app.com:443 и затем отправить запрос: HEAD / HTTP/1.1 Host: www.test.app.com R или 14 GET / HTTP/1.1 Host: www.test.app.com R Если сервер не поддерживает«Client-Initiated Renegotiation», то будет выведено сообщение об ошибке. Если сервер поддерживает данный механизм, то сервер отправит клиенту снова свои серти- фикаты. Поддержка механизма «Client-Initiated Renegotiation» может быть использована для реализации в отношении веб-сервера DoS- атаки, так как при каждом установлении соединения сервер вы- нужден тратить существенно больше вычислительных ресурсов чем клиент. Чтобы проверить возможность реализации DoS-атаки, можно проверить, сколько раз клиент может инициировать пересогласо- вание (renegotiation) криптографических параметров: GET / HTTP/1.1 Host: www.test.app.com R R R R R Другой способ тестирования – использование эксплоита thc-ssl- dos [6], например: # thc-ssl-dos ––accept 192.168.1.1 443 Шаг 6. Проверить наличие уязвимости к атаке «BEAST». Дан- ная атака использует недостатки блочных шифров, работающих в режиме CBC, и существует во всех версиях протоколов SSL/TLS до версии TLS 1.1. Для того чтобы защититься от атаки BEAST, необходимо использовать шифр RC4 или протокол TLS версии 1.1 и старше. С другой стороны, шифр RC4 в настоящее время счита- ется небезопасным, поэтому его использование нежелательно. Для 15 защиты от атаки BEAST на практике предлагается два подхода: первый из них носит название «Строгое ослабление» (Strict mitiga- tion) и предполагает использование протокола TLS версии 1.1 и старше со всеми клиентами, которые его поддерживают; второй подход называется «Приоритезация RC4» (RC4 prioritization) и за- ключается в повышении приоритета шифра RC4 для клиентов, поддерживающих только протоколы SSL 2.0, SSL 3.0 и TLS 1.0. Таким образом, необходимо убедиться, что клиенты SSL 3.0 или TLS 1.0, не поддерживающие шифр RC4, не смогут установить соединение: # openssl s_client –connect www.test.app.com:443 –no_ssl2 –no_tls1_1 –no_tls1_2 –cipher 'ALL:!RC4' или что клиенты, поддерживающие шифр RC4, установят соеди- нение, используя его # openssl s_client –connect www.test.app.com:443 –no_ssl2 –no_tls1_1 –no_tls1_2 –cipher 'ALL:+RC4' Шаг 7. Проверить наличие уязвимости к атаке «Heartbleed» по косвенным признакам, а также путем использования активных те- стов в Metasploit Framework. Просмотреть трассировку в Wireshark и определить поддержку расширения «Heartbeat» после выполнения команды # openssl s_client –connect www.test.app.com:443 –tlsextdebug Проверить поддержку сервером протокола «Heartbeat» через OpenSSL путем выполнения команды # openssl s_client –connect www.test.app.com:443 –tlsextdebug Если сервер не возвращает в сообщениях данные о расширении «Heartbeat», то он не уязвим к данной атаке. 16 Для того чтобы проверить, отвечает ли сервер на запросы Heartbeat, выполнить команды # openssl s_client –connect www.test.app.com:443 –msg Для проверки уязвимости клиента (например, веб-браузера) к Heartbleed атаке можно установить соединение с любым сервером и просмотреть трассировку соединения. Рассмотрим вариант активного тестирования (выполнение ата- ки с использованием уязвимости) в среде Metasploit Framework. Для тестирования клиента выполнить следующие команды: # msfconsole > use auxiliary/server/openssl_heartbeat_client_memory > show options > run В веб-браузере открыть ресурс Metasploit, отвечающий за те- стирование на наличие уязвимости к атаке Heartbleed и просмот- реть информацию о результате тестирования клиента. Для тестирования сервера в среде Metasploit Framework выпол- нить следующие команды: # msfconsole > use auxiliary/scanner/ssl/openssl_heartbleed > show options > set RHOSTS www.test.app.com > set RPORT 443 > set VERBOSE true > run С помощью проекта http://un1c0rn.net найти веб-серверы, уязвимые к атаке Heartbleed (в крайнем случае, можно использо- вать тестовые сервера, уязвимые атаке Heartbleed, например heartbleed.csr-group.com). Подтвердить уязвимость к атаке в среде Metasploit Framework или с помощью сервиса http://ssllabs.com 17 Шаг 8. Проверить наличие уязвимости к атаке «CRIME» по косвенным признакам. Данная атака основана на сжатии данных на уровне SSL/TLS. Для проверки достаточно выполнить команду # openssl s_client –connect www.test.app.com:443 –reconnect | grep 'Compression' Шаг 9. Проверить наличие HTTP-заголовков Strict-Transport- Security, устанавливаемых на стороне веб-сервера. Отправить сле- дующий HTTP-запрос к веб-приложению в программе Burp Suite GET / HTTP/1.1 Host: www.test.app.com \r\n HTTP-ответ должен содержать заголовок следующего вида: Strict-Transport-Security: max-age=31536000; includeSubDomains Проверить наличие страниц со смешанным контентом (mixed- content pages) – страниц, доступных по HTTPS, но содержащих ресурсы (картинки, скрипты JavaScript, файлы CSS, медиа- контент), доступные по протоколу HTTP. Для этого следует скон- фигурировать браузер для работы с тестируемым веб- приложением через веб-прокси Burp Suite, в процессе работы с веб-приложением необходимо во вкладке HTTP History просмот- реть историю и удостовериться, что все запросы к серверу отправ- ляются только по протоколу HTTPS. Проверить, что cookie, содержащие чувствительную информа- цию, имеют атрибут secure, например: Set-Cookie: SessionId=371d2sm6cbn3d31a;path=/;secure Проверить, что чувствительный контент не кэшируется на сто- роне клиента. Запрещение кэширования определяется наличием 18 HTTP-заголовков Pragma, Cache-Control и Expires со следующими рекомендованными значениями: Pragma: no-cache Cache-Control: no-cache, no-store, must-revalidate, max-age=0 Expires: 0 Проверить, что приложение защищено от атаки «SSL Stripping». Для этого необходимо убедиться, что веб-приложение доступно только по протоколу HTTPS и не доступно опционально по протоколу HTTP или в веб-приложении используется заголовок Strict-Transport-Security (при условии того, что пользователь га- рантированно попадет на сайт по протоколу HTTPS). Шаг 10. Выполнить тестирование SSL/TLS с использованием сервиса ssllabs.com. В веб-браузере перейти по адресу https://www.ssllabs.com/ssltest/index.html , ввести до- менное имя сервера, выполнить сканирование, просмотреть и про- анализировать полученные результаты. Сравнить результаты сканирования сервера с результатами, по- лученными при его ручном тестировании. Выполнить тестирование нескольких веб-клиентов (например, веб-браузеров Internet Explorer, Mozilla Firefox, Google Chrome, WhiteHat Security Aviator, Яндекс Браузер, Apple Safari, Opera и т.п.). Для этого в каждом тестируемом браузере открыть страницу https://www.ssllabs.com/ssltest/index.html , выполнить сканирование, просмотреть и проанализировать результаты. Вопросы и задания 1. Проверить произвольный веб-сервер, поддерживающий SSL/TLS, на соответствие рекомендациям Qualys SSL Labs [7]. 2. Написать скрипт, выполняющий идентификацию всех под- держиваемых сервером криптографических наборов SSL/TLS. 3. Просканировать веб-серверы 10 известных компаний, бан- ков, операторов связи с помощью сервиса ssllabs.com. Проанали- зировать результаты. 19 Тестирование защищенности механизма управления доступом Цель работы Целью лабораторной работы является обучение методам и средствам тестирования защищенности механизма управления доступом в веб-приложениях. Краткие теоретические сведения Одним из основных механизмов защиты современных веб- приложений является механизм управления доступом. Обычно выделяют следующие этапы управления доступом [8]: − идентификация – установление идентификационных данных; − аутентификация – подтвержденное установление идентифика- ционных данных; − авторизация – назначение прав идентификационным данным. При входе в веб-приложение (sign in, log in) пользователь иден- тифицируется (сообщает свой идентификатор) и аутентифициру- ется (доказывает, что он именно тот пользователь, чей идентифи- катор был сообщен). Большинство веб-приложений используют аутентификацию по паролю. В веб-приложениях с высоким уровнем защищенности (например, в Интернет-банках) также применяются протоколы двухфакторной аутентификации. Очевидным недостатком аутен- тификации по паролю является возможность использования паро- лей с плохими статистическими характеристиками. Хранение па- роля или его передача по каналам связи в открытом или даже за- шифрованном виде потенциально несет угрозу раскрытия пароля. Тем не менее, современные защищенные веб-приложения в большинстве случаев используют передачу пароля в зашифрован- ном виде с помощью протоколов семейства SSL/TLS, а хранение пароля в хешированном виде. При этом для хранения паролей пользователей рекомендуется использовать не криптографические хэш-функции общего назначения (например, SHA или MD5), а специализированные функции PBKDF2, bcrypt, scrypt и т.п. Также для хранения паролей необходимо использовать «соль», предна- 20 значенную для затруднения проведения атак по словарям и радуж- ным таблицам. Авторизация в веб-приложениях может быть определена как процесс проверки того, разрешен или запрещен запрос на получе- ния доступа пользователя к ресурсу в соответствии с заданной по- литикой безопасности. Как правило, в веб-приложениях реализу- ется ролевая (RBAC) или атрибутная (ABAC) политика логическо- го управления доступом. Одним из методов тестирования возможности получения при- вилегий другого пользователя является дифференциальный ана- лиз. Его идея заключается в идентификации всех возможных за- просов и соответствующих им URL, которые может выполнить данный пользователь. Затем все полученные запросы выполняются от имени другого пользователя веб-приложения. Механизм авторизации рекомендуется реализовывать на уров- нях представления, бизнес-логики и данных веб-приложения. Уро- вень представления – не отображает функционал (например, фор- мы, фреймы, ссылки, кнопки), на который пользователь не имеет прав доступа. Уровень бизнес-логики обеспечивает выполнение проверки наличия соответствующих прав доступа до выполнения запроса в веб-приложении, т.е. никакие функции не могут быть выполнены до авторизации (например, если пользователь отправ- ляет запрос на удаление учетной записи, то веб-приложение долж- но убедиться, что пользователь имеет право на удаление учетной записи и не выполнять никаких функций до того, как это будет установлено). Уровень данных обеспечивает проверку наличия прав доступа пользователя к данным, а не только к функционалу обработки данных (например, пользователь, используя URL вида /delete?record=1, должен удалять только те записи в базе данных, на которые он имеет право доступа DELETE). Постановка задачи Выполнить тестирование защищенности механизма управления доступом исследуемого веб-приложения. 21 Последовательность действий Шаг 1. Настроить работу браузера через штатный прокси- сервер Burp Suite. В веб-браузере открыть главную страницу те- стируемого веб-приложения www.test.app.com Шаг 2. Зарегистрироваться в веб-приложении. Получить иден- тификатор учетной записи и пароль доступа к веб-приложению. Проанализировать предсказуемость идентификаторов пользовате- лей и, если это возможно, алгоритм назначения идентификаторов. Проанализировать реализованную в веб-приложении парольную политику. Оценить доступную сложность выбора паролей пользо- вателями. Опционально выполнить атаку полного перебора паро- лей. Шаг 3. Перейти по ссылке для аутентификации в приложении. При этом необходимо убедиться, что форма аутентификации до- ступна только по протоколу HTTPS. Убедиться, что вводимые пользователем логин и пароль отправляются в зашифрованном виде по протоколу HTTPS. Убедиться, что логин и пароль не от- правляются с помощью HTTP-метода GET. Шаг 4. Проверить, что в веб-приложении изменены стандарт- ные пароли для встроенных учетных записей. Проверить, что но- вые учетные записи создаются с различными паролями. Шаг 5. Проверить возможность идентификации пользователей веб-приложения через формы регистрации, входа и восстановле- ния пароля. Для этого следует ввести несуществующее имя пользователя (например, qawsedrf1234) и произвольный пароль, а затем имя су- ществующего пользователя и произвольный, но неправильный па- роль. В обоих случаях должно быть выведено одно и то же сооб- щение об ошибке вида «Ошибка в имени пользователя или невер- ный пароль». Также оба HTTP-ответа должны совпадать с точно- стью до изменяемых параметров и быть получены за одно и то же время. В противном случае веб-приложение имеет скрытый канал (оракул), позволяющий идентифицировать его пользователей. Шаг 6. Проверить возможность реализации атаки подбора па- роля пользователя. Ввести имя пользователя. Ввести несколько раз неправильный пароль (5 – 10 раз). После этого ввести правильный 22 пароль для этой учетной записи. Ввести одинаковый пароль для разных учетных записей (для 5 – 10). Проверить возможность доступа к веб-приложению. Блокиро- вание учетных записей пользователя после нескольких неудачных попыток входа создает условие для реализации DoS-атаки и не должно использоваться в механизмах защиты от атак подбора па- ролей. Вместо этого необходимо использовать возрастающие вре- менные задержки или средства анти-автоматизации (например, CAPTCHA). Шаг 7. Проверить, что чувствительный контент (например, страницы с введенными номерами кредитных карт, счетов, адре- сов) не доступен через механизм History веб-браузера, а также не кэшируется им. Войти под учетной записью пользователя, перейти на страницу с чувствительным контентом. Ввести новые данные. Выйти из приложения. Нажать кнопку «Back». Пользователь не должен иметь возможность выполнять новые запросы (при кор- ректной реализации управления сессиями). Если при этом пользо- вателю доступны ранее запрашиваемые страницы, то это означает, что серверная часть веб-приложения не запретила веб-браузеру сохранять данные в истории. Запрещение кэширования определяется наличием HTTP- заголовков Pragma, Cache-Control и Expires со следующими реко- мендованными значениями: Pragma: no-cache Cache-Control: no-cache, no-store, must-revalidate, max-age=0 Expires: -1 Шаг 8. Запустить веб-приложение Web Goat. Ввести логин: «guest», пароль: «guest». Перейти по ссылке « Access Control Flaws → Bypass a Path Based Access Control ». Изучить условия задачи. Ис- пользуя FireBug (или любой аналогичный инструмент), изменить значение AccessControlMatrix.html на ../../main.jsp. Нажать кнопку « View File ». 23 Перейти по ссылке « LAB: Role Based Access Control → Stage 1 ». Изучить условия задачи. Войти под пользователем Tom (пароль: Tom ). Можно видеть, что от пользователя скрыта кнопка « DeleteProfile », так как он не должен иметь возможности уда- лять учетные записи. Нажать кнопку « View Profile ». В Burp Suite просмотреть запрос. Используя FireBug (или любой анало- гичный инструмент), изменить HTML-размету, заменив элемент на элемент Нажать кнопку « DeleteProfile ». Просмотреть отправленный запрос в Burp Suite. Профиль пользователя будет удален. Опционально решить задачу « LAB: Role Based Access Control → Stage 2 ». Перейти по ссылке « LAB: Role Based Access Control → Stage 3 ». Изучить условия задачи. Войти под пользователем Tom (пароль: Tom). Нажать кнопку « View Profile ». В Burp Suite про- смотреть запрос. Можно видеть, что пользователю доступны дан- ные своего профиля. Используя FireBug (или любой аналогичный инструмент), изменить HTML-размету, заменив элемент на элемент 24 Нажать кнопку « ViewProfile ». Просмотреть отправленный запрос в Burp Suite. Будут выведены данные профиля пользователя Curly Stooge. Опционально решить задачу « LAB: Role Based Access Control → Stage 4 ». Перейти по ссылке « Remote admin access ». Изучить условия задачи. Просмотреть подменю « Admin Functions ». Перейти по ссылке WebGoat/attack?Screen=86&menu=200&admin=true. Просмотреть подменю «Admin Functions». Вопросы и задания 1. Изучить рекомендации к защищенной реализации механизма хранения паролей. Исследовать механизм восстановления паролей выбранного веб-приложения. 2. Исследовать минимально допустимую длину и сложность паролей в произвольных пяти веб-приложениях из рейтинга ALEXA TOP 100. 3. Исследовать наличие оракулов в механизмах аутентифика- ции произвольных пяти веб-приложениях из рейтинга ALEXA TOP 100. Тестирование защищенности механизма управления сессиями Цель работы Целью лабораторной работы является обучение современным методам и средствам тестирования защищенности механизма управления сессиями в веб-приложениях. Краткие теоретические сведения Сессия веб-приложения – это последовательность HTTP- запросов и соответствующих им HTTP-ответов, ассоциированных с конкретным пользователем. Протокол HTTP не имеет встроен- ных механизмов управления сессиями (stateless protocol) и поэтому механизм управления сессиями реализуется логикой веб- приложения. Как минимум, сессия создается при успешной аутен- 25 тификации пользователя в веб-приложении. При этом генерирует- ся уникальный идентификатор (токен) сессии, ассоциированный с этим пользователем. Данный идентификатор передается в каждом HTTP-запросе и является аналогом пароля пользователя, так как любой HTTP-запрос, содержащий такой идентификатор, будет воспринят веб-приложением как запрос от легитимного пользова- теля. Как правило, идентификатор сессии передается в заголовках Cookie средствами веб-браузера, реже в специальных HTTP- заголовках (например, X-Auth-Token) средствами AJAX. Передача идентификатора сессии в URL является наименее защищенной и в настоящее время, как правило, не применяется. Приведем основные требования безопасности к реализации ме- ханизма управления сессиями [8]: − имя сессионного идентификатора не должно позволять легко идентифицировать веб-приложение (например, PHPSESSID, ASP.NET_SessionId, JSESSIONID); − длина сессионного идентификатора должна быть не менее 128 бит; − энтропия сессионного идентификатора должна быть не менее 64 бит; − передача сессионного идентификатора должна осуществляться в заголовках Cookie с флагами HttpOnly, Secure и выставлен- ным атрибутом Domain; − после изменения состояния пользователя (вход в веб- приложение, смена пароля, смена роли, истечение таймаута не- активности и т.д.), критичного с точки зрения политики без- опасности, должен создаваться новый идентификатор сессии, а старый – аннулироваться; − после изменения протокола HTTP на HTTPS должен создавать- ся новый идентификатор сессии, а старый – аннулироваться; − аннулирование сессионного идентификатора должно быть реа- лизовано как на клиенте, так и на сервере; − должны быть реализованы таймаут неактивности, абсолютный таймаут и таймаут обновления сессионного идентификатора. 26 Выделяют следующие основные атаки на механизмы управле- ния сессиями: − фиксация сессии; − подбор идентификатора сессии; − перехват идентификатора сессии; − кража идентификатора сессии. Получение идентификатора сессии пользователя приводит, как правило, к получению злоумышленником всех прав пользователя. Постановка задачи Выполнить тестирование защищенности механизма управления сессиями исследуемого веб-приложения. Последовательность действий Шаг 1. Настроить работу браузера через штатный прокси- сервер Burp Suite. В веб-браузере открыть главную страницу тестируемого веб-приложения www.test.app.com . Просмотреть Cookie, определить, создается ли сессия для неаутентифицированных (анонимных) пользователей. Шаг 2. Ввести корректные логин и пароль. Определить, что используется в качестве транспорта для передачи идентификатора сессии. Если для этого используется механизм Cookie, то определить имена cookie, их атрибуты (Secure, HttpOnly, Domain, Path, Expires) и значения. Проанализировать адекватность используемых атрибутов Cookie. Шаг 3. Проанализировать имя идентификатора сессии, его структуру и значение, определить, используется ли кодирование или шифрование данных. Используя инструмент Sequencer в Burp Suite, проанализировать вероятностные характеристики последовательности идентификаторов сессий. Сделать вывод о соответствии реализации функции генерации идентификаторов требованиям безопасности. Сделать вывод о возможности использования атаки грубой силы для генерации сессионного идентификатора пользователя. Шаг 4. Проверить аннулируемость сессии на серверной стороне. Сохранить Cookie в веб-браузере (можно использовать 27 расширение Export Cookies), выйти из приложения. Импортировать сохраненные ранее Cookie в браузер (можно использовать расширение Import Cookies). Перейти по любому адресу веб-приложения. Если вы попадете в предыдущую сессию, то это означает, что аннулирование сессии происходит только на клиенте. Проверить, что пользователь может завершить свою сессию в любой момент времени – каждая страница, доступная после аутентификации, содержит ссылку типа «Sign out», позволяющую завершить сессию. Проверить, какие механизмы таймаутов реализованы в веб-приложении. Шаг 5. Проверить возможность выполнения атаки типа «Фиксация сессии». Для этого проверить наличие следующего недостатка: веб-приложение не обновляет сессионный идентификатор, отправленный браузером пользователя, после успешной аутентификации последнего. Отправить запрос веб- приложению и получить сессионный идентификатор в Cookie: GET / HTTP/1.1 Host: www.test.app.com \r\n Получить и проанализировать ответ HTTP/1.1 200 OK Date: Wed, 14 Aug 2008 08:45:11 GMT Server: IBM_HTTP_Server Set-Cookie: ID=d8eyYq3L0z2fgq10m4v; Path=/; secure Аутентифицироваться, используя запрос с полученным иден- тификатором ID: POST https://www.test.app.com/auth HTTP/1.1 Host: www.test.app.com Cookie: ID=d8eyYq3L0z2fgq10m4v \r\n user=test&password=Zz123456 28 Если аутентификация прошла успешно, то приложение уязвимо к атаке фиксации сессии. Дополнительно убедиться, что идентификатор сессии передается только в Cookie и не раскрывается в лог-файлах, сообщениях об ошибках, URL и т.д. Шаг 7. Проверить, что идентификатор сессии меняется после повторной аутентификации, смены пароля, роли и т.д. Шаг 8. Проверить, что веб-приложение не позволяет иметь две одинаковые сессии с двух разных узлов сети. Вопросы и задания 1. Предложить сценарий атаки, использующий недостаток ан- нулирования сессии только на клиентской стороне веб- приложения. 2. Используя поисковые системы (Google, Shodan), найти веб- приложения с механизмом URL Rewriting. 3. Написать сценарий JavaScript, устанавливающий или считы- вающий идентификатор сессии пользователя. Тестирование на устойчивость к атакам отказа в обслуживании Цель работы Целью лабораторной работы является обучение методам и средствам тестирования веб-приложений на устойчивость к атакам отказа в обслуживании (DoS-атакам). Краткие теоретические сведения Целью реализации DoS-атаки является нарушение доступности веб-приложения. Это может быть достигнуто путем DoS-атаки на канал связи, программную платформу веб-сервера или на само веб-приложение. Традиционно DoS-атаки являются сетевыми (используют недостатки сетевых технологий) и могут быть классифицированы по уровням модели ISO/OSI. Например, атаки ICMP Flood (L3) и DNS/NTP Amplification (L7) приводят к отказу канала связи, а атаки Ping of Death (L3), SYN Flood (L4), SSL Renegotiation DoS 29 (L5/L6), HTTP Flood (L7), Slow HTTP (L7) воздействуют на платформу веб-приложения (операционная система, веб-сервер, фрэймворк и т.д.). Для достижения отказа в обслуживании с помощью атак прикладного уровня (L7) атакующему может потребоваться существенно меньшее количество ресурсов. Например, если для успешной реализация атаки SYN Flood она должна быть распределенной (DDoS) и использовать ботнет, то для реализации атак класса Slow HTTP DoS (Slowloris, Slow HTTP Post, Slow HTTP Read) обычно достаточно одного компьютера [10 – 13]. Вместе с тем для веб-приложений также характерны DoS-атаки уровня приложения, возможные из-за наличия уязвимостей в его коде [9]. Например, возможность проведения атаки типа SQL injection может позволить злоумышленнику удалить базу данных с учетными записями пользователей или выполнить запрос вида select benchmark(100000000, now()) для израсходования ресурсов системы. Также примерами атак уровня приложения являются атаки XML Billion Laughs (XML Bomb), XML Quadratic Blowup Attack, ZIP of Death (ZIP Bomb). Постановка задачи Выполнить тестирование устойчивости веб-приложения www.test.app.com к DoS-атакам на уровне протокола HTTP. Последовательность действий Шаг 1. Установить программу slowhttptest, доступную по URL вида https://code.google.com/p/slowhttptest Изучить документацию. Запустить сетевой анализатор Wireshark. Шаг 2. На тестовом стенде, эмулирующем работу веб-сервера www.test.app.com, установить и выполнить базовые настройки для веб-серверов Apache, Nginx и IIS. Запустить веб-сервер Apache. Шаг 3. Запустить в отношении веб-сервера атаку Slowloris, просмотреть трассировку соединения, проверить доступность веб- сервера с помощью произвольного браузера: 30 # slowhttptest -H -c 3000 -r 3000 -i 50 -l 6000 –u http://www.test.app.com Провести несколько тестов с различными параметрами. Построить графики состояния веб-сервера. Шаг 4. Запустить в отношении веб-сервера атаку Slow HTTP POST, просмотреть трассировку соединения, проверить доступность веб-сервера с помощью произвольного браузера: # slowhttptest -B -c 3000 -r 3000 -i 50 -l 6000 –u http://www.test.app.com Провести несколько тестов с различными параметрами. Построить графики состояния веб-сервера. Шаг 5. Запустить в отношении веб-сервера атаку Slow Read, выбрав файл достаточного размера, просмотреть трассировку соединения, проверить доступность веб-сервера с помощью произвольного браузера: # slowhttptest -X -c 3000 -r 3000 -l 6000 -k 5 -n 50 -w 1 -y 2 -z 1 –u http://www.test.app.com/bigauth.js Провести несколько тестов с различными параметрами. Построить графики состояния веб-сервера. Шаг 6. Остановить сервер Apache. Запустить сервер Nginx. Проделать предыдущие шаги в отношении сервера Nginx. Шаг 7. Остановить сервер Nginx. Запустить сервер IIS. Проделать предыдущие шаги в отношении сервера IIS. Шаг 8. В отношении сервера Apache выполнить атаку Apache Range Header. Проанализировать результаты. Выполнить команду # slowhttptest -R -u http://www.test.app.com -t GET -c 1000 -a 10 -b 3000 -r 500 Выполнить атаку Apache Range Header с использованием Metasploit Framework: 31 # msfconsole > use auxiliary/dos/http/apache_range_dos > show options > set RHOSTS www.test.app.com > set RPORT 80 > set RLIMIT 100 > set THREADS 3 > run Вопросы и задания 1. Как можно по косвенным признакам определить уязвимость веб-сервера к атакам типа Slow HTTP DoS? 2. Реализовать механизмы защиты для веб-сервера Apache от атак Slow HTTP DoS. 3. Реализовать и протестировать веб-приложение, уязвимое к атаке XML Bomb. Поиск уязвимостей к атакам CSRF Цель работы Целью лабораторной работы является обучение методам и средствам идентификации и эксплуатации уязвимостей веб- приложений к атакам CSRF. Краткие теоретические сведения Атака Cross-Site Request Forgery (CSRF или XSRF) переводится как «Межсайтовая подделка запросов» [14, 15]. Данная атака заключается в том, что злоумышленник вынуждает браузер пользователя отправить без ведома последнего произвольный HTTP-запрос. Уязвимость к атаке CSRF обусловлена недостатками отсутствия или некорректности проверки веб-приложением источника (origin) HTTP-запросов. Как правило, атака проводится в два этапа. На первом этапе злоумышленник подготавливает веб-ресурс (либо на своем собственном сервере, либо на каком-либо форуме или в социальной сети), содержащий код HTML или JavaScript и 32 вынуждающий браузер пользователя выполнить нужный злоумышленнику HTTP-запрос. На втором этапе злоумышленник вынуждает жертву зайти на подготовленный им ресурс, передав ей ссылку с завлекающим текстом. Для этого злоумышленник может воспользоваться социальными сетями, электронной почтой или системами обмена мгновенными сообщениями, а также использовать методы социальной инженерии. Для маскировки адреса вредоносного веб- ресурса, злоумышленник может воспользоваться сервисом по сокращению URL (например, goo.gl или bit.ly). Рекомендуемым общим методом защиты от атак CSRF является метод Synchronizer Token Pattern, осованный на использование случайных токенов [15]. Нерекомендуемыми методами защиты от атак CSRF являются: − проверка HTTP-заголовка Referer; − проверка наличия HTTP-заголовка X-Requested-With; − использование дополнительных действий пользователя для подтверждения; − использование заголовка Cookie (метод защиты «Double submit cookies»); − отправка нескольких запросов; − использование метода POST. При реализации защиты от атак CSRF в первую очередь требуется убедиться, что приложение не содержит уязвимостей, позволяющих провести атаку XSS, так как почти все меры противодействия атакам CSRF могут быть преодолены через использование данной уязвимости. Кроме того, необходимо проверить, что все действия, изменяющие состояние веб-приложения (действия по изменению или удалению различных объектов и т.п.), реализуются только с использованием метода POST (либо обычный POST, либо POST через AJAX). Постановка задачи Выполнить идентификацию и эксплуатацию уязвимостей к атакам CSRF. 33 Последовательность действий Шаг 1. Запустить веб-приложение WebGoat. Ввести логин: « guest », пароль: « guest ». Перейти по ссылке « Cross-Site Scripting → Cross-Site Request Forgery ». Изучить условия задачи. Ввести в поле « Title » значение « Hello », а в поле « Message » значение « test ». Нажать кнопку « Submit ». Просмотреть с помощью Burp Suite или аналогичного средства отправленный браузером запрос Ввести в поле « Title » значение « Hello », а в поле « Message » следующий HTML-код: Шаг 2. Перейти по ссылке « Cross-Site Scripting → CSRF Prompt By-Pass ». Изучить условия задачи. Ввести в поле « Title » значение « Hello », а в поле « Message » следующий HTML-код: Шаг 3. Проверить уязвимость веб-приложения www.app.test.com к атакам CSRF. Найти функцию, меняющую состояние веб-приложения. Выполнить эту функцию. Просмотреть HTTP-запрос. Удалить из него заголовки Referer и X-Requested- With (если они имеются). Проверить, что в запросе используется метод POST. Проверить наличие в запросе параметра, соответствующего CSRF-токену (он может называться CSRF_token, CSRFToken, authenticity_token). Приложение уязвимо к атаке CSRF, если успешно выполнен один из следующих тестов: − запрос не содержит CSRF-токенов в специальных заголовках и параметрах формы, а заголовки Referer и X-Requested-With мо- 34 гут быть удалены из запросов без нарушения функционально- сти приложения; − запрос содержит CSRF-токен, но последний может быть удален из-запроса без нарушения функциональности приложения; − запрос содержит CSRF-токен, но значение последнего может быть любым или пустым; − CSRF-токен одного пользователя может быть использован дру- гим пользователем; − CSRF-токен является предсказуемым; − приложение обрабатывает как POST-запросы с CSRF-токенами, так и GET-запросы без CSRF-токенов; − существует hard-coded CSRF-токен для отладки и тестирования. Шаг 4. К обнаруженной уязвимости к атаке CSRF написать эксплоит. Например, пусть для удаления учетной записи используется следующий запрос: POST /delete HTTP/1.1 Host: www.app.test.com Cookie: JSESSIONID=KxwexXHkDqzObNrFnXZN19Lq \r\n user=test&en=187213&pp=true Если данный запрос не содержит CSRF-токенов, то для эксплуатации CSRF-уязвимости можно разместить на ресурсе злоумышленника следующий HTML-код: 35 Перейти на веб-ресурс злоумышленника, убедиться, что подде- ланный запрос отправляется и обрабатывается приложением. Вопросы и задания 1. Для веб-приложения, уязвимого к атаке CSRF, написать экс- плоит, отправляющий данные типа multipart/form-data. 2. Для веб-приложения, уязвимого к атаке XSS, написать на языке JavaScript эксплоит, извлекающий CSRF-токен. 3. Показать, как, используя уязвимость к атаке CSRF, можно выполнить атаку XSS. Поиск уязвимостей к атакам XSS Цель работы Целью лабораторной работы является обучение методам и средствам идентификации и эксплуатации уязвимостей веб- приложений к атакам XSS. Краткие теоретические сведения Атака Cross-Site Scripting (XSS) – это атака на веб-приложение, использующая недостатки неправильной обработки данных и позволяющая выполнить произвольный сценарий (JavaScript, VBScript) в контексте источника (origin) уязвимого веб- приложения. Атаки XSS классифицируются по вектору и способу воздействия. По вектору воздействия атаки XSS бывают отраженными (reflected), устойчивыми (persistent) и основанными на объектной модели документа (DOM-based). По вектору атаки XSS делятся на активные и пассивные. Устойчивая атака XSS – это XSS атака, в результате которой введенный злоумышленником код сохраняется на веб-сервере и возвращается пользователю в запросе не содержащем вектор атаки. Отраженная атака XSS – XSS атака, в результате которой код, введенный злоумышленником, передается пользователю в ответе на тот же запрос, в котором передан вектор атаки. 36 Атака XSS, называется DOM-based, если код злоумышленника может быть выполнен в браузере пользователя без отправки запроса на сервер веб-приложения. В результате успешной реализации атаки XSS злоумышленник может выполнить, например, следующие действия: − перенаправить пользователя на любой веб-сайт; − получить аутентификационные данные пользователя, переда- ющиеся в Cookie; − получить любые данные, к которым имеет доступ клиентская часть веб-приложения; − получить доступ к внутренней сети пользователя; − выполнить Deface веб-сайта и т.д. В общемировой практике тестирования защищенности веб- приложений в качестве доказательства уязвимости приложения к атаке XSS принято демонстрировать возможность выполнения JavaScript-кода вида alert(1), prompt(/XSS/), confirm(0) и т.п. При тестировании наличия уязвимости к атакам XSS важно определять контекст, в который выводятся данные. Существуют следующие виды контекстов: HTML, SCRIPT, STYLE, URL и ат- рибутный [16]. Ниже приведены примеры XSS-векторов для каж- дого из контекстов: |