19 смертных грехов, угрожающих безопасности программ
Шрифт:
□ Подлог (spoofing) . Противник представляет данные, как бы пришедшие от другого участника сеанса связи, хотя на самом деле данные подложные. Обычно для этого требуется открыть новое соединение, возможно, воспроизведя данные, посланные во время предыдущей аутентификации. В некоторых случаях такую атаку можно провести против уже существующего соединения, особенно когда виртуальное соединение устанавливается поверх транспортного протокола, не поддерживающего соединений (обычно UDP). Очень трудно (хотя и возможно) проделать такое с протоколами, требующими установления соединения, если операционная система должным образом рандомизирует
□ Вмешательство. Противник модифицирует передаваемые данные, возможно, вполне невинно, например заменяя единичный бит нулевым. В протоколах на базе TCP это довольно сложно из–за кодов циклической избыточности (CRC), но поскольку CRC–код не является криптографически безопасным, то такую защиту легко обойти, когда есть возможность поменять несколько битов, не оказывающих существенного влияния на обработку данных.
□ Перехват. Противник ждет момента установления соединения, а затем отрезает одного из участников, подменяя все исходящие от него данные своими. В наши дни внедрить новый трафик в середину сеанса или подделать существующий довольно трудно (по крайней мере, в случае использования протокола TCP и современных операционных систем на обоих концах), но все–таки возможно.
Если вас беспокоит безопасность сетевых соединений, то вы должны знать, какие услуги могут предоставлять приложения. Мы сначала поговорим о базовых службах, а потом – в разделе «Искупление греха» – о способе достижения цели. Как бы то ни было, для защиты от такого рода атак необходимо обеспечить три основных сервиса безопасности.
□ Начальная аутентификация. Необходимо гарантировать, что каждая сторона знает, с кем общается. Есть много способов добиться этого, но самыми распространенными являются пароли в силу своего удобства. Говоря о данном грехе, мы не будем затрагивать вопросы аутентификации, но еще вернемся к ним в грехах 10, 11 и 17.
□ Аутентификация во время сеанса. Даже если вы уверены в том, с кем начали общаться, хотелось бы удостовериться, что вы продолжаете обмен данными с тем же лицом. Это более строгий вариант обеспечения целостности сообщений. Легко убедиться в том, что пришло именно то сообщение, которое было отправлено, но неплохо бы знать еще, что его отправил законный пользователь, а не противник. Например, протокол TCP обеспечивает слабую проверку целостности сообщения, но никакой аутентификации.
□ Конфиденциальность. Это, наверное, наименее важный из сервисов безопасности. Есть немало ситуаций, когда нужно лишь гарантировать аутентичность данных, а шифровать их необязательно. Обычно не имеет смысла обеспечивать конфиденциальность без начальной и последующей аутентификации. Например, если противник пользуется потоковым шифром, например RC4 (у него есть также режимы работы, обеспечивающие блочное шифрование), то он может переставить случайные биты в шифртексте, и без надлежащей аутентификации сообщения об этом никто не узнает. Если противнику известен формат данных, то он сможет добиться и более разрушительного эффекта, поменяв конкретные биты.
Родственные грехи
Совсем несложно полностью игнорировать вопросы безопасности в сети. Но не менее просто воспользоваться сервисами безопасности неправильно, особенно это относится к протоколам Secure Sockets Layer и Transport Layer Security (SSL / TLS) (Грех 10). Аутентификация тоже является важной частью инфраструктуры сетевой безопасности и также
Где искать ошибку
Этот грех обычно проявляется, когда:
□ приложение пользуется сетью;
□ проектировщик не обращает внимания на риски, связанные с работой в сети, или недооценивает их.
Например, типичный аргумент звучит так: «мы ожидаем, что этот порт будет доступен только из части сети за межсетевым экраном». На практике в большинстве случаев нарушения безопасности так или иначе участвуют люди, причастные к работе компании, – недовольные, подкупленные или желающие оказать дружескую услугу сотрудники, уборщики, клиенты, поставщики, приехавшие осмотреть место развертывания своего продукта, и т. д. К тому же не так уж редко настройки межсетевого экрана не совпадают с ожидаемыми. А как вы думаете, сколько людей из–за неполадок с сетью временно отключают экран, а после устранения проблемы забывают его включить? В большой сети со многими точками входа представление о защищенной внутренней сети уже можно считать устаревшим. Такую сеть следует рассматривать как полуоткрытую, враждебную среду.
Выявление ошибки на этапе анализа кода
Если вы не задумывались о «площади атакуемой поверхности» приложения (в это понятие входят все точки входа в него), то следует заняться этим незамедлительно. В модели угроз, если таковая составлена, уже должны быть отражены точки входа. Как правило, сетевой трафик просто шифруется по протоколам SSL/TLS. Если это так, то в грехе 10 вы найдете рекомендации по устранению слабых мест.
В противном случае для каждой точки, которая может иметь выход в сеть, определите, какой механизм применяется для обеспечения конфиденциальности основного потока данных, начальной и последующей аутентификации. Иногда риск считается допустимым, хотя не предусматривается никакой защиты, особенно если частью системы является электронная почта.
Если какие–то сетевые соединения защищены, проверьте, работает ли защита, как задумано. Это может оказаться довольно сложно, поскольку требует глубоких знаний в области криптографии. Вот некоторые базовые рекомендации:
□ не занимайтесь реализацией криптографических решений самостоятельно. Пользуйтесь протоколом SSL или API на базе системы Kerberos, который Windows предоставляет в составе библиотек DCOM/RPC;
□ если вы не используете готового решения, то первым делом убедитесь в том, что конфиденциальность обеспечивается везде, где это необходимо. Обычно в программе не должно быть никаких путей, позволяющих отправить в сеть незашифрованные данные;
□ если основной поток данных шифруется с помощью пары ключей, то почти всегда наблюдается некое недопонимание. Криптография с открытыми ключами настолько неэффективна, что обычно используется лишь для шифрования случайных сеансовых ключей и необходимых для аутентификации данных, после чего эти ключи служат для симметричного шифрования. Если вы систематически применяете криптографию с открытыми ключами, то система легко может отказать в обслуживании из–за перегрузки. К тому же очень многое может пойти наперекосяк, особенно если длина открытого текста относительно велика. (Детали выходят за рамки данной книги, однако в разделе «Другие ресурсы» приведены ссылки на дополнительные источники информации.);