19 смертных грехов, угрожающих безопасности программ
Шрифт:
□ Не храните секретные данные в куках.
Стоит подумать
□ Об использовании как можно большего числа дополнительных защитных мер.
Грех 8.
Пренебрежение защитой сетевого трафика
Рекомендуется
□ Пользуйтесь стойкими механизмами аутентификации.
□ Аутентифицируйте все сообщения, отправляемые в сеть вашим приложением.
□ Шифруйте все данные, которые должны быть конфиденциальны. Лучше перестраховаться.
□ Если возможно,
Не рекомендуется
□ Не отказывайтесь от шифрования данных из соображений производительности. Шифрование на лету обходится совсем недорого.
□ Не «зашивайте» ключи в код и ни в коем случае не думайте, что XOR с фиксированной строкой можно считать механизмом шифрования.
□ Не игнорируйте вопросы защиты данных в сети.
Стоит подумать
□ Об использовании технологий уровня сети, способных еще уменьшить риск. Речь идет о межсетевых экранах, виртуальных частных сетях (VPN) и балансировании нагрузки.
Грех 9.
Применение загадочных URL и скрытых полей форм
Рекомендуется
□ Проверяйте все данные, поступающие из Web, в том числе и посредством форм, на признаки злоумышленности.
□ Изучите сильные и слабые стороны применяемого вами подхода, если вы не пользуетесь криптографическими примитивами.
Не рекомендуется
□ Не встраивайте конфиденциальные данные в HTTP–заголовки и в HTML–страницы, в том числе в URL, куки и поля форм, если канал не шифруется с помощью таких технологий, как SSL, TLS или IPSec, или данные не защищены криптографическими средствами.
□ Не доверяйте никаким данным в Web–форме, поскольку злоумышленник может легко подставить любые значения вне зависимости от того, используется SSL или нет.
□ Не думайте, что приложение защищено, коль скоро вы применяете криптографию: противник может атаковать систему другими способами. Например, он не станет угадывать случайные числа криптографического качества, а просто попытается подсмотреть их.
Грех 10.
Неправильное применение SSL и TLS
Рекомендуется
□ Пользуйтесь последней версией SSL/TLS. В порядке предпочтительности: TLS 1.1, TLS 1.0hSSL3.
□ Если это имеет смысл, применяйте списки допустимых сертификатов.
□ Прежде чем посылать данные, убедитесь, что сертификат партнера можно проследить до доверенного УЦ и что его срок действия не истек.
□ Проверяйте, что в соответствующем поле сертификата партнера записано ожидаемое имя хоста.
Не рекомендуется
□ Не пользуйтесь протоколом SSL2. В нем имеются серьезные криптографические дефекты.
□ Не полагайтесь на то, что используемая вами библиотека для работы с SSL/TLS надлежащим образом выполнит все проверки, если только речь не идет о протоколе HTTPS.
□ Не ограничивайтесь проверкой одного лишь имени (например, в поле DN), записанного
в сертификате. Кто угодно может создать сертификат и вписать туда произвольное имя.Стоит подумать
□ О применении протокола OCSP для проверки сертификатов в цепочке доверия, чтобы убедиться, что ни один из них не был отозван.
□ О загрузке свежей версии CRL–списка после окончания срока действия текущего и об использовании этих списков для проверки сертификатов в цепочке доверия.
Грех 11.
Использование слабых систем на основе паролей
Рекомендуется
□ Гарантируйте невозможность считывания пароля с физической линии во время аутентификации (например, путем защиты канала по протоколу SSL/TLS).
□ Выдавайте одно и то же сообщение при любой неудачной попытке входа, какова бы ни была ее причина.
□ Протоколируйте неудачные попытки входа.
□ Используйте для хранения паролей одностороннюю функцию хэширования с затравкой криптографического качества.
□ Обеспечьте безопасный механизм смены пароля человеком, который знает пароль.
Не рекомендуется
□ Усложните процедуру переустановки пароля по телефону сотрудником службы поддержки.
□ Не поставляйте систему с учетными записями и паролями по умолчанию. Вместо этого реализуйте процедуру инициализации, которая позволит задать пароль для записи по умолчанию в ходе инсталляции или при первом запуске приложения.
□ Не храните пароли в открытом виде на сервере.
□ Не «зашивайте» пароли в текст программы.
□ Не протоколируйте неправильно введенные пароли.
□ Не допускайте коротких паролей.
Стоит подумать
□ Об использовании алгоритма типа PBKDF2, который увеличивает время вычисления односторонней свертки.
□ О многофакторной аутентификации.
□ Об использовании протоколов с нулевым знанием, которые снижают шансы противника на проведение успешной атаки с полным перебором.
□ О протоколах с одноразовым паролем для доступа из не заслуживающих доверия систем.
□ О программной проверке качества пароля.
□ О том, чтобы посоветовать пользователю, как выбрать хороший пароль.
□ О реализации автоматизированных способов переустановки пароля, в частности путем отправки временного пароля по почте в случае правильного ответа на «личный вопрос».
Грех 12.
Пренебрежение безопасным хранением и защитой данных
Рекомендуется
□ Думайте, какие элементы управления доступом ваше приложение применяет к объектам явно, а какие наследует по умолчанию.
□ Осознайте, что некоторые данные настолько секретны, что никогда не должны храниться на промышленном сервере общего назначения, например долгосрочные закрытые ключи для подписания сертификатов Х.509. Их следует хранить в специальном аппаратном устройстве, предназначенном исключительно для формирования цифровой подписи.