Вопросы на собеседовании: Инженер по безопасности приложений

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

• Начинаю с конкретного источника, например Express `req.query`, и иду через возвращаемые значения, параметры, поля, обратные вызовы и псевдонимы до опасной операции вроде `db.query` или `child_process.exec`.
• Проверяю реализацию обёрток, а не доверяю названиям: `runSafeQuery` всё ещё может соединять строку перед вызовом драйвера базы данных.
• Использую граф вызовов или запрос пути CodeQL для подтверждения межпроцедурного маршрута, а затем проверяю, может ли каждый найденный путь действительно выполниться.
• Добавляю целевой тест с управляемым атакующим вводом и безопасный парный случай, чтобы подтвердить, какая ветка достигает опасной операции и меняет ли значение предполагаемый санитайзер.

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

• Источниками служат HTTP-параметры, сообщения и исходно введённые пользователями значения из базы данных; выполнение SQL, вывод HTML и запуск процессов образуют разные классы опасных операций.
• Привязка параметров защищает только позиции значений SQL, а кодирование HTML только конкретный контекст вывода; ни одно из них не делает строку безопасной для командной оболочки.
• Я моделирую распространение через коллекции, свойства объектов, конструкторы и вспомогательные функции фреймворка, чтобы отметка не терялась на обычных абстракциях приложения.
• До включения модели в CI добавляю негативные тесты безопасных потоков и позитивные тесты для каждой пары источника и опасной операции.

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

• Проверка `isUUID` может ограничить путь или идентификатор, но не очищает исходную строку для HTML или командной строки.
• Я читаю реализацию с учётом Unicode, декодирования, длины и поведения при ошибке и убеждаюсь, что вызывающий код использует проверенное возвращаемое значение, а не исходный ввод.
• Предпочитаю типизированное преобразование вроде `parseTenantId(): TenantId` булевой проверке, потому что безопасное значение сложнее случайно отбросить.
• Регрессионные тесты включают варианты обхода и доказывают, что поток недоверенных данных прерывается только на нужной ветке.

Я полагаюсь на автоматическое экранирование только в документированном контексте вывода и отслеживаю все способы его отключения.

• Подстановка текста в React и HTML-шаблоны Jinja обычно кодирует HTML, но `dangerouslySetInnerHTML`, фильтр Jinja `safe` и сырые блоки снимают эту защиту.
• Кодирования HTML-текста недостаточно внутри JavaScript, CSS или URL, поэтому там нужны предназначенные для контекста API или строгие белые списки.
• Значение после серверного рендеринга может привести к DOM XSS, если клиентский код передаст его в `innerHTML`, `insertAdjacentHTML` или небезопасный сторонний компонент.
• Я проверяю конфигурацию шаблонизатора и пользовательские фильтры: глобальное отключение экранирования превращает гарантию фреймворка в недоказанное предположение для всего приложения.

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

• Изменения маршрутов, схем, авторизации, сериализаторов, шаблонов, запросов, файловой системы и исходящих обращений проверяю раньше механических рефакторингов и сгенерированных файлов.
• Прослеживаю один полный запрос от точки входа до побочного эффекта и сравниваю новый путь с принятым способом аутентификации и изоляции арендаторов.
• Проверяю удалённые проверки и изменённые значения по умолчанию в diff, затем изучаю blame и соседний код, если изменение опирается на неявный инвариант.
• Запрашиваю целевые тесты отказа в авторизации, некорректного ввода и граничных случаев, а не одобряю код только по успешным сценариям.

Я уделяю внимание API, которые повторно интерпретируют строки как код, разметку, пути, запросы или команды.

• `eval`, `Function`, таймеры со строками и `vm.runInNewContext` являются точками выполнения кода, даже если ввод сначала прошёл разбор JSON.
• `child_process.exec`, `execSync` и `{ shell: true }` запускают командную оболочку; `spawn` или `execFile` с фиксированной программой и массивом аргументов исключают её разбор.
• `innerHTML`, `insertAdjacentHTML` и React `dangerouslySetInnerHTML` требуют очистки для конкретного контекста, например по строго настроенной политике DOMPurify.
• Динамический `require`, пути файловой системы и слияние объектов требуют белых списков или канонизации, поскольку могут привести к обходу каталогов и загрязнению прототипа.

Я проверяю API Java, которые вычисляют выражения, строят запросы, десериализуют объекты или запускают процессы операционной системы.

• `Runtime.exec(String)` сам по себе не запускает командную оболочку: он разбивает строку на имя программы и аргументы, поэтому метасимволы оболочки не получают особого смысла. Однако управление именем программы или параметрами всё равно позволяет подменять запускаемый процесс и внедрять опасные аргументы.
• `new ProcessBuilder("sh", "-c", value)` явно запускает оболочку и допускает командную инъекцию, если `value` не доверен. Вместо этого я задаю фиксированную программу, передаю аргументы отдельно и разрешаю только ожидаемые параметры.
• Конкатенация в `Statement.execute` создаёт SQL-инъекцию; `PreparedStatement` защищает значения, но не параметризует имена таблиц и направления сортировки.
• Вычисление SpEL, OGNL, шаблонов и скриптов, а также `ObjectInputStream` для недоверенных байтов могут привести к выполнению кода, поэтому такие пути нужно устранять или жёстко ограничивать.

