Уязвимость нулевого дня
Уязвимость нулевого дня / 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.
Существует бесконечное количество способов допустить ошибку в коде, которая станет причиной уязвимости. К счастью, во всём этом есть определённые закономерности. Большинство ошибок можно классифицировать и выявить определённые ошибочные паттерны.
Эти паттерны хорошо изучены, и существуют их классификации. Наиболее значимые среди них:
- OWASP Application Security Verification Standard (OWASP ASVS);
- Common Weakness Enumeration (CWE);
- SEI CERT Coding Standards.
Для выявления уязвимостей нулевого дня используются статические анализаторы кода, такие как PVS-Studio. Как правило, такие анализаторы поддерживают один или несколько стандартов, перечисленных выше.
Примечание. Статические анализаторы — это достаточно общее понятие. Чтобы подчеркнуть, что анализатор ориентирован предотвращать уязвимости, его называют средством статического тестирования защищённости приложений (SAST). См. также PVS-Studio SAST.
Неправильно говорить, что SAST-решения непосредственно выявляют уязвимость нулевого дня. Анализаторы выявляют потенциальные уязвимости. Другими словами, они указывают на странные/аномальные фрагменты кода, которые могут являться ошибками и дефектами безопасности.
Только небольшая часть выявленных ошибок на самом деле представляет угрозу. Возьмём, например, ошибку "переполнение буфера". Все стандарты классифицируют её как крайне опасную с точки зрения безопасности. Но только малую часть таких ошибок можно эксплуатировать. Большинство из них приводят к неприятным, но не фатальным последствиям. Например, переполнение буфера может приводить к порче изображения.
Хотя только часть ошибок может стать причинами уязвимостей, программистам нет смысла пытаться их как-то разделять. Рационально исправлять все участки кода, на которые выданы предупреждения (кроме случаев явно ложных срабатываний анализатора). Даже если исправляется не потенциальная уязвимость, а просто ошибка, это всё равно полезно. Тем более что часто очень непросто понять, представляет ли та или иная ошибка опасность с точки зрения безопасности. Лучше не рисковать, а исправить её.
Дополнительные ссылки:
- OWASP, уязвимости и taint анализ в PVS-Studio C#. Смешать, но не взбалтывать.
- Анализатор кода PVS-Studio как инструмент для поиска дефектов безопасности и защищённости приложений. Отчёт Forrester Research о SAST, Q3 2020.
- Какая разница между DevOps и DevSecOps?
- Статический анализатор кода PVS-Studio как защита от уязвимостей нулевого дня.
- Как PVS-Studio может помочь в поиске уязвимостей?
0