001. Безопасность веб-приложений - Эльдар Заитов

YOUTUBE · 16.11.2025 04:47

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

Введение

0:00
  • Ильдар рассказывает о своей работе в Яндексе по безопасности сервисов и инфраструктуры.
  • Обсуждаются различия между работой пинтестера и внутреннего специалиста по безопасности.

Роль пинтестера и внутреннего специалиста

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

Ответственность и диалог

1:52
  • Внутренний специалист должен быть уверен в своих рекомендациях, чтобы не испортить отношения с сотрудниками.
  • Важно обсуждать и находить компромиссы с разработчиками.
  • Необходимо помнить о долговременном сотрудничестве.

Диалог с разработчиками

3:07
  • Безопасник должен учитывать мнение разработчиков и находить компромиссы.
  • Разработчики могут предлагать полезные советы, которые могут улучшить безопасность.
  • Безопасность должна быть сбалансирована с бизнес-задачами.

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

5:07
  • Уязвимости веб-сервисов делятся на серверные и клиентские.
  • Серверные уязвимости более опасны и не требуют взаимодействия пользователя.
  • Клиентские уязвимости требуют действий пользователя и плохо масштабируются.

Структура веб-сервиса

6:22
  • Современный веб-сервис состоит из фронтенда, бэкенда и базы данных.
  • Фронтенд агрегирует запросы и взаимодействует с бэкендами через протоколы.
  • База данных взаимодействует с бэкендами через нативные протоколы.

Логические уязвимости

8:33
  • Логические уязвимости включают отсутствие разграничения доступа и избыточную функциональность.
  • Пример логической уязвимости: возможность получения сообщений по недостаточно случайному идентификатору.
  • Такие уязвимости сложно найти, но они удобны для атак.

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

11:18
  • Уязвимости часто возникают из-за сложности реализации функциональности.
  • Примеры сложных форматов: ASN.1, изображения.
  • Некорректная реализация сложной функциональности увеличивает риск уязвимостей.

Причины уязвимостей

12:48
  • Плохо продуманная архитектура: сервис, изначально задуманный для ограниченного круга пользователей, становится масштабируемым, что приводит к проблемам с идентификацией и авторизацией.
  • Человеческий фактор: ошибки из-за усталости, семейных проблем или других личных обстоятельств.

Ошибки реализации

13:48
  • Ошибки реализации — наиболее частая и систематизируемая причина уязвимостей.
  • Виды ошибок реализации: инъекции, race conditions, раскрытие информации, директивы.
  • Раскрытие информации облегчает эксплуатацию других уязвимостей.

Инъекции

15:03
  • Обсуждение инъекций как одного из видов ошибок реализации.
  • Упоминание о скель-инъекциях и необходимости заполнения анкеты.

Введение в инъекции

15:33
  • Обсуждение уязвимостей, связанных с инъекциями в SQL-запросы.
  • Уязвимости связаны с особенностями языка запросов и работы с базами данных.
  • Примеры уязвимостей: небезопасная десерализация и внешние сущности.

CSRF-инъекции

16:29
  • Объяснение, почему CSRF-инъекции выделены в отдельный класс.
  • Неправильная обработка концов строк библиотеками и программами как причина уязвимостей.

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

18:21
  • Использование фонемовской архитектуры, где код и данные находятся в одном месте.
  • Пример уязвимости: конкатенация пользовательского ввода с модификатором.

Борьба с инъекциями

19:21
  • Рекомендация использовать prepared statements для защиты от SQL-инъекций.
  • Важность понимания работы REM для предотвращения уязвимостей.
  • Критика использования скейпинга и санитайзинга как неэффективных методов.

Пример уязвимости в Яндексе

21:21
  • Описание реальной уязвимости в сервисе Яндекса 2012 года.
  • Ошибка разработчика: попытка закодировать управляющие символы без учёта переноса строки.

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

23:14
  • Разбиение сервисов на микросервисы для повышения безопасности.
  • Передача пользовательского ввода в виде массива вместо строки.
  • Изоляция кода в контейнерах для предотвращения выполнения кода.

Десерализация объектов

25:10
  • Проблема десерализации объектов в языках программирования.
  • Примеры методов десерализации: pickle в Python, yaml в Ruby, JSON в Java.
  • Пример уязвимого кода на Python с использованием pickle.

