Глава 44 / 51
Том 5 · Расширения, эксплуатация и практика

Границы безопасности и модель доверия: цена полной мощности

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

Обзор

Позиционирование: не справочник пентестера, а глава моделирования угроз. Продукт — ваш собственный чек-лист аудита развёртывания. Предусловия: гл. 03 (поверхность возможностей), гл. 40 (вложенная компиляция).

44.1 Введение

Модель безопасности большинства рантаймов — «минимальные права по умолчанию»; XServer наоборот — полные права по умолчанию: скрипты зовут 2963 API (включая полные наборы процессов/файлов/сети), открывают ещё один компилятор, на Windows напрямую пользуются системными библиотеками. Этот размен покупает ноль накладных расходов на границе и полноту возможностей, ценой правильного размещения доверия. Глава выясняет, где именно.

44.2 Полный смысл «без песочницы»

кусок скрипта = нативный код в процессе хоста ├── общее адресное пространство: дикая ссылка пробивает весь сервис ├── те же права: читает всё, что читает хост (включая файлы приватных ключей) ├── может рекомпилировать: xsCreateTCC → любой новый код └── может наружу/запускать: xrtProcessRun / нативные сокеты Вывод: контроль над devfile = контроль над сервером
ЗаблуждениеФакт
«скрипт упал — хост выжил»нет — один процесс; одна ошибка сегментации завершает весь сервис
«не экспортировать опасные API — и безопасно»у таблицы символов нет проверки сигнатур; скрипт может extern любой символ хоста
«вложенную компиляцию можно выключить»это экспортируемый символ — кто контролирует devfile, контролирует всё, и наоборот

Это не список дефектов, а проектный факт: первый экран xsbase.h гласит «ноль ограничений: без песочницы, без прав, без пространств имён; всё открыто приложению». Честное объявление границы безопаснее ложного обещания изоляции.

44.3 Слои доверия

СлойСторонаВердикт доверияОборона
0развёртыватель (кто кладёт devfile)полное доверие — эквивалент входа на серверучётные записи ОС и права на файлы
1авторы скриптов (если не развёртыватель)как «могущие писать серверный код»код-ревью / управление правами коммита
2податели плагинов (сцена гл. 40)не доверять — пока не сузили поверхность возможностейсобственный белый список символов (ниже)
3клиенты публичной сетиникогда не доверятьоборона слоя протоколов (44.4) + прикладная аутентификация

Второй слой — единственный, где надо «работать»: когда плагинная система принимает внешний код, внедряйте через tcc_add_symbol только собственный белый набор plugin_api_*, не выдавайте xsCreateTCC и заголовки VFS — квазипесочница, ограниченная лексически и по символам. Она не остановит злонамеренный машинный код, но остановит «опасный код от честного человека» — в этом подлинная сила границ такого класса.

44.4 Сводка обороны публичной сети

Оборона третьего слоя (клиенты) рассеяна по главам; сводим в аудит-лист:

  • Транспорт: TLS-эндпоинты + сертификаты по хостам (гл. 08/12); наличие открытого эндпоинта должно быть решением, а не умолчанием
  • Лимиты запроса: header/path/body_limit (431/414/413) ужаты по бизнесу (гл. 09)
  • Лимиты времени: idle_timeout против медленных атак (проверено образцом slowloris из drill)
  • Статический слой: восьмивекторная защита от обхода + deny_dotfiles (гл. 10)
  • WS: ws_message_limit (1009) + обязательный подпротокол (гл. 22)
  • Бинарные протоколы: limits xtp2 действуют с заголовка + битый кадр = разрыв (гл. 33)
  • Плоскость управления: аутентификация + интрасетевой vhost (гл. 27); глубокий медосмотр отдельно от зонда LB (гл. 43)
  • SQL: привязка параметров без исключений (гл. 32)
  • Бизнес-аутентификация и валидация ввода: ваш код — XServer не делает это за вас и не мешает вам

44.5 Контракт

  • Граница: контроль devfile = контроль сервера; доверие клиенту = никогда.
  • Слои: внешний код входит в плагинный слой только после сужения поверхности возможностей.
  • Аудит: перед выходом пройдите лист 44.4; при каждом новом маршруте/ручке/плагине проходите связанные пункты заново.

Частые ошибки

Ввод пользователей компилируется в плагины
Симптом
«Продвинутая функция» позволяет подавать C-код на исполнение сервером.
Причина
Сторону третьего слоя приняли за нулевой — это раздача серверных шеллов зарегистрированным. Вычисление выражений идите путём синтаксического разбора (ограниченная грамматика) или строго белосписочного мини-вычислителя; даже с кэшем компиляций гл. 40 открывайте его лишь доверенным источникам.
Открытый порт управления торчит в публичную сеть
Симптом
/admin/* прикрыт простым паролем и ездит по 80-му порту.
Причина
Плоскость управления достаточно ценна для полного обслуживания — TLS + отдельный vhost + привязка к интрасети (комбинация гл. 20/27).

Упражнения

БазовыйАудит развёртывания

По листу 44.4 проведите аудит своего демо-развёртывания; двумя колонками «выполнено / отсутствует».

Приёмка: у каждого отсутствующего пункта есть план исправления (правка конфигурации / кода / мотив принятого риска).
ПродвинутыйГраница белого списка

Оберните плагинную систему гл. 40 в белый список plugin_api_* (без xsCreateTCC и файловых API); опишите силу границы.

Приёмка: вызов символа вне списка роняет компиляцию плагина; документация не преувеличивает границу.
ВызовАтакующие учения

Прогоните по своему сервису раунд drill-атак (медленные/сверхлимит/обход/битые кадры); зафиксируйте сработавшие линии обороны.

Приёмка: для каждого класса атаки названа остановившая её оборона; до слоя скриптов не дошло ничего.

Итоги

ТезисВывод
Модельполные права по умолчанию; доверие ставится правильно, а не возможности урезаются
Фактыконтроль devfile = контроль сервера; изоляции уровня процессов нет
Слоиразвёртывателю полное доверие / плагины сначала сужаются / клиентам никогда
Оборонадевять пунктов публичного листа (44.4) как база аудита
API, затронутые в главе
tcc_add_symbol · граница белого списка Ручки лимитов · параметры обороны
Что дальше по xrt