Практическое руководство по аудиту веб-интерфейса

от

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

Начинается всё обычно: браузер подсказывает добавить атрибут autocomplete, менеджер паролей не распознаёт поле, 404 на favicon. Кажется, что речь о стандартной веб-разработке.

Потом появляются пути /cgi/login.cgi, /cgi/system.cgi, поиск объектов в window, рекурсивный обход с защитой от исключений. Контекст смещается. Это уже не про форму на сайте. Это про интерфейс, который управляет железом.

[√] проверять источник кода перед применением советов — embedded-устройства и веб-приложения имеют разные модели угроз
[ ] копировать примеры без анализа контекста — можно случайно запустить разведку вместо дебага
[ ] игнорировать относительные пути в примерах — ../ может работать в одной директории и ломаться в другой

Я замечаю, что авторы технических постов иногда не проговаривают явно, для какой среды предназначен код. Это создаёт риск: читатель применяет решение не по адресу.

Как отличить встроенный интерфейс от обычного веб-приложения

Embedded-устройства — роутеры, камеры, контроллеры — часто используют устаревшие технологии. CGI-скрипты, document.write, относительные пути, обфусцированный клиентский код.

Веб-приложения на современных фреймворках ведут себя иначе. Они не прячут данные в глобальной области видимости и не возвращают XML вместо JSON без предупреждения.

[√] смотреть на структуру путей: /cgi/ — маркер legacy-интерфейса
[ ] проверять наличие минификации и обфускации в клиентских скриптах
[ ] анализировать ответы сервера: смешанные форматы (HTML/XML/JSON) характерны для встроенных систем

Проверка через консоль помогает быстро определить тип интерфейса:

// Быстрый тест: есть ли CGI-скрипты в корневой области
fetch('/cgi/', { credentials: 'include' })
    .then(r => r.status)
    .then(status => console.log('CGI доступен:', status === 200))
    .catch(() => console.log('CGI не отвечает'));

Если сервер отвечает 200 на /cgi/ — перед вами почти наверняка устройство с legacy-интерфейсом.

Почему относительные пути в примерах создают проблемы

Пример с favicon:

<link rel="icon" href="../images/favicon.ico" type="image/x-icon">

Путь ../images/ работает только если текущая страница находится на уровень ниже корня. На /admin/login.html — сработает. На / — сломается.

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

Я предпочитаю явно указывать путь от корня: /images/favicon.ico. Так код работает независимо от того, в какой папке открыта страница.

Как искать пользовательские данные в глобальной области видимости

Функция поиска массивов с пользователями:

function findUserArrays(obj, path = '', depth = 0) {
    if (depth > 4 || !obj || typeof obj !== 'object') return;

    for (let key in obj) {
        try {
            const val = obj[key];
            const fullPath = path ? `${path}.${key}` : key;

            if (Array.isArray(val) && val.length && val[0]?.username) {
                console.log('Найдено:', fullPath, val);
            } else if (typeof val === 'object') {
                findUserArrays(val, fullPath, depth + 1);
            }
        } catch(e) {}
    }
}

Этот код решает конкретную задачу: найти данные там, где их не должно быть видно. Защита от исключений в try-catch — не паранойя, а необходимость. В обфусцированном коде доступ к некоторым свойствам может выбрасывать ошибку.

[√] ограничивать глубину рекурсии — предотвращает зависание при обходе больших объектов
[ ] оборачивать доступ к свойствам в try-catch — защищает от геттеров с исключениями
[ ] проверять наличие характерных полей (username, name) — ускоряет поиск релевантных данных

Вопрос остаётся: зачем вообще данные пользователей оказываются в window? В правильно спроектированной системе они не должны быть доступны через консоль.

Что означает проверка angular через typeof

Код проверки:

typeof angular !== 'undefined' ? console.log('AngularJS подключён') : console.log('AngularJS не найден');

AngularJS (версия 1.x) официально не поддерживается с 2022 года. Если он встречается в 2026 — это сигнал о том, что система давно не обновлялась.

[√] проверять версию фреймворка перед использованием примеров кода
[ ] учитывать, что устаревшие библиотеки могут иметь неизвестные уязвимости
[ ] планировать миграцию, если проект зависит от неподдерживаемых технологий

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

