Классификация и виды уязвимостей
Классификаторы
Использование стандартизованных описаний уязвимостей упрощает работу специалистов по информационной безопасности. В настоящее время существует несколько популярных классификаторов:
- CVE (Common Vulnerabilities and Exposures) — словарь конкретных уязвимостей конкретных продуктов;
- CWE (Common Weakness Enumeration) — база данных типов уязвимостей. Основная задача проекта — предоставить описания распространённых видов уязвимостей, способы их предотвращения, обнаружения и исправления;
- SecurityFocus BID;
- OSVDB (Open Sourced Vulnerability Database) — «открытая база данных уязвимостей», созданная тремя некоммерческими организациями. Прекратила работу 5 апреля 2016 года. Блог продолжает работать;
- Secunia — лента уязвимостей известной датской компании Secunia в области компьютерной и сетевой безопасности;
- IBM ISS X-Force.
Современные анализаторы кода и автоматизированные аудиторы могут использовать подобные базы уязвимостей. Это повышает уровень доверия к продукту, а также может оказаться важным при составлении отчётов об уязвимостях, имеющихся в программном продукте.
Встречаются и другие классификаторы. При работе с ними следует обращать внимание на авторов, так как каждая система классификации должна создаваться экспертами в данной области.
Виды уязвимостей
Список распространённых ошибок, ставящих под угрозу безопасность современных программ:
внедрение SQL-кода (англ. SQL injection);
уязвимости, связанные с web-серверами (XSS, XSRF, расщепление
уязвимости web-клиентов (DOM XSS);
переполнение буфера (англ. Buffer Overflow);
дефекты форматных строк (англ. Uncontrolled format string);
целочисленные переполнения (англ. Integer overflow);
некорректная обработка исключений и ошибок;
внедрение команд (командная инъекция, англ. Command injection);
утечка информации (англ. Information Exposure);
ситуация гонки (англ. Race condition);
слабое юзабилити (англ. Insufficient Psychological Acceptability);
выполнение кода с завышенными привилегиями (англ. Execution with Unnecessary Privileges);
хранение незащищенных данных (англ. Protection Mechanism Failure);
проблемы мобильного кода (англ. Mobile Code Issues);
слабые пароли;
слабые случайные числа;
неудачный выбор криптографических алгоритмов;
использование небезопасных криптографических решений;
незащищенный сетевой трафик (англ. Cleartext Transmission of Sensitive Information);
неправильное использование PKI (англ. Improper Certificate Validation);
доверие к механизму разрешения сетевых имен (англ. Reliance on Reverse DNS Resolution).
Перечислить все известные уязвимости невозможно, учитывая, что каждый день появляются новые. В данном списке приведены часто встречающиеся уязвимости, допустить которые легко, но последствия которых могут быть катастрофическими. Например, причиной распространения червя Blaster стала ошибка всего в двух строках кода.
Рекомендации по безопасному написанию кода
Большая часть кода приложения может просто использовать инфраструктуру, реализованную в .NET. В некоторых случаях требуется дополнительная защита на уровне приложения, построенная либо путем расширения системы, либо с помощью новых специальных методов.
Используя принудительные разрешения .NET и другие средства обеспечения безопасности в коде, следует возводить барьеры, чтобы предотвратить доступ вредоносного кода к информации, которую не нужно использовать, или выполнить другие нежелательные действия. Кроме того, необходимо соблюсти баланс между безопасностью и удобством использования во всех планируемых сценариях с использованием доверенного кода.
В этом обзоре описываются различные способы разработки кода, взаимодействующего с системой безопасности.
Защита доступа к ресурсам
При разработке и написания кода необходимо защитить и ограничить доступ данного кода к ресурсам, особенно при использовании или вызове кода неизвестного происхождения. Убедиться, что ваш код является безопасным, можно с помощью следующих методов.
Не используйте управление доступом для кода (CAS).
Не используйте частично доверенный код.
Не используйте атрибут алловпартиаллитрустедкаллер (APTCA).
Не используйте удаленное взаимодействие .NET.
Не используйте модель DCOM.
Не используйте двоичные модули форматирования.
Безопасность доступа к коду и прозрачный для системы безопасности код не поддерживаются в качестве границы безопасности с частично доверенным кодом. Мы не рекомендуем загружать и выполнять код из неизвестных источников, не предприняв дополнительные меры безопасности. Ниже приведены дополнительные меры безопасности.
Виртуализация
Контейнеры AppContainer
Пользователи операционной системы (ОС) и разрешения
Контейнеры Hyper-V
Do'stlaringiz bilan baham: |