Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
Если вы решите предоставить параметры, позволяющие ослабить безопасность, то мы рекомендуем запрятать их подальше. Не вручайте пользователю мыло и веревку! Считается, что средний пользователь не станет щелкать мышью больше трех раз, чтобы найти нужный параметр. Упрячьте такие параметры поглубже в интерфейсе конфигурации. Например, вместо того чтобы включать в диалоговое окно вкладку Security (Безопасность), сделайте вкладку Advanced (Дополнительно), а уже на ней – кнопку Security. При нажатии этой кнопки откройте окно, в котором будут отображаться текущие значения параметров безопасности, средства для конфигурирования протоколов и другие безвредные вещи. И поместите еще одну кнопку Advanced – вот она–то и позволит сделать что–то по–настоящему опасное. И ПОЖАЛУЙСТА, сопровождайте такие действия предупреждениями!
Упрощайте избирательное ослабление политики безопасности
Обеспечив максимальную безопасность по умолчанию, можете добавить немного гибкости, чтобы пользователь смог избирательно ослабить политику безопасности, не открывая брешей всему миру.
Хороший пример такого рода – это идея «Информационной панели» (Information Bar), небольшой области состояния, добавленной к Internet Explorer в Windows ХР SP2 (позже ее позаимствовал Firefox). Она находится сразу под строкой ввода адреса и информирует пользователя о текущих политиках безопасности. Например, браузер не спрашивает, хочет ли пользователь разрешить выполнение активного или мобильного кода, а просто запрещает, но информирует об этом. В этот момент пользователь может при желании изменить политику (если, конечно, имеет на это право), но по умолчанию предпринимается безопасное действие. Пользователю не надо думать о доверии, система безопасна, но сообщает, если происходит что–то необычное. Информационная панель показана на рис. 19.3.
Рис. 19.3. Информационная панель в Internet Explorer
Ясно описывайте последствия
Если пользователь поставлен перед необходимостью принять решение об ослаблении политики безопасности (например, дать разрешение на использование ресурса кому–то еще или рискнуть загрузить какой–то один потенциально небезопасный файл), то вы должны ясно обрисовать, чем это грозит! То же самое относится к случаю, когда пользователя надо информировать о произошедшем событии, касающемся безопасности, хотя напрямую оно с его действиями не связано.
Сообщение об опасности не должно быть перегружено техническими подробностями. Например, одна из многих причин, по которым обсуждавшееся выше окно с информацией о сертификате – это никуда не годный механизм ослабления политики безопасности, состоит как раз в том, что содержащиеся в нем сведения совершенно невразумительны. Другая серьезная проблема заключается в том, что на основании этой информации нельзя предпринять никаких действий, но об этом ниже.
Мы рекомендуем выводить короткое сообщение об ошибке, а подробности показывать, только если пользователь попросит. Это называется прогрессивным раскрытием информации. Не обременяйте пользователя или администратора ненужной и непонятной информацией, захотят – сами попросят.
В качестве удачных примеров можно привести то, как браузеры Internet Explorer и Firefox выводят информацию о сертификатах корневых УЦ. На рис. 19.4 показано, как Internet Explorer отображает сертификат и предлагает его установить. Если вам нужна дополнительная информация, а если честно, нужна она только знающим пользователям, то достаточно перейти на вкладку Details (Детали) или Certification Path (Перечень сертификатов). Вкладки – это превосходный механизм прогрессивного раскрытия информации.
Отметим, что показанное на рисунке диалоговое окно Internet Explorer – это стандартный диалог операционной системы, его можно вызвать с помощью функции CryptUIDlgViewCertificate:...int wmain(int argc, wchar_t* argv[]) {
wchar_t *wszFilename = NULL;
if (argc == 2) {
wszFilename = argv[1];
} else {
return -1;
}
PCERT_CONTEXT pCertContext = NULL;
BOOL fRet = CryptQueryObject(CERT_QUERY_OBJECT_FILE,
wszFilename,
CERT_QUERY_CONTENT_FLAG_ALL,
CERT_QUERY_FORMAT_FLAG_ALL
0,
NULL, NULL, NULL, NULL, NULL,
(const vois **) &pCertContext);
if (fRet && pCertContext) {
CRYPTUI_VIEWCERTIFICATE_STRUCT cvs;
memset(&cvs, 0, sizeof(cvs));
cvs.dwSize = sizeof(cvs);
cvs.pCertContext = pCertContext;
CryptUIDlgViewCertificate(&cvs, NULL);
} else {
// Не удалось загрузить сертификат
// Код ошибки в GetLastError
}
if (pCertContext) {
CertFreeCertificateContext(pCertContext);
pCertContext = NULL; // считайте меня параноиком!
}
return 0;
}
В Firefox есть аналогичный набор диалоговых окон, они показаны на рис. 19.5 и 19.6. Правда, рассчитаны они на чуть более технически подготовленного пользователя.
Рис. 19.4. Диалоговое окно для показа сертификата в Internet Explorer
Рис. 19.5. Диалоговое окно для загрузки сертификата в Firefox
Рис. 19.6. Диалоговое окно для просмотра сертификата в Firefox
Помогайте пользователю предпринять действия
Ну хорошо, вы сообщили пользователю о возникновении проблемы, угрожающей безопасности. А дальше–то что? Пользователь может что–то предпринять? Быть может, заглянуть в протокол или прочитать какую–то онлайновую статью? Помогите человеку решить проблему, не оставляйте его в недоумении.
Повторим – это относится лишь к случаю, когда вы просто обязаны что–то показать пользователю.
Вернемся к рассмотренному выше примеру HTTPS. Пусть вы придумали понятный способ сказать пользователю, что сайт, на который он сейчас зайдет, – совсем не тот, куда он намеревался попасть (то есть имена в сертификатах не совпадают). И что вы порекомендуете? Можно, конечно, предложить попробовать еще раз, но проблема, скорее всего, никуда не денется, по крайней мере не так скоро. Можете посоветовать обратиться к администратору, но тот, зная о данной конкретной проблеме, вероятно, просто скажет «жми ОК», не понимая, что пользователь отныне вообще перестанет отличать реальные сайты от поддельных.
Вывод таков: не существует очевидного способа известить пользователя о возникшей ситуации и предложить какой–то выход. Поэтому, наверное, лучше всего не говорить прямо о том, что произошло, а выдать какую–нибудь ошибку общего вида, свидетельствующую о недоступности сервера.
Предусматривайте централизованное управление
Реализуйте какой–нибудь механизм управления своим приложением, предпочтительно с использованием средств операционной системы. Именно поэтому так популярны групповые политики, хранящиеся в Windows в Active Directory, ведь они экономят администраторам массу времени. С единой консоли можно управлять многочисленными параметрами приложения и ОС.Другие ресурсы
□ Usability Engineering by Jacob Nielson (Morgan Kaufman, 1994)
□ Сайт Джекоба Нильсона, посвященный инженерным аспектам практичности: www.useit.com
□ 10 Immutable Laws of Security: www.microsoft.com/teclmet/archive/community/ columns/security/essays/lOsalaws.mspx
□ «10 Immutable Laws of Security Administrartion» by Scott Culp: www.microsoft. com/technet/archive/community/columns/security/essays/lOsalaws.mspx
□ «Writing Error Messages for Security Features» by Everett McKay: http://msdn. microsoft.com/library/en–us/dnsecure/html/security errormessages.asp
□ «Why Johny Can't Encrypt: A Usability Evaluation of PGP5.0» by Alma Whitten and J.D.Tygar: www.usenix.org/publicationd/library/proceedings/ sec99/full_papers/whitten/whitten_html/index.html
□ «Usability of Security: A Case Study» by Alma Whitten and J.D.Tygar: reports–archive.adm.cs.cmu.edu/anon/1998/CMU_CS–98–155.pdf
□ «Are Usability and Security Two Opposite Directions in Computer Systems?» by Konstantin Rozinov: http://rozinov.sfs.poly.edu/papers/security_vs_ usability.pdf
□ Use the Internet Explorer Information Bar: www.microsoft.com/windowsxp/ using/web/sp2_infobar.mspx
□ IEEE Security and Privacy September–October 2004: http://csdl. computer. org/comp/mags/sp/2004/05/j5toc.htm
□ Introduction to Group Policy in Windows Server 2003: www.microsoft.com/ windowsserver2003/techinfo/overview.mspx
Резюме
Рекомендуется
□ Оцените, чего хочет пользователь в плане безопасности, и снабдите его информацией, необходимой для работы.
□ По возможности делайте конфигурацию по умолчанию безопасной.
□ Выводите простые и понятные сообщения, но предусматривайте прогрессивное раскрытие информации для более опытных пользователей и администраторов.
□ Сообщения об угрозах безопасности должны предлагать какие–то действия.
Не рекомендуется
□ Избегайте заполнять огромные диалоговые окна техническими подробностями. Ни один пользователь не станет это читать.
□ Не показывайте пользователю дорогу к самоубийству, прячьте подальше параметры, которые могут оказаться опасными!
Стоит подумать
□ Об избирательном ослаблении политики безопасности, но при этом ясно и недвусмысленно объясняйте пользователю, к каким последствиям ведут его действия.
Приложения
Приложение А. Соответствие между 19 смертными грехами и «10 ошибками» OWASP
В январе 2004 года организация «Открытый проект по безопасности Web–приложений» (Open Web Application Security Project – OWASP) опубликовала документ, озаглавленный «Десять самых критичных уязвимостей Web–приложений» (www.owasp.org/documentation/topten.html). Ниже 19 описанных в этой книге грехов сопоставляются с тем, что перечислены в документа OWASP.
