Анализ JavaScript и методы Burp Suite, которые действительно работают

Большинство багхантеров знают, как проводить разведку (рекогносцировку). Они находят поддомены, собирают URL-адреса и загружают JavaScript-файлы. На этом разведка заходит в тупик. Никаких уязвимостей, никаких последствий, никакого вознаграждения. А все потому, что разведка — не цель.

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

В этой статье я объясню, что делать после разведки и как превратить JavaScript-файлы в отчеты о реальных уязвимостях с помощью Burp Suite.

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

Шаг 1: Изменение подхода после разведки

Перестаньте думать так: «У меня есть URL-адреса. Теперь мне нужны полезные нагрузки».

Начните думать так: «Как это приложение принимает решения?»

JavaScript — не просто код фронтенда. Это раскрытая логика.

Современные приложения раскрывают критически важные детали через JS:

• внутренние API;

• скрытые параметры;

• флаги функций;

• ролевую логику;

• маршруты только для администраторов;

• устаревшие или унаследованные конечные точки;

• решения по безопасности, принятые на стороне клиента.

Умение читать JavaScript похоже на чтение внутренней документации к бэкенду, не предназначенной для публичного доступа.

Шаг 2: Правильное чтение JavaScript

Не ищите слепо alert(1) или eval.

Сначала поймите структуру.

Открыв JS-файл, сосредоточьтесь на:

• базовых путях API;

• версионированных конечных точках (/v1/, /v2/, /internal/);

• заголовках аутентификации;

• флагах функций (feature toggles);

• проверках ролей;

• логике обработки ошибок.

Минифицированные файлы раздражают, но логика в них все равно присутствует.

Используйте инструменты разработчика в браузере или форматируйте файл для удобного чтения перед анализом.

Шаг 3: Поиск наиболее значимых ключевых слов, указывающих на уязвимости

Ищите эти ключевые слова во всех JS-файлах:

admin
internal
debug
test
staging
beta
role
permission
access
feature
flag
enabled
disabled
isAdmin
isStaff
token
key
secret
config

Эти ключевые слова часто указывают на:

• неэффективный контроль доступа;

• скрытую административную функциональность;

• незащищенные внутренние API;

• ошибки в логике.

Пример:

if (user.role === "admin") {
  enableExport()
}

Важный вопрос: проверка выполняется только в JavaScript или также на бэкенде?

Часто бэкенд слишком доверяет фронтенду.

Шаг 4: Извлечение конечных точек из JavaScript

JavaScript-файлы часто раскрывают необработанные пути API, например:

/api/user/profile
/api/admin/export
/internal/reports
/graphql

Эти конечные точки могут не отображаться при обычном просмотре.

Ваша задача:

1. Скопировать эти конечные точки.

2. Отправить их в Burp Repeater.

3. Протестировать их вручную.

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

Шаг 5: Тестирование конечных точек JavaScript в Burp Suite

Как только конечные точки идентифицированы, Burp становится вашим основным оружием.

Первое правило тестирования: ручной режим > автоматический.

Автоматическое тестирование помогает в обнаружении. Ручное тестирование находит настоящие баги.

Всегда сначала тестируйте конечные точки вручную.

Шаг 6: Процесс ручного тестирования в Burp

Отправив запрос в Burp Repeater, сделайте следующее:

1. Выполните проверку аутентификации:

• удалите заголовок Authorization;

• замените токен на токен другого пользователя;

• используйте просроченные или поврежденные токены.

Если конечная точка все еще работает, у вас может быть:

• обход аутентификации;

• IDOR (insecure direct object reference — небезопасные прямые ссылки на объекты);

• повышение привилегий

2. Выполните манипуляцию параметрами.

Изменяйте параметры агрессивно:

• числа → другие идентификаторы пользователей;

• булевы значения (true → false);

• поля ролей (user → admin);

• поля статуса (inactive → active).

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

3. Проверьте скрытые параметры из JavaScript.

JS часто раскрывает параметры, которые никогда не отправляются через интерфейс.

Пример:

fetch("/api/user/update", {
  body: {
    email,
    role,
    isVerified
  }
})

Попробуйте добавить параметры вроде role или isVerified вручную через Burp.

Скрытые параметры — настоящая золотая жила.

Шаг 7: Тестирование на наличие распространенных уязвимостей с помощью JS

Анализ JavaScript часто приводит к обнаружению следующих классов ошибок.

1. Нарушение контроля доступа (Broken Access Control):

• доступ к API администратора для обычных пользователей;

• незащищенные функции экспорта или удаления.

2. Небезопасные прямые ссылки на объекты (Insecure Direct Object Reference):

• параметры userId, orderId, accountId;

• последовательные или предсказуемые идентификаторы;

3. Недостатки бизнес-логики (Business Logic Flaws):

• пропуск шагов;
  
• изменение состояния с нарушением порядка;

• повторная отправка запросов.

4. Раскрытие информации (Information Disclosure):

• отладочные конечные точки;

• внутренние сообщения об ошибках;

• подробные ответы API.

5. Излишнее доверие к валидации на клиентской стороне:

• ограничения, применяемые только в JS;

• проверка ролей только в интерфейсе.

Шаг 8: Установка расширений Burp Suite, которые действительно помогают

Не устанавливайте все подряд.

Эти расширения полезны в сочетании с анализом JS.

Logger++

Помогает отслеживать все запросы, связанные с конкретным действием. Очень полезно для понимания цепочек запросов.

Autorize

Автоматически проверяет проблемы с авторизацией, повторяя запросы с разными токенами.

Param Miner

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

Turbo Intruder

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

Помните: расширения помогают вам. Они не заменяют ваше мышление.

Шаг 9: Комбинирование анализа JS и Burp для максимального эффекта

Настоящий эффект дает комбинирование анализа JS и Burp.

Пример комбинирования:

1. JS раскрывает скрытую административную конечную точку.

2. Конечная точка не имеет корректной проверки ролей.

3. Burp подтверждает доступ от имени пользователя с низкими привилегиями.

4. Выполняется действие, доступное только администратору.

Это точный, высокоэффективный отчет.

Типичные ошибки, которых следует избегать

• Слепой перебор полезных нагрузок (payload spraying).

• Игнорирование логики в JavaScript.

• Использование только сканеров.

• Невнимательное чтение ответов сервера.

• Пропуск ручного тестирования.

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

Заключение

Разведка указывает, где искать. JavaScript показывает, как все работает. Burp Suite демонстрирует, что ломается.

Если вы правильно свяжете эти три компонента, поиск багов станет предсказуемым. 

Хватит охотиться вслепую. Начните понимать приложения. Именно это понимание позволяет настоящим багхантерам стабильно зарабатывать.

Читайте также:

• 7 методов работы со строками в JavaScript, о которых знают всего 2% разработчиков
• Используйте эти хаки для трехкратного ускорения скриптов JavaScript уже сегодня
• Почему шифрование и дешифрование данных необходимо для безопасности приложений и бэкенд-систем

Читайте нас в Telegram, VK и Дзен

---

Перевод статьи Monika sharma: JavaScript Analysis & Burp Suite Techniques That Actually Work