19 смертных грехов, угрожающих безопасности программ
Шрифт:
Разумеется, конфиденциальные данные нужно защищать с помощью подходящих средств, например списков АСЕ в Windows и Apple MAC OS X 10.4 Tiger или прав доступа в *nix.
Есть и другие защитные меры, такие, скажем, как шифрование (с корректной политикой управления ключами) и управление цифровыми правами (Digital Rights Management – DRM). Механизм DRM в этой книге не рассматривается, но вкратце его суть в том, что пользователь может явно определить, кому разрешено открывать, читать, модифицировать и передавать другим лицам содержимое документов, в частности электронной почты. Организация может создать шаблоны политик управления
Если говорить об атаках с хронометражем, то обычно в защите нуждаются криптографические ключи. Пользуйтесь реализациями, которые препятствуют атакам с хронометражем, если эта проблема вас беспокоит. Кстати, это еще одна причина не создавать собственные криптосистемы!
Искупление греха в С# (и других языках)
Следующий пример – это модифицированный вариант греховного кода на С#, который был показан выше, но та же идея применима и к любому другому языку. Обратите внимание, что сообщения об ошибках выводятся лишь, если пользователь обладает правами администратора Windows. Кроме того, предполагается, что в этой программе предварительно запрашивается декларативное разрешение, так что обращения к протоколу событий всегда завершаются успешно, а не возбуждают исключение SecurityException из–за того, что в доступе отказано.
try {
// код обращения к SQL-серверу опущен
} catch (SqlException se) {
Status = sqlstring + " failed\r\n";
foreach (SqlError e in se.Errors)
Status += e.Message + "\r\n";
WindowsIdentity user = WindowsIdentity.GetCurrent;
WindowsPrincipal prin = new WindowsPrincipal(user);
if (prin.IsInRole(WindowsBuiltInRole.Administrator))
Response.Write("Error" + Status);
else {
Response.Write("An error occured, please bug your admin");
// Записать данные в протокол Windows Application Event Log
EventLog.WriteEntry("SQLApp", Status.EventLogEntryType.Error);
}
}
Отметим, что некоторые приложения самостоятельно определяют привилегированных и доверенных пользователей, тогда нужно пользоваться встроенными в них или в среду исполнения механизмами управления доступом.
Учет локальности
Иногда имеет смысл выводить информацию об ошибках только локальным пользователям. Чтобы решить этот вопрос, взгляните на IP–адрес, по которому вы собираетесь отправлять данные. Если он отличается от 127.0.0.1 или его эквивалента в IPv6 (::1), не посылайте данные. Даже если это открытый IP–адрес самой текущей машины, отправленные на него пакеты обычно видны всем машинам в локальной сети.
Дополнительные защитные меры
Если приложение состоит из нескольких процессов, то некоторую помощь вам могут оказать такие защищенные ОС, как SE Linux, Trusted Solaris, или надстройки над ОС типа Argus PitBull (работает для Linux, Solaris и AIX). Обычно вы можете пометить данные на уровне файла, и система будет отслеживать их передачу между процессами.
Несколько более практичная рекомендация заключается в том, чтобы хранить все данные в зашифрованном виде, пока не возникнет необходимость показать их. Большинство
Можно также выполнять «контроль на выходе», то есть проверять корректность выводимых данных. Так, если некоторая часть приложения может выводить только числа, проверьте, что, кроме цифр, в выходном потоке ничего нет. О проверке входных данных мы слышим постоянно, но иногда имеет смысл проверять и выходные.
Другие ресурсы
□ «СасЬе–timing attacks on AES» by Daniel J. Bernstein:antiforgery/cachetiming–20050414.pdf
□ «Cache for fun and profit» (атака на RSA на машинах с гипертредингом, аналогичная атака Бернстайна на AES) by Colin Percival: www.daemonology.net/ papers/htt.pdf
□ Computer security: Art and Science by Matt Bishop (Addison–Wesley, 2002), Chapter 5, «Confidentiality Policies»
□ Default Passwords: www.cirt.net/cgi–bin/passwd.pl
□ Windows Rights Management Services: www.microsoft.com/resources/ documentation/windowsserv/2003/all/rms/en–us/default.mspx
□ XrML (extensible Rights Markup Language): www.xrml.org
□ Encrypting File System overview: www.microsoft.com/resources/documentation/ windows/xp/all/proddocs/en–us/encrypt–overviewmspx
Резюме
Рекомендуется
□ Решите, кто должен иметь доступ к информации об ошибках и состоянии.
□ Пользуйтесь средствами операционной системы, в том числе списками ACL и разрешениями.
□ Пользуйтесь криптографическими средствами для защиты секретных данных.
Не рекомендуется
□ Не раскрывайте информацию о состоянии системы не заслуживающим доверия пользователям.
□ Не передавайте вместе с зашифрованными данными временные метки высокого разрешения. Если без временных меток не обойтись, уменьшите разрешение или включите их в состав зашифрованной полезной нагрузки (по возможности).
Стоит подумать
□ О применении менее распространенных защитных механизмов, встроенных в операционную систему, в частности о шифровании на уровне файлов.
□ Об использовании таких реализаций криптографических алгоритмов, которые препятствуют атакам с хронометражем.
□ Об использовании модели Белла–ЛаПадулы, предпочтительно в виде готового механизма.
Грех 14. Некорректный доступ к файлам
В чем состоит грех
Найти в программе грех некорректного доступа к файлам довольно трудно, он легко может ускользнуть от внимания. В этом направлении можно выделить три типичные проблемы безопасности. Первая – это «гонки»: между моментом проверки условий защиты для файла и моментом использования этого файла часто есть некоторое окно, когда файл уязвим. Гонка обычно проистекает из–за ошибок синхронизации, вследствие чего один процесс может вмешаться в работу другого, открывая брешь для атаки.