Регулировка агрессивности сканирования с помощью Level и Risk в sqlmap

Kali LinuxBeginner
Практиковаться сейчас

Введение

sqlmap — это мощный инструмент для тестирования на проникновение с открытым исходным кодом, который автоматизирует процесс обнаружения и эксплуатации уязвимостей SQL-инъекций. При проведении сканирования два наиболее важных параметра, которыми вы можете управлять, это --level и --risk. Эти параметры определяют тщательность и агрессивность сканирования.

  • Level (Уровень): Контролирует количество выполняемых тестов. Диапазон от 1 до 5, причем более высокие уровни выполняют более обширные тесты на большем количестве точек инъекции (например, HTTP-заголовки).
  • Risk (Риск): Контролирует рискованность используемых полезных нагрузок (payloads). Диапазон от 1 до 3, причем более высокие риски используют потенциально деструктивные полезные нагрузки (например, запросы на основе времени, которые могут замедлить работу базы данных).

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

Понимание стандартных уровней Level (1) и Risk (1)

На этом этапе вы выполните базовое сканирование sqlmap без указания level или risk. По умолчанию sqlmap использует --level=1 и --risk=1. Это наименее полное и самое безопасное сканирование.

Level 1 тестирует только GET и POST параметры. Risk 1 использует полезные нагрузки, которые, как правило, безвредны для веб-приложения, такие как базовые тесты на основе булевых значений и ошибок.

Выполните следующее сканирование против уязвимого приложения, которое было для вас настроено. Опция --batch автоматически отвечает на все вопросы выбором по умолчанию, делая сканирование неинтерактивным.

Выполните следующую команду в вашем терминале:

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --batch

Вы увидите, как sqlmap начнет процесс тестирования. Обратите внимание на сводку в конце, которая показывает количество сделанных запросов и найденные уязвимости.

...
[INFO] testing 'Boolean-based blind - WHERE or HAVING clause'
[INFO] testing 'Error-based - WHERE or HAVING clause'
[INFO] testing 'Time-based blind'
...
[INFO] GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N
sqlmap identified the following injection point(s) with a total of XXX HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 2129=2129

    Type: error-based
    Title: SQLite OR error-based - CUME_DIST
    Payload: id=1 OR 1 GROUP BY CUME_DIST(1)

    Type: time-based blind
    Title: SQLite > 2.0 AND time-based blind
    Payload: id=1 AND 7415=CASE WHEN (substr(sqli,1,1)='S') THEN 7415 ELSE 0 END
---
[INFO] fetched data logged to text files under '/home/labex/.local/share/sqlmap/output/127.0.0.1'
...

Это первоначальное сканирование выполняется относительно быстро и подтверждает уязвимость в параметре id.

Увеличение глубины сканирования с помощью --level=3

На этом этапе вы увеличите глубину сканирования, установив уровень равным 3. Более высокий уровень указывает sqlmap выполнять больше тестов и проверять дополнительные места на наличие уязвимостей.

  • --level=2 добавляет тесты для HTTP-заголовков Cookie.
  • --level=3 добавляет тесты для HTTP-заголовков User-Agent и Referer.

Увеличивая уровень, вы просите sqlmap быть более тщательным. Это естественным образом увеличит количество запросов и время сканирования.

Теперь запустите сканирование снова, но на этот раз добавьте опцию --level=3:

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --level=3 --batch

Наблюдайте за выводом. Вы заметите, что sqlmap теперь явно упоминает тестирование заголовков, таких как Cookie и User-Agent.

...
[INFO] testing for SQL injection on GET parameter 'id'
...
[INFO] testing for SQL injection on HTTP Cookie header
...
[INFO] testing for SQL injection on HTTP User-Agent header
...
sqlmap identified the following injection point(s) with a total of YYY HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 2129=2129
...
---
[INFO] fetched data logged to text files under '/home/labex/.local/share/sqlmap/output/127.0.0.1'
...

Хотя наше простое приложение не уязвимо через эти заголовки, реальное приложение может быть. Вы должны заметить, что общее количество HTTP-запросов (YYY) выше, чем на предыдущем шаге (XXX).

Увеличение инвазивности сканирования с помощью --risk=2

На этом этапе вы изучите параметр --risk. Этот параметр контролирует "опасность" используемых полезных нагрузок.

  • --risk=1 (По умолчанию): Использует в основном безвредные полезные нагрузки.
  • --risk=2: Добавляет тесты на основе тяжелых запросов с временной задержкой (time-based blind injection). Они могут создавать значительную нагрузку на сервер базы данных.
  • --risk=3: Добавляет тесты SQL-инъекций на основе OR и другие потенциально деструктивные полезные нагрузки, которые могут изменять данные.

