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

• Ильдар рассказывает о своей работе в Яндексе, связанной с безопасностью сервисов и продуктов.  

• Обсуждается разница между работой пинтестера и специалиста по безопасности внутри компании.  

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

• Специалисты по безопасности внутри компании должны быть уверены в своих рекомендациях.  

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

• Безопасность должна быть вторичной по отношению к бизнес-задачам.  

• Веб-сервисы делятся на серверные и клиентские части.  

• Серверные уязвимости более опасны и могут компрометировать данные без участия пользователя.  

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

• Веб-сервис состоит из фронтенда, бэкенда и базы данных.  

• Фронтенд агрегирует запросы и взаимодействует с бэкендом через протоколы.  

• Сервисы могут быть запущены в разных дата-центрах и взаимодействовать друг с другом.  

• Уязвимости делятся на логические, эксплуатационные и ошибки реализации.  

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

• Примеры логических уязвимостей: IDOR, insecure direct object reference.  

• Уязвимости часто возникают из-за сложности реализации функциональности.  

• Примеры: парсинг ASN.1 и изображений, которые могут содержать уязвимости из-за сложности форматов.  

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

• Кодовая база требует больше размышлений, что увеличивает человеческий фактор.  

• Плохо продуманная архитектура, особенно когда маленький сервис становится большим.  

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

• Ошибки реализации систематизируемы и предотвратимы.  

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

• Ошибки реализации делятся на инъекции, race conditions, раскрытие информации и директивы.  

• Инъекции облегчают эксплуатацию других уязвимостей.  

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

• Простые инъекции, такие как SQL-инъекции, будут рассмотрены.  

• Обсуждение уязвимостей, связанных с инъекциями в SQL-запросы.  

• Инъекции позволяют внедрять команды в выполнение команд на сервере.  

• Небезопасная десерализация и внешние сущности.  

• CRF-инъекции возникают из-за неправильной обработки концов строк.  

• Пример уязвимого кода на Python.  

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

• Использование prepared statements для предотвращения SQL-инъекций.  

• Проблемы с пользовательским вводом в запросах.  

• Прицепменты как рекомендуемый способ борьбы с инъекциями.  

• Разработчик использовал небезопасные символы для кодирования.  

• Уязвимость в том, что код был выполнен из пользовательского запроса.  

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

• Десерализация позволяет выполнять код в системе.  

• Примеры уязвимого кода на Python и Ruby.  

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

• Иногда нужно передать стерилизованные объекты клиенту и получить их обратно.  

• Для этого используется криптографическая функция, например, HMAC, для проверки целостности.  

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

• Разные парсеры могут по-разному интерпретировать JSON, что может привести к уязвимостям.  

• Рекомендуется использовать одни и те же парсеры для унификации.  

• Пример: уязвимость в npm из-за разных парсеров.  

• XML имеет множество расширений, которые могут быть уязвимы.  

• Внешние сущности могут быть использованы для подключения файлов или ответов на запросы.  

• Отключение парсинга внешних сущностей может помочь избежать уязвимостей.  

• RFC 2616 запрещает модифицирующие действия на GET-запросы.  

• В реальной жизни разработчики могут создавать обработчики, нарушающие этот запрет.  

• XML сложен и может содержать уязвимости, поэтому его использование следует минимизировать.  

• JSON используется в разных языках программирования и имеет универсальные библиотеки.  

• JSON обеспечивает более безопасный способ сериализации и десериализации объектов.  

• XML более универсален, но менее безопасен.  

• URL-инъекции могут привести к попаданию пользовательского ввода в ответ сервера.  

• Это может привести к уязвимостям на стороне клиента и сервера.  

• Важно учитывать управляющие последовательности в URL для предотвращения уязвимостей.  

• Параметры запросов могут быть уязвимы для атак.  

• Атакующий может изменить данные, передаваемые на бэкенд.  

• Важно правильно кодировать и декодировать параметры для предотвращения уязвимостей.  

• Path traversal vulnerabilities позволяют атакующему получить содержимое файлов.  

• Атакующий может передать путь с точками, чтобы выйти на предыдущую директорию.  

• Для борьбы с этим нужно правильно обрабатывать пути и избегать небезопасных методов.  

• Не рекомендуется использовать файловую систему для хранения данных.  

• Используйте общие сторожи для данных, чтобы избежать нагрузки на систему.  

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

• Пример из 80-х годов: аппарат для лучевой терапии, где магнитная система управлялась оператором.  

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

• Гонки в веб-приложениях могут быть опасными уязвимостями.  

• Финансовые приложения часто уязвимы из-за гонок.  

• Пример: промокод, который можно активировать дважды из-за отсутствия транзакций.  

• Решение: использовать транзакции для безопасности.  

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

• Пример: Яндекс удаляет аутентификационную часть куки при логировании.  

• Важно убирать ненужные данные из ответов сервера, чтобы усложнить их использование.  

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

• Важно правильно хранить ключи шифрования.  

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

