Уязвимости из OWASP Top 10. A1: 2017 – Injections (Часть 1)

    Описание уязвимостей — это одно, а вот попробовать найти уязвимость и поработать с ней — совсем другое дело. Именно для этих целей создаются и развиваются специальные приложения, в которых намеренно оставлены уязвимости. Если набрать в поисковой системе запрос «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, так как эти уязвимости, как правило, имеют катастрофические последствия в случае реализации.

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

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

    Комментарии 2

      0
      Ни в коем случае не забрасывайте цикл статей!
        0
        Спасибо за отзыв. Мы все наши проекты доводим до конца, гарантируем, что этот цикл статей не станет исключением.

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

      Самое читаемое