Урок 8. Найти скрытые точки и проверить результат
Интерфейс показывает только предусмотренные переходы. Другие полезные точки можно найти в служебных файлах, JavaScript и ограниченном поиске путей. Каждую находку нужно проверить отдельным запросом.
От robots.txt к карте сайта
Откройте работающий «Кружок» и добавьте к его адресу /robots.txt. Прочитайте строки Disallow, Allow и Sitemap: они дают гипотезы, но ещё не подтверждают содержание найденных страниц.
Откройте указанный путь с заметками, затем /sitemap.xml. В карте сайта найдите страницы проектов, документацию и схему API. Все адреса должны относиться к вашему текущему экземпляру лаборатории.
Как JavaScript раскрывает обращения к API
В Network найдите загруженный /static/research.js и откройте его в Sources. Найдите вызов fetch в функции loadProjects, выпишите метод и путь.
1 — research.js в Sources; 2 — вызов fetch к API проектов.
Пройдите путь от robots.txt до JavaScript
Уровень: базовое закрепление.
Пройдите живую цепочку robots.txt → sitemap → research.js. В обычном JavaScript найдите функцию loadProjects.
Заполните отдельные поля цепочки: путь из Disallow, sitemap, JavaScript, метод и путь запроса из loadProjects.
Точнее: карта исходников (source map) как дополнительная подсказка
Этот блок необязателен для основного маршрута. В конце файла находится ссылка на research.js.map. Если открыть карту исходного кода через DevTools, в восстановленном attachments.ts можно найти дополнительную функцию loadAttachments и запрос, который она собирает.
1 — восстановленный attachments.ts; 2 — функция loadAttachments; 3 — связь с research.js.
Строка в JavaScript или карте исходников объясняет намерение клиентской части. Чтобы узнать, работает ли точка на сервере, её нужно открыть вручную; дополнительная находка не заменяет основной маршрут.
Проверяем найденные пути
Сначала запросите найденный в JavaScript /api/projects, затем /api/schema и сравните список маршрутов с клиентским кодом. Если выполняли дополнительный блок, после входа можно также открыть список вложений существующего проекта и сравнить его с запросом без активной сессии.
Записывайте только наблюдаемые факты: метод, путь, требуется ли вход, код и тип ответа. Не переносите значение cookie в заметки.
Гипотеза становится строкой карты только после отдельного подтверждающего запроса.
Разбираем ограниченный результат dirsearch
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"
Для каждого настоящего пути сохраните короткий устойчивый признак ответа.
Исключите soft 404 из результатов dirsearch
Уровень: базовое закрепление.
Используйте сохранённый результат ограниченного 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 и сохранить устойчивые признаки ответа. Итогом становится проверенная карта, а не список предположений сканера.