• Процесс безопасности включает секьюрити-ревью и автоматический поиск уязвимостей.  

• Важно находить и исправлять проблемы на ранних этапах разработки.  

• Рекомендуется использовать безопасные компоненты и библиотеки для переиспользования.  

• Описываются решения для проблем на вики.  

• Используется сканер уязвимостей, ранее был DoubleVerify, но он перестал развиваться.  

• Создан сервис для запуска сканирования и отображения результатов в понятном виде.  

• Тестировщики могут запускать сканирование и настраивать его автоматически.  

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

• Аналитика помогает отслеживать найденные уязвимости и их исправления.  

• Современные сканеры не могут полностью покрыть веб-приложения.  

• Используется Burp Suite для сканирования, но покрытие все еще ограничено.  

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

• Сервисы могут не иметь аутентификации, что популярно в небольших компаниях.  

• В Яндексе используется черный ящик для аутентификации и проверки данных.  

• Черный ящик позволяет контролировать доступ к данным пользователей.  

• Атакующий может заставить приложение перейти на вредоносный сервер.  

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

• Для защиты используются контроль схем, доменных имен и редиректов.  

• Важно тщательно валидировать URL и контент, который возвращается.  

• Можно использовать preflight запросы для проверки ресурсов.  

• Внутренний сервис должен ходить наружу, но не наоборот.  

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

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

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

• Прокси может быть распределенной системой с мониторингом и логами.  

• Вайт-листы и блэк-листы при парсинге сложны и неэффективны.  

• Прокси за пределами доверенной инфраструктуры снижает риски.  

• Атакующие могут использовать DNS для направления запросов на внутренние адреса.  

• Прифлайт позволяет возвращать разные ответы на один и тот же запрос.  

• Прокси и аутентификация важны для защиты от атак.  

• В современных сетях сложно контролировать все IP-адреса.  

• Аутентификация и авторизация должны быть везде.  

• Это защищает от атак на бэкенды и предотвращает CSRF.  

• Атаки на пользователей направлены на обход Same Origin Policy.  

• Same Origin Policy предотвращает взаимодействие между разными доменами.  

• Куки ставятся на домен и не могут быть использованы для взаимодействия между доменами.  

• Флаги безопасности, такие как Secure и HttpOnly, ограничивают использование кук.  

• Внедрение этих флагов требует изменений в коде и сервисах.  

• Лучше сразу выставлять все флаги для безопасности.  

• Механизм JSONP позволяет получать данные между доменами.  

• JSONP устарел и не должен использоваться в современных браузерах.  

• Разработчики часто используют JSONP из-за простоты, но это небезопасно.  

• JSONP позволяет передавать данные между доменами.  

• Использование JSONP может привести к уязвимостям.  

• Рекомендуется избегать использования JSONP и использовать другие методы.  

• Кросс-домен ресурс шаринг позволяет обмениваться данными между доменами.  

• Важно проверять заголовки Access-Control-Allow-Origin.  

• Неправильная реализация может привести к уязвимостям.  

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

• Важно анализировать регулярные выражения для выявления уязвимостей.  

• Использование инструментов для анализа регулярных выражений помогает выявить ошибки.  

• Использование iframe позволяет обойти ограничения на выполнение скриптов.  

• Важно проверять заголовки Access-Control-Allow-Origin при использовании iframe.  

• Неправильное использование iframe может привести к уязвимостям.  

• Вебсокеты позволяют создавать долгоживущие соединения.  

• Важно проверять заголовки Origin при использовании вебсокетов.  

• Неправильная проверка может привести к уязвимостям.  

• Кросс-сайт форжери позволяет выполнять действия на другом домене.  

• Единственный работающий способ защиты — использование CSRF-токенов.  

• Проверка соответствия значений в куках и POST-запросах помогает защититься.  

• DOM позволяет выполнять код в контексте уязвимого домена.  

• Атакующий может использовать DOM для выполнения кода на уязвимом домене.  

• Важно проверять, что код выполняется в контексте правильного домена.  

• Некоторые разработчики не проверяют валидность JSON.  

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

• Важно следить за валидностью JSON и проверять, с какого домена он отправлен.  

• Пользовательские данные должны быть санитайзированы.  

• Методы обработки зависят от контекста: JavaScript, JSON.  

• Разделение доменов на куковые и безкуковые для безопасности.  

• Максимальное внимание уделяется доменам с куками.  

• Белый список доменов для безопасного REST-шаринга.  

• Контент секьюрити полиси усложняет эксплуатацию уязвимостей.  

• Автоматизация анализа кода и сканирования.  

• Использование общих безопасных компонентов.  

• Обучение и коммуникация для предотвращения авралов.  

• Не использовать активные сканеры, такие как Kaspersky.  

• Использовать Burp Suite для поиска уязвимостей.  

• Заводить тикеты в очереди веб для найденных уязвимостей.  

• Описывать уязвимости понятным языком.  

• Приводить примеры эксплуатации и шаги для воспроизведения.  

• Рекомендовать способы устранения уязвимостей.