Я отмечаю API Python, которые десериализуют объекты, вычисляют выражения, запускают командную оболочку или строят пути и запросы из строк.

• `pickle.loads`, `marshal.loads` и небезопасный `yaml.load` могут создавать выбранные атакующим объекты; для обычных данных лучше JSON или `yaml.safe_load`.
• `eval`, `exec` и динамический импорт выполняют код, а `subprocess.run(..., shell=True)` добавляет интерпретацию метасимволов командной оболочки.
• SQL через f-строку остаётся уязвимым; плейсхолдеры DB-API должны передавать значения, а идентификаторы выбираются из белого списка или собираются SQL-конструктором драйвера.
• Извлечение через `tarfile` или `zipfile` и объединение путей через `pathlib` требуют проверки, что итоговый путь остаётся внутри целевого каталога.

Проверка пути и последующее открытие являются разными операциями, поэтому атакующий может между ними заменить символическую ссылку или запись каталога.

• `realpath` перед `open` всё ещё оставляет окно гонки, если другой процесс может изменить проверенный путь.
• В Linux я предпочитаю операции относительно файлового дескриптора, например `openat` с `O_NOFOLLOW`, доверенным дескриптором каталога и строгими правами и владельцем.
• Авторизацию и работу с файлом выполняю через один открытый дескриптор, а результат публикую атомарным `rename`, не разрешая путь повторно.
• Временные файлы создаю через `mkstemp` или аналогичный API с исключительным созданием, а не по предсказуемому имени после предварительного `exists`.

Проверка безопасности может устареть, если параллельный запрос изменит защищённое состояние до фиксации записи.

• Два запроса на погашение купона могут оба увидеть `used = false` и использовать один купон дважды, если проверка и обновление выполняются раздельно.
• Я закрепляю инвариант в одном условном обновлении, уникальном ограничении или транзакции с нужной блокировкой строки и принимаю только победивший результат.
• Если авторизация зависит от изменяемого членства, проверка политики и чувствительное изменение должны выполняться в одной транзакции или доверенной операции базы данных.
• Ключи идемпотентности останавливают повторные попытки одного запроса, но не заменяют блокировки и ограничения для разных запросов к одному ресурсу.

Я ограничиваю весь жизненный цикл исходящего запроса, а не только полученный от пользователя текст URL.

• Использую одну выбранную библиотеку разбора URL, разрешаю только `http` и `https`, запрещаю учётные данные и необычные числовые записи IP-адресов, а перед подключением получаю через DNS и проверяю все адреса назначения.
• Сетевой уровень блокирует адреса обратной петли, локальные адреса канала, диапазоны RFC 1918 и локальные диапазоны IPv6, адреса метаданных облака и запрещённые порты, в том числе после повторного разрешения DNS.
• Перенаправления отключены либо каждая новая цель проходит ту же проверку; размер ответа, время ожидания и число перенаправлений ограничены.
• Компоненты с высоким риском работают через прокси исходящего трафика или в изолированной сети, где белый список делает внутренние сервисы недоступными по архитектуре.

Я нахожу места, где типизированное построение запроса сменяется сырым SQL, и определяю, какие части строки снова влияют на структуру запроса.

• Такие API, как SQLAlchemy `text`, Prisma `$queryRawUnsafe`, Knex `raw`, нативные запросы Hibernate и строковый `orderBy`, требуют проверки как точки выполнения SQL, даже если остальной код использует ORM.
• Плейсхолдеры связывают только значения. Имена таблиц и столбцов, операторы, направления сортировки и фрагменты SQL должны выбираться из фиксированных соответствий или собираться безопасным API.
• Я проверяю обёртки и поведение шаблонных строк: одни API параметризуют подставленные значения, а другие с похожими именами соединяют строки напрямую.
• В тестах передаю метасимволы как значения и неожиданные варианты идентификаторов, затем проверяю сформированный SQL и результат, чтобы данные не могли изменить структуру запроса.

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

• Вложенные или пересекающиеся квантификаторы, неоднозначные альтернативы и повторяемые группы перед несовпадающим окончанием служат тревожными признаками. Якоря сами по себе не делают поиск линейным.
• Перед поиском я ограничиваю длину строки, а неоднозначные выражения заменяю простым разбором, ограниченными квантификаторами или движком с линейным временем, например RE2, если хватает его возможностей.
• Регулярные выражения от пользователя запрещаю либо принимаю только ограниченный синтаксис и малый размер: успешная компиляция ещё не означает безопасное выполнение.
• В регрессионные замеры добавляю специально подобранные строки, которые почти совпадают, и задаю предел времени. Изоляция процесса и тайм-ауты остаются дополнительной, а не основной защитой.