Рекомендации по использованию безопасных форматов

28:10
  • Избегание использования стандартных сериализаторов, если ввод может быть от пользователя.
  • Предпочтение JSON для сериализации объектов из-за его безопасности и простоты реализации.
  • Рекомендации по выбору JSON для сериализации Java-классов.

Контроль целостности данных

29:10
  • Для передачи стерилизованных объектов клиенту используется контроль целостности с помощью криптографической функции, например, HMAC с секретным ключом.
  • При получении объекта проверяется его целостность, и если объект не изменился, он десериализуется.
  • Контроль целостности следует использовать только в крайнем случае, так как он может быть реализован некорректно.

Проблемы с парсерами JSON

31:10
  • Разные парсеры JSON могут по-разному интерпретировать один и тот же JSON-файл, что может привести к уязвимостям.
  • Рекомендуется использовать унифицированные парсеры, например, из библиотеки Jackson.

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

32:10
  • Внешние сущности в XML могут быть использованы для чтения файлов из файловой системы или ответов на запросы.
  • Отключение парсинга внешних сущностей не всегда решает проблему, так как остаётся парсинг DTD-схем.

Рекомендации по использованию XML

34:07
  • XML сложен и расширяем, что увеличивает вероятность появления уязвимостей.
  • При использовании XML рекомендуется отключать ненужные функции, такие как парсинг DTD-схем и внешние сущности.
  • JSON предпочтительнее XML для сериализации данных.

CSRF-инъекции

38:07
  • CSRF-инъекция позволяет пользовательскому вводу попадать в ответ сервера через управляющие последовательности в HTTP-запросах.
  • Примеры атак: изменение заголовков, добавление кук, модификация данных.
  • Важно учитывать различия в интерпретации управляющих последовательностей между фронтендом и бэкендом.

Амперсэнд-инъекции

40:50
  • Амперсэнд разделяет параметры запроса, что может позволить атакующим изменять данные, передаваемые на бэкенд.
  • Пример атаки: изменение логина пользователя через параметры запроса.
  • Необходимо обратно кодировать пользовательский ввод после декодирования.

Пастроверсалы и CSRF

41:48
  • Пастроверсалы позволяют получать содержимое файлов от пользователя через имя файла.
  • Атакующий может передать путь с точками и слэшами для чтения содержимого файлов.
  • Для борьбы с CSRF-инъекциями в пастроверсалах необходимо учитывать вложенность файлов и использовать безопасные методы передачи данных.

Избегание использования файловой системы

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

Пример уязвимости «гонка»

44:48
  • В аппарате для лучевой терапии «Теракт 25» из-за гонки параметров люди получали избыточную дозу облучения.
  • Гонки могут привести к значительным финансовым потерям в финансовых приложениях.
  • Пример уязвимости: активация промокода дважды из-за независимой проверки валидности.

Борьба с гонками

46:48
  • Используйте транзакции при работе с базами данных.
  • Будьте осторожны при активации промокодов и работе с финансами.

Раскрытие информации и логирование

47:48
  • Логирование куки пользователя может позволить получить доступ к аккаунтам других людей.
  • В Яндексе удаляют часть сессионной куки при логировании для предотвращения подделки.
  • Возвращаемые заголовки запроса могут позволить прочитать куки через CORS.

Криптография и её ограничения

50:45
  • Криптография сама по себе не обеспечивает безопасность, важно правильно хранить ключи шифрования.
  • Хранение ключей рядом с шифрованными данными делает шифрование бессмысленным.

Процесс security review

51:45
  • Security review помогает избежать багов в продакшене и выявить типовые проблемы.
  • Ручной процесс позволяет найти проблемы в коде и библиотеках.

Автоматизация поиска уязвимостей

53:45
  • Автоматические сканеры должны находить уязвимости на ранних стадиях разработки.
  • В облаке есть возможность активировать регулярное сканирование сервисов.
  • Рекомендуется использовать безопасные компоненты и библиотеки для переиспользования.

Рекомендации по безопасности

54:45
  • Создавайте наборы безопасных компонентов и библиотек для решения основных проблем безопасности.
  • Пишите текстовые гайды и рекомендации на основе результатов security audits.

Решение проблем с уязвимостями

