Три топ-уязвимости по версии OWASP TOP-10

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Всем привет! Меня зовут Свят, работаю QA gangsta lead в EVO, я в тестировании уже 9 лет. Ищу уязвимости как веба так и мобильных приложений свыше 5 лет, веду тренинги по тестированию безопасности, провожу независимые аудиты security и QA. Также у меня есть security QA-блог для начинающих и Telegram-канал.

В данной статье обсудим топовые три уязвимости. Откуда я взял, что они типовые? Да вот недавно OWASP зарядил предварительный вариант OWASP TOP 10 2021, основанный на статистике веб приложений за последние 4 года.

Поэтому я думаю будет интересно всем знать, как QA так и DEV, что теперь является самыми критическими дырами в веб приложении.

Что изменилось

Для начала мы глянем, как выглядел в 2017 году и как теперь будет выглядеть с 2021 года этот список.

Как мы видим, все также Injection и Broken Authentication остаются лидерами на своих позициях и занимают первое и второе место. Да-да, до сих пор присутствуют Injection на веб проектах. Чуть позже покажу в количественном соотношении как часто находят эту и другие уязвимости на сайтах, где вы и поймете почему они имеют эту позицию в рейтинге.

Ну и вы заметили, что XSS, который в 2017 году находился на 7 месте, переместился аж на третье место в 2021 в список OWASP, закрыв ТОП 3 самых критических уязвимостей сайтов на следующие 3-4 года, так как эта статистика обновляется в таком промежутке.

Год назад от разных людей из различных вертикалей в IT индустрии я только и слышал: «Да то устаревшие стандарты OWASP TOP 2017!», «Да такие уязвимости почти уже не репортяться!», «XSS это не уязвимость!», — некоторые даже поговаривали мне.

Если вы тоже сталкивались с такими людьми и вас также заверяли, когда вы им говорили про эти уязвимости, что таких больше нет в нашу эру технологий, то теперь, основываясь на новой статистике OWASP 2021, можно смело кричать «А я же говорил!»

Статистика уязвимостей в количественном соотношении

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

Как мы видим, Injection был зарепорчен 34061 раз. За ним следует Broken authentication — 13735 раз. И так как мы сегодня разговариваем о ТОП 3 критических уязвимости, то финиширует XSS, про которую зарепортили аж 433353 раза.

Вас наверняка заинтересовало, почему XSS всего на третьем месте при таком количестве репортов, а injection на первом, что в 12 раз меньше? Рейтинг OWASP строиться не только на количественном соотношении, но и на критичности уязвимости. Так как если у вас на проекте найдут где-то sql injection и используют его в нужном русле, вы подвергаете себя опасности потерять не только конфиденциальную информацию одного клиента, но и можете «отдать» всю базу данных клиентов, к примеру кредитных карт, паролей от учеток и т. д. А в случаи XSS уязвимости злоумышленник получает контроль точечно, то есть над той жертвой, которая попалась на внедренные скрипты на какой-то из страниц веб сайта. Соответственно вам теперь должно быть понятней про масштаб атаки этих двух разных уязвимостей.

Как искать и какие лучшие практики стоит применять

Injection

Я ранее писал статейку о том, как искать sql injection, чтоб не повторяться, вы можете ее прочесть. Но, чтоб хоть что-то написать про эту категорию, я расскажу про еще один подтип в категории injection, это OS command injection.

Давайте сразу взглянем на практическом примере через приложение BWapp, как работает эта уязвимость и что можно с помощью ее сделать:

Что у нас тут на картинке? Представьте, что это консоль операционной системы, через которую мы можем проверять какой-то ресурс с помощью команды nslookup. Давайте проверим с помощью нее сайт www.nsa.gov, который отображен на скриншоте выше. При выполнении такой команды, сервак нам отдаст все его IP.

Да, в этом примере нет никакой уязвимости, так как это стандартная команда ОС, с помощью которой можно получить ответ от сервера под каким ip он находится, но если этот сервер был настроен не правильно и будет отвечать на дополнительные команды, которые мы ему будет давать, то тут уже стоит задуматься над сменой админа :)

Выше показан пример с дополнительной командой ;pwd к нашему сайту, по которой сервер не должен был давать нам ответ в таком виде, так как с помощью этой команды мы узнали у него рабочую директорию.

Следующий, закрепительный пример для понимания OS command injection будет с UNIX командой ;ls после названия нашего сайта. Работает она так: «покажи мне все содержимое в этом каталоге в этом сервере». Таким образом, сервер сливает нам всю информацию своего содержимого. Далее эти файлы можно читать с помощью команды ;cat и названия файла, которое мы хотим прочесть.

Broken Authentication

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

