💉SQL-инъекции — одни из самых известных способов атак на веб-приложения.
В карточках разбираем три основных вида SQL-инъекций: внутриполосные, внеполосные и слепые. Показываем, чем они отличаются друг от друга и каким образом злоумышленники получают информацию из базы данных.
А на примере обхода аутентификации демонстрируем, как всего одна строка способна изменить логику SQL-запроса и предоставить доступ к админской учетной записи без проверки пароля.
В карточках разбираем три основных вида SQL-инъекций: внутриполосные, внеполосные и слепые. Показываем, чем они отличаются друг от друга и каким образом злоумышленники получают информацию из базы данных.
А на примере обхода аутентификации демонстрируем, как всего одна строка способна изменить логику SQL-запроса и предоставить доступ к админской учетной записи без проверки пароля.
❤2
CVSS — это открытый стандарт оценки уязвимостей, который помогает понять, насколько серьезной может быть обнаруженная проблема.
Каждой уязвимости присваивается балл по шкале от 0 до 10: чем выше значение, тем потенциально серьезнее последствия📈
Этот стандарт используют разработчики программного обеспечения, специалисты по информационной безопасности, DevOps-команды и облачные провайдеры.
CVSS помогает быстрее расставлять приоритеты и принимать решения о том, какие угрозы требуют внимания в первую очередь.
В карточках рассказываем, кто применяет CVSS на практике и как эта система помогает управлять уязвимостями в современных ИТ-инфраструктурах.
А в следующем материале разберем диапазоны CVSS-оценок и выясним, что они означают для безопасности вашей инфраструктуры 🔜
Каждой уязвимости присваивается балл по шкале от 0 до 10: чем выше значение, тем потенциально серьезнее последствия📈
Этот стандарт используют разработчики программного обеспечения, специалисты по информационной безопасности, DevOps-команды и облачные провайдеры.
CVSS помогает быстрее расставлять приоритеты и принимать решения о том, какие угрозы требуют внимания в первую очередь.
В карточках рассказываем, кто применяет CVSS на практике и как эта система помогает управлять уязвимостями в современных ИТ-инфраструктурах.
А в следующем материале разберем диапазоны CVSS-оценок и выясним, что они означают для безопасности вашей инфраструктуры 🔜
🌚4
CVSS: на какие уязвимости бизнесу стоит обращать внимание в первую очередь
Мы уже разобрались, что такое CVSS и зачем используется этот стандарт. Теперь посмотрим, как интерпретировать полученные оценки и какие действия стоит предпринимать в зависимости от уровня риска.
Как читать шкалу:
🟢 1–3,9 — низкий уровень
Уязвимость существует, но вероятность успешной атаки или потенциальный ущерб невелики. Такие проблемы обычно устраняют в рамках плановых обновлений.
🟡 4–6,9 — средний уровень
Для успешной атаки злоумышленнику часто необходимы дополнительные условия — например, доступ к учетной записи пользователя или открытие вредоносного файла жертвой.
🟠 7–8,9 — высокий уровень
Возможна удаленная эксплуатация, утечка данных или нарушение работы сервисов. Исправление лучше не откладывать. Показательный пример — EternalBlue (CVE-2017-0144). Несмотря на оценку CVSS 8,1, после публикации эксплойта уязвимость использовалась для распространения вируса-вымогателя WannaCry по всему миру.
🔴 9–10 — критический уровень
Максимальный приоритет. Такие уязвимости часто позволяют удаленно выполнять код или получать полный контроль над системой. Самый известный пример — Log4Shell (CVE-2021-44228). Уязвимость получила максимальные 10 баллов CVSS, поскольку позволяла удаленно выполнять код на серверах без авторизации.
Важно отметить, что оценка CVSS показывает серьезность уязвимости, но не учитывает особенности конкретной инфраструктуры. Уязвимость с высоким баллом может не представлять опасности для вашей компании, если затрагивает неиспользуемый компонент. И наоборот — проблема со средним рейтингом может стать критичной при наличии публичного эксплойта или доступа к важным бизнес-системам.
Поэтому одной оценки CVSS недостаточно для определения реального уровня риска. При проведении анализа защищенности специалисты DDoS-Guard используют международные стандарты и методики оценки рисков. Это позволяет определить реальные угрозы для конкретного бизнеса и выполнить требования законодательства РФ в области защиты КИИ, персональных данных и информационной безопасности.
CVSS помогает понять, с чего начать работу с уязвимостями, но окончательные приоритеты всегда определяются особенностями конкретной инфраструктуры.
Мы уже разобрались, что такое CVSS и зачем используется этот стандарт. Теперь посмотрим, как интерпретировать полученные оценки и какие действия стоит предпринимать в зависимости от уровня риска.
Как читать шкалу:
🟢 1–3,9 — низкий уровень
Уязвимость существует, но вероятность успешной атаки или потенциальный ущерб невелики. Такие проблемы обычно устраняют в рамках плановых обновлений.
🟡 4–6,9 — средний уровень
Для успешной атаки злоумышленнику часто необходимы дополнительные условия — например, доступ к учетной записи пользователя или открытие вредоносного файла жертвой.
🟠 7–8,9 — высокий уровень
Возможна удаленная эксплуатация, утечка данных или нарушение работы сервисов. Исправление лучше не откладывать. Показательный пример — EternalBlue (CVE-2017-0144). Несмотря на оценку CVSS 8,1, после публикации эксплойта уязвимость использовалась для распространения вируса-вымогателя WannaCry по всему миру.
🔴 9–10 — критический уровень
Максимальный приоритет. Такие уязвимости часто позволяют удаленно выполнять код или получать полный контроль над системой. Самый известный пример — Log4Shell (CVE-2021-44228). Уязвимость получила максимальные 10 баллов CVSS, поскольку позволяла удаленно выполнять код на серверах без авторизации.
Важно отметить, что оценка CVSS показывает серьезность уязвимости, но не учитывает особенности конкретной инфраструктуры. Уязвимость с высоким баллом может не представлять опасности для вашей компании, если затрагивает неиспользуемый компонент. И наоборот — проблема со средним рейтингом может стать критичной при наличии публичного эксплойта или доступа к важным бизнес-системам.
Поэтому одной оценки CVSS недостаточно для определения реального уровня риска. При проведении анализа защищенности специалисты DDoS-Guard используют международные стандарты и методики оценки рисков. Это позволяет определить реальные угрозы для конкретного бизнеса и выполнить требования законодательства РФ в области защиты КИИ, персональных данных и информационной безопасности.
CVSS помогает понять, с чего начать работу с уязвимостями, но окончательные приоритеты всегда определяются особенностями конкретной инфраструктуры.
❤5✍3
Мы привыкли считать свет символом прогресса. Он сделал города безопаснее, продлил рабочий день и позволил людям жить в привычном ритме независимо от времени суток. Но у этого удобства есть цена.
Всего за полтора столетия человечество практически уничтожило естественную темноту — явление, которое миллионы лет определяло жизнь людей, животных и целых экосистем.
Почему ночное небо исчезает из нашей повседневности, как искусственное освещение влияет на сон, миграцию птиц и поведение насекомых, и действительно ли современная экономика заинтересована в том, чтобы ночь никогда не наступала?
Разбираемся в нашей новой статье на Хабре 👉 https://habr.com/ru/companies/ddosguard/articles/1057518/
А в конце материала покажем, как выглядело бы ночное небо, если бы человеческий глаз мог одновременно увидеть все звезды сразу👀
Всего за полтора столетия человечество практически уничтожило естественную темноту — явление, которое миллионы лет определяло жизнь людей, животных и целых экосистем.
Почему ночное небо исчезает из нашей повседневности, как искусственное освещение влияет на сон, миграцию птиц и поведение насекомых, и действительно ли современная экономика заинтересована в том, чтобы ночь никогда не наступала?
Разбираемся в нашей новой статье на Хабре 👉 https://habr.com/ru/companies/ddosguard/articles/1057518/
А в конце материала покажем, как выглядело бы ночное небо, если бы человеческий глаз мог одновременно увидеть все звезды сразу👀
Хабр
Световое загрязнение: как капитализм уничтожает ритм жизни, работавший миллионы лет
Интернет-соединения не будет, если роутер не включен в розетку, смартфон разрядится, GPS-приемник потеряет сигнал без источника питания — все прорывные изобретения завязаны на свете, настолько глубоко...
👍6
AI-агенты для аудита кода научились запускать вредоносное ПО вместо его поиска🤖
Исследователи из AI Now Institute описали новую атаку Friendly Fire, которая позволяет превратить AI-агентов для анализа безопасности в — напротив — инструмент компрометации системы. Под удар попали автономные режимы Claude Code и OpenAI Codex, когда они используются для проверки стороннего кода без подтверждения каждого действия со стороны пользователя.
Злоумышленнику достаточно разместить специально подготовленный репозиторий или изменить содержимое доступного проекта, добавив безобидный на вид README.md, в котором содержится инструкция запустить якобы проверочный скрипт security.sh. Если разработчик поручает AI-агенту провести аудит проекта, тот самостоятельно читает документацию, считает запуск скрипта частью процесса проверки и выполняет его. В демонстрации исследователей скрипт незаметно запускал скрытый бинарный файл уже на машине пользователя.
Авторы подчеркивают, что проблема носит архитектурный характер и не сводится к конкретной версии Claude Code или Codex. Уязвимым оказывается сам сценарий, в котором агент получает право выполнять команды при анализе недоверенного кода. Исправить ситуацию простым обновлением не получится: среди возможных мер защиты рассматриваются ограничение автономности агентов, изоляция среды выполнения и более строгий контроль источников инструкций.
☝️Важно: не все режимы работы этих инструментов уязвимы. Исследователи тестировали именно автономные режимы, где агент может самостоятельно одобрять выполнение команд. В Claude Code это был auto-mode, в Codex — auto-review. При обычном режиме с ручным подтверждением каждого действия сценарий не воспроизводится.
Интересно, что Friendly Fire продолжает серию атак на AI-инструменты разработки, использующие один и тот же фундаментальный принцип — доверие модели к внешнему тексту. Ранее исследователи уже демонстрировали атаки через конфигурационные файлы (TrustFall), символьные ссылки (GhostApproval) и поддельные отчеты об ошибках (Agentjacking). В новом случае оказалось достаточно обычного README.md, который традиционно считается безопасной частью любого репозитория.
Хотя Friendly Fire пока остается proof-of-concept и случаев эксплуатации в реальных атаках не зафиксировано, исследование служит очередным напоминанием: AI-агент, обладающий правом выполнять команды, следует рассматривать как еще один привилегированный компонент инфраструктуры. И если раньше основной угрозой считались уязвимости в коде, который агент анализирует, то теперь объектом атаки становится сам процесс автоматизированного анализа.
В видео ниже демонстрация эксплойта, позволяющего скомпрометировать Claude Code👇
Исследователи из AI Now Institute описали новую атаку Friendly Fire, которая позволяет превратить AI-агентов для анализа безопасности в — напротив — инструмент компрометации системы. Под удар попали автономные режимы Claude Code и OpenAI Codex, когда они используются для проверки стороннего кода без подтверждения каждого действия со стороны пользователя.
Злоумышленнику достаточно разместить специально подготовленный репозиторий или изменить содержимое доступного проекта, добавив безобидный на вид README.md, в котором содержится инструкция запустить якобы проверочный скрипт security.sh. Если разработчик поручает AI-агенту провести аудит проекта, тот самостоятельно читает документацию, считает запуск скрипта частью процесса проверки и выполняет его. В демонстрации исследователей скрипт незаметно запускал скрытый бинарный файл уже на машине пользователя.
Авторы подчеркивают, что проблема носит архитектурный характер и не сводится к конкретной версии Claude Code или Codex. Уязвимым оказывается сам сценарий, в котором агент получает право выполнять команды при анализе недоверенного кода. Исправить ситуацию простым обновлением не получится: среди возможных мер защиты рассматриваются ограничение автономности агентов, изоляция среды выполнения и более строгий контроль источников инструкций.
☝️Важно: не все режимы работы этих инструментов уязвимы. Исследователи тестировали именно автономные режимы, где агент может самостоятельно одобрять выполнение команд. В Claude Code это был auto-mode, в Codex — auto-review. При обычном режиме с ручным подтверждением каждого действия сценарий не воспроизводится.
Интересно, что Friendly Fire продолжает серию атак на AI-инструменты разработки, использующие один и тот же фундаментальный принцип — доверие модели к внешнему тексту. Ранее исследователи уже демонстрировали атаки через конфигурационные файлы (TrustFall), символьные ссылки (GhostApproval) и поддельные отчеты об ошибках (Agentjacking). В новом случае оказалось достаточно обычного README.md, который традиционно считается безопасной частью любого репозитория.
Хотя Friendly Fire пока остается proof-of-concept и случаев эксплуатации в реальных атаках не зафиксировано, исследование служит очередным напоминанием: AI-агент, обладающий правом выполнять команды, следует рассматривать как еще один привилегированный компонент инфраструктуры. И если раньше основной угрозой считались уязвимости в коде, который агент анализирует, то теперь объектом атаки становится сам процесс автоматизированного анализа.
В видео ниже демонстрация эксплойта, позволяющего скомпрометировать Claude Code👇
❤3
Недавно мы писали о том, что в правилах защиты появилась возможность создавать условия по географическим регионам, а в общей статистике — отслеживать распределение трафика на графике «Запросы по регионам».
Теперь, для еще большей информативности, добавили карту, на которой можно увидеть, какие страны входят в каждый регион.
Это позволяет быстрее ориентироваться в региональном делении при настройке правил защиты.
Функция доступна во всех модулях, где используются регионы.
Теперь, для еще большей информативности, добавили карту, на которой можно увидеть, какие страны входят в каждый регион.
Это позволяет быстрее ориентироваться в региональном делении при настройке правил защиты.
Функция доступна во всех модулях, где используются регионы.
🔥4👍3🤯2
Почему ковровые DDoS-атаки сложнее обнаружить?
В отличие от классических сценариев, нагрузка распределяется между множеством IP-адресов, поэтому отдельные узлы могут выглядеть совершенно нормально, даже когда вся сеть уже находится под вредоносной нагрузкой.
Ситуацию усложняет и то, что многие такие атаки длятся менее минуты. Этого времени часто достаточно, чтобы перегрузить инфраструктуру и остаться незамеченными.
Практика показывает, что эффективная защита от ковровых атак требует анализа трафика всей сети, а не только отдельных IP-адресов. Именно поэтому современные анти-DDoS-решения используют поведенческие модели, машинное обучение и механизмы фильтрации трафика на уровне провайдера.
В карточках рассказываем, как работают механизмы ковровых DDoS-атак, почему они представляют угрозу для инфраструктуры и какие меры помогают снизить риски👆
В отличие от классических сценариев, нагрузка распределяется между множеством IP-адресов, поэтому отдельные узлы могут выглядеть совершенно нормально, даже когда вся сеть уже находится под вредоносной нагрузкой.
Ситуацию усложняет и то, что многие такие атаки длятся менее минуты. Этого времени часто достаточно, чтобы перегрузить инфраструктуру и остаться незамеченными.
Практика показывает, что эффективная защита от ковровых атак требует анализа трафика всей сети, а не только отдельных IP-адресов. Именно поэтому современные анти-DDoS-решения используют поведенческие модели, машинное обучение и механизмы фильтрации трафика на уровне провайдера.
В карточках рассказываем, как работают механизмы ковровых DDoS-атак, почему они представляют угрозу для инфраструктуры и какие меры помогают снизить риски👆
👀2