Фаза Generate

Область действия фазы

Фаза используется в модифицирующем расширении и является необязательной для его работы (соответствующая секция generate в YAML-файле может как присутствовать, так и отсутствовать).

Фаза должна отсутствовать в YAML-файле расширения, если создается немодифицирующее расширение.

Подробную информацию о типах расширений FAST вы можете получить здесь.

Синтаксис описания элементов запроса

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

Более подробная информация о синтаксисе описания элементов запроса доступна здесь.

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

Секция generate имеет следующую структуру:

generate:
  - into:
    - parameter 1
    - parameter 2
    - …
    - parameter N
  - method:
    - postfix
    - prefix
    - random
    - replace
  - payload:
    - payload 1
    - payload 2
    - …
    - payload N
  • Параметр into позволяет при необходимости указать один или несколько элементов запроса, куда будет вставляться полезная нагрузка. Значением параметра может быть строка или массив строк. В качестве значения параметра into может использоваться регулярное выражение, заданное в формате регулярных выражений Ruby.

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

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

    Предположим, что согласно политике тестирования из базового запроса извлекли два элемента запроса, которые можно модифицировать:

    • GET_uid_value
    • HEADER_COOKIE_value

    Расширение будет последовательно обрабатывать все модифицируемые элементы (также известны как insertion points).

    Если параметр into опущен, то полезные нагрузки будут последовательно вставляться в параметр GET_uid_value, и полученные тестовые запросы будут использованы для проверки целевого приложения на уязвимости. Затем, после завершения обработки результатов выполнения тестовых запросов, расширение будет обрабатывать параметр HEADER_COOKIE_value, и так же вставлять в этот параметр полезные нагрузки.

    Если же, например, указать в параметре into параметр запроса GET_uid_value, то полезная нагрузка будет вставляться в параметр GET_uid_value, но не в параметр HEADER_COOKIE_value:

    into: 
      - 'GET_uid_value'
    

    Поскольку в данном примере параметр только один, значением параметра into может быть и строка:

    into: 'GET_uid_value'

  • method — этот необязательный параметр позволяет определить список методов, которые будут использоваться при вставке полезной нагрузки в элемент базового запроса:

    • prefix — полезная нагрузка вставляется перед значением элемента базового запроса;
    • postfix — полезная нагрузка вставляется после значения элемента базового запроса;
    • random — полезная нагрузка вставляется в случайное место значения элемента базового запроса;
    • replace — полезная нагрузка заменяет значение элемента базового запроса.

    Методы вставки полезной нагрузки

    При отсутствии параметра method, по умолчанию будет использоваться метод вставки replace.

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

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

    method:
      - prefix
      - replace
    

    то для одной полезной нагрузки будет создано два тестовых запроса, для двух полезных нагрузок — четыре тестовых запроса (по два для каждой нагрузки) и так далее.

  • payload задает список полезных нагрузок (payload), которые будут вставляться в параметр базового запроса для создания тестового запроса, пытающегося эксплуатировать уязвимость.

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

    Генерация полезной нагрузки

    Полезная нагрузка представляет собой строку, которая будет вставлена в один из параметров при обработке запроса.

    Пример нескольких полезных нагрузок.
    payload:
      - "') or 1=('1"
      - "/%5c../%5c../%5c../%5c../%5c../%5c../%5c../etc/passwd/"
    

    Вы можете использовать особые маркеры в качестве части полезной нагрузки для расширения возможностей обнаружения уязвимости:

    • STR_MARKER — будет вставлена произвольная строка в то место полезной нагрузки, где будет указан маркер STR_MARKER.

      Например, STR_MARKER может использоваться при проверке на наличие XSS-уязвимости.

      Пример.

      'userSTR_MARKER'

    • CALC_MARKER — будет вставлена строка, содержащая в себе произвольное арифметическое выражение (например, 1234*100), в то место полезной нагрузки, где будет указан маркер CALC_MARKER.

      Например, CALC_MARKER может использоваться при проверке на наличие RCE-уязвимости.

      Пример.

      '; bc <<< CALC_MARKER'

    • DNS_MARKER — будет вставлена строка, содержащая в себе произвольное доменное имя (вида r4nd0m.wlrm.tl), в то место полезной нагрузки, где будет указан маркер DNS_MARKER.

      Например, DNS_MARKER может использоваться при проверке на наличие DNS Out-of-Bound-уязвимости.

      Пример.

      '; ping DNS_MARKER'

    Принцип действия маркеров

    Если в фазе Detect в ответе сервера будет обнаружен маркер из какой-либо полезной нагрузки, значит, атака удалась и уязвимость эксплуатируется успешно. Подробная информация о том, как фаза Detect работает с маркерами, находится здесь.

results matching ""

    No results matching ""