Ответ вслух Middle SSRF, файлы и редиректы спрашивают часто обновлено

Кейс: загрузка аватара по URL

Вопрос

Продукт хочет функцию «загрузить аватар по ссылке». Как вы её спроектируете безопасно?

Попробуйте сами

Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.

Показать ответ и разбор

Коротко

Образцовый ответ: «Главный риск SSRF: сервер пойдёт туда, куда скажет пользователь, включая метаданные облака и внутренние админки.

Что должно прозвучать в ответе

  • Риск: SSRF во внутреннюю сеть и метаданные облака

  • Только http и https, разрешение имени и проверка IP, подключение к проверенному IP

  • Без автоматических редиректов, таймауты, лимит размера

  • Отдельный воркер или egress-прокси без доступа во внутреннюю сеть

  • Проверка, что это картинка, перекодирование, хранение под своим именем

  • Ошибки без подробностей, мониторинг подозрительных адресов

Что могут спросить следом

  • Как защититься от DNS rebinding?
  • Почему бы просто не сделать чёрный список внутренних адресов?

Разбор

Образцовый ответ: «Главный риск SSRF: сервер пойдёт туда, куда скажет пользователь, включая метаданные облака и внутренние админки. Делаю так: принимаю только http и https на стандартных портах, сам резолвлю имя, проверяю все IP на приватные, loopback, link-local и зарезервированные диапазоны и подключаюсь именно к проверенному адресу, чтобы DNS rebinding не сработал. Редиректы не выполняю автоматически. Ставлю таймаут, лимит размера, проверяю, что ответ это изображение, и перекодирую его. Скачивание делаю в отдельном воркере, который ходит через egress-прокси без доступа во внутреннюю сеть: даже если в проверке ошибка, внутрь не попасть. Пользователю показываю общую ошибку без деталей».

Ответьте сами, а не прочитайте

В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.