19 смертных грехов, угрожающих безопасности программ
Шрифт:
□ Используйте средства, предоставляемые операционной системой для безопасного хранения секретных данных.
□ Используйте подходящие разрешения, например в виде списков управления доступом (ACL), если приходится хранить секретные данные.
□ Стирайте секретные данные из памяти сразу после завершения работы с ними.
□ Очищайте память прежде, чем освобождать ее.
Не рекомендуется
□ Не создавайте объектов, доступных миру для записи, в Linux, Mac OS X и UNIX.
□ Не создавайте
□ He храните материал для ключей в демилитаризованной зоне. Такие операции, как цифровая подпись и шифрование, должны производиться за пределами демилитаризованной зоны.
□ Не «зашивайте» никаких секретных данных в код программы. Это относится к паролям, ключам и строкам соединения с базой данных.
□ Не создавайте собственных «секретных» алгоритмов шифрования.
Стоит подумать
□ Об использовании шифрования для хранения информации, которую нельзя надежно защитить с помощью ACL, и о подписании ее, чтобы исключить неавторизованное манипулирование.
□ О том, чтобы вообще не хранить секретных данных. Нельзя ли запросить их у пользователя во время выполнения?
Грех 13.
Утечка информации
Рекомендуется
□ Решите, кто должен иметь доступ к информации об ошибках и состоянии.
□ Пользуйтесь средствами операционной системы, в том числе списками ACL и разрешениями.
□ Пользуйтесь криптографическими средствами для защиты секретных данных.
Не рекомендуется
□ Не раскрывайте информацию о состоянии системы не заслуживающим доверия пользователям.
□ Не передавайте вместе с зашифрованными данными временные метки высокого разрешения. Если без временных меток не обойтись, уменьшите разрешение или включите их в состав зашифрованной полезной нагрузки (по возможности).
Стоит подумать
□ О применении менее распространенных защитных механизмов, встроенных в операционную систему, в частности о шифровании на уровне файлов.
□ Об использовании таких реализаций криптографических алгоритмов, которые препятствуют атакам с хронометражем.
□ Об использовании модели Белла–ЛаПадулы, предпочтительно в виде готового механизма.
Грех 14.
Некорректный доступ к файлам
Рекомендуется
□ Тщательно проверяйте, что вы собираетесь принять в качестве имени файла.
Не рекомендуется
□ Не принимайте слепо имя файла, считая, что оно непременно соответствует хорошему файлу. Особенно это относится к серверам.
Стоит подумать
□ О хранении временных файлов в каталоге, принадлежащем конкретному пользователю, а не в общедоступном. Дополнительное преимущество такого решения – в том, что приложение может работать с минимальными
привилегиями, поскольку всякий пользователь имеет полный доступ к собственному каталогу, тогда как для доступа к системным каталогам для временных файлов иногда необходимы привилегии администратора.Грех 15.
Излишнее доверие к системе разрешения сетевых имен
Рекомендуется
□ Применяйте криптографические методы для идентификации клиентов и серверов. Проще всего использовать для этой цели SSL.
Не рекомендуется
□ Не доверяйте информации, полученной от DNS–сервера, она ненадежна!
Стоит подумать
□ Об организации защиты по протоколу IPSec тех систем, на которых работает ваше приложение.
Грех 16.
Гонки
Рекомендуется
□ Пишите код, в котором нет побочных эффектов.
□ Будьте очень внимательны при написании обработчиков сигналов.
Не рекомендуется
□ Не модифицируйте глобальные ресурсы, не захватив предварительно замок.
Стоит подумать
□ О том, чтобы создавать временные файлы в области, выделенной конкретному пользователю, а не в области, доступной всем для записи.
Грех 17.
Неаутентифицированный обмен ключами
Рекомендуется
□ Уясните, что обмен ключами сам по себе часто не является безопасной процедурой. Необходимо также аутентифицировать остальных участников.
□ Применяйте готовые решения для инициализации сеанса, например SSL/ TLS.
□ Убедитесь, что вы разобрались во всех деталях процедуры строгой аутентификации каждой стороны.
Стоит подумать
□ О том, чтобы обратиться к профессиональному криптографу, если вы настаиваете на применении нестандартных решений.
Грех 18.
Случайные числа криптографического качества
Рекомендуется
□ По возможности пользуйтесь криптографическим генератором псевдослучайных чисел (CRNG).
□ Убедитесь, что затравка любого криптографического генератора содержит по меньшей мере 64, а лучше 128 битов энропии.
Не рекомендуется
□ Не пользуйтесь некриптографическими генераторами псевдослучайных чисел (некриптографические PRNG).
Стоит подумать
□ О том, чтобы в ситуациях, требующих повышенной безопасности, применять аппаратные генераторы псевдослучайных чисел.
Грех 19.
Неудобный интерфейс
Рекомендуется
□ Оцените, чего хочет пользователь в плане безопасности, и снабдите его информацией, необходимой для работы.