Как интерпретировать проверку ответа сервера на формат

Проверка:

if (text.trim().startsWith('{')) {
    return JSON.parse(text);
}

Этот подход работает, когда сервер может вернуть разные форматы: JSON при успехе, HTML при ошибке 403, XML при сбое парсинга.

[√] сначала получать ответ как текст — даёт контроль над парсингом
[ ] проверять первый символ перед JSON.parse — предотвращает исключения
[ ] логировать неожиданные форматы — помогает диагностировать проблемы сервера

Не знаю точно, почему некоторые серверы возвращают HTML вместо JSON при ошибке. Возможно, это наследие архитектуры, где CGI-скрипты генерируют полные страницы.

Интерактивная проверка: определите тип интерфейса за три команды

Скопируйте в консоль браузера на целевой странице:

// 1. Проверка наличия CGI
fetch('/cgi/', { credentials: 'include' })
    .then(r => console.log('CGI статус:', r.status))
    .catch(e => console.log('CGI ошибка:', e.message));

// 2. Проверка глобальных объектов
const legacyHints = ['angular', 'lang', 'Auth', 'checkform'];
legacyHints.forEach(hint => {
    if (window[hint]) console.log('Найдено:', hint);
});

// 3. Проверка формата ответов
fetch(window.location.href)
    .then(r => r.text())
    .then(t => {
        const isJSON = t.trim().startsWith('{') || t.trim().startsWith('[');
        console.log('Ответ в формате JSON:', isJSON);
    });

Результаты покажут: работает ли CGI, есть ли устаревшие глобальные переменные, в каком формате сервер отдаёт данные.

Если все три проверки указывают на legacy-характеристики — перед вами, скорее всего, встроенное устройство.

Почему атрибут align в разметке говорит о возрасте кода

Пример:

<input align="left" name="pwd" type="password">

Атрибут align устарел в пользу CSS. Его наличие в коде — маркер того, что разметка не обновлялась много лет.

[√] заменять устаревшие атрибуты на CSS-правила при рефакторинге
[ ] документировать причины, если приходится сохранять старый код
[ ] тестировать визуальное отображение после замены атрибутов

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

Как оценить риски применения кода из неочевидного контекста

Совет по autocomplete:

<input name="pwd" type="password" autocomplete="current-password">

Абсолютно корректный и полезный. Работает одинаково хорошо и на веб-сайте, и на интерфейсе устройства.

Но когда тот же автор предлагает перебирать CGI-эндпоинты с куками сессии — контекст меняется. Это уже не улучшение UX, это разведка.

[√] разделять универсальные советы и специфичные для среды
[ ] проверять, не требует ли пример дополнительных привилегий
[ ] оценивать, может ли код быть интерпретирован как подозрительная активность

Фраза «это создаёт нагрузку и может быть расценено как подозрительная активность» звучит как предупреждение от человека, который уже видел логи сервера.

Что делать если текст смешивает разные уровни доступа

Легко пропустить переход от «добавьте атрибут» к «переберите эндпоинты». Автор не всегда явно маркирует смену контекста.

[√] выделять в тексте блоки по уровню доступа: клиентская часть, аутентифицированный запрос, административный интерфейс
[ ] проверять, требует ли пример предварительной авторизации
[ ] документировать предположения о правах пользователя

Я предпочитаю, когда автор явно пишет: «этот код работает только после входа в систему» или «требуется доступ к административной панели». Это снимает неопределённость.

Почему важно проверять примеры на изолированной среде

Код для поиска пользовательских данных может работать на одном устройстве и вызывать ошибку на другом. Различия в прошивке, версии ПО, конфигурации сервера.

[√] тестировать примеры на копии целевой системы
[ ] логировать все этапы выполнения для отладки
[ ] иметь план отката, если код меняет состояние системы

Не уверен, насколько безопасно запускать рекурсивный обход window на продакшен-устройстве. Теоретически это чтение, но на практике геттеры могут иметь побочные эффекты.

#вебаудит #embeddedсистемы #безопасностьформ #legacyкод #консоль_браузера

Загрузка…

Оставьте комментарий