Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
□ Найдите в интерфейсе пользователя все параметры, относящиеся к безопасности. Что включено по умолчанию, а что выключено? Если программа по умолчанию небезопасна, возможны проблемы. Неприятности могут возникнуть и в тех случаях, когда ослабить безопасность слишком легко.
□ Изучите систему аутентификации. Если пользователь не может успешно аутентифицировать второго участника соединения, есть ли возможность все–таки установить соединение? Разумеется, при этом пользователь понятия не имеет, кто находится на другом конце. Хороший пример – это SSL–соединение, когда клиентская программа соединяется с сервером, но имя в сертификате свидетельствует о том, что это не тот сервер, а пользователь даже не обращает на это внимания. (Скоро мы объясним эту ситуацию подробнее.)
Стоит также взглянуть, существует ли очевидный способ переустановить пароль. Если да, то можно ли использовать этот механизм, чтобы вызвать отказ от обслуживания? Нельзя ли с его помощью заманить пользователя в ловушку методами социальной инженерии?
Тестирование
В основе науки о практичности лежит тестирование. К сожалению, фирмы–разработчики такому тестированию не уделяют много внимания. При тестировании практичности пользователи обычно работают парами (метод обсуждения вслух). Они самостоятельно исследуют систему, часто в первый раз. При оценке безопасности можно применить такой же подход; главное, чтобы пользователь попробовал те функции, которые вас интересуют.
Обычно в ходе испытания пользователям предлагается набор заданий, но в их работу никто не вмешивается до тех пор, пока они не застрянут окончательно.
Основы тестирования практичности применимы и к безопасности, поэтому имеет смысл познакомиться с этой дисциплиной. Мы рекомендуем книгу Jacob Nielsen «Usability Engineering» (Morgan Kaufman, 1994) («Инженерная оценка практичности»). Кроме того, в статье Alma Whitten и J.D. Tygar «Usability of Security: A Case Study» («Практичность безопасности на конкретном примере») излагаются некоторые соображения по поводу тестирования функций безопасности программ с точки зрения удобства пользования.
Примеры из реальной жизни
К сожалению, в сообщениях, касающихся безопасности, нечасто встретишь примеры, которые относились бы к проблемам практичности. Главным образом это связано с тем, что такие проблемы разработчики склонны перекладывать на пользователей. Проще во всем обвинить пользователя, чем постараться не подвергать его опасности.
Но парочку своих любимых примеров мы все же приведем.
Аутентификация сертификата в протоколе SSL/TLS
Мы говорили об этом в грехе 10. Основная проблема в том, что когда браузер обнаруживает, что сертификат сайта, на который зашел пользователь, недействителен или вообще относится к другому сайту, он обычно выводит окно с невразумительным сообщением, например такое, как на рис. 19.1.
Рис. 19.1 . Диалоговое окно, которое открывает Internet Explorer, если браузер заходит на сайт с «самоподписанным» сертификатом
Типичный пользователь, увидев такое, подумает: «Ну и что все это значит?» В общем–то ему наплевать, поэтому он просто зайдет на сайт, нажав кнопку 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 – вот она–то и позволит сделать что–то по–настоящему опасное. И ПОЖАЛУЙСТА, сопровождайте такие действия предупреждениями!