Более высокий риск может выявить уязвимости, которые более безопасные тесты могут пропустить, но он также увеличивает вероятность нарушения работы целевой системы. Его следует использовать с осторожностью.

Давайте выполним сканирование с повышенным уровнем риска. Мы вернемся к стандартному уровню (1), чтобы изолировать эффект параметра риска.

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --risk=2 --batch

Во время этого сканирования вы увидите, как sqlmap использует более агрессивные методы, основанные на времени. Эти полезные нагрузки работают, заставляя базу данных выполнять длительную операцию (например, функцию бенчмаркинга или задержки), а затем измеряя время отклика сервера для получения информации.

...
[INFO] testing 'Boolean-based blind - WHERE or HAVING clause'
[INFO] testing 'Error-based - WHERE or HAVING clause'
[INFO] testing 'Time-based blind (heavy query)'
...
[INFO] GET parameter 'id' appears to be 'Time-based blind' injectable
...

Сканирование с --risk=2 является более интенсивным, чем стандартное сканирование, даже при том же уровне, потому что сами полезные нагрузки более сложны.

Выполнение сканирования с комбинацией --level=5 и --risk=3

На этом этапе вы объедините наивысшие настройки уровня и риска для наиболее полного и агрессивного сканирования.

  • --level=5: Наивысший уровень. Тестирует все возможные точки внедрения, включая HTTP-заголовок Host.
  • --risk=3: Наивысший риск. Использует полезные нагрузки, которые потенциально могут изменять записи в базе данных. Это опасно и должно использоваться только в системах, где у вас есть явное разрешение на деструктивное тестирование.

Эта комбинация приводит к очень длительному и интенсивному сканированию. Это подход "все включено", который применяет каждый известный тест к цели.

Выполните следующую команду. Имейте в виду, что это сканирование займет значительно больше времени, чем предыдущие.

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --level=5 --risk=3 --batch

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

...
[INFO] testing for SQL injection on GET parameter 'id'
...
[INFO] testing for SQL injection on HTTP Cookie header
...
[INFO] testing for SQL injection on HTTP User-Agent header
...
[INFO] testing for SQL injection on HTTP Referer header
...
[INFO] testing for SQL injection on HTTP Host header
...
[CRITICAL] OR-based injection tests might result in an update of all table rows. Continue? [y/N] y
...

Это сканирование демонстрирует максимальные возможности sqlmap, но также подчеркивает важность понимания компромиссов. Такое сканирование часто непрактично и слишком рискованно для стандартных проверок.

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

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

Если вы просмотрите вывод терминала из каждого шага, вы заметите четкую закономерность:

  1. Стандартное сканирование (--level=1, --risk=1): Базовый уровень. Оно было быстрым и отправило наименьшее количество запросов.
  2. Увеличенный уровень (--level=3): Количество запросов увеличилось, поскольку sqlmap протестировал больше точек внедрения (Cookie, User-Agent). Продолжительность соответственно увеличилась.
  3. Увеличенный риск (--risk=2): Продолжительность сканирования увеличилась не обязательно из-за большего количества запросов, а потому, что полезные нагрузки, основанные на времени, по своей природе медленны.
  4. Максимальная агрессивность (--level=5, --risk=3): Это сканирование отправило значительно большее количество запросов и заняло самое длительное время выполнения со значительным отрывом.

Вот сводка ожидаемого поведения:

Параметры сканирования Протестированные точки внедрения Типы полезных нагрузок Относительная продолжительность
Стандартное (L1, R1) GET/POST Базовые булевы, ошибки Короткая
--level=3 GET/POST, Cookie, User-Agent Базовые булевы, ошибки Средняя
--risk=2 GET/POST Добавляет тяжелые, основанные на времени Средне-длинная
--level=5 --risk=3 Все заголовки Добавляет основанные на OR, стековые Очень длинная

Ключевой вывод заключается в том, что существует прямая зависимость. Увеличение level и risk обеспечивает более тщательное тестирование и более высокую вероятность обнаружения скрытых уязвимостей, но это достигается ценой значительно увеличенного времени сканирования и повышенного риска нарушения работы целевой системы.

Итоги

В этой лабораторной работе вы успешно изучили, как регулировать агрессивность сканирований sqlmap с помощью параметров --level и --risk.

Вы узнали, что:

  • --level контролирует область действия сканирования, определяя, какие части HTTP-запроса тестируются на наличие уязвимостей. Более высокие уровни являются более всесторонними.
  • --risk контролирует степень вмешательства сканирования, определяя типы используемых SQL-полезных нагрузок. Более высокие риски с большей вероятностью обнаружат уязвимости, но могут быть опасны для целевой базы данных.
  • Настройки по умолчанию (level=1, risk=1) разработаны для быстроты и безопасности.
  • Увеличение этих значений приводит к увеличению времени сканирования и требует большей осторожности.

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