Используйте безопасные значения по умолчанию

Большинство пользователей использует настройки по умолчанию приложения и предполагает, что они безопасны. Если они должны сделать определенный выбор и принять многократные меры для создания программы безопасной, немногие сделают так. Поэтому настройки по умолчанию для Вашей программы должны быть максимально безопасными.

Например:

• Если Ваша программа запускает другие программы, она должна запустить их с минимальными полномочиями, которые они должны выполнить.

• Если Ваша программа поддерживает дополнительно соединение SSL, флажок должен быть проверен по умолчанию.

• Если Ваша программа выводит на экран пользовательский интерфейс, требующий, чтобы пользователь решил, выполнить ли потенциально опасное действие, опция по умолчанию должна быть безопасным выбором. Если нет никакого безопасного выбора, не должно быть никакого значения по умолчанию. (См. Инструкции по Элементу UI: Средства управления в Инструкциях по Интерфейсу пользователя OS X.)

И т.д.

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

Каждый раз, когда возможно, необходимо принять решения безопасности для пользователей: в большинстве случаев Вы знаете больше о безопасности, чем они делают, и если Вы не можете оценить доказательство для определения, какой выбор является самым безопасным, возможности являются пользователями, не будет в состоянии сделать так также.

Для детального обсуждения этой проблемы и тематического исследования, см. статью «Firefox and the Worry-Free Web» в Cranor и Garfinkel, Безопасности и Удобстве пользования: Разработка Защищенных систем, которые Могут Использовать Люди.

Оправдайте надежды пользователей для безопасности

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

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

Авторизация должна быть отзывной: если пользователь предоставит авторизацию кому-то, то пользователь обычно ожидает быть в состоянии отменить ту авторизацию позже. Каждый раз, когда возможно, Ваша программа должна не только сделать это возможным, она должна упростить делать. Если по некоторым причинам не будет возможно отменить авторизацию, необходимо ясно дать понять прежде, чем предоставить авторизацию. Необходимо также прояснить, что отмена авторизации не может инвертировать ущерб, уже нанесенный (если программа не обеспечивает возможность восстановления).

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

Как агент пользователя, необходимо тщательно избежать выполнять операции, которые пользователь не ожидает или предназначает. Например, избегите автоматически выполнять код, если он выполняет функции, которые явно не авторизовал пользователь.

Защитите все интерфейсы

Некоторые программы имеют многопользовательские интерфейсы, такие как графический интерфейс пользователя, интерфейс командной строки и интерфейс для удаленного доступа. Если какой-либо из этих интерфейсов требует аутентификации (такой как с паролем), то все интерфейсы должны потребовать его. Кроме того, если Вы требуете аутентификации через командную строку или удаленный интерфейс, уверены, что механизм аутентификации безопасен — не передают пароли в открытом тексте, например.

Файлы места в безопасных местах

Если Вы не шифруете весь вывод, расположение, где Вы сохранили файлы, имеет важные импликации безопасности. Например:

• FileVault может защитить корневой объем (или домашняя папка пользователя до OS X v10.7), но не другие расположения, где пользователь мог бы принять решение поместить файлы.

• Полномочия папки могут быть установлены таким способом, которым другие могут управлять своим содержанием.

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

Сделайте ясный выбор безопасности

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

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

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

Будьте чувствительны к факту, что немного пользователей являются специалистами по безопасности. Дайте столько же информации — в ясных, нетехнических условиях — по мере необходимости для них для создания обоснованного решения. В некоторых случаях могло бы быть лучше не дать им опцию изменения поведения по умолчанию.

Например, большинство пользователей не знает, каков цифровой сертификат, уже не говоря об импликациях принятия сертификата, подписанного неизвестными полномочиями. Поэтому это - вероятно, не хорошая идея позволить пользователю постоянно добавить сертификат привязки (сертификат, которому доверяют для подписания других сертификатов), если Вы не можете быть уверены, что пользователь может оценить законность сертификата. (Далее, если пользователь будет специалистом по безопасности, то они будут знать, как добавить сертификат привязки цепочке для ключей без справки Вашего приложения так или иначе.)

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

