Здравствуйте, дорогие друзья.
Продолжаем рассматривать SQL-инъекции, и в данном случае я бы хотел затронуть тему безопасности и предотвращение инъекций через страницы авторизации.
Перейдем непосредственно к практике, и рассмотрим самый высокий уровень безопасности на сайте Mutillidae:
Это довольно серьезный уровень защиты, но в некоторых ситуациях его можно обойти. Данный уровень безопасности не является идеальным, и существуют веб-приложения с более высоким уровнем защиты от SQL-инъекций.
Начинаем экспериментировать с этим веб-сайтом, и введем в поле «Name» - admin, а в поле «Password» - zzz. Напоминаю, что мы уже сконнектились с Burp Suite. Как это делать, я рассматривал в предыдущей статье:
Перехватчик в Burp Suite работает:
Жмем кнопку «Login», и видим перехваченные пакеты в Burp:
Нам нужно внедрить мини-эксплойт для проверки, точно также, как я делал ранее. Переходим на вкладку «Params», и уже там редактируем наш пароль, на «zzz“ or 1=1 #»:
Работаем дальше с перехватчиком, и жмем кнопку «Forward», для дальнейшей передачи пакетов. Как видим, получаем ошибку аутентификации:
Можно прийти к выводу, что эта страница достаточно защищена, так как с такими настройками безопасности мы не можем осуществить инъекцию.
Еще раз повторюсь, что это не самый лучший метод защиты веб-сайта, но в этом конкретном случае защита достаточно хороша.
Посмотрим на код авторизации этого сайта, на разных настройках безопасности. Разница в выражении «SELECT»:
Как видим, в первом незащищенном варианте авторизации присутствует выражение «SELECT», и две переменные «$username», «$password»:
Суть в том, что все, что Вы введете в текстовое поле на странице авторизации, будет использоваться в этом выражении. Вспомним, что использовалась фильтрация со стороны пользователя, и мы ее очень легко обходили с помощью «Proxy». Чтобы мы не ввели в Proxy — передавалось в $password (в нашем примере).
Вспомните пример с логином «admin», и когда мы вводили любой пароль. Представление в виде кода будет выглядеть вот так:
Данное выражение является истинным.
А вот в случае с защищенным кодом, используется функция «real_escape_string». Эта функция является своеобразным фильтром, и удаляет переход на новую строку, одиночные кавычки, двойные кавычки и другие недопустимые символы:
Ключевой момент функции «real_escape_string» в том, что она помимо фильтрации обрамлена одинарными кавычками, и если бы их не было, мы могли бы сделать инъекцию, либо обойти эту функцию:
Сама функция удаляет дополнительные внедренные кавычки. Информация, которую мы будем вводить в поля авторизации, будет рассматриваться как обычный текст, но не как какой-либо код, который выполняется на сервере.
Давайте я приведу пример работы данной защиты.
Скопируем инъекцию, под пользователем «admin» - «admin' or 1=1#», и вставим ее в наш код:
Код просканирует внедренный эксплойт и удалит одинарную кавычку:
Кавычка будет удалена, и функция также пропадет, после выполнения. Запись будет иметь вид:
Теперь нужно удалить точки, и двойные кавычки:
Заметьте, что присутствуют одинарные кавычки в коде. Это некая перестраховка, и наша инъекция не будет работать, но если бы они не добавили их в код, даже при использовании функции — эта инъекция сработала бы.
Это не самый лучший способ защиты веб-сайта, хотя это неплохая временная защита сайта.
На этом все. Всем хорошего дня!
