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

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

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

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

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

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

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

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

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

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

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

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

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

Грех 13.

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

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

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

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

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

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

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

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

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

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

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

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

Грех 14.

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

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

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

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

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

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

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

Грех 15.

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

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

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

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

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

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

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

Грех 16.

Гонки

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

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

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

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

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

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

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