Урок 8. Найти скрытые точки и проверить результат

Интерфейс показывает только предусмотренные переходы. Другие полезные точки можно найти в служебных файлах, JavaScript и ограниченном поиске путей. Каждую находку нужно проверить отдельным запросом.

От robots.txt к карте сайта

Откройте работающий «Кружок» и добавьте к его адресу /robots.txt. Прочитайте строки Disallow, Allow и Sitemap: они дают гипотезы, но ещё не подтверждают содержание найденных страниц.

Откройте указанный путь с заметками, затем /sitemap.xml. В карте сайта найдите страницы проектов, документацию и схему API. Все адреса должны относиться к вашему текущему экземпляру лаборатории.

Как JavaScript раскрывает обращения к API

В Network найдите загруженный /static/research.js и откройте его в Sources. Найдите вызов fetch в функции loadProjects, выпишите метод и путь.

JavaScript с вызовом API в DevTools

1 — research.js в Sources; 2 — вызов fetch к API проектов.

Пройдите путь от robots.txt до JavaScript

10 б.

Уровень: базовое закрепление.

Пройдите живую цепочку robots.txt → sitemap → research.js. В обычном JavaScript найдите функцию loadProjects.

Заполните отдельные поля цепочки: путь из Disallow, sitemap, JavaScript, метод и путь запроса из loadProjects.

Точнее: карта исходников (source map) как дополнительная подсказка

Этот блок необязателен для основного маршрута. В конце файла находится ссылка на research.js.map. Если открыть карту исходного кода через DevTools, в восстановленном attachments.ts можно найти дополнительную функцию loadAttachments и запрос, который она собирает.

Исходный файл attachments.ts в DevTools

1 — восстановленный attachments.ts; 2 — функция loadAttachments; 3 — связь с research.js.

Строка в JavaScript или карте исходников объясняет намерение клиентской части. Чтобы узнать, работает ли точка на сервере, её нужно открыть вручную; дополнительная находка не заменяет основной маршрут.

Проверяем найденные пути

Сначала запросите найденный в JavaScript /api/projects, затем /api/schema и сравните список маршрутов с клиентским кодом. Если выполняли дополнительный блок, после входа можно также открыть список вложений существующего проекта и сравнить его с запросом без активной сессии.

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

Гипотеза пути проходит через результат инструмента и ручную проверку до записи в карту

Гипотеза становится строкой карты только после отдельного подтверждающего запроса.

Разбираем ограниченный результат dirsearch

Ограниченный словарь поиска
Fallback: сохранённый результат того же запуска

discovery-results.json — сохранённый результат того же запуска. Для основного маршрута можно открыть этот файл и перейти к ручной проверке кандидатов: навык урока состоит не в установке инструмента, а в умении отличить настоящую точку от похожего ответа.

Если dirsearch уже установлен, дополнительно воспроизведите короткий запуск. Скачайте discovery-wordlist.txt, скопируйте origin лаборатории из панели и сохраните его в переменной:

export KRUZHOK_URL='вставьте сюда origin своей лаборатории'
dirsearch -u "$KRUZHOK_URL" -w discovery-wordlist.txt --threads 1 --timeout 3 --retries 0 --no-color

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

В проверенном запуске dirsearch v0.4.3 команда показывает восемь строк с кодом 200:

/robots.txt
/sitemap.xml
/health
/docs/api
/api/schema
/research-notes
/legacy/admin-console
/legacy/backup-export

Первые шесть строк и последние две пока одинаково являются только кандидатами.

Сначала убедитесь, что обычный случайный путь вне устаревшего пространства отвечает настоящим 404:

curl -i "$KRUZHOK_URL/missing-outside-legacy-a81f2c"

Затем создайте эталон внутри той же устаревшей группы и сравните его с двумя правдоподобными кандидатами. Для основного маршрута достаточно открыть три ответа через Burp Suite или curl и сравнить код, длину, <title> и характерный текст.

Дополнительно: автоматизируем сравнение

Следующий цикл собирает те же признаки автоматически и вычисляет SHA-256. Он полезен как пример shell-автоматизации, но для ответа задачи не обязателен:

for path in legacy/missing-a81f2c legacy/admin-console legacy/backup-export; do
  body="$(mktemp)"
  code="$(curl -sS -o "$body" -w '%{http_code}' "$KRUZHOK_URL/$path")"
  bytes="$(wc -c < "$body" | tr -d ' ')"
  title="$(sed -n 's:.*<title>\(.*\)</title>.*:\1:p' "$body")"
  hash="$(shasum -a 256 "$body" | cut -d ' ' -f 1)"
  printf '/%s code=%s length=%s title=%s sha256=%s\n' "$path" "$code" "$bytes" "$title" "$hash"
  rm "$body"
done

Сравните у всех трёх ответов код, длину, <title>, характерный текст и, если запускали дополнительный цикл, SHA-256. Совпадение с заведомо отсутствующим устаревшим путём означает ложный 404 (soft 404); отличие требует ручной проверки содержимого. Итоговую классификацию двух кандидатов сформулируйте сами в задании ниже.

Откройте вручную через Burp Suite или curl и шесть остальных кандидатов. Для каждого решите, отличается ли его ответ от подходящего отсутствующего пути:

curl -i "$KRUZHOK_URL/robots.txt"
curl -i "$KRUZHOK_URL/sitemap.xml"
curl -i "$KRUZHOK_URL/health"
curl -i "$KRUZHOK_URL/docs/api"
curl -i "$KRUZHOK_URL/api/schema"
curl -i "$KRUZHOK_URL/research-notes"
Dirsearch показал путь с кодом 200. Достаточно ли этого, чтобы добавить путь в итоговую карту? · 5 б.

Для каждого настоящего пути сохраните короткий устойчивый признак ответа.

Исключите soft 404 из результатов dirsearch

10 б.

Уровень: базовое закрепление.

Используйте сохранённый результат ограниченного dirsearch либо воспроизведите запуск с выданным словарём. Создайте отсутствующий путь внутри той же группы legacy и сравните его тело с ответами кандидатов.

В отдельных полях выберите шесть реальных путей и два soft-404 кандидата, затем укажите baseline и основание сравнения.

Для дополнительного признака используйте title, характерный фрагмент или SHA-256 тела.

Собираем карту точек обращения

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

Таблица подтверждённых точек обращения

Карта связывает источник, запрос, состояние, ответ и короткий вывод.

Где это пригодится на олимпиаде

В задаче «Зельеварение» для 9 класса на региональном этапе ВсОШ 2026 года участник запускал dirsearch и переходил к найденному /secret (источник: официальный разбор задачи, стр. 2). В задачах Web 9-1, Web 10-2 и Web 11-2 заключительного этапа 2026 года для 9–11 классов участники проверяли robots.txt или результаты dirsearch и вручную открывали найденные пути. Отдельных подтверждённых олимпиадных примеров на карту исходников и soft 404 в доступных разборах нет; здесь soft 404 — практический навык проверки результатов сканера.

Вывод

robots.txt, карта сайта, клиентский JavaScript и ограниченный результат dirsearch дают только гипотезы о точках обращения. Настоящий путь нужно открыть вручную, сравнить с корректным отсутствующим адресом, исключить soft 404 и сохранить устойчивые признаки ответа. Итогом становится проверенная карта, а не список предположений сканера.