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

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

• Отмечу `req.query.url` как источник, потому что клиент может менять query-параметры в обход обычного интерфейса.
• Прослежу присваивания, вызовы помощников, парсинг, валидацию и редиректы до `fetch`, Axios или другого API исходящих запросов.
• Зафиксирую защитные проверки на пути, затем проверю, ограничивают ли они конечный адрес после DNS-разрешения и редиректов, а не только исходную строку.

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

• Пути запроса, query-параметры, тело, заголовки и cookie напрямую контролируются клиентом.
• Строки базы, сообщения очереди, загруженные файлы и ответы партнерского API остаются недоверенными, если на них может влиять другой пользователь или система.
• TypeScript-тип или JSON-парсер меняет представление, но не доказывает безопасность или авторизованность значения.

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

• Выполнение SQL, запуск shell-процесса, рендеринг шаблона и `innerHTML` могут интерпретировать данные как код или синтаксис.
• Запись в файловую систему, редиректы, исходящие HTTP-запросы и десериализаторы могут пересекать важные границы приложения.
• Одно значение может быть безвредным в логе и опасным в shell-команде, поэтому я классифицирую sink по реальному API и контексту.

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

• Комментарий может законно содержать `<`, кавычки или амперсанды, поэтому запрет всех специальных символов испортит обычный текст.
• При выводе в HTML-текст шаблонизатор должен кодировать символы для этого HTML-контекста.
• Если то же значение попадает в URL или JavaScript-строку, ему нужен кодировщик или безопасный API для другого контекста.

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

• Например, `date` сопоставлю с `created_at`, а `total` с `total_cents`, отклоняя остальные значения.
• Плейсхолдеры базы связывают значения, но не имена таблиц или столбцов, поэтому одной параметризации здесь недостаточно.
• Такое сопоставление также закрывает случайный доступ к внутренним столбцам с допустимыми SQL-именами.

API должен сам применять правило ролей, потому что клиент может обойти React-форму и отправить запрос напрямую.

• На сервере нужно сверять значение с точным набором ролей для этой операции, а не со всеми известными системе ролями.
• Отдельно нужно авторизовать назначающего роль, потому что допустимое значение `admin` все равно может быть запрещено этому пользователю.
• Следует добавить API-тест, где обычный пользователь отправляет `admin` и неизвестное значение и получает отказ.

Граница доверия появляется при каждом переходе между компонентами с разными идентичностями, правами или контролем над данными.

• Ввод браузера переходит в API, поэтому API независимо от интерфейса аутентифицирует, валидирует и авторизует его.
• Задание из очереди переходит от API к worker, поэтому worker проверяет форму сообщения и не исходит из того, что каждый отправитель всегда формирует корректные сообщения.
• API и worker входят в базу под сервисными учетными записями, права которых должны соответствовать их разным задачам.

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

• Для отчетов дам отдельную учетную запись базы с доступом только к нужным представлениям или операциям `SELECT`.
• Удаление помещу за отдельный сервисный метод и проверку авторизации, не выдавая каждому модулю универсальный клиент базы.
• Фоновые конвертеры и парсеры запущу под непривилегированным пользователем ОС с доступом только к рабочему каталогу.

Я верну клиенту стабильную общую ошибку, а полезные детали оставлю в закрытых серверных логах.

• Ответ не должен содержать SQL, имена таблиц, пути файловой системы, кадры стека и значения окружения.
• Исключение нужно залогировать с correlation ID, маршрутом запроса и безопасным контекстом для расследования разработчиками.
• Ожидаемые ошибки вроде повторного email следует преобразовать в отдельный безопасный ответ вместо утечки исходного исключения базы.

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

• Проверка пути до URL-декодирования может пропустить `%2e%2e/`, хотя файловая система позже получит `../`.
• Нужно один раз распарсить и нормализовать значение библиотекой платформы, отклонить неверные или неоднозначные формы и использовать проверенный результат.
• Повторного декодирования следует избегать, потому что двойная кодировка может изменить смысл уже после первой проверки.

Код смешивает подконтрольные клиенту данные с SQL-синтаксисом, поэтому email может изменить структуру запроса.

• Конкатенацию нужно заменить плейсхолдером драйвера, например `WHERE email = $1`, и передать `email` в массиве значений.
• Не следует чинить это ручным экранированием кавычек, потому что режимы базы и крайние случаи делают его ненадежным.
• Регрессионный тест с email, содержащим кавычку, должен подтвердить, что он остается одним связанным значением и не меняет выражение.

