Здравствуйте, дорогие друзья.
В данном уроке мы рассмотрим высокий уровень безопасности, и разберем, почему он не уязвим к SQL-инъекциям.
Перейдем в DVWA, и выставим настройки безопасности на «высокий»:
Перейдем на вкладку «SQL Injection». Все по-стандарту, проверяем страницу с помощью цифры 1:
Как видим, все работает.
Теперь попробуем ввести SQL-инъекцию в преобразованный URL:
Как мы можем видеть, страница не работает.
Попытаемся ввести кавычку «'», в адресную строку URL:
Опять та же ситуация. Страница не работает.
Как правило мы не смотрим на код, но в данной ситуации предлагаю проанализировать его. Страница по-составу неуязвима к SQL-инъекциям.
Мы попробуем сравнить код на высоком уровне безопасности, с кодом на средних настройках.
Для просмотра кода, нам нужно нажать на кнопку «View Source», которая располагается в правом нижнем углу:
Вот, собственно, сам код:
Откроем также исходники на средних настройках безопасности для сравнения:
Итак, на средних настройках безопасности мы видим, что id читается и записывается в переменную id:
Далее используется функция «mysql_real_escape_string». Эта функция предназначена считывания каждого элемента в переменной id и ищет специальные символы:
Все кавычки, которые мы попытаемся ввести в этой строке, будут просто удалены. Нам просто не нужно использовать символы, для работы с адресной строкой URL.
Выражение выглядит как:
Нам не нужно вставлять кавычки в переменную «id».
Алгоритм эксплуатации следующий, и Вы его знаете. Нужно ввести какое-либо значение в переменную «id», и только после этого можно вводить инъекцию кода в URL. Нам не нужно использовать кавычки.
Если мы будем сравнивать код, с исходниками на высоком уровне безопасности, то обнаружим, что выражение будет фактически идентичным, за исключением обрамления переменной id одинарными кавычками в SQL-выражении.
Давайте попрактикуемся с выполнением кода в URL на среднем и на высоком уровне безопасности:
По-идее, на среднем уровне безопасности, при вводе утверждения 1 and 1=1, функция будет отбрасывать специальные символы, но их у нас нет, поэтому выражение будет выполнено.
Таким образом можно вставить истинное утверждение на высоком уровне безопасности:
Так как средние настройки мы уже тестировали, то рассмотрим высокий уровень. 1 and 1=1 будет рассматриваться, как часть id пользователя, и не будет частью SQL-выражения. Мы можем видеть, что функции «mysql_real_escape_string» недостаточно, но можно оставить данный код в исходном состоянии, и это будет довольно безопасно, но не высокая защита от SQL-инъекций.
На этом все. Всем хорошего дня!