В часто заключенной в кавычки, но редко применяемой монографии Джером Сэлцер и Михаэль Шредер записали, что “Важно, что интерфейс пользователя разработан для простоты использования, так, чтобы пользователи обычно и автоматически применяли механизмы защиты правильно. Кроме того, до такой степени, что умственное изображение пользователя его целей защиты соответствует механизмы, которые он должен использовать, ошибки будут минимизироваться. Если он должен перевести свое изображение его потребностей защиты на радикально различный язык спецификации, он сделает ошибки”. (Сэлцер и Шредер, “Защита информации в Компьютерных системах”, Продолжения IEEE 63:9, 1975.)

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

• “Действительно ли Ваш компьютер физически безопасен, или действительно ли возможно, что у неавторизованного пользователя будет физический доступ к компьютеру?”

• “Ваш компьютер подключен к сети?”

От ответов пользователя можно определить, как лучше всего защитить данные. Если Вы не обеспечиваете «опытный» режим, не задавайте вопросы пользователя как следующее:

• “Вы хотите зашифровать свои данные, и если так, с который схема шифрования?”

• “Сколько времени должен использоваться ключ?”

• “Вы хотите разрешить доступ SSH к своему компьютеру?”

Эти вопросы не соответствуют представлению пользователем проблемы. Поэтому ответы пользователя на такие вопросы, вероятно, будут ошибочны. В этом отношении очень важно понять перспективу пользователя. Очень редко интерфейс, кажущийся простым или интуитивным программисту, фактически простому или обладающему интуицией средним пользователям.

