Охват к подписчикам
21,5%
ERR
Реакции к просмотрам
0,42%
125 на 38 постов
Пересылки к просмотрам
0,84%
247
Постов в день
1,6
всего 39
Где отзываются чаще
доля реакций к просмотрам- 7 авг.Кто рано встает... тот уже не спящего в такую рань в отпуске админа застает 🙂 Но заметьте — админа, не забывшего, что 3К+ человек всю неделю терпят тут всякие странные посты ради того, чтобы насладиться пятничными мемами 🤗4,78%
- 14 авг.Что может быть грустнее, чем последняя пятница в отпуске? 🥺 Правильно, много чего. Потому что пятница — есть пятница, как ни крути. Так что, всем взбодриться (мемы в помощь) и уверенным шагом отправляться в её правильную часть! А, и чудесных всем выходных ещё 🙈4,25%
- 23 июл. 2024 г.🤨 Добавляете закладки в опенсорс-репозитории? Молодой человек, пройдемте. В рамках threat intelligence, помимо исследования «традиционных» вредоносных программ, мы также занимаемся поиском закладок в репозитории Python Package Index с помощью сервиса PT PyAnalysis. Тенденция такова, что не проходит и недели без троянов ☕️. При этом злоумышленники загружают не только полнофункциональные инфостилеры, но и свои маленькие пробы пера. PT PyAnalysis очернил проекты нескольких разработчиков за последние дни, расскажем о самых интересных поделках: 🤔 Скрины 1, 2. Кампания с Android-стилером, содержащим арабские комментарии. Он отправляет файлы через телеграм-бот (как их детектить в сетевом трафике своей инфраструктуры мы писали здесь), токен которого вшит в коде. Пакеты имеют название вида raquest, ebell. 🤔 Скрин 3. Серия клипперов (троянов, ворующих данные из буфера обмена — clipboard), косящих под проверки лицензии. Закрепляются на устройствах под управлением Windows, добавляя запись автозагрузки в реестр. Слушают буфер обмена каждую секунду, в случае изменений отправляют данные в дискорд-канал. Пакеты имеют названия вида testjsonn1, testjson2, gentorqkkh. 🤔 Скрины 4, 5. Стилер, обходящий диски в поисках файлов .env, добывающий ключи SSH из стандартных путей и отправляющий все добро на сервер злоумышленника с помощью утилиты curl. Имеет логику, зависящую от целевой платформы: отдельную — для Windows, отдельную — для Linux и MacOS. Пакет: popeye-pip-v3. Имя разработчика говорит само за себя: shyam_the_hacker. Уведомили Python Package Index, пакеты выпилены 👋 Несмотря на то, что названия этих пакетов выглядят незамысловато и вряд ли вы опечатаетесь, написав raquest вместо requests, такие пакеты могут попасть к вам через транзитивные зависимости. Построение внутреннего защищенного зеркала — сложный, но жизненно важный элемент для обеспечения современной безопасной разработки ❤️ #ti #stealer #pypi #pyanalysis @ptescalator2,77%
- 15 июн.без подписи1,47%
- 2 авг.🔎 Ковыряем Codex Security OpenAI выложили @openai/codex-security — CLI и TypeScript-SDK для поиска, валидации и фикса уязвимостей в коде. Самое время заглянуть внутрь. Проект Сам пакет построен поверх @openai/codex и @openai/codex-sdk. В src/ около 13,7 тыс. строк TypeScript, логика скана вынесена в _bundled_plugin/. Это бандл из 13 скиллов (каждый со своим субагентом), MCP-сервера, 32 Python-скриптов, реф-документов (references/) и JSON-схем (schemas/: coverage, findings, scan-manifest). Как оно работает Сначала threat-model строит модель угроз, затем оркестратор security-scan гоняет файлы через finding-discovery, который ищет кандидатов на уязвимости. Каждый кандидат проходит validation и attack-path-analysis (цепочка source → контроль → sink). В финале идут фиксы, и формирование отчёта. Из 13 скиллов основными остаются именно эти 5, плюс триаж, отчетность и харденинг. Классы уязвимостей Таксономия в проекте задана набором примеров в скиллах, прежде всего в severity-policy и finding-discovery, и сами документы отмечают их как «не исчерпывающие». На практике границы охвата задаёт то, что модель сама распознает как уязвимость, детерминированного списка правил нет. В документах упомянуты семейства: - Инъекции: Command Injection, SQL/NoSQL/LDAP/XPath Injection, SSTI, XXE, XSS, Path Traversal, LFI/AFR/AFW, SSRF. - Контроль доступа: обход авторизации и IDOR, нарушения границ доверия, обход аутентификации и захват аккаунта, CSRF на критичных действиях, повышение привилегий. - Данные: утечка секретов, PII, ключей подписи и весов моделей, URL-импортёры и callback-клиенты. - Выполнение кода и память: повреждения памяти, побеги из песочниц, контейнеров, VM и интерпретаторов, небезопасная десериализация (pickle, yaml, кодеки), опасные загрузки файлов, абьюз плагинов и макросов. - Прочее: криптографические ошибки, уязвимости цепочки поставок, хардкод кред, логические уязвимости с нарушением целостности данных, DoS через исчерпание ресурсов. Нейросимвольность За моделью оставлена вся нечёткая часть работы: рассуждение о достижимости пути, контексте, намерениях разработчика. Формальная же логика сосредоточена в py-скриптах: ранжирование файлов, нормализация кандидатов, валидация контракта скана, генерация report.md и SARIF. Скиллы весьма объёмны и пестрят оговорками вида «do not», «never», «must». По ним, при желании, можно восстановить всю историю боли и страданий разработчиков, занимавшихся отладкой этого проекта 🤗 Поддерживается режим --mode deep, который сводится к многократному независимому запуску discovery (--max-discovery-runs 10, --stop-after-no-new 3) с последующим слиянием кандидатов на проверку. Смысл тут в том, что из-за недетерминизма LLM, для поднятия полноты и покрытия, нужно прогнать поиск несколько раз и взять объединение результатов. Настраивать агрессивность можно руками: --workers, --subagents, --effort .... И да, это недёшево — модуль cost.ts как бы намекает. Глубокий прогон среднего репозитория (~60 KLoC, связка c0wrk и sp4rk) обходится в десятки миллионов токенов. Точность анализа при этом весьма высокая, если включать глубокий режим (проверял на ShopVault — у gpt-5.6 knowledge cut-off августа 2025, вроде, т.ч. пока норм). Окружение и защита Безопасность рантайма базово есть. Модуль trusted-executable чистит PATH, чтобы агент ненароком не запустил лишнего, и защищает от подсунутых в репу бинарников, учитывает симлинки и специфику Windows. Для пакетных задач есть докер-сканы, опциональный AppArmor-профиль. Есть коннекторы к GitHub, Linear и Atlassian, API-ключи для CI в систему не пишутся. Pro/Cons ➕ Построение атакуемых трасс, разумное разделение между LLM и формальным слоем, лаконичная, но эффективная защита. ➖Полнота держится на детерминизме модели и количестве перезапусков, что делает каждый скан непрогнозируемой историей. Количественных бенчмарков нет, правила поверхностны, и полагаются на знания LLM. ⚠ TL;DR: в пайплайне лишним не будет. Если токенов не жалко. #ИИ_безопасность #ИИ_инструменты0,87%
- 21 июн.🧩 Принципы и паттерны безопасной разработки: ISP Часть 3. А у нас на очереди, принцип разделения интерфейсов (Interface Segregation Principle, ISP — пожалуй, один из наиболее простых в SOLID), гласящий: Клиенты не должны зависеть от интерфейсов, которые они не используют. Проще говоря, лучше несколько узкоспециализированных интерфейсов, чем один «толстый», навязывающий потребителю кучу лишнего. С точки зрения безопасности, ISP напрямую перекликается с принципом наименьших привилегий (Least Privilege). «Толстый» интерфейс — это расширенная поверхность атаки: клиент получает доступ к методам, которые ему для работы не нужны. Если один из таких методов оказывается привилегированной операцией, а её защита оказывается слабее ожидаемой, то любой потребитель интерфейса внезапно получает доступ к критичному функционалу. 💡Тривиальный пример: interface IUserService { User getProfile(Long id); void updateProfile(User u); void resetPassword(String email); void deleteUser(Long id); void assignRole(Long id, Role r); List<User> exportAll(); } Потребитель, которому нужно лишь отображать профиль, вынужден зависеть от deleteUser, assignRole и exportAll. Если защита реализована на уровне имплементации, а не интерфейса, то одна ошибка авторизации — и профильный компонент может удалять пользователей. ❗Что делать? Нарушения ISP порождают целый ряд CWE, связанных с чрезмерно широким доступом: • CWE-749: Exposed Dangerous Method or Function • CWE-306: Missing Authentication for Critical Function • CWE-250: Execution with Unnecessary Privileges В примере выше правильнее ввести два интерфейса, соответствующие уровням привилегий принятой в приложении модели доступа: interface IUserProfile { User getProfile(Long id); void updateProfile(User u); } interface IUserAdmin { void deleteUser(Long id); void assignRole(Long id, Role r); List<User> exportAll(); } Компоненту, работающему с профилями, IUserAdmin попросту недоступен, даже при наличии бага в авторизации. Разделение интерфейсов можно (и нужно) также проводить, и по границам доверия: один интерфейс не должен обслуживать функциональность по обе стороны от любой из определенных моделью угроз границ. В плане соблюдения ISP, среди мейнстримовых языков здесь выгодно выделяются два: 💻 Go — не запрещает «толстые» интерфейсы, но поощряет их дробление через удобство композиции и интерфейсы потребителей. Стандартную библиотеку этого языка вполне можно рассматривать, как эталон соблюдения ISP. 👣 Rust — та же композиционная история, но через трейты и необходимость соблюдения «orphan rule». Забавно, что в этих языках есть и явный анти-паттерн, который не запрещен: пустой интерфейс (interface{} в Go / dyn Any в Rust). Это нарушение ISP: клиент зависит от всего и ни от чего одновременно. Они существуют для низкоуровневых нужд, и их использования стоит по-возможности избегать. 🐛 Жизненное CVE-2023-22515 — Atlassian Confluence (Broken Access Control, CVSS 10.0). Confluence использовал фреймворк XWork2 для маршрутизации HTTP-запросов. Через единый веб-интерфейс были доступны как пользовательские действия (просмотр/редактирование страниц), так и привилегированные операции первичной настройки (/setup/setupadministrator.action). В терминах ISP — один «толстый» интерфейс маршрутизации обслуживал и рядовых пользователей, и административный мастер установки. Атакующий отправлял запрос, манипулирующий свойством bootstrapStatusProvider.applicationConfig.setupComplete через механизм привязки параметров XWork2, «сбрасывая» флаг завершённости установки. После этого endpoint создания администратора становился доступен без аутентификации — атакующий создавал собственный админский аккаунт и получал полный контроль. Если бы интерфейс маршрутизации был сегрегирован (setup-эндпоинты физически изолированы от пользовательских, с отдельным middleware авторизации), манипуляция параметрами одного интерфейса не открыла бы доступ к другому. В патче (разбор) эндпоинты, относящиеся к установочным действиям, блокируются после первичной установки, а маршрутизация разделена. ⚠ TL;DR: «Толстый» интерфейс — расширенная поверхность атаки. Если клиент видит метод, то рано или поздно кто-то найдёт способ его вызвать. Стоит разделять интерфейсы, как по привилегиям, так и по границам доверия. #безопасность_кода #гайд0,85%
- 5 авг.🔍 Наиболее интересные уязвимости 🐛 CVE-2026-63221, обнаруженная в CodeIgniter4 в версиях с 4.3.0 по 4.7.3, приводит к SQL Injection. Проблема заключалась в том, что внутренний метод _deleteBatch() при формировании запроса на удаление подставлял связанные значения из условий where() напрямую в запрос, что позволяло внедрить и выполнить произвольный SQL код. В исправлении разработчики вынесли обработку значений в новый метод convertWhereBindsForBatch(), который обрабатывает значения через db->escape() перед их подстановкой в SQL. 🐛 CVE-2026-67346, обнаруженная в Swarms до версии 6.8.1, приводит к Server-Side Request Forgery (SSRF). Проблема заключалась в том, что функция _is_safe_url() проверяла только IP-адрес, указанный непосредственно в URL, но не анализировала доменные имена, что позволяло злоумышленнику заставлять сервер обращаться к произвольным хостам. В исправлении разработчики добавили проверку IP-адресов, полученных в результате DNS-разрешения имени хоста, и начали отклонять URL, которые указывают на приватные диапазоны адресов. 🐛 CVE-2026-67438, обнаруженная в OliveTin в версиях с 3000.2.0 по 3000.17.x, приводит к OS Command Injection. Проблема заключалась в том, что функция checkShellArgumentSafety() не считала пользовательские типы аргументов с префиксом regex: небезопасными для Shell-режима, что позволяло злоумышленниу передать значение, удовлетворяющее регулярному выражению, и выполнить произвольные команды операционной системы. В исправлении разработчики начали рассматривать все типы аргументов с префиксом regex: как небезопасные для Shell-режима и запретили их использование при формировании shell-команд. 🐛 CVE-2026-54705, обнаруженная в MathLive до версии 0.110.0, приводит к Cross-Site Scripting (XSS). Проблема заключалась в том, что команды \text{} и \mbox{} сохраняли специальные HTML-символы без экранирования и затем напрямую включали их в сформированную HTML- и MathML-разметку, что позволяло злоумышленнику внедрить вредоносный HTML- или JavaScript-код, который выполнялся при отображении математического выражения. В исправлении разработчики добавили экранирование специальных HTML-символов при формировании HTML- и MathML-представлений текстовых элементов. 🐛 CVE-2026-54662, обнаруженная в swagger-typescript-api до версии 13.12.2, приводит к Remote Code Execution (RCE). Проблема заключалась в том, что значение servers[0].url из OpenAPI-спецификации без экранирования вставлялось в поле baseUrl сгенерированного TypeScript-клиента, что позволяло злоумышленнику сформировать специально подготовленную OpenAPI-спецификацию, внедрить произвольный TypeScript-код и добиться его выполнения при импорте сгенерированного модуля. В исправлении разработчики добавили экранирование строковых литералов JavaScript через функцию escapeJsStringLiteral().0,43%
- 12 авг.🔍 Наиболее интересные уязвимости 🐛 CVE-2026-53992, обнаруженная в ProjectSend в версиях r1945 - r2098, приводит к Cross-site Scripting (XSS). Проблема заключалась в прямом использовании параметров запроса ($_GET['start_date'] и $_GET['end_date']) в HTML-атрибутах полей фильтра без экранирования. В исправлении разработчики стали оборачивать оба параметра в htmlspecialchars($_GET[...], ENT_QUOTES, 'UTF-8') непосредственно при их чтении. 🐛 CVE-2026-70609, обнаруженная в Electron версиях до 39.8.7, 40.9.0, 41.2.0 и 42.0.0-beta.1, приводит к Remote Code Execution (RCE). Проблема заключалась в том, что dock_state_, полученный из аргумента mode функции webContents.openDevTools() или сохранённых настроек DevTools, подставлялся напрямую в строку JavaScript-кода для выполнения скрипта в контексте DevTools. В исправлении разработчики добавили функцию IsValidDockState(), сверяющую значение с фиксированным набором {"bottom","left","right","undocked"}. 🐛 CVE-2026-71313, обнаруженная в rclone версий с 1.51.0 по 1.75.0, приводит к Path Traversal. Проблема заключалась в том, что localPath()строила путь к файлу через filepath.Join(f.root, ...). В исправлении разработчики добавили в localPath() проверку filepath.Rel(f.root, localPath) и возврат ошибки errPathEscapes, если результат выходит за пределы root. 🐛 CVE-2026-71319, обнаруженная в Nuxt DevTools до версии 3.3.1, приводит к Remote Code Execution (RCE). Проблема заключалась в том, что RPC-методы updateOptions(), clearOptions() и openInEditor() не требовали токена, аopenInEditor() запускал launch-editor как дочерний процесс с путём, настраиваемым через тот же updateOptions(). В исправлении разработчики добавили обязательный параметр token в эти методы, проверяемый через ensureDevAuthToken() перед выполнением. 🐛 CVE-2026-71434, обнаруженная в Statamic CMS до версий 5.74.3 и 6.24.2, приводит к Unrestricted File Upload. Проблема заключалась в том, чтоFrontendFormRequest::extraRules() применяла правило AllowedFile только к полям assets, не подмешивая правила валидации настроенного AssetContainer, а для полей files ограничение по расширению вообще не задавалось. В исправлении разработчики распространили extraRules() на оба типа полей, подмешав allowed_extensions для files и validationRules() контейнера для assets.0,32%
- 24 мая 2025 г.🔔 Через пару часов стартует встреча PT Application Inspector без купюр! Сегодня, 24 мая, в «Лужниках» на PHDays Fest — уникальная возможность честно и напрямую поговорить с разработчиками PT Application Inspector! 💥 🕡 14:30–16:00, зал «Лавлейс» (нужен билет PRO): Впервые команда PT Application Inspector открыто разберет JSA, недокументированные фичи и ответит на все ваши вопросы — без заготовленных сценариев и продаж! Хотите узнать, как работает продукт, что можно улучшить или чего не хватает? Приходите в зал и задавайте вопросы напрямую. 📌 Регистрация: [ссылка]. Все в зал «Лавлейс» — будет горячо! 🔥 #POSIdev #PHDays #AppSec0,27%
- 6 июн.без подписи0,24%
- 16 апр.401 meetup – call for papers Друзья, пишу поделиться отличной новостью! Анонсирую оффлайн-митап про Identity & Access Management (IAM) в Москве 27 мая. Концепция: свободный вендор-независимый митап для сообщества. Подробности и начало регистрации для участников будут объявлены позднее, а пока приглашаю спикеров заявиться с докладами. Очень жду и приветствую доклады про аутентификацию, управление доступом и смежные области. Это будет классная возможность выступить на релевантную аудиторию. Тайминг 35-40 минут. Запись постараюсь организовать, чтобы материалы были доступны. Принимаем любые идеи, крутые технические или архитектурные доклады всегда в цене. А если вам нужно вдохновение, вот темы, о которых особенно хочется послушать: - Аутентификация и авторизация: MFA, passwordless, адаптивная risk-based аутентификация, Just-in-Time Access, политики и модели контроля доступа - Протоколы и стандарты: интересные, новаторские практики использования OAuth 2.0, OIDC, SAML, применение новых RFC и спецификаций - Безопасность identity: Identity Threat Detection and Response (ITDR), уязвимости, атаки на аутентификацию, контроль доступа и меры защиты от них - Практика и highload: опыт использования “нестандартного” Open Source (Ory, Casdoor, ZITADEL, etc.), адаптация IAM под высокие нагрузки и специфичные НФТ, разработка собственных IAM-решений - Новые вызовы: аутентификация и контроль доступа для AI-агентов и MCP - Enterprise-задачи: B2B IAM, федерации, мультитенантность - Customer IAM (CIAM): UX и безопасность, управление аккаунтами и согласиями, social login - Архитектура: аутентификация и контроль доступа в распределенных системах, service-to-service взаимодействия, SPIFFE - Интеграции: комплексные решения из нескольких компонентов: IdM, IAM, SIEM, API Gateway, etc. ⛔️ Для подачи заявки на доклад заполняйте форму. Прием заявок открыт до 1 мая (но времени не так много, не затягивайте). Со всеми заполнившими форму свяжемся. По вопросам можно писать Андрею Кузнецову. Сомневаетесь, подходит ли ваша тема? Оставляйте заявку – обсудим и подумаем вместе. Мы открыты к специалистам с различным опытом и профилем. Если у вас есть идея доклада, но вы никогда не выступали и переживаете, мы поддержим и поможем подготовиться <3 Напоследок TLDR: 📆 27 мая оффлайн в Москве, площадку согласился предоставить Яндекс 📩 Заявки на доклады присылайте в форму до 1 мая Stay tuned! #announce #iam_general0,21%
- 14 мая 2025 г.📢 Прямой разговор с разработчиками AppSec-решений Positive Technologies Анонсируем первый POSIdev Community Day на PHDays Fest! 24 мая в «Лужниках» сообщество POSIdev устраивает насыщенный день для всех, кто в теме AppSec и безопасной разработки! 🔥 🗓 Программа в зале «Лавлейс» (нужен билет PRO): 🕤 9:30–13:30 — Олимпиада по программированию: креативные задачи от лидеров POSIdev. Покажи, на что способен! [регистрация] 🕡 14:30–16:00 — PT Application Inspector без купюр: открытый диалог с разработчиками без заготовленных сценариев, разбор JSA и фичи, которых нет в мануалах. [регистрация] 🕔 16:30–18:00 — Root of the Hill: хардкорное хакерское соревнование! 🕖 19:00–22:00 — IT-нетворкинг: игры, напитки, закуски и живое общение с экспертами. [регистрация] 🏕 В шатре «Бэббидж» (тоже билет PRO): Воркшопы от экспертов Positive Technologies, Yandex Cloud и Swordfish Security + лекция от спикера из Ирана. Не пропустите, будет мощно! 💻 #POSIdev #PHDays #AppSec0,19%