19 смертных грехов, угрожающих безопасности программ
Шрифт:
Примеры из реальной жизни
К сожалению, в сообщениях, касающихся безопасности, нечасто встретишь примеры, которые относились бы к проблемам практичности. Главным образом это связано с тем, что такие проблемы разработчики склонны перекладывать на пользователей. Проще во всем обвинить пользователя, чем постараться не подвергать его опасности.
Но парочку своих любимых примеров мы все же приведем.
Аутентификация сертификата в протоколе SSL/TLS
Мы говорили об этом в грехе 10. Основная проблема в том, что когда браузер обнаруживает, что сертификат сайта, на который зашел пользователь, недействителен или вообще относится к другому сайту, он обычно выводит окно с невразумительным сообщением, например такое, как на рис. 19.1.
Рис. 19.1 .
Типичный пользователь, увидев такое, подумает: «Ну и что все это значит?» В общем–то ему наплевать, поэтому он просто зайдет на сайт, нажав кнопку Yes и даже на дав себе труда попытаться понять, в чем проблема. Редкий пользователь, обуреваемый любопытством, решит нажать кнопку View Certificate (Показать сертификат), а потом все равно не будет знать, на что смотреть.
В разделе «Искупление греха» мы покажем более правильные способы решения этой конкретной проблемы.
Установка корневого сертификата в Internet Explorer 4.0
Предположим, что вам нужно установить сертификат нового корневого удостоверяющего центра (УЦ), чтобы получить доступ к сайту, защищенному SSL/ TLS, сертификат которого выпущен «левым» УЦ (обычно с помощью OpenSSL или Microsoft Certificate Server). До выхода в свет Internet Explorer 5.0 вы бы увидели окно, показанное на рис. 19.2. (Не надо затевать разговор о рисках, связанных с установкой сертификата корневого УЦ с сайта, который вы не можете аутентифицировать. Это другая тема.)
Это окно никуда не годится, потому что оно бесполезно как для обычных пользователей, так и для администраторов. Для человека, не знакомого с криптографией (а это большая часть населения планеты), текст выглядит полной бессмыслицей. А для администратора наличие двух сверток не дает ничего, если только он не позвонит конкретному человеку или фирме и не попросит для подтверждения повторить обе свертки: SHA–1 и MD5. К счастью, в Internet Explorer 5.0 и более поздних версиях это окно заменено куда более осмысленным.
Рис. 19.2. Предложение установить корневой сертификат в Internet Explorer 4.0
Искупление греха
Есть несколько базовых принципов создания удобных и безопасных систем, которые следует применять на этапе проектирования. Мы их рассмотрим, но напомним еще раз, что самый эффективный способ решения таких проблем – полагаться на тестирование практичности, а не на собственную интуицию.
Делайте интерфейс пользователя простым и понятным
Мы пытаемся убедить вас, что пользователя следует, как правило, изолировать от большинства вопросов, связанных с безопасностью. Если же это невозможно (например, когда пользователь должен выбрать или ввести пароль), то программа должна вести с ним диалог, призывая к безопасному поведению и стараясь не вызвать недовольства.
Вспомните: «Безопасность (почти) никогда не стоит у пользователей на первом месте». Для иллюстрации этого тезиса мы еще приводили в пример систему, в которой пользователь должен был сделать несколько попыток, чтобы выбрать приемлемый пароль.
Лично мы полагаем, что не нужно накладывать слишком строгих ограничений на выбор пароля, поскольку это приведет лишь к тому, что пользователи станут записывать или забывать пароли. Но с теми ограничениями, что есть, пользователя нужно познакомить в самом начале. Перечислите требования к паролю рядом с полем ввода и изложите их максимально просто. Хотите, чтобы пароль был не короче восьми знаков и содержал хотя бы одну не–букву? Так и скажите!
Принимайте за пользователей решения, касающиеся безопасности
Люди, как правило, не изменяют значений, принятых по умолчанию. Если вы позволите им выполнять доверенный код и выберете по умолчанию слабый, но быстрый шифр, то большинство пользователей не станут ради страховки переводить систему в более
Поэтому нужно проектировать и разрабатывать систему так, чтобы она была безопасной по умолчанию. Включите и шифрование, и аутентификацию сообщений! А если нужно, то и многофакторную аутентификацию.
В то же время избегайте чрезмерного количества настраиваемых параметров. Это может привести не только к выбору пользователем менее безопасной конфигурации, но и к проблемам с организацией совместной работы приложений. Например, нет нужды поддерживать все существующие наборы шифров. Вполне достаточно одного стойкого набора на базе AES. Будьте проще! Простота – это ваш помощник в деле обеспечения безопасности.
Избегайте также вовлекать пользователя в принятие решений о доверии. Так, в разделе «Примеры из реальной жизни» мы говорили о проверке сертификата SSL/TLS браузерами (конкретно, при работе по протоколу HTTPS). Если проверка не проходит, пользователь видит непонятное окно с предложением принять решение, для чего у него обычно не хватает квалификации.
Что же делать? Оптимальный подход – считать, что сайт, не прошедший проверку сертификата, вообще не работает. Тем самым ответственность за предоставление гарантий достоверности сертификата снимается с пользователя и возлагается на Web–сервер и владельца сертификата. При таком развитии событий пользователя не просят ничего решать. Если пользователь не может зайти на сайт из–за ошибки в сертификате, то такой сайт для него ничем не отличается от неработающего. А раз никто не может зайти, администратор сайта об этом рано или поздно узнает и будет вынужден принять меры. Побочный эффект такого подхода – принуждение людей, отвечающих за Web–сервер, выполнять свою работу. Сейчас же операторы сайта знают, что могут вольно относиться к именам в сертификатах, поскольку по умолчанию браузеры все равно установят соединение. Это классический пример на тему «курица и яйцо».
Такой же метод следует применять к людям, которые не хотят связываться с инфраструктурой открытых ключей. Они выпускают собственные сертификаты, доверять которым нет никаких оснований. Такие сертификаты не должны работать, пока не установлены в качестве корневых.
К сожалению, решить эту проблему только на уровне браузера невозможно. Если какой–то браузер реализует описанную стратегию, а все остальные не будут ей следовать, то обвинить в недоступности сайта можно будет «браузер–новатор», а не сервер. Возможно, подкорректировать надо сам протокол HTTPS!
Если вы решите предоставить параметры, позволяющие ослабить безопасность, то мы рекомендуем запрятать их подальше. Не вручайте пользователю мыло и веревку! Считается, что средний пользователь не станет щелкать мышью больше трех раз, чтобы найти нужный параметр. Упрячьте такие параметры поглубже в интерфейсе конфигурации. Например, вместо того чтобы включать в диалоговое окно вкладку Security (Безопасность), сделайте вкладку Advanced (Дополнительно), а уже на ней – кнопку Security. При нажатии этой кнопки откройте окно, в котором будут отображаться текущие значения параметров безопасности, средства для конфигурирования протоколов и другие безвредные вещи. И поместите еще одну кнопку Advanced – вот она–то и позволит сделать что–то по–настоящему опасное. И ПОЖАЛУЙСТА, сопровождайте такие действия предупреждениями!
Упрощайте избирательное ослабление политики безопасности
Обеспечив максимальную безопасность по умолчанию, можете добавить немного гибкости, чтобы пользователь смог избирательно ослабить политику безопасности, не открывая брешей всему миру.
Хороший пример такого рода – это идея «Информационной панели» (Information Bar), небольшой области состояния, добавленной к Internet Explorer в Windows ХР SP2 (позже ее позаимствовал Firefox). Она находится сразу под строкой ввода адреса и информирует пользователя о текущих политиках безопасности. Например, браузер не спрашивает, хочет ли пользователь разрешить выполнение активного или мобильного кода, а просто запрещает, но информирует об этом. В этот момент пользователь может при желании изменить политику (если, конечно, имеет на это право), но по умолчанию предпринимается безопасное действие. Пользователю не надо думать о доверии, система безопасна, но сообщает, если происходит что–то необычное. Информационная панель показана на рис. 19.3.