Итак, поехали:

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

2. Стоит убедиться, нету ли в системе дефолтных учеток с дефолтными логинами и паролями к системе. К примеру как эти

3. Проверить механизмы блокировки учетной записи для уменьшения влияния атаки brute force. Учетные записи обычно блокируются после 3–5 неудачных попыток входа в систему.

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

5. Глянуть, нет ли доступа к каким-то конфиденциальным страницам, вызывая их напрямую через URL сайта.

6. Обратить внимание на то, как происходит сброс старого пароля на новый, какие данные нужны для восстановления пароля. Предупреждаете ли пользователя, что кто-то хочет изменить его пароль? Генерирует ли приложение случайный пароль при выдачи нового пароля и тд.

7. И напоследок, все эти методы проверить на всех ваших платформах. К примеру, вы проверили все это на вашем вебе и ничего не нашли подозрительного, а вот на мобильном приложении комбо из уязвимостей.

XSS

И поговорим про последнюю в этой статье уязвимость. Я ранее тоже писал статейку о том, как искать XSS, чтоб не повторяться, вы можете ее прочесть. Но я немного дополню ту статью новой инфой, как подбирать скрипт под разный инпут, где вы проводите поиск на эту уязвимость.

Начнем с примера поисковой строки на сайте. У нас есть сайт, у него есть поиск товаров по названию.

С чего стоит начать подбор скрипта? Для начала нам надо понять количество мест, куда передается наши вводимые значения, которые мы вводим в поиск на сайте. Не стоит думать, что xss скрипт может отработать только в одном месте. Тоесть мы ввели название товара «qwerty» в поиск и мы видим что у нас вывелось уведомление:

Поиск: QWERTY, найдено 0 наименований.

Но на самом деле наше наименование передалось не только в это место на UI этого ресурса. Если заглянуть в консоль браузера и открыть HTML разметку этого сайта, а затем в поиске вбить «qwerty», то увидим такую картину:

Если мы обратим внимание на количество, то увидим: в 9 местах на этой странице передалось значение, которое мы вводили в поиске. Что это означает? Это говорит о том, что под разные 9 мест может отработать собственный скрипт XSS, тоесть если не отработает XSS в одном месте, то он может отработать в другом. Да, разработчик мог зафильтровать отработку пейлоад в одном месте, но это не означает, что он не забыл сделать фильтрацию во всех других местах.

Приведу несколько примеров в кусках HTML разметках.

Атрибут value

<form action="page.php" method="POST">
<input name="name" value="<script>alert()</script>">
</form>

Вот мы ввели проверочный пейлоад <script>alert()</script>. В данном случае XSS не отработает, так как скрипт передался просто значением в атрибут value. Это означает, что скрипт стоит немного модифицировать, чтоб попытаться воспроизвести XSS.

<form action="page.php" method="POST">
<input name="name" value=""><script>alert()</script>">
</form>

Давайте взглянем на пейлоад "><script>alert()</script> в том же самом примере. Мы видим, что этими символами (">) в скрите мы производим манипуляции html разметки страницы. Первым символом мы закрыли атрибут value, а вторым символом — тег input. Теперь если же не было сделанно разработчиком никакой обработки от пользовательского ввода, наш скрипт вызовет попап на сайте. Все, можно сказать, мы заработали 50-100 баксиков, если вы ищете уязвимости по программе баг баунти. А если ищете уязвимость без спросу, то за нарушение работы приложения можете только 5 лет заработать.

Тег <title>

<html>
<head>
<title>Привет, "><script>alert()</script><title>
</head>
</html>

Итак, если мы применим наш наработанный пейлоад в данном случае, то тут он не отработает, так как тег <title> все переведет как текст между своими тегами. Но опять таки, мы же настырные ребята, давайте немного поправим наш скрипт, чтоб найти, есть ли уязвимость в этом месте.

<html>
<head>
<title>Привет, "></title><script>alert()</script><title>
</head>
</html>

На скрине выше в наш готовый раннее скрипт добавили закрытие тега </title>. Теперь мы закрываем существующий тег title, и тем самым даем браузеру отработать наш попап на данной странице. Ну конечно же, если нету никакой защиты от пользовательского ввода.

Мы нашли уже 2 места, где есть уязвимость к XSS атаке, и можем получить двойное вознаграждения за данную уязвимость по программе баг баунти либо поощрения в своей компании.

Что ж, давайте сделаем подытог:

• мы узнали, какие теперь уязвимости считаются самыми критическими в веб приложениях на следующие 3-4 года, пока OWASP не обновит рейтинг опять
• немного больше узнали, как искать такие уязвимости и на что обращать внимание при поиске

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