Описание уязвимостей — это одно, а вот попробовать найти уязвимость и поработать с ней — совсем другое дело. Именно для этих целей создаются и развиваются специальные приложения, в которых намеренно оставлены уязвимости. Если набрать в поисковой системе запрос «Purposely vulnerable app», вы найдете ни один десяток ссылок.

В этом цикле мы начнем разбирать уязвимости из OWASP Top 10, и в качестве полигона я буду использовать такое намеренно уязвимое приложение. В моем случае это будет OWASP Mutillidae II. Это не то, чтобы самый лучший вариант, но в нем уязвимости структурированы именно так, как нужно для образовательных целей.



Дайте вашу руку

Итак, первая уязвимость — это инъекции. В OWASP Mutillidae II представлено несколько вариантов, и начнем мы с самого простого «SQLi extract Data» > «User Info (SQL)».
Перед нами обычное окно аутентификации – то, с чем вы взаимодействуете ежедневно:



У нас нет ни логина, ни пароля — ничего. Ну что ж, давайте зарегистрируемся на этом сайте. Я создам пользователя с именем belowzero273 и паролем 123:



Отлично! Мы создали учетную запись, торжественная надпись «1 rows inserted» как бы намекает, что добавлена некая строка, судя по всему в таблицу, потому что большое количество учетных записей проще всего хранить в СУБД.

Теперь залогинимся с нашей новой учетной записью в систему. Успешно, отлично.
Когда мы работаем с веб-страницей, всегда нужно помнить, что наше взаимодействие не ограничивается содержимым страницы. Есть еще строка адреса, например. В которой мы можем заметить массу интересного:

http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details

Например, мы видим, что пароль передается в открытом виде. Это плохо, так как трафик могут перехватить. Но, возможно, не такая уж катастрофа — трафик будет обернут в TLS.
Давайте попробуем заменить пароль прямо в строке, например, этот кусок:

username=belowzero273&password=123

на

username=belowzero273&password=12345

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

У нас нет столько времени, поэтому попробуем кое-что другое. Добавим к нашему неправильному паролю знак апострофа:

username=belowzero273&password=123

на

username=belowzero273&password=12345'

Теперь мы получили полноценную ошибку:



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

Теперь мы видим, что на самом деле, когда мы нажимаем кнопку «Отправить» в фоне выполняется следующий запрос:

SELECT * FROM accounts WHERE username='belowzero273' AND password='12345'

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

Обратите вниманием, что в запросе стоит функция and, то есть обе переменные должны оказаться верны, ведь это комбинация логина и пароля. Логично.

Давайте еще немного поколдуем над этим запросом:

SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1=’1

Мы добавили условие, которое выполняется всегда: 1=1. И запрос будет выполнен в двух случаях: или мы угадали комбинацию логина и пароля, или 1=1. То есть всегда будет выполняться.

Получается, что в качестве пароля можно указать следующее:

' or 1='1

Апостроф в конце строки уже не нужен, логика веб-приложения поставит его за нас. Бум! И мы получили выборку из базы со всеми аккаунтами:



Круто, теперь у нас есть логины и пароли всех, кто зарегистрирован в этом приложении. И даже хуже, пароли тут лежат в открытом виде.

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

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

admin' or 1='1

То есть мы ищем запись в базе, где логин admin, а пароль – любой.

Пароль не найден!

Пароли не всегда хранятся в открытом виде, но не значит, что аутентификация делается безопасно. Посмотрим второй пример в OWASP Mutillidae II «SQLi Bypass Authentication» > «Login».

Аутентификацию можно обойти, если сформировать соответствующий запрос. Совсем недавно мы создали учетную запись belowzero273, а теперь давайте в качестве логина укажем:

' or ('a' = 'a' and username='belowzero273') -- 

Здесь мы проверяем заведомо правильное условие – а=а, а логин – belowzero273, а также отсекаем часть запроса с помощью «–».

Жмем Enter и успешно входим в систему при том, что свой пароль мы нигде не указали.

Так просто?

Иногда клиенты спрашивают, неужели так просто можно обойти аутентификацию на нашем сайте? Обычно я отвечаю вопросом на вопрос: «А вы уверены, что этого уже не произошло?». Инъекции не случайно находятся в топе рейтинга OWASP, так как эти уязвимости, как правило, имеют катастрофические последствия в случае реализации.

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

Прочитать блог автора статьи можно по этой ссылке.