Приложение В. Сводка рекомендаций
В этом приложении сведены наши советы о том, что следует делать, чего не следует, а о чем стоит подумать. Мы решили включить его, потому что иногда разработчику во время написания программы хочется не читать всю книгу, а просто вспомнить, что надо и чего не надо делать.
Грех 1.
Переполнение буфера
Рекомендуется
□ Тщательно проверяйте любой доступ к буферу за счет использования безопасных функций для работы со строками и областями памяти.
□ Пользуйтесь встраиваемыми в компилятор средствами защиты, например флагом /GS и программой ProPolice.
□ Применяйте механизмы защиты от переполнения буфера на уровне операционной системы, например DEP и РаХ.
□ Уясните, какие данные контролирует противник, и обрабатывайте их безопасным образом.
Не рекомендуется
□ Не думайте, что компилятор и ОС все сделают за вас, это всего лишь дополнительные средства защиты.
□ Не используйте небезопасные функции в новых программах.
Стоит подумать
□ Об установке последней версии компилятора C/C++, поскольку разработчики включают в генерируемый код новые механизмы защиты.
□ О постепенном удалении небезопасных функций из старых программ.
□ Об использовании строк и контейнерных классов из библиотеки С++ вместо применения низкоуровневых функций С для работы со строками.
Грех 2.
Ошибки, связанные с форматной строкой
Рекомендуется
□ Пользуйтесь фиксированными форматными строками или считываемыми из заслуживающего доверия источника.
□ Проверяйте корректность всех запросов к локали.
Не рекомендуется
□ Не передавайте поступающие от пользователя форматные строки напрямую функциям форматирования.
Стоит подумать
□ О том, чтобы использовать языки высокого уровня, которые в меньшей степени уязвимы относительно этой ошибки.
Грех 3.
Переполнение целых чисел
Рекомендуется
□ Проверяйте на возможность переполнения все арифметические вычисления, в результате которых определяется размер выделяемой памяти.
□ Проверяйте на возможность переполнения все арифметические вычисления, в результате которых определяются индексы массивов.
□ Пользуйтесь целыми без знака для хранения смещений от начала массива и размеров блоков выделяемой памяти.
Не рекомендуется
□ Не думайте, что ни в каких языках, кроме C/C++, переполнение целого невозможно.
Грех 4.
Внедрение SQL–команд
Рекомендуется
□ Изучите базу данных, с которой работаете. Поддерживаются ли в ней хранимые процедуры? Как выглядит комментарий? Может ли противник получить доступ к расширенной функциональности?
□ Проверяйте корректность входных данных и устанавливайте степень доверия к ним.
□ Используйте параметризованные запросы (также распространены термины «подготовленное предложение» и «связывание параметров») для построения SQL–предложений.
□ Храните информацию о параметрах соединения вне приложения, например в защищенном конфигурационном файле или в реестре Windows.
Не рекомендуется
□ Не ограничивайтесь простой фильтрацией «плохих слов». Существует множество вариантов написания, которые вы не в состоянии обнаружить.
□ Не доверяйте входным данным при построении SQL–предложения.
□ Не используйте конкатенацию строк для построения SQL–предложения даже при вызове хранимых процедур. Хранимые процедуры, конечно, полезны, но решить проблему полностью они не могут.
□ Не используйте конкатенацию строк для построения SQL–предложения внутри хранимых процедур.
□ Не передавайте хранимым процедурам непроверенные параметры.
□ Не ограничивайтесь простым дублированием символов одинарной и двойной кавычки.
□ Не соединяйтесь с базой данных от имени привилегированного пользователя, например sa или root.
□ Не включайте в текст программы имя и пароль пользователя, а также строку соединения.
□ Не сохраняйте конфигурационный файл с параметрами соединения в корне Web–сервера.
Стоит подумать
□ О том, чтобы запретить доступ ко всем пользовательским таблицам в базе данных, разрешив лишь исполнение хранимых процедур. После этого во всех запросах должны использоваться только хранимые процедуры и параметризованные предложения.
Грех 5.
Внедрение команд
Рекомендуется
□ Проверяйте все входные данные до передачи их командному процессору.
□ Если проверка не проходит, обрабатывайте ошибку безопасно.
Не рекомендуется
□ Не передавайте непроверенные входные данные командному процессору, даже если полагаете, что пользователь будет вводить обычные данные.
□ Не применяйте подход «все кроме», если не уверены на сто процентов, что учли все возможности.
Стоит подумать
□ О том, чтобы не использовать регулярные выражения для проверки входных данных; лучше написать простую и понятную процедуру проверки вручную.
Грех 6.
Пренебрежение обработкой ошибок
Рекомендуется
□ Проверяйте значения, возвращаемые любой функцией, относящейся к безопасности.
□ Проверяйте значения, возвращаемые любой функцией, которая изменяет параметры, относящиеся к конкретному пользователю или машине в целом.
□ Всеми силами постарайтесь восстановить нормальную работу программы после ошибки, не допускайте отказа от обслуживания.
Не рекомендуется
□ Не перехватывайте все исключения без веской причины, поскольку таким образом можно замаскировать ошибки в программе.
□ Не допускайте утечки информации не заслуживающим доверия пользователям.
Грех 7.
Кросс–сайтовые сценарии
Рекомендуется
□ Проверяйте корректность всех входных данных, передаваемых Web–приложению.
□ Подвергайте HTML–кодированию любую выводимую информацию, формируемую на основе поступивших входных данных.
Не рекомендуется
□ Не копируйте ввод в вывод без предварительной проверки.
□ Не храните секретные данные в куках.
Стоит подумать
□ Об использовании как можно большего числа дополнительных защитных мер.
Грех 8.
Пренебрежение защитой сетевого трафика
Рекомендуется
□ Пользуйтесь стойкими механизмами аутентификации.
□ Аутентифицируйте все сообщения, отправляемые в сеть вашим приложением.
□ Шифруйте все данные, которые должны быть конфиденциальны. Лучше перестраховаться.
□ Если возможно, передавайте весь трафик по каналу, защищенному SSL/ TLS. Это работает!
Не рекомендуется
□ Не отказывайтесь от шифрования данных из соображений производительности. Шифрование на лету обходится совсем недорого.
□ Не «зашивайте» ключи в код и ни в коем случае не думайте, что 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. Их следует хранить в специальном аппаратном устройстве, предназначенном исключительно для формирования цифровой подписи.
□ Используйте средства, предоставляемые операционной системой для безопасного хранения секретных данных.
□ Используйте подходящие разрешения, например в виде списков управления доступом (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).
Стоит подумать
□ О том, чтобы в ситуациях, требующих повышенной безопасности, применять аппаратные генераторы псевдослучайных чисел.
Грех 19.
Неудобный интерфейс
Рекомендуется
□ Оцените, чего хочет пользователь в плане безопасности, и снабдите его информацией, необходимой для работы.
□ По возможности делайте конфигурацию по умолчанию безопасной.
□ Выводите простые и понятные сообщения, но предусматривайте прогрессивное раскрытие информации для более опытных пользователей и администраторов.
□ Сообщения об угрозах безопасности должны предлагать какие–то действия.
Не рекомендуется
□ Избегайте заполнять огромные диалоговые окна техническими подробностями. Ни один пользователь не станет это читать.
□ Не показывайте пользователю дорогу к самоубийству, упрятывайте подальше параметры, которые могут оказаться опасными!
Стоит подумать
□ Об избирательном ослаблении политики безопасности, но ясно и недвусмысленно объясняйте пользователю, к каким последствиям ведут его действия.
Хотя операции в самом языке Visual Basic, может быть, и неуязвимы для переполнения целого, но потенциальная проблема состоит в том, что вызовы Win32 API обычно принимают в качестве параметров 32–разрядные целые без знака (DWORD). Если ваша программа передает системному вызову 32–разрядное целое со знаком, то в ответ может получить отрицательное число. Аналогично вполне допустимо выполнить такую операцию, как 2 – 8046, над числами со знаком, но что, если указать в качестве одного из операндов такое число без знака, чтобы возникло переполнение? Если системный вызов возвращает некоторое значение, а потом вы выполняете манипуляции над этим значением и величиной, прямо или косвенно (после тех или иных вычислений) полученной от пользователя, и напоследок обращаетесь к другим системным вызовам, то можете оказаться в угрожаемой ситуации. Переходы от знаковых чисел к беззнаковым и обратно чреваты опасностью. Даже если переполнение целого и не приведет к исполнению произвольного кода, необработанные исключения станут причиной отказа от обслуживания. Неработающее приложение не приносит доходов заказчику.Греховность JavaВ отличие от Visual Basic и С#, в язык Java не встроена защита от переполнений. Вот цитата из спецификации языка «Java Language Specification*, размещенной по адресу http://java.sun.com/docs/books/jls/second_edition/html/typeValues.doc.html#9151: 
Правильно ли затравлен CRNG–генераторЕсли затравку для CRNG–генератора формирует система, то риска, скорее всего, нет. Но в языке типа Java, где API не пользуется системным генератором или не задействует CRNG напрямую, у вас может быть возможность задать затравку самостоятельно. И этим часто пользуются хотя бы для того, чтобы ускорить инициализацию. (В Java это случается часто, поскольку инициализация класса SecureRan–dom происходит довольно медленно; см. раздел «Java» ниже в этой главе.)Есть и другая крайность – когда затравка фиксирована. В таком случае систему следует считать небезопасной. Если затравка хранится в файле и периодически обновляется значением, которое выработано генератором, то безопасность зависит от того, насколько хороша была первоначальная затравка и насколько надежно защищен файл.Если используется код для получения энтропии сторонней фирмы, то степень риска определить сложно. (Теория энтропии находится за рамками данной книги.) Хотя в таких случаях риск может быть невелик, все же, если есть возможность воспользоваться системным генератором, мы рекомендуем так и поступить.Есть лишь два случая, когда такой возможности нет, – это необходимость повторно воспроизвести поток случайных чисел (встречается очень редко) и работа с операционной системой, не поддерживающей такого механизма (в наши дни это разве что некоторые встраиваемые системы). 
