Топ-10 вопросов на Безопасника / Собеседование с разбором ответов и материалами

YOUTUBE · 30.11.2025 04:53

Ключевые темы и таймкоды

Интервью на позицию сеньор а секьюрити

0:00

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

Вопросы и ответы

1:45

Вопросы касаются инструментов, используемых в области безопасности, таких как Джейсон Веб Токин, МЛС и ТЛС.
Марина также обсуждает различные атаки на эти инструменты и их защиту.

Защита от ссор и куки

12:48

Марина обсуждает различные способы защиты от ссор и куки, включая использование Джейсон Веб Токин, кастомных хедеров и цессоров в токинг.
Она также упоминает о том, как настроить сайт куки, чтобы предотвратить доступ к данным извне.

Классификация уязвимостей

15:25

Обсуждаются различные классификации уязвимостей, включая топ-10, которые меняются со временем.
Упоминается классификация уязвимостей по источнику, например, уязвимости в источнике кода или в источнике данных.

Конфликт в ветке

20:01

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

Пуш и комит

22:13

Объясняется разница между пушем и комитом: пуш синхронизирует текущую ветку с удаленной, а комит добавляет новое изменение в историю.

Докер и обход уязвимостей

23:58

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

Обсуждение уязвимостей в веб-приложениях

29:44

В видео обсуждается, как защититься от уязвимостей в веб-приложениях, таких как инъекции и сторты.
Упоминается, что использование специальных конструкторов запросов может быть более эффективным, чем написание собственных кастомных фильтров.

Примеры уязвимостей и их анализ

31:54

В видео анализируются примеры уязвимостей в веб-приложениях, включая использование конкатенации строк и отсутствие контроля над параметрами.
Обсуждаются потенциальные инъекции и сторты, а также их возможные источники.

Рекомендации по защите от уязвимостей

37:11

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

Безопасность обработки файлов

43:21

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

Определение формата файла

45:22

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

Обработка файлов с разными форматами

47:01

Можно попробовать забанить файл, но это не всегда эффективно.
Использование редактора для обработки таких файлов может быть сложным и рискованным.

Системные компоненты

48:13

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

Уязвимости в системе

50:30

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

Динамические сервисы и переполнение памяти

52:24

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

Межсервисная аутентификация

54:09

Межсервисная аутентификация может быть эффективным способом защиты от атак.
Если в системе появляется уязвимость, важно быстро реагировать и предпринимать меры.

Инциденты и действия в случае их возникновения

56:02

В случае инцидента, важно оценить его влияние и действовать в соответствии с этим.
Если инцидент ожидаем, можно действовать по заранее определенному плану.
Если инцидент не ожидаем, важно собрать информацию и действовать в соответствии с ситуацией.

Приоритизация и порядок действий

1:00:58

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

Влияние на бизнес

1:03:50

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

Обсуждение безопасности и рисков

1:05:50

В видео обсуждается, как убедить представителей бизнеса и разработчиков обратить внимание на безопасность, а не на доработку фич.
Приводится пример, когда один запрос может сжечь деньги у другого человека, и это будет не самое сложное убеждение.

Анализ инцидента и его последствия

1:10:14

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

Мониторинг и оценка инцидента

1:12:42

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

Заключение

1:14:40

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