55:45
  • Описываются решения проблем на Вики для разработчиков.
  • Используется сканер уязвимостей, ранее применялся Double-U Triaf на Python, но он перестал развиваться.
  • Создан сервис для автоматического запуска сканирования и отображения результатов тестировщикам.

Процесс сканирования и анализа

56:45
  • Тестировщики могут настраивать запуск сканирования вместе с выкладками релизов и автотестами.
  • Сканеры находят уязвимости и отправляют отчёты в парсер, который преобразует их в понятный вид.
  • Результаты сканирования используются для создания тикетов в трекере и аналитики.

Проблемы покрытия сканера

58:41
  • Покрытие современного сканера для веб-приложений ограничено из-за вызовов из JavaScript и вёрстки.
  • Замена сканера на Burp Suite для улучшения покрытия.
  • Запросы, отправленные тестировщиками, используются для увеличения покрытия сканера.

Архитектурные ошибки и аутентификация

1:00:41
  • В некоторых компаниях сервисы используют общую базу данных для аутентификации.
  • В Яндексе применяется отдельный веб-сервис «чёрный ящик» для аутентификации.
  • Права доступа к данным пользователя варьируются в зависимости от приложения.

Преимущества единой точки входа

1:03:41
  • Единая точка входа позволяет реализовывать ограничения и антифрод в одной системе.
  • Пример единой точки входа — Яндекс Паспорт.
  • Двухфакторная идентификация реализуется в одном сервисе, что упрощает управление.

Уязвимости CSRF

1:05:37
  • CSRF-атаки позволяют атакующим контролировать запросы и перенаправлять их на внутренние сервисы.
  • Возможные способы защиты: контроль схем контроля, проверка доменных имён, запрет редиректов.
  • Важность тщательной валидации URL и контента, возвращаемого сервером.

Дополнительные меры защиты

1:08:37
  • Использование preflight запросов для проверки содержимого ресурсов перед выполнением GET-запросов.
  • Подход к защите с двух сторон: со стороны URL и контента.
  • Пример внутреннего сервиса, который должен взаимодействовать с внешними ресурсами, — сервис веб-мастера.

Изоляция и прокси

1:09:37
  • Правильное решение: прокси за пределами доверенной инфраструктуры.
  • Запросы от прокси к внутреннему приложению идентичны запросам от атакующего.
  • Необходимо изолировать прокси, чтобы предотвратить доступ к его внутренним компонентам.

Сложности с блэк-листами

1:10:37
  • Блэк-листы неэффективны из-за множества способов записи локалхоста.
  • Разные парсеры URL интерпретируют входные параметры по-разному.
  • Простое решение: вынести прокси за пределы доверенной инфраструктуры.

Риски редиректов и DNS

1:11:37
  • Редиректы нужно запрещать, контент — валидировать.
  • Атакующий может использовать DNS для направления запросов внутрь инфраструктуры.
  • Проверка резолвов и прифлайтов сложна и может привести к гонкам.

Аутентификация и авторизация

1:13:36
  • В больших сетях и облаках сложно определить доверенные и недоверенные IP-адреса.
  • Каждый компонент должен аутентифицироваться и авторизовываться.
  • Аутентификация защищает от CSRF-атак.

Same Origin Policy

1:15:34
  • Same Origin Policy — ключевой механизм безопасности в браузерах.
  • Уязвимости, обходящие Same Origin Policy, редки и быстро исправляются.
  • Пример: домен «a.yandex.ru» имеет один и тот же Origin, но разные порты.

Куки и их флаги безопасности

1:17:34
  • Куки ставятся на домен и отправляются только при запросах к этому домену.
  • Флаги безопасности куки: Secure, HttpOnly.
  • Внедрение флагов безопасности требует значительных усилий и времени.

Джейсон Пи и его устаревание

1:21:34
  • Джейсон Пи — устаревший механизм обмена данными между доменами.
  • Разработчики продолжают использовать Джейсон Пи, несмотря на отсутствие необходимости.
  • В 2018 году нет браузеров, которые не поддерживают другие механизмы обмена данными.

Уязвимость JSONP

1:22:30
  • JSONP позволяет передавать данные через колбек с контролируемым пользовательским вводом.
  • При подключении скрипта на другом домене данные могут быть использованы атакующей стороной.
  • Использование JSONP считается уязвимостью, рекомендуется избегать его применения.

