Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14❤4😁4
Forwarded from Heisenbug — канал конференции
На ближайшем Heisenbug про тестирование безопасности будет один доклад. Но для тех, кому близка тема безопасности, у нас есть еще подкаст SafeCode Live, и его новый выпуск — уже на YouTube. Разбираемся в ролях, связанных с безопасностью, и кого и как искать, если регулятор поставил условие, что «должна быть безопасность».
Будет полезно нанимающим менеджерам и всем, кому интересно развиваться в AppSec.
Гости выпуска обсуждают:
— чем занимаются специалисты по безопасности;
— кто такой security champion и как им стать, если ты — разработчик;
— кто такой AppSec Business Partner;
— какие возможности у найма с рынка: основные проблемы и подводные камни;
— как проводить собеседование;
— что спрашивать у работодателя, если ты ищешь работу;
— как удержать сотрудников после того, как нашли;
— как взращивать компетенции внутри компании.
Гости:
— Светлана Газизова, Head of Audit в Swordfish Security. Знает, как делать хороший AppSec.
— Алексей Антонов, коммерческий директор Вебмониторэкс.
Ведущий: Сергей Деев, эксперт по кибербезопасности в МТС RED.
Подписывайтесь на YouTube-канал и Telegram-канал SafeCode, чтобы не пропустить новые выпуски!
Будет полезно нанимающим менеджерам и всем, кому интересно развиваться в AppSec.
Гости выпуска обсуждают:
— чем занимаются специалисты по безопасности;
— кто такой security champion и как им стать, если ты — разработчик;
— кто такой AppSec Business Partner;
— какие возможности у найма с рынка: основные проблемы и подводные камни;
— как проводить собеседование;
— что спрашивать у работодателя, если ты ищешь работу;
— как удержать сотрудников после того, как нашли;
— как взращивать компетенции внутри компании.
Гости:
— Светлана Газизова, Head of Audit в Swordfish Security. Знает, как делать хороший AppSec.
— Алексей Антонов, коммерческий директор Вебмониторэкс.
Ведущий: Сергей Деев, эксперт по кибербезопасности в МТС RED.
Подписывайтесь на YouTube-канал и Telegram-канал SafeCode, чтобы не пропустить новые выпуски!
🔥6
Всем привет! 👋
(@vkochetkov здесь)
Отбирая статьи для понедельничной рубрики, наткнулся на забавное эссе, посвящённое проверкам входных данных. Должен признаться, я в душе не чаю, кто его автор — признанный ли он эксперт или нет... вроде раньше не слышал🤔 Но пройти мимо и не прокомментировать, не смог.
Дело в том, что сей Pedram, предлагая решать проблему обработки входных данных «зря в корень», похоже, даже близко себе не представляет, где этот корень находится. Рассмотрим на примере первой части статьи. В ней автор рассматривает примеры решений одного из челленджей SecDim, основанного на CVE-2021-43798, и отбраковывает одно за другим, апеллируя к тому, что они не устраняют корень проблемы. Корень же Path Traversal, по убеждению автора, заключается в (я цитирую):
> is the lack of path canonicalization
И здесь он глубоко ошибается. Канонизация, нормализация, валидация, санитизация и прочие «-ации» хороши тогда, когда применяются на уровне модели предметной области, а не на уровне синтаксиса весьма низкоуровневых сущностей, коими являются файловые пути. Причиной уязвимости здесь является протаскивание этих сущностей на уровень предметной области, вместо сокрытия за абстракциями. И грамотным подходом в данном случае было бы не «отдать пользователю файл по запрошенному пути», а «отдать пользователю запрошенный по буквенно-числовому идентификатору объект», а уже связь между этими идентификаторами и физическими файлами, устанавливать без участия пользователя, где-то на стыке слоя представления и слоя бизнес-логики.
Возможно для кого-то это и окажется откровением, но уязвимости в том числе к инъекциям, зачастую, и в первую очередь, являются проблемами дизайна предметной области приложения, и только потом — синтаксическими багами про недостаточную предварительную обработку.
Btw, предложенное автором решение никак не защищает от, например, обращения к альтернативным потокам NTFS, если приложение окажется (не дай бог, конечно) развёрнутым под виндой. Как и от внедрения нуль-байта, управляющих символов и прочих DoS через жестко-заданные в ОС файловые имена. Зависит от окружения, конечно, но кто ж так в корень-то смотрит?🤦♂️
И потом, если уж мы протащили файловые пути на уровень бизнес-логики, то реализуя тем самым требование «отдать пользователю существующий файл по запрошенному, жестко-заданному пути». И вот что мешало вспомнить о принципе KISS и сделать как-то так — ума не приложу:
На две трети решённая задача обеспечения безопасности приложения — это грамотный дизайн его архитектуры и модели предметной области.
А не вот это вот всё... 🫠
❗️И да, это тоже #экспериментальная_рубрика. А вы как думали?👇
(@vkochetkov здесь)
Отбирая статьи для понедельничной рубрики, наткнулся на забавное эссе, посвящённое проверкам входных данных. Должен признаться, я в душе не чаю, кто его автор — признанный ли он эксперт или нет... вроде раньше не слышал
Дело в том, что сей Pedram, предлагая решать проблему обработки входных данных «зря в корень», похоже, даже близко себе не представляет, где этот корень находится. Рассмотрим на примере первой части статьи. В ней автор рассматривает примеры решений одного из челленджей SecDim, основанного на CVE-2021-43798, и отбраковывает одно за другим, апеллируя к тому, что они не устраняют корень проблемы. Корень же Path Traversal, по убеждению автора, заключается в (я цитирую):
> is the lack of path canonicalization
И здесь он глубоко ошибается. Канонизация, нормализация, валидация, санитизация и прочие «-ации» хороши тогда, когда применяются на уровне модели предметной области, а не на уровне синтаксиса весьма низкоуровневых сущностей, коими являются файловые пути. Причиной уязвимости здесь является протаскивание этих сущностей на уровень предметной области, вместо сокрытия за абстракциями. И грамотным подходом в данном случае было бы не «отдать пользователю файл по запрошенному пути», а «отдать пользователю запрошенный по буквенно-числовому идентификатору объект», а уже связь между этими идентификаторами и физическими файлами, устанавливать без участия пользователя, где-то на стыке слоя представления и слоя бизнес-логики.
Возможно для кого-то это и окажется откровением, но уязвимости в том числе к инъекциям, зачастую, и в первую очередь, являются проблемами дизайна предметной области приложения, и только потом — синтаксическими багами про недостаточную предварительную обработку.
Btw, предложенное автором решение никак не защищает от, например, обращения к альтернативным потокам NTFS, если приложение окажется (не дай бог, конечно) развёрнутым под виндой. Как и от внедрения нуль-байта, управляющих символов и прочих DoS через жестко-заданные в ОС файловые имена. Зависит от окружения, конечно, но кто ж так в корень-то смотрит?
И потом, если уж мы протащили файловые пути на уровень бизнес-логики, то реализуя тем самым требование «отдать пользователю существующий файл по запрошенному, жестко-заданному пути». И вот что мешало вспомнить о принципе KISS и сделать как-то так — ума не приложу:
if not str.isidentifier(filename) or filename not in os.listdir("/resources"):
return HttpResponseBadRequest()
(почему не с помощью os.path.exists() — пусть будет домашним заданием)На две трети решённая задача обеспечения безопасности приложения — это грамотный дизайн его архитектуры и модели предметной области.
А не вот это вот всё... 🫠
❗️И да, это тоже #экспериментальная_рубрика. А вы как думали?👇
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍12🍌2❤1
Forwarded from Positive Technologies
Уже завтра, 11 октября в 11:00, Алексей Астахов, руководитель продуктов Application Security, Positive Technologies, примет участие в прямом эфире AM Live, на котором обсудят лучшие средства, инструменты и практики российской безопасной разработки, процессы ее внедрения и поговорят о том, где взять нужных для этого специалистов.
Слушайте, если хотите узнать:
• Что такое опасная и безопасная разработка на конкретных примерах.
• Из чего состоят процессы DevSecOps и как определить, насколько они зрелые у вас в компании.
• С чего начать внедрение безопасной разработки и какие IT-продукты в этом помогут.
• Какие практики и инструменты лучше всего подходят для проверки исходного кода.
• Как подготовить инфраструктуру и найти сотрудников.
• Как обеспечить DevSecOps при внешней и open-source-разработке.
• Что про все это думают регуляторы.
• Каковы перспективы безопасной разработки: прогнозы, законодательство, станет ли она must have для всех.
Регистрируйтесь и готовьте ваши вопросы. До встречи в эфире!
@Positive_Technologies
#PositiveЭксперты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12
📰 Кажущийся большим, но на деле — весьма сжатый гайд о том, как найти в аббревиатуре «IoT» ту самую букву «S», означающую «Security».
📰 Очередной метод сокрытия внедряемого в .NET-сборки кода от ресёрчеров CheckPoint.
📰 Языковой ИИ-ассистент для тех, кому слишком скучно работать в консоли с популярными security-тулами.
📰 Неплохой и весьма обширный гайд по атакам на front-end веб-приложений.
📰 Обзор и сравнительный анализ современных инструментов поиска утечек памяти.
📰 Опыт Авито по организации виртуализированной песочницы в macOS.
📰 Локальный TCP/UDP прокси для пентеста приложений с кастомными протоколами.
📰 Описание забавной атаки на клиентов Cloudflare средствами самой Cloudflare.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14❤2🤩1
🐛 CVE-2023-41580, обнаруженная в платформе управления IP-адресами phpipam до версии 1.5.2, позволяет аутентифицированному атакующему получать конфиденциальные данные из хранилища через LDAP инъекцию. Уязвимость заключается в отсутствии санитизации пользовательских данных, попадающих в функцию
$adldap->user()->info, которая формирует LDAP запросы для получения данных о пользователе. В исправлении данные, попадающие в LDAP запрос, проходят через экранирующую функцию ldap_escape с флагом LDAP_ESCAPE_DN.
🐛 CVE-2023-42809 в клиенте Redisson до версии 3.22.0 позволяет исполнять произвольный код при подключении к вредоносному серверу. Уязвимость заключается в попадании пользовательских данных в функцию ObjectInputStream.readObject и их небезопасной десериализации. В патче был добавлен "белый" список классов, который определяет разрешенные объекты при десериализации. Упрощению эксплуатации способствует наличие в составе Redisson библиотеки "Apache Commons Collections 4", для которой существует стандартный ysoserial гаджет "CommonsCollections2".🐛 CVE-2023-43793 в децентрализованной социальной медиа платформе Misskey до версии 2023.9.0 позволяет обходить процесс аутентификации, для эндпойнтов, начинающихся с
/queue. Проблема затрагивала процедуру сравнения пути эндпойнта с закодированным URI, что обеспечивало обход процесса аутентификации. В исправлении URI запроса перед его сравнением декодируется при помощи функции decodeURI.🐛 CVE-2023-44390, выявленной в .NET библиотеке html-санитизации HtmlSanitizer до версии 8.0.723, позволяет обходить процесс санитизации и добавлять вредоносные html-объекты. В библиотеке данные, находящиеся в комментариях или в текстовых полях html документа, обрабатывались без экранирования. Для этих случае в патче была добавлена замена символов
"<" и ">" на их html-мнемоники ("<" и ">"). 🐛 CVE-2023-26153 в библиотеке для работы с геолокацией geokit-rails до версии 2.5.0 позволяет неаутентифицированному атакующему выполнять произвольные команды с помощью эксплуатации небезопасной YAML десериализации. Проблема связана с попаданием значения
"geo_location" куки в уязвимую функцию YAML.load. Для исправления уязвимости функцию YAML.load заменили на безопасную функцию JSON.parse.Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥4🔥2🍌1
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣24❤8