to the top
close form
Для получения триального ключа
заполните форму ниже
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

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

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

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

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

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


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

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

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

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-решения непосредственно выявляют уязвимость нулевого дня. Анализаторы выявляют потенциальные уязвимости. Другими словами, они указывают на странные/аномальные фрагменты кода, которые могут являться ошибками и дефектами безопасности.

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

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

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

Популярные статьи по теме
C++ — язык 2022 года. Почему так, и что с другими языками?

Дата: 20 Янв 2023

Автор: Сергей Васильев

C++ становится языком 2022 года по версии TIOBE, обгоняя Python. Rust, C#, Go и прочие — далеко позади. Странно? Сейчас разберёмся.
PVS-Studio в 2022 году

Дата: 19 Янв 2023

Автор: Полина Алексеева

На дворе январь 2023, а значит, самое время подвести итоги уже прошлого 2022 года. Мы расскажем, чем занимались, и покажем, что нового появилось в анализаторе за это время. Давайте вместе взглянем на…
PVS-Studio: 2 фишки для быстрого старта

Дата: 08 Дек 2022

Автор: Сергей Васильев

В этой заметке расскажу, как легко начать использовать PVS-Studio. Рассмотрим два сценария: когда вы пробуете анализатор впервые и когда внедряете его в проект.
Почему ты делаешь за меня мою работу? Типы людей, которые не пишут в поддержку

Дата: 06 Дек 2022

Автор: Алёна Фоканова

Привлекательное название статьи должно раскрывать то, что будет в ней. Так вот, работа специалистом поддержки клиентов подразумевает появление вопросов к пользователю. Иногда возникает как раз такой:…
Как Apple и другие крупные компании настиг программный баг

Дата: 09 Ноя 2022

Автор: Ульяна Гришина

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

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

Следующие комментарии next comments
close comment form
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо