Перенаправления — это механизм, с помощью которого сервер указывает клиенту (например, веб-браузеру) необходимость перейти на другой URL. Они являются стандартной частью протокола HTTP и используются для управления трафиком между веб-сайтами.
Чем опасно открытое перенаправление:
Позволяет проводить фишинговые атаки;
Используется для эксплуатации уязвимостей браузеров и плагинов;
Способствует распространению вредоносного контента и дезинформации.
➡️ В этом видео Денис Данилов, инженер по безопасности приложений Swordfish Security, рассказывает, как защититься от этой уязвимости. Эксперт объясняет, какие подходы использовать на сервере, чтобы исключить риск, а также показывает реальный пример эксплуатации, когда злоумышленник может обмануть пользователя, даже если сайт выглядит безопасным.
В этом видео инженер по безопасности приложений Swordfish Security Оксана Сурвилло рассказала, какие данные можно и нельзя хранить в куки и как защитить их с помощью флагов Secure, HttpOnly, Domain, Path и SameSite.
Куки — это текстовые файлы, хранящиеся на устройствах пользователей. Они содержат небольшие фрагменты данных, например, идентификатор сессии. С их помощью сайты запоминают информацию о пользователях.
Сегодня украденные куки зачастую дают больше возможностей для хакеров, чем логин и пароль. Например, компрометация сессионного куки позволяет злоумышленнику войти в почту, CRM и облачные хранилища без пароля и дополнительной верификации.
🔒 При неправильной настройке куки также могут стать объектом атак злоумышленников, поэтому важно обеспечить их безопасность.
🔼Также в видео эксперт показывает реальный сценарий эксплуатации уязвимости в куки, в результате которой злоумышленник может получить доступ к аккаунту администратора сайта.
Разработали фреймворк для оценки зрелости безопасности ИИ-систем
Сегодня безопасность систем ИИ становится ключевым фактором, определяющим уровень доверия к ним. Для того чтобы организация смогла справиться с этими вызовами, ей необходимо, в первую очередь, определить текущий уровень зрелости и оценить свои слабые и сильные стороны.
Команда Swordfish Security разработала Swordfish: Secure AI Maturity Model (SAIMM) —фреймворк, который помогает компаниям системно выстраивать безопасность ИИ-решений и снижать риски на всех этапах жизненного цикла разработки.
Мы обобщили опыт внедрения ИИ-систем в корпоративной среде, результаты работы с заказчиками из разных отраслей и текущие международные практики безопасности — от OWASP и NIST до MITRE ATLAS. На основе этого сформирована модель зрелости, охватывающая ключевые аспекты безопасности современных ML- и LLM-систем, включая агентные сценарии.
SAIMM построен на основе пяти базовых доменов в области безопасности ИИ и одного специализированного в области агентных систем. Для каждого домена предусмотрена дорожная карта с действиями, артефактами и техническими мерами.
Домены SAIMM:
1️⃣ Управление и риск-менеджмент Политики, роли, риск-аппетит, процедуры аудита, внутренние стандарты и этические принципы.
2️⃣ Защита данных и конфиденциальность Качество, происхождение, доступы, ПДн и локализация. Надежное обучение моделей и эксплуатация ИИ.
3️⃣ Безопасность модели Устойчивость моделей к атакам любого рода и защита артефактов модели от несанкционированного доступа.
4️⃣ Безопасность цепочек поставок Встроенная безопасность в конвейер разработки ПО. Контроль состава и безопасности всех внешних компонентов: модели, библиотеки, датасеты.
5️⃣ Инфраструктура и операционная безопасность Надежное функционирование системы, устойчивость к сбоям, дрейфу и атакам. Организация реагирования на инциденты.
6️⃣ Безопасность агентных систем Контроль автономного поведения агентов для предотвращения нежелательных действий и рисков.
SAIMM выступает практической картой зрелости безопасности ИИ, позволяющей не просто измерять готовность, но и выстраивать стратегию безопасного внедрения и масштабирования искусственного интеллекта в корпоративной среде.
В этом видео инженер по безопасности приложений Swordfish Security Денис Данилов разбирает уязвимость стандарта передачи данных JSON Web Token (JWT).
Суть уязвимости
JWT состоит из трех частей:
Header — заголовок, где указывается алгоритм подписи (например, HS256),
Payload — полезная нагрузка (данные пользователя, роли и т. д.),
Signature — подпись, которая формируется с помощью секретного ключа.
Проблема возникает, если сервер не проверяет, какой алгоритм указан в заголовке. Если там стоит alg: "None", библиотека может интерпретировать это буквально — и не проверять подпись вовсе.
В результате злоумышленник может:
извлечь JWT токен (например, из cookies),
заменить полезную нагрузку (например, указать "role": "admin"),
подставить alg: "None" в заголовке,
отправить подделанный токен на сервер и получить доступ к чужому аккаунту.
Как научиться находить такие уязвимости?
Такой тип ошибки — не уникален для JWT. Это общий паттерн: разработчик полагается на библиотеку, не разбираясь в деталях. В продакшене такие недочёты дорого обходятся — и бизнесу, и карьере инженера.
Swordfish Security мы регулярно сталкиваемся с подобными уязвимостями в реальных проектах. Опыт показывает: даже базовое понимание архитектуры протоколов и моделей угроз помогает разработчикам предотвращать критичные ошибки ещё на этапе проектирования. Этот кейс, кстати, — часть одного из модулей курса по DevSecOps нашей академии, где мы разбираем типовые уязвимости и подходы к их предотвращению.
