Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

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

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

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

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

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


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

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

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

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

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

Дата: 04 Май 2022

Автор: Сергей Хренов

Приветствую всех программистов, а также сочувствующих. Кто из нас хотя бы раз в жизни не оставлял комментарии в коде? Был ли это ваш код, а может, чужой? Что за комментарии вы написали: полезные или …
Visual Studio 2022 стильно и свежо. История о её поддержке в PVS-Studio

Дата: 15 Фев 2022

Автор: Николай Миронов

Кажется, анонс Visual Studio 2022 был только недавно, и вот она уже вышла. Это означало ровно одно – поддержать данную IDE нужно в ближайшем релизе PVS-Studio. О том, с какими сложностями пришлось ст…
Лучшие срабатывания статического анализатора

Дата: 29 Окт 2021

Автор: Максим Звягинцев

У всех, кто запускал статический анализатор в первый раз на большом проекте, был небольшой шок по поводу сотен, тысяч или даже десятков тысяч предупреждений. Как-то грустно становится после такого. Т…
Зачем нужна техническая поддержка и как в ней не выгореть?

Дата: 01 Сен 2021

Автор: Николай Миронов

Не всем нравится работать в поддержке. Огромное количество людей выгорает на ней. Так может не стоит вообще её иметь? Какую выгоду она несёт? Можно ли как-то не выгорать от поддержки? Попробуем найти…
Как делался новый дизайн сайта PVS-Studio

Дата: 04 Июн 2021

Автор: Инна Пристягина

Сайту PVS-Studio в этом году исполнится 15 лет. Это солидный возраст для любого интернет-ресурса. Далёкий 2006-й в России был признан годом гуманитарных наук. В июне появилась никому не знакомая тогд…

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

Следующие комментарии
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять