Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
Дополнительные защитные меры
Вот небольшой перечень дополнительных защитных мер, которые можно включить в приложение:
□ используйте шифрование при хранении секретной информации и цифровую подпись для обнаружения попыток манипулирования, если нельзя защитить ее с помощью задания строгих ограничений доступа (ACL);
□ используйте ACL или разрешения для ограничения числа лиц, которые имеют доступ (для чтения или записи) к секретным данным, хранящимся на диске;
□ по завершении работы с секретными данными безопасно стирайте память. В таких языках, как Java или управляемый код в .NET, это, вообще говоря, невозможно, но в .NET 2.0 проблема частично решается с помощью класса SecureString.
Другие ресурсы
□ Writing Secure Code, Second Edition by Michael Howard and David C. LeBlanc (Microsoft Press, 2002), Chapter 6, «Determining Appropriate Access Control»
□ Writing Secure Code, Second Edition by Michael Howard and David C. LeBlanc (Microsoft Press, 2002), Chapter 8, «Cryptographic Foibles»
□ Writing Secure Code, Second Edition by Michael Howard and David C. LeBlanc (Microsoft Press, 2002), Chapter 9, «Protecting Secret Data»
□ Windows Access Control: http://msdn.microsoft.com/library/default.asp?url=/ library/en–us/secauthz/security/access_control.asp
□ Windows Data Protection: http://msdn.microsoft.com/library/default.asp7urH/ library/en–us/dnsecure/html/windataprotection–dpapi.asp
□ «How To: Use DPAPI (Machine Store) from : by J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy: http://msdn.microsoft.com/ Hbrary/en–us/dnnetsec/html/SecNetHT08.asp
□ Threat Mitigation Techniques: http://msdn.microsoft.com/library/en–us/ secbp/security/threat_mitigation_techniques.asp
□ Implementation of SecureZeroMemory: http://msdn.microsoft.com/library/ en–us/dncode/html/securel0102002.asp
□ «Making String More Secure»: http://weblogs.asp.net/shawnfa/archive/ 2004/05/27/143254.aspx
□ «Secure Programming for Linux and Unix HOWTO – Creating Secure Soft–ware» by David Wheeler: www.dwheeler.com/secure–programs
□ Java Security, Second Edition by Scott Oaks (O'Reilly, 2001), Chapter 5, «Key Management, pp. 79–91
□ Jad Java Decompiler: http://kpdus.tripod.com/jad.html
□ Class KeyStore (Java 2 Platform 5.0): http://fl.java.sun.eom/j2se/l.5.0/docs/ api/java/security/KeyStore.html
□ «Enabling Secure Storage with Keychain Services»: http://developer.apple. com/d оси me ntation/S ecu rity/Conceptual/keychainServ Concepts/ keychainServConcepts.pdf
□ Java KeyStore Explorer: http://www.lazgosoftware.com/kse/
□ «Enabling Secure Storage With Keychain Services»: http://developer. apple, com / documentation/Security/Reference/keychainservices/index.html
□ introduction to Enabling Secure Storage With Keychain Services»: developer.apple.com/documentation/Security/Conceptual/keychainServ Concepts/03tasks/chapter_3_section_2.html
□ Knowledge Base Article 329290: «How to use ASP.NET utility to encrypt credentials and session state connection strings»: http://support.microsoft.com/ default.aspx? scid=kb;en–us;329290
□ «Safeguard Database Connection Strings and Other Sensitive Settings in Your Code» by Alek Davis: http://msdn.microsoft.com/msdnmag/issues/03/ll/ ProtectYourData/default.aspx
□ 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, когда противник мог что–то узнать о пароле, засекая время реакции на ввод неверных паролей. Если первая буква введенного пароля правильна, то система отвечает быстрее, чем в случае неправильной буквы.
Проблема возникает тогда, когда противник может измерить время между сообщениями, содержимое которых зависит от секретных данных. На первый взгляд представляется уж слишком вычурным, но, как мы увидим, такие атаки встречаются на практике.
Вообще говоря, существует немало криптографических алгоритмов, уязвимых для атак с хронометражем. Во многих алгоритмах с открытым ключом и даже в некоторых алгоритмах с секретным ключом встречаются операции, зависящие от времени. Например, в некоторых реализациях алгоритма AES применяется поиск в таблицах, время которого может зависеть от ключа (то есть изменяется при смене ключа). Если не позаботиться об усилении защиты таких таблиц, то путем статистической атаки с хронометражем можно узнать ключ AES, просто наблюдая за процессом шифрования данных.