Загрязнение прототипа возникает, когда управляемые атакующим пути к свойствам изменяют прототип объекта, а не только его собственные данные.

• Рекурсивное слияние и функции задания пути должны запрещать `__proto__`, `prototype` и `constructor` на любой глубине, а не только на верхнем уровне.
• Я обновляю уязвимые библиотеки слияния и предпочитаю копирование по схеме в явные DTO или словари без прототипа.
• Код авторизации и конфигурации проверяет собственные свойства через `Object.hasOwn`, а не доверяет унаследованным значениям по умолчанию.
• Тесты отправляют вложенный JSON и параметры строки запроса, а затем проверяют, что обычные объекты и решения по безопасности не изменились.

Я привязываю запрос к строгой модели формы для конкретной операции и не передаю сущность JPA механизму веб-привязки.

• В форме объявлены только редактируемые поля, `WebDataBinder.setAllowedFields` задаёт белый список на уровне фреймворка, а `setIgnoreUnknownFields(false)` запрещает стандартное молчаливое игнорирование неизвестных свойств.
• Запрещённые поля лишь попадают в список подавленных, поэтому я отклоняю запрос при ошибках в `BindingResult` или непустом `getSuppressedFields()` и возвращаю 400 при сбое строгой привязки.
• Сервис переносит проверенные значения в загруженную с учётом арендатора сущность, а владельца, роль и ID учётной записи получает из серверного контекста аутентификации, поэтому вложенный путь не может выбрать служебное состояние.
• В MVC-тестах я отправляю служебные, неизвестные и вложенные имена вроде `roles[0]` и проверяю отказ вместе с отсутствием изменений в хранилище.

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

• JSON, Protobuf или ограниченная схема CBOR переносят примитивы и объявленные сообщения без Java `ObjectInputStream`, Python pickle и активации имён типов .NET.
• Я ограничиваю глубину вложенности, размеры коллекций и строк и общее число байтов, потому что даже безопасное создание объектов может исчерпать память или процессорное время.
• HMAC подтверждает целостность и подлинность, но не делает опасный десериализатор безопасным при компрометации ключа подписи или доверенного отправителя.
• Устаревшую нативную сериализацию изолирую за белым списком и границей миграции, а зависимости с цепочками гаджетов по возможности удаляю.

Я отключаю DTD и любое разрешение внешних сущностей, затем проверяю эти настройки на конкретной версии используемого парсера.

• Парсер не должен загружать внешние общие и параметрические сущности, схемы или ресурсы XSLT из сети и локальных файлов.
• Я ограничиваю размер ввода, расширение сущностей, глубину вложенности и время обработки для защиты от отказа в обслуживании, например при экспоненциальном расширении сущностей.
• Если формату нужна схема, она загружается из доверенного локального каталога, а не по URI из документа.
• Регрессионный пример пытается прочитать локальный файл и обратиться к внешнему контрольному адресу, чтобы тест доказывал защиту, а не просто наличие флага.

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

• Повторяющиеся ключи объекта, числа вне допустимого диапазона, бесконечность и NaN, некорректный Unicode и чрезмерная вложенность отклоняются до того, как шлюз и приложение смогут истолковать их по-разному.
• Схема проверяет то же разобранное значение, которое затем использует бизнес-логика. Нельзя проверять исходный текст одним компонентом, а потом заново разбирать его другой библиотекой.
• Если протокол подписывает канонический JSON, все отправители и проверяющие используют одинаковые документированные правила канонизации. В остальных случаях подпись проверяется по точным исходным байтам до разбора.
• Набор проверочных примеров проводит неоднозначные данные через реальные парсеры шлюза и приложения и подтверждает одинаковый отказ без побочных изменений.

Я считаю декодер и каждый производный артефакт частью обработки недоверенных данных в изолированном конвейере.

• Сервис проверяет сигнатуру файла и декодирует изображение обновлённой библиотекой, затем повторно кодирует его в поддерживаемый формат, не сохраняя управляемые атакующим метаданные или полиглотное содержимое.
• До создания миниатюры ограничиваю число пикселей, размеры, число кадров, память после распаковки, процессорное время и размер результата.
• Обработка запускается без прав root в песочнице без сети, с файловой системой только для чтения и новой временной директорией.
• Оригиналы и результаты хранятся под случайными ключами в закрытом хранилище, а при скачивании задаются фиксированный тип содержимого и `Content-Disposition` без определения типа браузером.

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

• Каждое имя нормализуется и разрешается внутри целевой директории; абсолютные пути, выход к родительскому каталогу, символические и жёсткие ссылки, устройства и дубли нормализованных имён отклоняются.
• Ограничения охватывают число записей, размер отдельного файла и всего распакованного содержимого, коэффициент сжатия, вложенность и время обработки, чтобы остановить архивные бомбы.
• Для извлечения использую безопасные API библиотеки и запись относительно дескриптора, после чего непривилегированный обработчик без сети разбирает только разрешённые типы файлов.
• Ничего не публикую до полного успеха импорта, а при любой ошибке удаляю частичный результат.