Клиент может внедрить операторы MongoDB вместо простых значений полей, ожидаемых приложением.

• Ввод вроде `{"password": {"$ne": null}}` меняет смысл запроса, если произвольный объект попадает в `find`.
• Следует построить новый фильтр из проверенных скалярных полей, например `{ email: validatedEmail }`, а не пересылать объект запроса.
• Ключи с `$` стоит отклонять как дополнительную защиту, но не вместо явной схемы.

Я уберу shell и передам в `subprocess.run` фиксированный исполняемый файл с отдельными аргументами.

• Список вроде `["convert", input_path, output_path]` с `shell=False` оставляет метасимволы внутри одного аргумента имени файла.
• Пути должен генерировать сервер, применяя правила файлов до запуска процесса.
• Конвертер нужно запускать с низкими правами ОС, таймаутом и лимитами ресурсов для сдерживания сбоев парсера.

Приложение считает пользовательский ввод исходником Jinja-шаблона, поэтому опасные выражения шаблона могут раскрыть данные или выполниться.

• Шаблон нужно оставить фиксированным в коде и передавать пользовательское значение как данные, например `render_template("message.html", message=value)`.
• Автоэкранирование Jinja для HTML нужно оставить включенным, но оно не защищает от server-side template injection.
• Тест со значением в форме выражения должен подтвердить, что оно выводится текстом, а не вычисляется.

Неэкранированный ввод может добавить операторы LDAP-фильтра и изменить набор найденных записей каталога.

• Конкатенация имени в `(&(uid=` плюс ввод плюс `)(active=true))` позволяет символам `*`, `(` и `)` влиять на синтаксис.
• Нужно применять API LDAP-библиотеки для экранирования значения фильтра или построения фильтра, а не общий replace обратных слешей.
• Учетную запись каталога следует оставить только для чтения и ограничить нужным поддеревом, чтобы снизить последствия ошибочного запроса.

Соединенный путь все еще может выйти из каталога отчетов, особенно если `name` абсолютный или содержит переходы к родителю.

• Лучше принимать ID отчета и получать серверное имя файла, а не открывать клиентам имена файловой системы.
• Если имена необходимы, оба пути нужно разрешить через `pathlib.Path.resolve` и потребовать, чтобы цель была относительной к разрешенному корню отчетов.
• Следует проверить обработку symlink и по возможности открывать проверенную цель без перехода по ссылкам, затем протестировать абсолютные и закодированные родительские пути.

До записи он должен убедиться, что каждая запись архива разрешается внутри выбранного каталога распаковки.

• Абсолютные имена и выход к родителю нужно отклонять, затем сравнивать каждую нормализованную цель с нормализованным корнем.
• Созданные архивом symlink опасны, потому что следующая запись может пройти через них за пределы каталога.
• Нужны лимиты числа записей и общего распакованного размера, чтобы правильная проверка пути не оставила decompression DoS.

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

• Нужно задать лимиты запроса и распакованного размера, проверить сигнатуру поддерживаемым парсером и отклонять поврежденные или зашифрованные файлы, которые функция не поддерживает.
• Файл следует хранить под сгенерированным именем в приватном карантине, а не в веб-доступном или исполняемом каталоге.
• Парсинг нужно запускать в изолированном worker с низкими правами, лимитами времени и памяти, а результат выдавать только после авторизации.

Нативная Java-десериализация может создать выбранный атакующим граф объектов, методы которого запускают опасную gadget-цепочку.

• Подходящая gadget-цепочка в classpath может превратить `readObject` в выполнение кода до валидации приложения.
• Лучше использовать простой формат вроде JSON, отображать его в узкий data class и проверять поля по схеме.
• Если legacy-сериализацию пока нельзя убрать, нужен строгий allowlist `ObjectInputFilter` и изоляция операции.

В современном PyYAML `yaml.load` принимает явно указанный `Loader`, и именно выбранный загрузчик определяет, какие YAML-теги и Python-типы можно создавать; `yaml.safe_load` использует `SafeLoader`.

• Для недоверенного YAML используйте `yaml.safe_load` или `yaml.load(..., Loader=yaml.SafeLoader)`, затем проверьте полученные данные по ожидаемой схеме.
• Не используйте `yaml.unsafe_load` или `UnsafeLoader` для недоверенных данных: они допускают создание Python-объектов, которое может привести к опасному поведению.
• Нельзя одинаково оценивать все вызовы `yaml.load`: проверяйте указанный загрузчик и пользовательские конструкторы, а также ограничивайте размер входных данных.