Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

Шаг 2
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности
close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS‑Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

Вебинар: C++ ЛИНТЕРЫ — ХОРОШО, НО НЕДОСТАТОЧНО - 20.06

>
>
>
Уязвимость нулевого дня

Уязвимость нулевого дня

19 Июл 2021

Уязвимость нулевого дня / 0-day / zero day — этот термин обозначает ещё не устранённые уязвимости.

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

Название термина отражает, что у разработчиков нет ни дня на исправление дефекта, так как они о нём пока не знают.

Большинство уязвимостей связано не с какими-то просчётами в системах безопасности или высокоуровневыми ошибками в логике, а с обыкновенными ошибками в коде приложений.

The National Institute of Standards and Technology (NIST) reports that 64% of software vulnerabilities stem from programming errors and not a lack of security features.

Существует бесконечное количество способов допустить ошибку в коде, которая станет причиной уязвимости. К счастью, во всём этом есть определённые закономерности. Большинство ошибок можно классифицировать и выявить определённые ошибочные паттерны.

Эти паттерны хорошо изучены, и существуют их классификации. Наиболее значимые среди них:

Для выявления уязвимостей нулевого дня используются статические анализаторы кода, такие как PVS-Studio. Как правило, такие анализаторы поддерживают один или несколько стандартов, перечисленных выше.

Примечание. Статические анализаторы — это достаточно общее понятие. Чтобы подчеркнуть, что анализатор ориентирован предотвращать уязвимости, его называют средством статического тестирования защищённости приложений (SAST). См. также PVS-Studio SAST.

Неправильно говорить, что SAST-решения непосредственно выявляют уязвимость нулевого дня. Анализаторы выявляют потенциальные уязвимости. Другими словами, они указывают на странные/аномальные фрагменты кода, которые могут являться ошибками и дефектами безопасности.

Только небольшая часть выявленных ошибок на самом деле представляет угрозу. Возьмём, например, ошибку "переполнение буфера". Все стандарты классифицируют её как крайне опасную с точки зрения безопасности. Но только малую часть таких ошибок можно эксплуатировать. Большинство из них приводят к неприятным, но не фатальным последствиям. Например, переполнение буфера может приводить к порче изображения.

Хотя только часть ошибок может стать причинами уязвимостей, программистам нет смысла пытаться их как-то разделять. Рационально исправлять все участки кода, на которые выданы предупреждения (кроме случаев явно ложных срабатываний анализатора). Даже если исправляется не потенциальная уязвимость, а просто ошибка, это всё равно полезно. Тем более что часто очень непросто понять, представляет ли та или иная ошибка опасность с точки зрения безопасности. Лучше не рисковать, а исправить её.

Дополнительные ссылки:

Популярные статьи по теме


Комментарии (0)

Следующие комментарии next comments
close comment form