Заключить Ka-ping в кавычки Yee (Проект взаимодействия с пользователем для Защищенных систем, в http://www .eecs.berkeley.edu/Pubs/TechRpts/2002/CSD-02-1184.pdf):

• Чтобы иметь возможность использования системы безопасно в мире ненадежного и иногда соперничающего программного обеспечения, пользователь должен быть уверен во всех следующих утверждениях:

• • Вещи не становятся небезопасными все собой. (Явная Авторизация)

  • Я могу знать, безопасны ли вещи. (Видимость)

  • Я могу сделать вещи более безопасными. (Revocability)

  • Я не принимаю решение сделать вещи небезопасными. (Путь Наименьшего сопротивления)

  • Я знаю то, что я могу сделать в системе. (Ожидаемая Возможность)

  • Я могу отличить вещи, имеющие значение для меня. (Надлежащие Границы)

  • Я могу сказать систему, что я хочу. (Выразительность)

  • Я знаю то, что я говорю системе делать. (Ясность)

  • Система защищает меня от того, чтобы быть дурачившимся. (Идентифицируемость, Доверяемый путь)

Для дополнительных подсказок считайте Диалоговые окна в Инструкциях по Интерфейсу пользователя OS X и Предупреждениях, Листах Действия и Модальных Представлениях в Инструкциях по Интерфейсу пользователя iOS.

Боритесь с социальными техническими атаками

С социальными техническими атаками особенно трудно бороться. В социальной технической атаке атакующий дурачит пользователя в выполняющийся код атаки или отказ от частной информации.

Стандартная форма социальной технической атаки упоминается как фишинг. Фишинг относится к созданию официально выглядящей электронной почты или веб-страницы, дурачащей пользователя в размышление, что они имеют дело с объектом, с которым они знакомы, таковы как банк, с которым у них есть учетная запись. Как правило, пользователь получает электронное письмо, сообщающее им, что существует что-то не так с их учетной записью и тем, чтобы давать команду им нажать на ссылку в электронном письме. Ссылка берет их к веб-странице, имитирующей реальный; т.е. это включает значки, формулировку и графические элементы, повторяющие тех, пользователь привык видеть на законной веб-странице. Пользователь проинструктирован для ввода такой информации как их номер социального страхования и пароль. Сделав так, пользователь бросил достаточно информации, чтобы позволить атакующему получать доступ к учетной записи пользователя.

Борьба с фишингом и другими социальными техническими атаками является трудной, потому что восприятие компьютера электронной почты или веб-страницы существенно отличается от того из пользователя. Например, рассмотрите электронную почту, содержащую ссылку на http://scamsite.example.com/ но в котором говорится в тексте ссылки Apple Web Store. С точки зрения компьютера URL соединяется с сайтом жульничества, но с точки зрения пользователя, она соединяется с интернет-магазином Apple. Пользователь не может легко сказать, что ссылка не приводит к расположению, которое они ожидают, пока они не будут видеть URL в своем браузере; компьютер так же не может решить, что текст ссылки вводит в заблуждение.

Еще более того, даже когда пользователь смотрит на фактический URL, компьютер и пользователь могут чувствовать URL по-другому. Набор символов Unicode включает много символов, выглядящих подобными или идентичными общим английским буквам. Например, российский глиф, объявленный как «r», точно походит на английский «p» во многих шрифтах, хотя это имеет различное значение Unicode. Эти символы упоминаются как омографы. Когда веб-браузеры начали поддерживать интернационализировавшие доменные имена (IDN), некоторые phishers устанавливают веб-сайты, выглядевшие идентичными законным, с помощью омографов в их веб-адресах для дурачения пользователей, заставляя думать, URL был корректен.

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

Например, для помехи атаке омографа доменного имени много браузеров выводят на экран интернационализировавшие доменные имена (IDN) в формате ASCII по имени «Punycode». Например, веб-сайт самозванца с URL http://www.apple.com/ это использует римский сценарий для всех символов за исключением буквы, для которого она использует символ кириллицы, выведен на экран как http://www.xn--pple-43d.com.

Различные браузеры используют различные схемы при решении, который интернационализировал доменные имена для показа и которые перевести. Например, Safari использует эту форму, когда URL содержит символы в двух или больше сценариях, не позволяющихся в том же URL, таком как символы кириллицы и традиционные символы ASCII. Другие браузеры рассматривают, является ли набор символов подходящим для языка пользователя по умолчанию. Все еще другие поддерживают whitelist реестров, активно предотвращающих такой спуфинг и использующих punycode для доменов из всех других реестров.

Для большего количества глубокого анализа проблемы более предложенные подходы к борьбе с ним и некоторым тематическим исследованиям, видят Безопасность и Удобство пользования: Разработка Защищенных систем, которые Люди Могут Использовать Cranor и Garfinkel.

Для узнавания больше о социальной технике в целом считайте Искусство Обмана: Управляя Человеком Безопасности Mitnick, Саймоном и Уозниэком.

Используйте безопасность APIs, когда возможно

Один способ избежать добавлять уязвимости системы обеспечения безопасности к Вашему коду состоит в том, чтобы использовать доступную безопасность APIs, когда это возможно. Платформа Интерфейса Безопасности API обеспечивает много ракурсов пользовательского интерфейса для поддержки обычно выполняемых задач защиты.

Платформа Интерфейса Безопасности API обеспечивает следующие представления:

• SFAuthorizationView класс реализует представление авторизации в окне. Представление авторизации является текстом значков блокировки и сопутствующим текстом, указывающим, может ли быть выполнена работа. Когда пользователь щелкает по закрытому значку блокировки, диалоговое окно авторизации выводит на экран. Как только пользователь авторизовывается, значок блокировки кажется открытым. Когда пользователь щелкает по открытой блокировке, Authorization Services ограничивает доступ снова и изменяет значок на закрытое состояние.

• SFCertificateView и SFCertificatePanel классы выводят на экран содержание сертификата.

• SFCertificateTrustPanel дисплеи класса и дополнительно позволяют пользователю отредактировать доверительные настройки в сертификате.

• SFChooseIdentityPanel класс выводит на экран список идентификационных данных в системе и позволяет пользователю выбрать ту. (В этом контексте идентификационные данные относятся к комбинации закрытого ключа и его связанного сертификата.)

• SFKeychainSavePanel класс добавляет интерфейс к приложению, позволяющему пользователю сохранить новую цепочку для ключей. Пользовательский интерфейс почти идентичен используемому для того, чтобы сохранить файл. Различие - то, что этот класс возвращает цепочку для ключей в дополнение к имени файла и позволяет пользователю указать пароль для цепочки для ключей.

• SFKeychainSettingsPanel класс выводит на экран интерфейс, позволяющий пользователю изменить настройки цепочки для ключей.

Документация для платформы Интерфейса Безопасности находится в Ссылке Платформы Интерфейса Безопасности.