19 смертных грехов, угрожающих безопасности программ
Шрифт:
□ Reflector for .NET: http://www.aisto.com/roeder/dotnet/
Резюме
Рекомендуется
□ Думайте, какие элементы управления доступом ваше приложение применяет к объектам явно, а какие наследует по умолчанию.
□ Осознайте, что некоторые данные настолько секретны, что никогда не должны храниться на промышленном сервере общего назначения, например долгосрочные закрытые ключи для подписания сертификатов Х.509. Их следует хранить
□ Используйте средства, предоставляемые операционной системой для безопасного хранения секретных данных.
□ Используйте подходящие разрешения, например в виде списков управления доступом (ACL), если приходится хранить секретные данные.
□ Стирайте секретные данные из памяти сразу после завершения работы с ними.
□ Очищайте память прежде, чем освобождать ее.
Не рекомендуется
□ Не создавайте объектов, доступных миру для записи, в Linux, Mac OS X и UNIX.
□ Не создавайте объектов со следующими записями АСЕ: Everyone (Full Control) или Everyone (Write).
□ He храните материал для ключей в демилитаризованной зоне. Такие операции, как цифровая подпись и шифрование, должны производиться за пределами демилитаризованной зоны.
□ Не «зашивайте» никаких секретных данных в код программы. Это относится к паролям, ключам и строкам соединения с базой данных.
□ Не создавайте собственных «секретных» алгоритмов шифрования.
Стоит подумать
□ Об использовании шифрования для хранения информации, которую нельзя надежно защитить с помощью ACL, и о подписании ее, чтобы исключить неавторизованное манипулирование.
□ О том, чтобы вообще не хранить секретные данные. Нельзя ли запросить их у пользователя во время выполнения?
Грех 13. Утечка информации
В чем состоит грех
Опасность утечки информации состоит в том, что противник получает данные, которые могут привести к явному или неявному нарушению политики безопасности. Целью могут быть как сами эти данные (например, сведения о клиентах компании), так и информация, с помощью которой противник сможет решить стоящую перед ним задачу.
По–крупному есть два основных пути утечки информации:
□ Случайно. Данные считаются ценными, но каким–то образом, возможно, из–за логической ошибки в программе или по некоему неочевидному каналу, они просочились наружу. А возможно, данные были бы сочтены ценными, если бы проектировщики осознавали последствия их утечки для безопасности.
□ Намеренно. Иногда команда проектировщиков и конечные пользователи неодинаково понимают, что именно нужно защищать. Обычно это касается охраны тайны личной жизни.
Случаи непреднамеренного раскрытия ценной информации за счет
Последствия утечки информации не всегда очевидны. Ну да, вы понимаете, зачем надо защищать номера социального страхования и кредитных карточек, но как насчет других данных, возможно, тоже конфиденциальных? Материалы исследования Jupiter Research 2004 года показали, что люди, принимающие решения в бизнесе, озабочены непреднамеренной переадресацией электронной почты и конфиденциальных документов, а также утратой мобильных устройств. Следовательно, не предназначенные для разглашения данные следует адекватно защищать.
Подверженные греху языки
Раскрытие информации не связано с каким–то конкретным языком, хотя если говорить о случайных утечках, то многие современные языки высокого уровня усугубляют проблему, так как выдают излишне подробные сообщения об ошибках, которые могут оказаться полезными противнику. Но в конечном итоге вы все равно должны решить для себя, что лучше: сообщить пользователю ценную информацию об ошибке или помешать противнику, скрывая внутренние детали системы.
Как происходит грехопадение
Мы уже отметили, что грех утечки информации имеет две стороны. Вопрос охраны тайны личной жизни волнует большинство пользователей, но мы полагаем, что он находится за рамками данной книги. Мы считаем, что вы должны внимательно оценивать потребности своих пользователей и обязательно интересоваться их мнением о применяемой вами политике безопасности. Но в этой главе мы не будем затрагивать такие вопросы, а посмотрим, как можно случайно допустить утечку ценной для противника информации.
Побочные каналы
Очень часто противник может по крохам собрать важные сведения, измеряя нечто такое, о чем проектировщики даже не подозревали. Или, по крайней мере, не думали, что «разглашение» может иметь какие–либо последствия для безопасности!
Есть два вида так называемых побочных каналов: связанные с хронометражем и с хранением. По хронометрируемому каналу противник получает информацию о внутреннем устройстве системы, измеряя время выполнения операций. Например, в грехе 11 мы описали простой хронометрируемый канал в процедуре входа в систему TENEX, когда противник мог что–то узнать о пароле, засекая время реакции на ввод неверных паролей. Если первая буква введенного пароля правильна, то система отвечает быстрее, чем в случае неправильной буквы.