Кросс-доменный ресурс-шаринг

1:23:30
  • Механизм кросс-доменного ресурс-шаринга позволяет обмениваться ресурсами между доменами.
  • Веб-сервер возвращает заголовок Access-Control-Allow-Origin, определяющий, какие домены могут получать данные.
  • Некорректная реализация может позволить любому домену получать данные, что создаёт уязвимость.

Проблемы с кросс-доменным ресурс-шарингом

1:25:30
  • Разработчики часто не проверяют происхождение запросов, что позволяет атакующему получить данные.
  • Важно валидировать происхождение запросов и разрешать доступ только доверенным доменам.
  • Ошибки в написании регулярных выражений могут привести к уязвимостям.

Обход ограничений через iframe

1:26:30
  • Механизм sandbox в HTML5 позволяет запретить выполнение скриптов в iframe.
  • Атакующий может инициировать запрос из iframe, используя пустой домен, и получить доступ к содержимому ответа сервера.
  • Необходимо проверять происхождение запросов при использовании iframe.

Уязвимости веб-сокетов

1:28:30
  • Веб-сокеты позволяют создавать долгоживущие соединения, но требуют проверки происхождения запросов.
  • Игнорирование проверки происхождения может позволить атакующему читать сообщения пользователя.
  • Разработчики должны самостоятельно реализовывать проверку происхождения в библиотеках для работы с веб-сокетами.

Кросс-сайт форжери

1:30:27
  • Кросс-сайт форжери позволяет заставить пользователя выполнить действие в другом домене.
  • Единственный эффективный способ защиты — использование CSRF-токенов.
  • Проверка реферера не всегда эффективна, так как его можно отключить.

Кросс-сайт скриптинг

1:33:27
  • Кросс-сайт скриптинг позволяет выполнить код в контексте уязвимого домена.
  • Атакующий может передать код через параметры запроса и выполнить его на уязвимом сайте.
  • Даже если куки недоступны, код может получить доступ к контенту сервера и отправить его куда-либо.

Пример уязвимости с Evan Listener

1:35:27
  • Evan Listener получает сообщения от любых доменов без проверки их происхождения.
  • Атакующий может отправить код через iframe и выполнить его на уязвимом сайте.
  • Разработчикам необходимо внимательно проверять происхождение сообщений, получаемых от Evan Listener.

Обработка пользовательских данных

1:36:27
  • Необходимо санитайзить пользовательские данные перед их использованием.
  • Методы обработки данных зависят от контекста: JavaScript или JSON.
  • Разделение доменов на куковые и безкуковые для повышения безопасности.

Безопасность куковых доменов

1:37:27
  • Максимальное внимание уделяется безопасности доменов с куками и пользовательскими сессиями.
  • На куковых доменах не раздаётся пользовательский контент и не выкладываются странные скрипты.
  • Уязвимости на куковых доменах более опасны, чем на безкуковых.

Белый список и Content Security Policy

1:38:23
  • Белый список должен исключать домены с возможными уязвимостями.
  • Content Security Policy усложняет эксплуатацию уязвимостей, но его можно обойти.
  • Подгрузка JavaScript-скриптов только с контролируемых доменов.

Унификация и автоматизация

1:40:23
  • Унификация взаимодействия сервисов и компонентов.
  • Автоматизация анализа кода и сканирования.
  • Использование общих безопасных компонентов.

Обучение и коммуникации

1:41:23
  • Предоставление понятных гайдов для разработчиков.
  • Раннее взаимодействие с командами для предотвращения авралов.
  • Избегание ситуаций, когда команды вынуждены переделывать работу в последний момент.

Домашнее задание

1:42:23
  • Не использовать активные сканеры, например, Kuenetix, чтобы не повредить сервис.
  • Рекомендация использовать Burp Suite.
  • Создавать тикеты в очереди Web для найденных уязвимостей.
  • В тикете должны быть описание уязвимости, пример эксплуатации и рекомендации по устранению.

Завершение

1:45:23
  • Обсуждение уязвимостей и тикетов в среду вечером.
  • Просьба не использовать копипаст из Википедии и не сканировать сервис Kuenetix.