19 смертных грехов, угрожающих безопасности программ

Стоит также взглянуть, существует ли очевидный способ переустановить пароль. Если да, то можно ли использовать этот механизм, чтобы вызвать отказ от обслуживания? Нельзя ли с его помощью заманить пользователя в ловушку методами социальной инженерии?

Тестирование

В основе науки о практичности лежит тестирование. К сожалению, фирмы–разработчики такому тестированию не уделяют много внимания. При тестировании практичности пользователи обычно работают парами (метод обсуждения вслух). Они самостоятельно исследуют систему, часто в первый раз. При оценке безопасности можно применить такой же подход; главное, чтобы пользователь попробовал те функции, которые вас интересуют.

Обычно в ходе испытания пользователям предлагается набор заданий, но в их работу никто не вмешивается до тех пор, пока они не застрянут окончательно.

Основы тестирования практичности применимы и к безопасности, поэтому имеет смысл познакомиться с этой дисциплиной. Мы рекомендуем книгу 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 – вот она–то и позволит сделать что–то по–настоящему опасное. И ПОЖАЛУЙСТА, сопровождайте такие действия предупреждениями!