Читать онлайн «19 смертных грехов, угрожающих безопасности программ». Страница 62

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

□ Проверяйте, что в соответствующем поле сертификата партнера записано ожидаемое имя хоста.

Не рекомендуется

□ Не пользуйтесь протоколом SSL2. В нем имеются серьезные криптографические дефекты.

□ Не полагайтесь на то, что используемая вами библиотека для работы с SSL/TLS надлежащим образом выполнит все проверки, если только речь не идет о протоколе HTTPS.

□ Не ограничивайтесь проверкой одного лишь имени (например, в поле DN), записанного в сертификате. Кто угодно может создать сертификат и вписать туда произвольное имя.

Стоит подумать

□ О применении протокола OCSP для проверки сертификатов в цепочке доверия, чтобы убедиться, что ни один из них не был отозван.

□ О загрузке свежей версии CRL–списка после окончания срока действия текущего и об использовании этих списков для проверки сертификатов в цепочке доверия.

Грех 11.

Использование слабых систем на основе паролей

Рекомендуется

□ Гарантируйте невозможность считывания пароля с физической линии во время аутентификации (например, путем защиты канала по протоколу SSL/TLS).

□ Выдавайте одно и то же сообщение при любой неудачной попытке входа, какова бы ни была ее причина.

□ Протоколируйте неудачные попытки входа.

□ Используйте для хранения паролей одностороннюю функцию хэширования с затравкой криптографического качества.

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

Не рекомендуется

□ Усложните процедуру переустановки пароля по телефону сотрудником службы поддержки.

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

□ Не храните пароли в открытом виде на сервере.

□ Не «зашивайте» пароли в текст программы.

□ Не протоколируйте неправильно введенные пароли.

□ Не допускайте коротких паролей.

Стоит подумать

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

□ О многофакторной аутентификации.

□ Об использовании протоколов с нулевым знанием, которые снижают шансы противника на проведение успешной атаки с полным перебором.

□ О протоколах с одноразовым паролем для доступа из не заслуживающих доверия систем.

□ О программной проверке качества пароля.

□ О том, чтобы посоветовать пользователю, как выбрать хороший пароль.

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

Грех 12.

Пренебрежение безопасным хранением и защитой данных

Рекомендуется

□ Думайте, какие элементы управления доступом ваше приложение применяет к объектам явно, а какие наследует по умолчанию.

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

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

□ Используйте подходящие разрешения, например в виде списков управления доступом (ACL), если приходится хранить секретные данные.

□ Стирайте секретные данные из памяти сразу после завершения работы с ними.

□ Очищайте память прежде, чем освобождать ее.

Не рекомендуется

□ Не создавайте объектов, доступных миру для записи, в Linux, Mac OS X и UNIX.

□ Не создавайте объектов со следующими записями АСЕ: Everyone (Full Control) или Everyone (Write).

□ He храните материал для ключей в демилитаризованной зоне. Такие операции, как цифровая подпись и шифрование, должны производиться за пределами демилитаризованной зоны.

□ Не «зашивайте» никаких секретных данных в код программы. Это относится к паролям, ключам и строкам соединения с базой данных.

□ Не создавайте собственных «секретных» алгоритмов шифрования.

Стоит подумать

□ Об использовании шифрования для хранения информации, которую нельзя надежно защитить с помощью ACL, и о подписании ее, чтобы исключить неавторизованное манипулирование.

□ О том, чтобы вообще не хранить секретных данных. Нельзя ли запросить их у пользователя во время выполнения?

Грех 13.

Утечка информации

Рекомендуется

□ Решите, кто должен иметь доступ к информации об ошибках и состоянии.

□ Пользуйтесь средствами операционной системы, в том числе списками ACL и разрешениями.

□ Пользуйтесь криптографическими средствами для защиты секретных данных.

Не рекомендуется

□ Не раскрывайте информацию о состоянии системы не заслуживающим доверия пользователям.

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

Стоит подумать

□ О применении менее распространенных защитных механизмов, встроенных в операционную систему, в частности о шифровании на уровне файлов.

□ Об использовании таких реализаций криптографических алгоритмов, которые препятствуют атакам с хронометражем.

□ Об использовании модели Белла–ЛаПадулы, предпочтительно в виде готового механизма.

Грех 14.

Некорректный доступ к файлам

Рекомендуется

□ Тщательно проверяйте, что вы собираетесь принять в качестве имени файла.

Не рекомендуется

□ Не принимайте слепо имя файла, считая, что оно непременно соответствует хорошему файлу. Особенно это относится к серверам.

Стоит подумать

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

Грех 15.

Излишнее доверие к системе разрешения сетевых имен

Рекомендуется

□ Применяйте криптографические методы для идентификации клиентов и серверов. Проще всего использовать для этой цели SSL.

Не рекомендуется

□ Не доверяйте информации, полученной от DNS–сервера, она ненадежна!

Стоит подумать

□ Об организации защиты по протоколу IPSec тех систем, на которых работает ваше приложение.

Грех 16.

Гонки

Рекомендуется

□ Пишите код, в котором нет побочных эффектов.

□ Будьте очень внимательны при написании обработчиков сигналов.

Не рекомендуется

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

Стоит подумать

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

Грех 17.

Неаутентифицированный обмен ключами

Рекомендуется

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

□ Применяйте готовые решения для инициализации сеанса, например SSL/ TLS.

□ Убедитесь, что вы разобрались во всех деталях процедуры строгой аутентификации каждой стороны.

Стоит подумать

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

Грех 18.

Случайные числа криптографического качества

Рекомендуется

□ По возможности пользуйтесь криптографическим генератором псевдослучайных чисел (CRNG).

□ Убедитесь, что затравка любого криптографического генератора содержит по меньшей мере 64, а лучше 128 битов энропии.

Не рекомендуется

□ Не пользуйтесь некриптографическими генераторами псевдослучайных чисел (некриптографические PRNG).

Стоит подумать

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