Почему использование eval и ActiveX в поле HTML-документа 1С считается небезопасным?

← На главную

Вопрос безопасности при работе с Полем HTML-документа в 1С:Предприятие является критически важным, особенно когда информационная база публикуется в открытом доступе (ДМЗ) или используется для отображения контента из внешних источников. Проанализируем эволюцию этого объекта, разберем причины блокировки функции eval и выясним, какие угрозы актуальны для современных платформ на базе WebKit.

Исторический контекст: Эпоха Internet Explorer и угроза ActiveX

Рассмотрим, почему старые версии платформы (до массового перехода на WebKit/Chromium) считались уязвимыми. В то время Поле HTML-документа использовало движок Internet Explorer (MSHTML), установленный в операционной системе Windows. Основная проблема заключалась в глубокой интеграции IE с компонентами ActiveX.

Разберем классический вектор атаки того времени:

Злоумышленник внедряет на HTML-страницу вредоносный скрипт (через взломанный внешний ресурс или подмену контента).
Скрипт пытается создать объект ActiveXObject, например, WScript.Shell или Scripting.FileSystemObject.
Если настройки безопасности зоны IE были недостаточно жесткими, скрипт получал возможность выполнять любые консольные команды в ОС от имени текущего пользователя 1С или читать/удалять файлы на диске.

Важный вывод: В современных версиях 1С на движке WebKit поддержка ActiveX отсутствует на уровне архитектуры. Это полностью устраняет риск выхода злоумышленника в операционную систему через компоненты COM/ActiveX.

Почему функция eval попала под запрет?

Перейдем к обсуждению функции eval(). Многие разработчики замечают, что попытка вызвать eval напрямую из контекста 1С в Поле HTML часто блокируется. Выясним причину этого ограничения. Это связано с реализацией политики безопасности контента — Content Security Policy (CSP).

Проанализируем ситуацию: функция eval() позволяет исполнять любую строку текста как JavaScript-код. Рассмотрим основные риски:

XSS-атаки (Cross-Site Scripting): Если вы выводите в поле HTML данные, полученные из ненадежного источника (например, текст электронного письма или описание товара со стороннего сайта) и не экранируете их, злоумышленник может вставить строку с кодом.
Обход типизации: Использование eval затрудняет статический анализ кода и позволяет динамически изменять логику взаимодействия страницы с платформой 1С.

Для минимизации этих рисков платформа 1С внедряет жесткие правила CSP, которые по умолчанию запрещают unsafe-eval. Это стандартная практика для современных веб-приложений, стремящихся исключить возможность инъекции произвольного кода.

Безопасность взаимодействия: Мост между JS и 1С

Разберем, как организовано взаимодействие между кодом 1С и JavaScript в современных условиях. Раньше часто использовался объект window.external, который предоставлял широкий доступ к методам контейнера. Сейчас мы используем более безопасные и изолированные механизмы.

Посмотрим на пример правильной организации вызова кода 1С из JavaScript:


// В JavaScript коде страницы
function SendTo1C(data) {
    // Используем стандартную схему навигации или события
    window.location.href = "v8connect://custom-action?data=" + encodeURIComponent(data);
}

На стороне 1С мы перехватываем это событие в обработчике ПриНажатии или через специализированные методы расширения. Такой подход (Bridge) является гораздо более безопасным, так как взаимодействие строго ограничено конкретными точками входа.

Критическая уязвимость: Функция Вычислить() в коде 1С

Проанализируем пример кода, который создает реальную «дыру» в безопасности, независимо от того, насколько защищен сам WebKit. Посмотрим на опасную экспортную функцию на форме 1С:


&НаКлиенте
Функция ВыполнитьДействиеИзJS(КодДляВыполнения) Экспорт
    // КРИТИЧЕСКАЯ ОШИБКА БЕЗОПАСНОСТИ
    Возврат Вычислить(КодДляВыполнения);
КонецФункции

Если разработчик предоставляет возможность JavaScript-коду вызывать подобную функцию 1С, то вся защита браузера становится бесполезной. Злоумышленник, подменив DOM-дерево в поле HTML, сможет вызвать этот метод и выполнить произвольный код на языке 1С (BSL) в контексте клиента.

Рекомендация: Никогда не используйте функции Вычислить() или Выполнить() с данными, приходящими из поля HTML. Вместо этого реализуйте жесткий список разрешенных команд (белый список).

Работа в ДМЗ и инструменты отладки

При публикации базы в демилитаризованной зоне (ДМЗ) возникают дополнительные опасения по поводу использования пользователями Консоли разработчика (вызывается через Ctrl+Alt+Shift+F12). Выясним, насколько это опасно.

Рассмотрим вкладку Network в консоли WebKit внутри 1С. Часто разработчики видят, что она пуста. Это происходит потому, что платформа 1С пропускает сетевой трафик через собственные внутренние прокси-классы для обеспечения авторизации и работы через настройки прокси 1С. Это затрудняет злоумышленнику перехват и анализ низкоуровневых HTTP-запросов между формой и сервером приложений.

Тем не менее, стоит учитывать следующие моменты при публикации базы вовне:

Изоляция процессов: В современных версиях WebKit работает в отдельном процессе. Крах или взлом внутри поля HTML не дает прямого доступа к памяти основного процесса 1С.
Clickjacking: Защищайте опубликованную базу заголовками X-Frame-Options, чтобы окно 1С нельзя было встроить в iframe на стороннем вредоносном ресурсе.
Ограничение внешних обработок: Самый надежный способ защиты — запретить пользователям, работающим через внешние каналы, запуск внешних обработок. Без этого инструмента возможности по «взлому» системы изнутри поля HTML крайне ограничены.

Итоговое сравнение безопасности

Подведем итог нашему анализу:

Тогда (IE): Основная угроза — ActiveX. Возможность прямого доступа к файловой системе и командной строке ОС. Защита зависела от системных настроек Windows.
Сейчас (WebKit): Основная угроза — XSS и манипуляции внутри документа. Защита встроена в платформу через CSP и изоляцию процессов. eval() запрещен именно для предотвращения исполнения неконтролируемого внедренного кода.

Таким образом, современное Поле HTML-документа значительно безопаснее своего предшественника, при условии, что разработчик 1С не создает «черных ходов» через небезопасное использование встроенного языка 1С.