WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |   ...   | 10 |

«Michael Howard David LeBlank WRITING SECURE CODE Second Edition Press Майкл Ховард Дэвид Лебланк ЗАЩИЩЕННЫЙ код 2-е издание, исправленное Москва 2004 УДК 004.45 ББК 32.973.26-018.2 Х68 ...»

-- [ Страница 7 ] --

Так как же бороться с /robust В Windows 2000 появилась возможность компиляции (Microsoft Interface Definition Language) с параметром /robust. Она позволяет выполнить динамическую проверку на вход службы маршалинга RPC сервера. Это увеличивает стабильность сервера, так как при этом отклоняется больше некорректных пакетов, в старых версиях Чрезвычайно важно, чтобы отклонял все некорректные пакеты.

Если приложение предназначено для работы в Windows 2000 и последующих ОС, обязательно применяйте этот параметр компилятора. При этом не придется ничего менять в исходном коде клиента или сервера. Единственный — такая возможность доступна только с Windows 2000. Если необходимо обеспечить совместимость и с Windows 4, придется создать две версии сер вера: для работы в Windows NT 4 и для Windows 2000 и последующих ОС. Приме нить параметр проще простого: просто добавьте /robust в командную строку вызова MIDL-компилятора.

Примечание Преимущества использования /robust огромны, поэтому действительно стоит создать два варианта сервера.

Атрибут [range] Он используется в для изменения значений важных параметров или например необходимых для хранения размера или длины. Так, лятор описать размер большого двоичного объекта (blob) данных:

void long [in] long Теоретически злоумышленник может присвоить переменным lo и hi значения, не вписывающиеся в рамки разрешенного диапазона, и нарушить работу сервера или Для снижения вероятности реализации такой атаки и предусмотрен ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов DCOM В следующем примере значения переменных /о и должны ходиться в диапазоне 0 — а это означает, что длина данных, на указывает не может превышать 1023 байта.

void Hessage([in, [in, long hi, [size_is(lo, char **ppData);

Заметьте: для создания кода выполняющего такую проверку, при компиляции необходимо использовать параметр Кроме того, в этом случае проверка того, действительно ли больше полностью возложе на на сервер.

Применяйте аутентификацию подключений Предотвратить DoS-атаки очень просто — заставьте клиентов фикацию. Представьте сервер, принимающий запросы клиентов и имеющий режима работы. В первом он принимает данные от всех подряд без подлинности, поэтому все от клиентов данные считаются аноним ными. Во втором режиме перед приемом данных проводится пользователя, данные, поступающие от не прошедших аутентификацию клиентов, отбрасываются. В каком режиме риск успешной DoS-атаки выше? Ответ в первом, анонимном варианте, так как в этом случае нечего противопоставить действиям анонимного злоумышленника. Если атакующий знает, что для совер атаки придется представиться, маловероятно, что он станет предпринимать враждебные действия! Так что поддерживайте на своих только подключения.

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

При добавлении методов защиты на более поздних (в отличие от встраивания их в приложение с самого начала) часто применяют следующий подход: в переходный период (па время обновления клиентской час ти) сервер принимает оба типа подключений. Затем постепенно поддержка не про ходящих аутентификацию подключений блокируется. Ясно, что наиболее безо пасный вариант — реализовать безопасность с самого начала.

Конфигурация клиента Для определения политик аутентификации, конфиденциальности и попыток модификации данных в клиентской части приложения следует задейство вать функцию Вот пример из упоминавшегося прило жения-телефона.

status = Часть III Дополнительные методы создания защищенного кода szSPN, // Для поддержки Kerberos SPN сервера.

NULL, 0);

Второй аргумент, szSPN, определяет основное имя службы (service principal name, SPN), о котором я расскажу чуть позднее. Третьему присво ено значение это означает, что данные, ко торыми обмениваются клиент и сервер шифруются, проходят аутентификацию и проверку на целостность и неизменность. В табл. 1б-2 указаны возможные зна чения уровня безопасности RPC.

Таблица 16-2. Уровни безопасности RPC Параметр Значение Примечание Устанавливается уровень безопасности службы DEFAULT по умолчанию. Лично я избегаю вариан та, ведь заранее какие параметры предусмотрены в службе. Возможно, это из-за того, что я слишком долго работаю в области информационной безопасности и предпочи таю понимать все происходящее В настоящее время значение по умолчанию для — 1 Аутентификация не выполняется. Настоятель но не рекомендую этот вариант 2 Аутентификация выполняется при первом CONNECT подключении клиента к серверу RPC С CALL 3 Аутентификация выполняется перед каждым Заметьте: если протокол поддер живает подключения (то есть его название на с это значение автоматичес ки превращается в I выполняется с целью убе диться в авторстве полученных данных 5 Действие параметра аналогично INTEGRITY но вдобавок прове ряется целостность данных 6 Аналогично PRIVACY но дополнительно данные шифруются Примечание Некоторые читатели заметят, что название аргумента — вводит в этот аргумент отвечает не только за аутентификацию, но и за целостность и конфиденциальность.

В итоге на стороне получаем такую картину: функция помещает идентификационную информацию клиента в описатель который при вызове удаленной процедуры передается серверу в каче стве первого параметра.

ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов DCOM Конфигурация сервера Для обеспечения подходящего уровня безопасности сперва создают серверный обработчик а затем конфигурация подключившегося клиента проверяется на соответствие заданному уровню безопасности.

Уровень аутентификации определяется функцией status = szSPN, NULL, Для наиболее важен второй аргумент, так как именно он определяет способ аутентификации клиента. Наиболее часто няется которое соответствует фикации. Однако, вместо этого значения в Windows 2000 и последующих ОС ре комендуется в этом случае способ выбирается автоматически из двух вариантов: и Существует еще один вариант - но предоставляет приложению больше свободы, позволяя ра ботать и в «старых» ОС, например Windows NT 4. Конечно, и злоумышленник по лучает больший простор в своих действиях: он может заставить использовать защищенный протокол Сервер извлекает информацию для аутентификации из описателя привязки клиента, вызвав в удаленной процедуре функцию При ж определяется используемый способ (NTLM или Kerberos) и желаемый уровень аутентификации (полное отсутствие аутентификации, аутентификация проверка целостности данных и т.п.). Вот небольшой пример.

// Функция со встроенным кодом проверки void unsigned { RPC_AUTHZ_HANDLE DWORD status = NULL, NULL, NULL);

if (status != RPC_S_OK> { вернула: status);

RpcRaiseException(ERROR_ACCESS_DENIED);

// Теперь проверим уровень аутентификации.

// Требуется как минимум аутентификация на уровне if (dwAuthn < { 420 Часть III Дополнительные методы создания защищенного кода запрашивает недостаточно надежный способ.

if != { не DWORD = 128;

if "Неизвестный поддерживает уровень аутентификации Xd\n", szMsg, Здесь выполняется ряд действий. Функция Message вызывается удаленно приложения-телефона. Сначала выясняется поддерживаемый уровень аутентифи кации вызовом функции и получением значения Если функция возвращает или же оказывается ниже требуемо го уровня безопасности, вызов завершается ошибкой, а инициирует исклю чение отказа в которое передается клиенту. При благоприятном исходе проверки производится вызывающего пользователя и определя ется его имя. Наконец, после отображения соответствующего сообщения испол вызова в контекст процесса.

Заметьте также, что здесь проверяются значения, возвращаемые всеми функ циями олицетворения. До Windows Server 2003 работа этих функций не вы зывала нареканий (обычно они завершались с ошибкой только из-за недостатка системной памяти или запрета олицетворения на системном уровне). Однако из за наличия в Windows Server 2003 новой привилегии Impersonate a client after authentication (олицетворение после такие ошибки будут возникать чаще, а именно в тех случаях, когда учетная запись процесса не обла дает этой привилегией.

Замечание о поддержке Kerberos Параметр используемый при вызове определяет ос новное имя сервера, необходимое для нормальной работы протокола Kerberos.

Помните: протокол Kerberos поддерживает взаимную клиента и сервера, a — только клиента. Проверка подлинности сервера предотвраща ет его подмену. Чтобы отключить поддержку Kerberos, установите параметр в NULL.

Значение этого параметра на стороне клиента определяется вызовом функции Она определена в и поэтому компонуется с библиотекой ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов Ntdsapi.dll. В следующем фрагменте кода демонстрируется использование DWORD cbSPN = MAX_PATH;

char szSPN[MAX_PATH + status = NULL, 0, NULL, szSPN);

Необходимо убедиться в что в серверном приложении используется то же ИМЯ:

SzSPN = NULL;

status = flpcServerInqDefaultPrincName( if (status != // Регистрируем информацию об аутентификации status = szSPN, 0, 0);

if (status != if (szSPN) Производительность при различных конфигурациях безопасности При анализе приложения в первую очередь интерес вызывает его Как же влияет обязательная аутентификация на производительность RPC серверов? В наборе инструментальных средств Microsoft Platform SDK есть при мер под названием оно предназначено специально проверки производительности в различных конфигурациях RPC. Это я выполнял на двух компьютерах. Клиент работал на машине под управлением Windows XP Professional, а сервер — под управлением Windows Server 2003 с процессором частотой 500 МГц и оперативной памятью в 25б Мб. Тест заключал ся в тысячекратном вызове удаленной функции, передающей серверу содержимое буфера размером 100 байт. В табл. показаны усреднен ные результаты трех тестов, выполненных для двух транспортов:

и TCP/IP.

422 Часть III Дополнительные методы создания защищенного кода Таблица Время выполнения теста при различных конфигурациях RPC Именованные каналы мс RPC_C_A PRIVACY Как принудительная не оказывает существенного вли яния на производительность. Быстродействие падает примерно на но это с лихвой окупается значительным уровня безопасности. Заметьте:

разница между уровнями и минимальна. Поэтому если в используется то имеет смысл перейти к Сейчас мы об этом поговорим Обеспечьте поддержку конфиденциальности и целостности Если вы обеспечили поддержку аутентификации при рекомендуем пойти дальше и реализовать и целостность пакетов. Ничем плохим это не грозит! В январе 2000 г. во время анализа безопасности проекти руемого крупного приложения Microsoft я предложил разработчикам реализовать конфиденциальность и целостность административной информации, пересыла емой средствами RPC. Разработчики поначалу опасались падения производитель ности, но после работы в таком (для этого потребовалось все го лишь изменить флаг в была выбрана более защищенная конфигурация. Позже (примерно за полгода до выхода продукта) для аудита при ложения пригласили специалистов занимающейся вопро сами безопасности. В выводах присутствовало следующее примечание, заставив шее меня улыбнуться: «Мы потратили массу времени, пытаясь взломать канал пере дачи администраторских но ровным счетом ничего не добились. В условиях, когда многим компаниям не удается организовать защиту данных та кой важности, нам остается лишь поаплодировать разработчикам за ние защищенных механизмов и На рис. 16-2 показан результат применения а на рис. - параметра Используйте строгие описатели контекста Если нет необходимости совместного использования описателей контекста не сколькими интерфейсами, применяйте описатели контекста (strict handle). В противном случае останется риск некоторых тривиальных DoS-атак.

Кратко изложу суть дела. Обычно при метода интерфейса создается опи сатель контекста, доступный другим интерфейсам. Наличие атрибута в ACF-файле гарантирует, что методы интерфейса будут принимать только описатели контекста, созданные его же методами, ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов DCOM Ox - - Б s - - 0.

Рис. 16-2. наличии Обратите внимание на пароля открытым текстом Рис. при наличии параметра Полезная нагрузка, то секретное сообщение, зашифровано 15- 424 Часть III Дополнительные методы защищенного кода Далее приводится пример незащищенного кода, в котором не предусмотрена обязательность строгих описателей контекста. Вначале приведу код в котором определяется с двумя интерфейсами: для управления принтерами и управления файлами.

interface void void out] void UsePrinter([in] ctx);

void ClosePrinter([in, out] *ctx);

• interface { typedef void void out] void UseFile([in] ctx);

void out] *ctx) А вот отрезок кода на C++ соответствующего void { // Создаем экземпляр *ctx = new if NULL) // действия по принтера.

void ctx) { // экземпляр объекта файла.

= // Выполняем операции с файлами, Это вполне работоспособный но в нем присутствует одна не за метная на первый взгляд брешь. Если злоумышленник передаст принтерный кон текст файловому интерфейсу, процесс может аварийно ся, так как строка CFileManipulator cFile вызовет ошибку нарушения доступа. Например, подобный сбой инициирует такой злонамеренный код.

void В последней строке при вызове функции передается не a ГЛАВА 16 Защита ActiveX-элементов и объектов Для устранения недостатка достаточно ACF-файл, включив в него атрибут interface interface Это среду исполнения действительно ли функциям и передаются только созданные ими самими опи сатели контекста.

Не полагайтесь при проверке доступа на описатели контекста Никогда не используйте описатели контекстов в качестве замены проверки до ступа. Иногда злоумышленники в состоянии перехватить описатель контекста и применить его для олицетворения другого при этом взломщику даже не требуется разбираться в содержимом описателя или данных Особенно это справедливо для случаев, когда данные не шифруются. При шифровании вероят ность реализации атаки существенно меньше, но ею все равно стоит регать, В при открытии описателя контекста осуществляет ся проверка доступа, и при этом предполагается, вызовы с одинаковым сателем контекста поступают с одного источника. Это может представлять или представлять угрозу безопасности — все определяется тем, какие действия с описателем контекста, но в общем случае это недопустимо. Если в коде необходимо выполнить проверку доступа, выполняйте ее защищаемого не полагаясь на содержащуюся в а информацию.

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

Примечание В сущности, это уязвимое место (ведь не гарантирует при с описателем контекста одному и тому же сеансу безопасности) можно рассматривать в качестве примера про блемы времени проверки и использования, когда программа, единож ды в чем-то, впоследствии продолжает считать, что далее ничего не меняется. В нашем случае пользователь проходит аутентифи кацию при создании описателя контекста, а при последующих вызовах других функций, применяющих этот же описатель, никаких проверок не выполняется и что описатель все еще действителен и не попал в руки злоумышленника.

426 Часть III Дополнительные методы создания защищенного кода Избегайте нулевых описателей контекста С формальной точки зрения работа с нулевым (NULL") описателем контекста свя зана проблемой устойчивости приложения (то есть корректностью обработки таких описателей), но если не предпринимать никаких мер, то они могут стать причиной уязвимости по отношению к DoS-атакам. Описатель контекста может указывать на как в этом примере:

void О Хотя bCtx не указывает на нулевым может оказаться указатель По этому при попытке использовать в коде указатель *bCtx произойдет сбой.

механизм заботится, чтобы все переданные функции описателя контекста были предварительно выделены сервером, но нулевой описатель — это особый случай и он всегда проходит такую проверку, Взгляните на следующий код.

short pphCtx, short { short sErr = 0;

HANDLE = NULL;

*pphCtx = NULL;

if == { hFile = if (hFile == { sErr = -1;

} else { // клиенту серверную для контекста, = ( if (pFid) { pFid->hFile hFile;

= } else SErr = ERROR_NOT_ENOUGH_MEMORY;

} return sErr;

' short { FILE_ID short sErr = 0;

if == { pFid = (FILE_ID RpcRevertToSelfO;

else ГЛАВА 16 Защита ActiveX-элементов и объектов sErr = -1;

:

return sErr;

!

short pphCtx) { *pFid = (FILE_ID = NULL;

= NULL;

return 0;

} Этот код открывать файл с помощью идентификато ра файла вызовом Если доступ к файлу разрешен, функция выделя ет динамическую память для хранения информации о куда и описатель контекста. Однако, вызов функций или IDFile закончится неудачей, указатель окажется равным NULL. Когда следствии пользователь вызовет или при попытке ра зыменовать нулевой указатель эти функции также потерпят крах.

Код RPC-сервера должен всегда проверять, что описатель контекста указывает не на NULL, а на действительно память.

if == NULL) { // Попытка нулевой описатель контекста.

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

qosSec;

= = = status = &qosSec);

Параметр ImpersonationType принимает одно из четырех (не позволяет получателю вызова кем ется клиент), LEVEL IDENTIFY получателю вызова иденти 428 Часть III Дополнительные методы создания защищенного кода GATE (последние два позволяют получателю вызова узнавать, кто клиент, и дей ствовать от его лица).

Используйте безопасные обратного вызова Для защиты функций предпочтительно использовать безопасные обратного вызова. Для этого при запуске вместо нужно вызывать или причем последний аргумент устанавливается так, чтобы указывать на которая вызывается средой для определения того, разрешено ли клиенту вызывать функции этого интерфейса.

В следующем примере разрешены только клиентские подключения с парамет ром безопасности и выше.

Л */ // Безопасная обратного вызова вызывается // при каждом вызове функции RPC-сервера, RPC_STATUS void { hPrivs;

DWORD RPC_STATUS status = NULL, NULL, NULL);

(status != RPC_S_OK) вернула: status);

return I // уровень // Требуется как на уровне пакетов.

if (dwAuthn < { поддерживает слишком слабую return return void raainO { ГЛАВА 16 Защита RPC, ActiveX-элементов и status = NULL, NULL, О, Примечание В некоторых версиях библиотеки и набора Platform SDK содержится неправильное описание безопасной функции обратного вместо void жно быть void Чтобы разрешить только защищенные подключения, при и следует установить флаг Он сужает круг разрешенных клиентских разрешены только те, уровень безопасности которых выше He шим проверку клиентам возвращается ошибка Это суще поправка. Если флаг не установлен, но подключения, среда исполнения RPC все равно передаст для обработ ки клиентский запрос приложению, которое немедленно откажет в доступе.

тановка флага среде исполнения отклонить не передавая егс л программу. И еще: этого флага в Windows NT 4/2000 позволяет ентам использовать нулевые (иначе — анонимные) сеансы, что в Windows ХР за для защиты чем описатель безопасности при вызове на то есть две чины. описатели безопасности допустимы когда в транспорта каналы или LRPC. В реализации на осно ве протокола TCP/IP описатели безопасности бесполезны. Во-вторых, все консчнь точки доступны через любой интерфейс, и этому посвящен следующий раздел.

Совместная работа нескольких в одном процессе Как вы наверное знаете, RPC-механизму все по какому сетевому протоко лу работать. К можно обратиться посредством любого мого сетевого протокола. В связи с этой особенностью возникает побочный эффект, который не затрагивает большинства пользователей, но о нем следует помнить, Если RPC-сервер располагается в одном процессе с другими серверами мер, если сервис содержит несколько все прослушивают каждый выбранный протокол. когда один процесс поддерживает три RPC-сервера: основанный на именованных каналах и LRPC, зующий и RPC3, работающий только через LRPC, то все три сервера нимают трех протоколов (именованных каналов. LRPC и (рис. 16-4).

430 Часть III Дополнительные методы создания кода Теоретически В реальности RPC.

+ Именованные Именованные Именованные Именованные Сок мы LR С каналы и LRPC каналы, LRPC каналы, LRPC каналы, LRPC и сокеты и сокеты и сокеты Рис. 16-4. Все три прослушивают все множество затребованных протоколов Вы ошибетесь, предположив, что сервер, использующий только LRPC, находится в безопасности — размещенные в том же процессе именованные каналы или сокеты, вынуждая первый использовать и эти протоколы!

Для проверки того, что клиентский запрос работает по определенному сете вому протоколу, нужно вызвать функцию а затем с по мощью функции RpcStringBindingParse определить последовательность протоко пример демонстрирует всю процедуру: в данном случае выясня ется, действует ли в контексте протокол LRPC.

• BOOL { BOOL = FALSE;

LPBYTE NULL;

if == LPBYTE pProtSeq = NULL;

// Нас интересует только последовательность протоколов, // поэтому присвоим остальным значение if NULL, NULL, NULL, NULL) == { // Убеждаемся, что клиентский запрос // выполнен LRPC, if == 0) flsLRPC = TRUE;

if (pProtSeq) ГЛАВА 16 Защита RPC, ActiveX-элементов и if (pBinding) return flsLRPC;

He забывайте добавлять аннотации к конечным точкам Аннотирование конечных точек — не вопрос безопасности, а просто хорошего стиля! При создании конечной точки обязательно вызовите функ цию и добавьте аннотацию. В дальнейшем это облегчит отладку — инструменты анализа конечных точек (такие, как RPCDump.exe из Windows Resource Kit) будут указывать назначение конечной точки, NULL;

if RPC_S_OK) { if NULL, "Приложение-телефон") == { // Класс! Аннотация добавлена!

I Я добавил этот совет лишь потому, что за свою жизнь потратил массу време ни, выясняя предназначение конечных точек, пока спецы по RPC не подсказали мне эту функцию.

Используйте популярные протоколы Используйте общеизвестные последовательности протоколов:

и Их популярность вынуждает производителей тестировать свои прило жения тщательнее.

Примечание Иногда клиент или «падает», и тогда вызов или сама код ошибки. Не как вы, но я уже успел забыть все значения кодов, кроме ошибки номер 5 — в до ступе»! Однако помощь всегда под рукой. В командной строке введите net где — десятичное представление номера ошиб ки, и ОС отобразит текстовую информацию о ней.

432 Часть Дополнительные методы создания защищенного кода Проверенные методы обеспечения безопасности DCOM — на самом деле лишь оболочка вокруг СОМ через сеть, так что многие понятия, описанные в предыдущем разделе об RPC, вам уже знакомы. Кроме имеющихся уже связанным с уровнем олицетворе ния и в DCOM и связанные с разрешениями на запуск и доступ и с контекстом пользователя, требующим объект. Вдобавок существует не трех вариантов обеспечения безопасности. Итак, начнем!

Основы DCOM Сначала запустим приложение При этом в Windows NT 4 или Win dows 2000 открывается диалоговое окно Distributed COM Configuration Properties (Свойства: Настройка COM), а в XP — окно позволяющее СОМ+ и На рис. 16- вкладка Default Properties (Свойства по умолчанию) диалогового окна Distributed COM Configuration Properties в Windows 2000.

год Г tewet She Рис. 16-5. Вкладка Default Properties окна Distributed Com Configuration Properties здесь можно разрешить или запретить DCOM на компьютере. Это средство: будьте осторожны, иначе некоторые компоненты неожиданно перестанут работать. Во-вторых, есть возможность разрешить СОМ Интернета (COM Internet Services). Они поддерживают RPC поверх превращая Web-сервер в и Не рекомендую отмечать этот флажок, не выяснив заранее, какие административные интерфейсы станут в этом случае доступными по HTTP. можно указать заданные по умолчанию проверки подлинности и олицетворения. параметры один в один ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов соответствуют параметрам RPC. Уровень проверки подлинности по умолчанию — Connect (Подключение), что соответствует значению олицетворения по умолчанию — Identify (Определить), что ет значению Последний элемент вкладки Default Properties — Provide additional security for reference tracking (Повышенная безопасность для ссылок). Тут по некоторые объяснения работы СОМ. При открытии объекта ся метод а при освобождении — Если число освобождений совпадает с числом вызовов объект но решает, что в нем больше нет необходимости, и самоуничтожается. К сожале нию, в СОМ не предусмотрена проверка того, исходят ли вызовы методов от од ного процесса, поэтому, если метод несколько лишних раз вы зывает написанный клиент или злоумышленник, объект — к великому изумлению пользователя — уничтожается. Типичный отказ в обслуживании, не правда ли? Но подобной ситуации удается избежать, обеспечив повышенную бе зопасность при отслеживании ссылок, однако имейте в виду: на это потребуются дополнительные ресурсы. При установке приложения на чужую систему не менять параметры безопасности для всех приложений — лучше добавить отсле живание ссылок вызовом функции присвоив значение аргументу На вкладке Default Security (Безопасность по умолчанию) задаются и по умолчанию доступа, запуска и конфигурирования. Разре шения доступа определяют, кто имеет право доступа к текущему процессу, разре шения запуска — круг допущенных к созданию объекта, а разрешения конфи — тех, кто имеет право на изменение параметров конфигурации. По следние особенно важны, так как DCOM-приложение можно для выполнения с правами текущего пользователя. Следует четко понимать, ч го любой пользователь, способный изменять параметры сможет в роли любого интерактивного пользователя. По умолчанию правом изменения кон фигурации обладают только члены групп (Администраторы) и Power Users (Опытные пользователи). Учтите, что члены группы Power Users в Win dows 2000, в отличие от Windows NT, обладают правами, незначительно уступаю щими администраторским. Не стоит изменять эти разрешения в сторону расши рения прав, но, с другой стороны, желая сократить их, не забудьте что это не нарушит работу других приложений. тест — проверить, в ли обычные пользователи выполнять свои задачи. Если да, то можно из двух вариантов: сократить права группы Power Users или лишить всех вателей прав, превратив их в рядовых.

Появившаяся в Windows 4 SP 4 вкладка Default Protocols (Набор протоко лов) позволяет задавать протоколы, применяемые в Кроме этого на ней определяется диапазон портов транспортных протоколов TCP и [в пользовательском интерфейсе им соответствуют названия TCP/IP (Ориентированный на подключение TCP/IP) и Datagram При необходимости работы DCOM через брандмауэр администра торам брандмауэра предоставляется отрадная возможность точно указать порт или диапазон портов, а использование TCP позволит настроить брандмауэр таким образом, чтобы подключение создавалось только в одном направлении, 434 Часть III Дополнительные методы создания защищенного кода Безопасность на уровне приложения Все доступные для всей системы, можно определять и для отдельных приложений. Для этого достаточно дважды щелкнуть значок приложения в спис ке на вкладке Applications (Приложения) диалогового окна Distributed COM Confi guration Properties или изменить параметры прямо в реестре, отыскав идентифи катор объекта в Заметьте: если приложение содержит несколько объектов, их конфигурации должны совпадать.

Лучше всего проанализировать разрешения, для всех объектов, и выбрать общий удовлетворяющий их все. Затем при менить управление безопасностью на уровне приложения для настройки различ ных параметров безопасности для отдельных объектов, но это слишком сложно и чревато ошибками. Для таких случаев есть хорошее правило: если у объектов сильно различаются требования к безопасности, их лучше разнести по разным приложениям или DLL-библиотекам. Помимо компонентов, использующих обще системные параметры, отдельные могут выполняться в раз личных пользовательских контекстах. Это очень важно, и об этом пойдет речь в следующем разделе. Наконец, если для передачи выбран протокол TCP или UDP, разные объекты разрешается настроить на работу по разным портам. Возможность выполнения сложных транзакций средствами при всего лишь двух откры тых портах (порт одной стороны и выбранный порт — с другой) намного лучше, чем полная прозрачность брандмауэра между двумя системами. Заметьте;

начиная с Windows 2000. устранена поддержка протоколов, на дей таграммах.

Некоторые параметры для отдельных приложений настраиваются только через реестр. Любые которые устанавливаются до запуска приложе ния, нельзя поменять в самом приложении. В частности, разрешения на запуск, информация о конечных точках и пользовательский контекст указываются толь ко в реестре.

Контексты пользователей в DCOM Подобно службе выполняется в разных пользовательских контек стах. Возможны следующие варианты: олицетворение пользователя, вызвавшего объект, выполнение от имени интерактивного пользователя, учетной записи SYS TEM (доступно только DCOM-серверам, реализованным в виде служ бы) или конкретного пользователя. В отличие от большинства пишущих о безопасности DCOM, я (Дэвид) расскажу вам, что по этому поводу думает и ха кер, и администратор по безопасности. Такова моя работа — взламывать системы и находить способы защиты от атак извне. Выбор пользовательского контекста для DCOM-объекта оказывает огромное на безопасность всей сети. Рас смотрим все возможные варианты со всеми их достоинствами и недостатками.

Выполнение в контексте пользователя, вызвавшего приложение В этом случае анализ последствий для безопасности довольно прост. Пользова тельские реквизиты нигде не хранятся, а управление доступом выполняется стан дартными средствами ОС. Правда, есть один недостаток: в систе мах, предшествующих Windows 2000, невозможно делегировать вызовы в другую ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов систему. Если должен иметь доступ к нелокальным ресурсам использовании Windows 4.0, выполнение в контексте вызвавшего пользователя невозможно. Даже в Windows 2000 и последующих ОС администра торам безопасности стоит соблюдать осторожность при назначении систем, до веренных для делегирования. К тому же, при этом падает производительность, так как запущенным в различных пользовательских контекстах экземплярам объекта требуются отдельные экземпляры оконных станций (window station) поддерживающих рабочий стол. Подробно об этом в Platform SDK Выполнение от имени интерактивного пользователя Это самый опасный вариант, и я настоятельно не рекомендую его применять.

при разработке отладочных инструментов. Во-первых, если в данный момент в системе никто не работает, DCOM-объект не удастся запус тить, а если пользователь выйдет из системы во время работы приложения, при ложение завершится. Во-вторых, атаки с целью повышения привилегий не заста вят себя ждать. Существует множество API-функций и иных методов момента интерактивного пользователя в систему. Достаточно опрашивать систему, дождаться входа администратора, а затем запустить объект для совершения вредоносных действий. Если вы абсолютно уверены в том, что вам необходим DCOM-объект именно в контексте интерактивного пользова теля, не забудьте предупредить вошедшего в систему пользователя о запуске при ложения, а также жестко ограничить круг имеющих права доступа к объекту и его запуска. И поаккуратнее с предоставляемыми методами.

Выполнение в контексте локальной системы Работающие как служба иногда выполняются под учетной сью Local System или. в Windows под непривилегированной записью сетевой службы. Учетная запись Local — самая в системе, чески определяющая поведение ОС. Сетевая служба не обладает такими ностями, но многие службы выполняются именно под ней, поэтому Тщательно проверяйте предоставляемые интерфейсы и будьте готовы рять клиента при выполнении проверок на доступ. Если DCOM-приложение яв ляется системной установите уровень олицетворения (на всех проке в Identify. В противном случае ничто не помешает вызывающим пользователям обзавестись повышенными привилегиями. В DCOM по умолчанию уровень олицетворения Identify, но программисты по привычке стараются выз функцию или API-функции для защиты прокси и поменять значение по умолчанию на Impersonate.

Примечание Стоит упомянуть о том, что в Windows Server добавлена привилегия олицетворения, подробнее о которой рассказывается в главе 7.

Выполнение от имени конкретного пользователя Microsoft Transaction Server обычно выполняет объекты именно таким и этот подход имеет свои преимущества. Будучи вызван пользователем домена, кт 436 Часть III методы создания защищенного кода способен операции на других системах от имени данного пользова теля. Кроме того, создается хотя бы по одной оконной станции на каждый а на каждого Любой учетной используемой для выпол нения требуется привилегия Log on as a batch job (Вход в каче стве службы). При назначении пользователя с помощью утилиты она присваивает нужные права, если же пользователь добавляется в самом приложе необходимые привилегии придется предоставлять программно. И убедитесь в отсутствии политик, переопределяющих вами приви легии.

Стоит учесть и недостатки этого способа. При выполнении DCOM-объекта от имени определенного пользователя в реестр записывается о его записи. Вроде нет причины для волнений — пароль в безопасности, не так ли? В некотором смысле вы правы: только администратору разрешается за пускать утилиту для считывания секретных данных LSA. А теперь представьте себе ситуацию: вы установили приложение на 3000 систем, и везде оно выполняется с правами администратора. То есть у вас имеется 3000 компьютеров, каждый из которых может стать причиной взлома всей группы. Предположим, что эти сис темы обслуживаются группой системных администраторов, поэтому с точки зрения безопасности компьютеры отличаются надежностью (то есть отдельно взятая система оказывается действительно уязвимой лишь день на каждые 1000 дней). Общая вероятность того, что все 3000 компьютеров в данный момент невозможно равна то есть примерно 0,05. Так что действия хакеров окажутся безуспешными всего дней в году, а остальное вре мя система не Если же вы переоценили своих администраторов, то шансы взлома окажутся еще Первое от этой запуск в контексте непривилегированного пользователя. Но даже в таком когда в системах хра нятся секретные данные (например, личные данные персонала), получение рек визитов и такого пользователя проблематично. Второй способ — уменьшение количества систем, на которых выполняется объект: 20 компьютеров защитить проще, чем 3000. Третий вариант — разделение контекстов разных пользователей на разных группах систем. В этом случае взлом одной группы не повлечет за со бой моментальное проникновение в другие системы. Если объекту для выполне ния работы требуются полномочия пользователя, заведите на каждой системе особую учетную запись (желательно локального пользовате ля). В варианте службы клиента SMS (Systems Management Server) реали зован такой подход, что лишает смысла действия взломщика. Они взламывают систему, получают доступ с правами администратора, считывают секретные дан ные, а в результате получают уже имеющийся уровень доступа. Ну никакой радо сти для хакера! Если вы системный могу вас заверить, что, когда хакеры веселятся, это означает для вас только головную боль и массу неприятно стей. И, наконец, в Windows XP и Windows Server доступны новые учетные записи — и Они не требуют управления паролями и не обладают высокими системными привилегиями.

ГЛАВА 16 Защита RPC, ActiveX-элементов и Программное управление безопасностью Технология позволяет устанавливать из программы параметры безопасно как сервера, так и клиента. Это выполняется вызовом на стороне сервера или клиента, клиент также вправе параметры пасности интерфейса, вызвав Похоже, у СОМ собственный язык описания своих возможностей, на котором параметров безопасности соответствует слово оболочка (blanket). Посмот какие параметры передаются функции pVoid, // Указывает на описатель безопасности LONG // Число элементов в asAuthSvc, // имен для регистрации void * // Зарезервировано для применения в будущем DWORD // Уровень аутентификации по умолчанию // для прокси DWORD // Уровень по // для прокси // информация // каждой аутентификации DWORD // Дополнительные // клиента и/или сервера void * // Зарезервировано для применения в будущем );

Первый параметр — описатель безопасности. Существует целый ряд вариан тов его применения: на существующий описатель безопасности, на иден приложения (application ID, или на конкретно означает содержимое определяется флагом в аргументе Если это AppID. вся информация берется из реестра, а другие аргументы игнорируются. Описатель определяет список тех, кому до ставляется доступ к причем после создания описателя безопасности на сервере его нельзя изменить. Этот параметр не применяется на клиенте и быть нулевым (то есть указывать на NULL), В документации к набору Platform мелким шрифтом (к сожалению, это обычная практика, когда речь идет о действи тельно важных вещах) указано, что, если сервер установил описатель на NULL, от ключается вся проверка доступа и остается аутентификация на основе параметра Так что не применяйте нулевой описатель безопасности.

Следующий шаг — выбор службы аутентификации. Во многих случаях это ос тавляется на усмотрение ОС, для этого параметру передают значение -1, Перейдем к параметру dwAuthnLevel, отвечающему за определение уровня аутентификации. Как уже упоминалось, присвоение этому параметру чения позволяет изрядно укрепить безопасность за счет незначительного снижения быстродействия. Практически всегда стоит обеспечивать безопасность на уровне пакетов. В результате согласования метров безопасности между сервером и клиентом выбирается уровень наиболее высокий из затребованных клиентом и сервером, 438 Часть III методы создания защищенного кода Уровень олицетворения не согласовывается, а просто задается клиентом. Кли енту имеет смысл сообщать какие действия разрешается совершать с переданными ему реквизитами пользователя. Существует интересная возмож ность — смена ролей клиента и сервера, так что неплохо установить флаг и на который в этом случае превращается в клиента! Как уже говорилось ранее, следует указывать значения если только не требуется более высокий уровень олицетворения.

А теперь о нескольких интересных аргумента Два - применяются в системах Windows 2000 и последующих для организации маскировки (cloaking).

Она промежуточному объекту получать доступ к низкоуровневому объек ту с правами пользователя, от имени которого делается вызов. При олицетворе нии пользователя обычно лучше всего обращаться к другим объек там в контексте самого пользователя — иначе объектам окажутся доступными «лишние» ресурсы. Чтобы помешать освобождению злонамеренными пользова телями объектов других пользователей флаг Но помните, что он не совместим с аутентификацией.

Начиная с Windows 2000, стал новый флаг — Он безопасность сервера при использовании DCOM за счет сни жения вероятности выполнения произвольных DLL-библиотек. установлен ном флаге допустим демаршалинг только классов с CLSID, представленных в Ole32.dll и службе компонентов (Component Services).

Идентификатор CLSID — это уникальное в масштабах число, однознач но определяющее В ссылки на объекты упаковываются путем создания объектных ссылок (object OBJREF), содержащих CLSID. Атака на идентификаторы CLSID в процессе позволяет вызвать загрузку произвольной DLL-библиотеки. Процессы, для объявления могут также посредством вызова обращаться к идентификаторам CLSID, содержащие При установленном флаге любая операция, в которой пред принимается попытка запуска серверного процесса от лица пользователя, завер шается с ошибкой Этот только при вызове кции позволяет предотвратить запуск ненадежных компонен тов в контексте привилегированной учетной записи (например, Local System), в котором выполняется приложение. Такая возможность реализована в Windows и последующих ОС.

для экспериментов с различными параметрами и проверкой ра боты их комбинаций я создал проверки безопасности DCOM (см. папку Сначала с помощью мастера ATL СОМ Арр из состава пакета Microsoft Visual C++ 6 я создал стандартный DCOM-сервер, затем добавил в интерфейс реализующий * DWORD * DWORD * AuthLevel, ГЛАВА 16 Защита ActiveX-элементов и объектов DWORD ImpLevel) == AuthZSvc, NULL, NULL);

== I I else return I Как вы видите, код довольно прост: сперва получается контекст текущего по тока, а затем с помощью объекта запрашивается оболоч ка Полученные результаты возвращаются клиенту. Клиентская TestClient выясняет текущие параметры безопасности клиента, выводит их на пе чать, вызывает метод который на фейсе безопасность на уровне пакетов, а затем вызывает на вере. Взглянем на результаты:

client security settings:

Client Security Information:

security support provider No authorization Principal name:

level = Connect level = Identify auth level to Packet Privacy Server Security Information:

Snego security support provider 440 Часть III Дополнительные методы создания защищенного кода authorization level = Packet privacy Impersonation level = Anonymous После установки и сборки приложения скопируйте TestClient.exe и на другую систему. Зарегистрируйте в ОС командой Убедитесь в что все набрали правильно — построенное с помощью мастера приложение не выдает никаких сообщений об успехе или неудаче регистрации. Приложив минимальные вы включите этот тестовый код и в свое приложение, чтобы понаблюдать, что происходит при изменении параметров безопасности. Однако будьте начеку: проверка бесполез на, если клиент и сервер работают на одной машине.

Источники и приемники В DCOM существует интересный способ обработки асинхронных вызовов, хотя, начиная с Windows 2000, в ОС этого семейства поддерживаются настоящие асин хронные вызовы. DCOM позволяет запросить сервер с тем, чтобы тот после завершения текущего вызова выполнил обратный вызов указанного клиентом интерфейса. Это реализуется посредством стыкуемого объекта (connectable object), Точки соединения (connection points) детально описаны во многих книгах [напри мер книга Гая (Guy и Хенри (Henry Eddon) «Inside Distributed (Microsoft Press, и за подробностями лучше обратиться к ним. С точки зре ния безопасности интересен тот факт, что в такой ситуации сервер превращает ся в клиента. Если оболочка безопасности сервера не настроена на предотвраще ние полного клиент в состоянии повысить свои привилегии.

Представьте себе следующую последовательность событий, связанных с: выполня ющимся под учетной записью Local сервером, который в обычном состо янии олицетворяет клиента. Сперва клиент сообщает серверу о своем объекте приемнике (sink) и просит завершить занимающий достаточно большое время вызов. Затем клиент принимает вызов, олицетворяет сервер и получает возможность манипулировать операционной системой. Исследуя эту проблему, я просмотрел три различные книги, посвященные DCOM, и только в одной из них.

и то мельком, упоминалось о проблемах безопасности, связанных со стыкуемы ми объектами. При разработке сервера с поддержкой стыкуемых объектов поста райтесь не попадать в эту ловушку.

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

Азы ActiveX Разработанная в Microsoft технология COM (Component Object Model) стала по пулярна благодаря независимости от языка программирования и возможности ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов повторного кода. Взаимодействие происходит через причем все компоненты обязаны поддерживать базовый ин терфейс ActiveX-элемент — это саморегистрирующийся поддерживающий интерфейс lUnknown. Поддержка интерфейса позволяет обращаться из языков высокого уровня Visual Basic и Perl) и языков сценариев (к VBScript и Jscript) к любым компонентами посредством механизма, который называется Automation. Архитектура ActiveX-элементов ши роко применяется для разработки программных внедряемых в раз личные в том числе в инструменты разработки и клиентские приложения (такие, как Web-браузеры и почтовые клиенты).

Проверенные методы обеспечения безопасности ActiveX Неправильно спроектированные или написанные ActiveX-элементы при водят к серьезным проблемам с безопасностью контейнеров двух видов — Web браузеров и почтовых клиентов. Ведь Web-страницы способны вызывать Active X средствами HTML или а приложения для работы с ной почтой часто отображают текст в виде HTML, поэтому (конечно, если это разрешено политиками безопасности) вызов ActiveX-элементы возможен и из электронных писем. Кстати, почтовый клиент Outlook 2002 (из состава Microsoft Office XP) по умолчанию не запускает содержащиеся в электронном письме Active X впрочем, так как и Outlook Express в Windows Server и Windows XP, Если содержит брешь, это грозит большими особенно если не предупредить пользователя о том. что HTML-страница сообщение электронной почты с HTML-страницей) собирается запустить мый ActiveX-элемент, Чтобы на HTML-странице (в Web-браузере или почтовом клиенте) запуск Acti veX-элемента происходил без оповещения пользователя, необходима особая фигурация политик безопасности. Стоит заметить, что, если код объявлен безо пасным в плане инициализации (safe for initialization, SFI) или сцена риев (safe for SFS), приложение может не предупреждать пользователя о потенциально опасном способе применения этого кода.

ActiveX-компоненты, безопасные в плане инициализации и исполнения сценариев При инициализации ActiveX-элемента локальные или удаленные данные открывать посредством различных СОМ-интерфейсов В этом случае воз никает угроза безопасности, так как источники данных не всегда надежны.

пасными в плане инициализации считаются ActiveX-элементы, отсутствие проблем с безопасностью при загрузке постоянных данных а лизации, причем независимо от их источника.

Безопасность в плане исполнения сценариев подразумевает, что автор элемента что элемент управления безопасен, так как в принципе не 442 Часть Дополнительные методы создания защищенного кода собен создать угрозу для безопасности. Однако то, что ActiveX-элемент безопа сен при вызове пользователями, отнюдь не означает, что он безопасен при авто матизированном запуске посредством ненадежных сценариев или Web-страниц.

Так, приложение Microsoft Excel является надежным инструментом, поступившим из заслуживающего доверия источника, но написанный со злым умыслом сцена рий будет использовать функции автоматизации этого приложения для удаления файлов и вирусов, стоит кратко описать возможности превращения ActiveX-элементов в небезопасные в плане инициализации и сценариев, Внимание! — это исполняемые и их можно щищать цифровыми подписями по технологии Хотя под пись гарантирует подлинность автора ActiveX-элемента и целостность самого элемента, она не предохраняет от ошибок или безопас ности.

Вот пример ActiveX-элемента, в плане исполнения сценариев.

В мае г. я занимался анализом безопасности Web-сайта, который требовал от пользователей загрузить и установить ActiveX-элемент. В первую очередь я безопасен ли элемент управления для работы в сценариях, и получил от разработчиков утвердительный ответ. Затем я спросил, есть ли в нем обладающие доступом к ресурсам (например, к файлам) на компьютере пользователя. Оказалось, что у ActiveX-элемента есть метод Print, позволяющий распечатать любой файл на любом принтере! Этого было достаточно, чтобы уве домить разработчика, что ActiveX-элемент считать безопасным для исполь зования в сценариях, так как при посещении хакерского Web-сайта, его хозяин злоумышленник сможет распечатать любой с жесткого диска пользова теля на своем причем пользователь не получит никакого предупреж дения.

Вы спросите, как же такое возможно? Запомните: любой Web-сайт в состоянии контролировать все загруженные в память компьютера ActiveX-элементы, если только не предпринять специальные шаги по предотвращения загрузки таких управления. Описанная брешь возникает из-за того, что Web-сайт за пускает ActiveX-элемент на своей Web-странице, а затем вызывает метод Print для печати конфиденциального документа.

Рекомендую ознакомиться с некоторыми примерами того, как ActiveX-элементы с цифровой написанные квалифицированными разработчиками без малейшего злого умысла, становились причиной серьезных брешей в защите, Просмотрите статьи View Exposes Unsafe Functionality» (Встро енный в Outlook элемент управления для просмотра предоставляет небезопасные возможности) Setup Control Vulnerability» (Уязвимость элемента управления для интерактив ной установки) и HTML Script and IE Script (Бреши, обусловленные уязвимо стью механизмом выполнения сценариев на HTML-страницах в Office и Internet Explorer) ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов DCOM Внимание! Угроза, исходящая от ActiveX, касается не только преднамеренно враждебных элементов — да таковых не так уж много. Настоящая опас ность в том, что злоумышленники используют дыры в безопасности вполне ActiveX-элементов, изменяя их поведение, Если требуется объявить ActiveX-элемент как безопасный в плане инициали зации или исполнения сценариев, обратитесь на сайт msdn.microsoft.com и выпол ните поиск по фразе safe for scripting. Но до этого настоятельно рекомендую про читать следующий раздел!

Проверенные методы создания SFI- и Первейшее правило создания ActiveX-элементов, безопасных в плане зации и/или исполнения сценариев, звучит так в плане инициализации или исполнения сценариев!

Затем нужно определить, что же, делает элемент управления бе зопасным в обоих отношениях. Если в нем есть функция, таящая угрозу, элемент обязательно отмечается, как небезопасный. Если есть хотя бы малейшие сомнения, даже и не думайте об объявлении ActiveX-элемента безопасным для использования в сценариях.

Внимание! Постарайтесь не делать распространенной ошибки: сперва управления объявляется безопасным, после этого его проверяют на пред мет наличия небезопасных функций и лишь при обнаружении таковых объявление о безопасности отменяется. В такой последовательности легко не заметить недокументированную (или плохо документированную) функцию и оставить брешь, подставив под удар пользователей своего продукта.

Безопасен ли ActiveX-элемент?

Процесс выяснения, является ли безопасным довольно преет:

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

• доступа к данным на локальном компьютере или в сети, как файлы или параметры реестра;

• раскрытия частной информации (например, частных ключей, паролей и документов);

• изменения или удаления информации, хранящейся на локальном ре или в сети;

• инициирования аварийного завершения приложения-контейнера;

• потребления слишком большого объема ресурсов как память и ;

о вое пространство);

• выполнения потенциально опасных системных вызовов, включая файлов.

444 Часть III Дополнительные методы создания защищенного кода Если хоть что-то из перечисленного имеет место, ActiveX-элемент нельзя считать безопасным в плане исполнения сценариев. Быстрый и простой способ заключа ется в просмотре всех названий в поиске глаголов, обращая особенное внимание на названия функции, например Read и т. п.

Заметьте: само по себе чтение файла или раздела реестра не обязательно вле чет за собой опасность для защиты. Но если атакующий в состоянии указать, ка кой конкретно ресурс считывать, а затем получить данные этого ресурса, то это действительно серьезная проблема.

Другой вариант — реализовать интерфейс Это позволяет прило жению-контейнеру (обычно это Internet Explorer) опрашивать объект и безопасен ли он в плане инициализации или исполнения сценариев.

Также следует проверять каждый метод и свойство на возможность возникно вения переполнения буфера (см. главу 19).

Ограничение области действия конкретным доменом Независимо от того, объявили ли вы ActiveX-элемент безопасным для сценариев или нет, вызывайте его только из определенного узкого круга доменов. Например, ограничьте действие ActiveX-элементов чтобы они вызывался только с страницы, относящейся к домену Этого можно добиться следующим образом.

Реализуйте интерфейс с методом SetSite, который должен вызы вать контейнер (например, Internet Explorer), чтобы получить указатель на интерфейс контейнера (для этого следует подключить заголовочный файл lobjectWithSite обеспечивает простую связь между ActiveX-элемен том и контейнером, 2. Затем для получения имени сайта используйте следующий псевдокод:

3. Наконец, программа должна выяснить, относится ли значение к дове ренным URL-адресам. Тут стоит немного подумать. Обычно совершают ошиб ку, содержится ли строка northwindtraders.com (ну, или имя другого нужного сервера) в имени сервера. Но такую проверку легко обойти, создав имя типа Поэтому лучше выполнять вы зовом из библиотеки эта функция получает имя хоста из URL-адреса (ему соответствует переменная начиная с конца строки.

Следующий пример (см. папку демон стрирует реализацию последнего этапа.

Л cpp */ BOOL char BOOL ГЛАВА 16 Защита RPC, ActiveX-элементов и объектов = // Нас интересует только имя = = BOOL fRet = 0, 0, ;

if { failed - > return FALSE;

II Проверяем на наличие если этот протокол if != return FALSE;

// наспех чувствительный к регистру поиск, // начиная с крайней правой части строки.

int int cbValid = int cbSize = (cbHostName > cbValid) ? cbValid : cbHostName;

for (int i <= cbSize;

if - i] l= return FALSE;

return TRUE;

void { char = BOOL fRequireHTTPS - TRUE;

if { нормально, - правомочный ;

Если вызов завершится с ошибкой, ActiveX-элемент не загрузи г так как он вызывается с Web-страницы, относящейся к неизвестному домену в данном случае не к домену nortbwindtraders.com.

что подробную информацию относительно использованных в этом разделе интерфейсов и функций СОМ вы найдете на сайте а в базе знаний Microsoft Knowledge в статье Tie ActiveX Controls to a Specific Domain» (Как закрепить ActiveX-компонент за конкретным доменом) приводится пример кода для ограничения области действия ActiveX-элемента определенным домено 446 Часть III Дополнительные методы создания защищенного кода Шаблон Во время мероприятий по укреплению безопасности Windows и Office в начале 2002 г. был разработан на C++. призванный облегчить при вязку к Web-сайтам и ограничение области действия элементов управления.

менение шаблона SiteLock позволяет разработчикам ограничить доступ к ActiveX элементам таким образом, чтобы элемент считался безопасным только в заранее определенном списке доменов, что не позволит взломщику задействовать ActiveX элемент для выполнения вредоносных действий. Программистам шаблон SiteLock позволяет создавать ActiveX-элементы, ведущие себя по-разному при вызове из различных доменов. В шаблоне средства проверки правомочности домена выде лены в отдельную общую библиотеку, что намного укрепляет защиту ActiveX-эле ментов и облегчает устранение обнаруженных Примечание Исходный код шаблона SiteLock открыт для общего доступа на Установка Bit Предположим, что все ваши старания пошли насмарку и вы умудрились выпус тить ActiveX-элемент с брешью в защите. Новая версия не решит проблему, осо бенно если пользователи решили полностью доверять подписанным вами ActiveX элементам. Со своего Web-сайта предоставит пользователю и запустит на исполнение старый — и все: пользователь перед лицом злоумышленника. Подскажу, как решить проблему. В разделе реестра Explorer есть подраздел ActiveX в котором со держится ряд в виде списка идентификаторов Чтобы прекратить действие старого ActiveX-элемента, создайте новый подраздел (если он еще не существует), указав в качестве названия строковое представле CLSID элемента, и добавьте в подраздел параметр типа с именем Compatibility Flags и значением 0x00000400. Все. этого достаточно. Рекомендую при появлении новых версий задавать этот параметр для всех устаревших версий, чтобы защитить пользователя, впервые устанавливающего ваш ActiveX-элемент, от ошибок в предыдущих За подробной информацией обращайтесь к статье Q240797 из Microsoft Knowledge Base.

Резюме Технологии и ActiveX обе базируются на часто приобретен ные при изучении RPC, полезны при работе с другими технологиями. Итак, «су хой» остаток о проверенных методах обеспечения безопасности:

• RPC — компилируйте все с /robust и ничего не запускайте в контексте учетной записи SYSTEM;

• DCOM — также ничего не выполняйте в контексте SYSTEM;

• ActiveX — никогда не объявляйте элементы управления безопасными в плане исполнения сценариев, не убедившись, что это действительно так, и исполь зуйте шаблон Противостояние атакам типа «отказ в обслуживании» атак типа в (Denial of Service, DoS) защититься слож нее всего. Чтобы выяснить, каким образом злоумышленники атакуют и выработать стратегию зашиты, необходим самый тщательный анализ. В этой главе я расскажу о некоторых видах из числа распространенных и проиллюстрирую рассказ фрагментами кода и примерами жизни». Часто про граммисты не заботятся о защите от объясняя это тем, что они не ведут напрямую к повышению привилегий, но учтите: организовав подставной пер и выведя из строя настоящий, атакующий получает такие же права, как и у атаку емого сервера. случаются все чаще, поэтому следует быть готовым к ним.

В этой главе рассказывается о наиболее часто реализуемых DoS-атаках, которые приводят к:

«краху» приложения и/или операционной системы;

недостатку процессорных ресурсов:

нехватке памяти:

общей нехватке ресурсов;

перегрузке сети.

Атаки, вызывающие «крах» приложений DoS-атаки, вызывающие аварийное завершение приложений, почти всегда исполь зуют недостатки не очень качественно написанных программ. Наиболее ны атаки такого типа на стеки сетевых протоколов. Одна из первых — bomb) — системы под управлением SunOS 4.x. Создается в заголовке которого указывается превышающая реальный размер пакета. Получение такой «бомбы» приводит к ошибке доступа к памяти, а само ядро 448 Часть III методы создания защищенного кода ОС «падает* (точнее, UNIX-системы впадают в состояние «паники», а Windows системы отображают «синий экран смерти» или сообщение об ошибке), далее происходит перезагрузка системы.

В атаке типа (Ping of Death), используются некоторые недостат ки внутреннего строения заголовков IP-пакетов. Это более свежий пример DoS атаки. Вот как выглядит структура struct.

unsigned char ip_version:4, unsigned char unsigned short ip_len;

unsigned short ip_ld;

unsigned short ip_offset;

unsigned char unsigned char unsigned short struct in_addr >;

В поле указан полный размер пакета в байтах. Число типа беззнакового целого (unsigned short) принимает значения не более 65 535, поэтому максималь ный размер всего пакета — 65 535 байт. Структура поля выглядит стран но — три бита в нем отведены для управления процессом фрагментации. Один из битов определяет, может ли пакет быть фрагментирован, еще один показыва ет, следуют ли за этим пакетом другие пакеты. Если оба бита равны возможны два варианта: или этот пакет — последний в серии фрагмен пакетов, или никакой фрагментации не было. Остальные бит оп ределяют смещение фрагмента относительно начала оригинального пакета. Так как квант смещения равен 8 байтам, максимальное смещение составляет 65 535 байт.

Так в чем же проблема? Она в том, что последний фрагмент можно к последнему возможному байту пакета (то есть к байту под номером 65 535). Если вы добавите несколько байт к этой позиции, суммарный объем собранного паке та превысит Примечание Тем, кто хочет точно знать, как работает атака «ping смерти* (Ping of Death), советую обратиться к одному из первых описаний этой ата ки, например, на странице Имеющаяся информация о том, какие системы уязвимы по отношению к этой атаке, противоречива. Известно только то, как обнаружили про блему: кто-то заметил, что вызов команды ping -1 65510 уэла> в системе под управлением Microsoft Windows 95/NT приводит к многих UNIX и Linux-систем, а также некоторых сетевых устройств.

Как защититься от подобных в сетевом ПО? Во-первых, ни при каких обстоятельствах не доверяйте тому, что приходит из сети. Единственный способ ГЛАВА 17 Противостояние атакам типа в обслуживании» избежать приложений — писать надежные программы и тщательно их тестировать. Не забывайте также, что многие вызывающие при ложений, создают ситуацию, в которой возможно выполнение произвольного кода, для этого взломщику придется приложить совсем немного усилий.

фрагмент кода иллюстрирует описанную проблему.

/* Пример кода сборки пакетов, выявляющего слишком пакеты ftinclude tfinclude using // Многие сборщики пакетов работают со связным списком.

// Фрагменты не всегда поступают в правильном порядке.

// Реальный код для сборки пакетов намного сложнее.

struct.

unsigned unsigned ip_type_of_service;

unsigned short ip_len;

unsigned short unsigned short ip_offset;

unsigned char unsigned char ip_protocol;

unsigned short struct in_addr ip_destination;

typedef frags, • II Предполагаем, что сборщику пакетов передали список, // упорядоченный по // Сперва сколько памяти выделять // для всего пакета.

unsigned long = 0;

// Проверяем пакет на "вредность" // и определяем его размер, unsigned short last_offset;

unsigned short datalen;

ip_hdr Packet;

// Проблемы с очередностью байтов не 450 Часть III Дополнительные методы создания защищенного кода // ведь это всего лишь пример.

последний Packet = // Как вы смещение кратно 8 байтам.

// и маскируем флаги.

last_offset = 4 - 8;

// Проверка чтобы // что размер пакета не в заголовке!

= - * 4;

// Приведение всех и вся к типу unsigned long // позволяет packetlen = (unsigned long)last_offset + (unsigned long)datalen;

// Если packetlen - переменная типа unsigned short, // то вычисления будут выглядеть вот так:

// offset = // datalen = 0x0020;

// total = 0x // что сократится до общей суммы 0x0010, // и следующая проверка всегда будут возвращать true, так как значение // переменной типа unsigned short не может превышать Oxffff.

if(packetlen > Oxffff) { // 0-па! Плохой пакет!

return false;

// память и начинаем сборку пакета из return :• Далее — иллюстрация другой проблемы: реально поступившие данные не со ответствуют описанию в данных. Я знаю множество случаев, когда именно такая ошибка порождала массу проблем в различных приложениях, начиная с Microsoft Office и заканчивая ядром операционной системы.

/* Второй пример */ struct !

buf;

short unsigned short ГЛАВА 17 Противостояние атакам типа в обслуживании" :

void // В чем проблема ТАКОГО представления?

if(pStr->len < 20) pStr->buf, * Выполним кое-какие операции.

Наиболее очевидный недостаток в том, что функция не проверяет, ся или нет указатели на NULL. Вторая ошибка — функция «верит» на слово сведени ям, предоставляемым структурой. Запомните;

при создании защищенного кода обязательно проверяйте все, что только можно. Например, при получении ой строки механизм в RPC должен выяснить, согласуется ли размер строки с размером буфера. Функции необходимо как минимум не указывает NULL. Никогда не считайте заранее, что клиенты доб ропорядочны, Атаки, вызывающие перегрузку процессора Цель подобных атак — заставить приложение «зависнуть» в цикле (лучше всего в бесконечном) ресурсоемких вычислений. Понятно, что от такой атаке системы толку мало. Вот пример того, как взломщик обнаруживает приложения к таким атакам: он запрашивает файл и получает со об ошибке с информацией, что файл не найден. приложе ние убирает лишние символы обратного слэша — как оно спра вится с множеством повторяющихся символов? Вот пример приложения (см. папку I* Приложение демонстрирует результаты работы двух различных методов удаления повторяющихся символов обратного слеша.

множество способов этой задачи.

здесь способы приводятся лишь в качестве примера.

ttinclude 452 Часть III Дополнительные методы создания защищенного кода В этом методе повторно но такой подход не слишком эффективный.

Затраты растут пропорционально квадрату размера входной строки.

Возвращается если обратный слеш убран.

// что buf - строка с завершающим нулем, buf) = buf;

bool = false;

= buf;

.

// Сдвигать все символы вниз на одну позицию // с функции strcpy, когда источник и адресат // ПЛОХО!

// Это пример того, как НЕЛЬЗЯ делать.

// Это приложение чревато опасностями // никогда не делайте этого.

= :

return Л Это метод выполнения той же задачи с меньшей на процессор.

Здесь чуть больше издержек на обработку коротких строк из-за выделения памяти, но зато требуется всего один проход всей строки.

*/ bool StripBackslash2(char* unsigned written;

char* = NULL;

tmp;

bool foundone = false;

len = + 1;

== 1) return false;

ГЛАВА 17 Противостояние атакам типа «отказ в обслуживании" tmpbuf = // Это не то, чего хотелось бы - стоит вернуть ошибку.

== NULL) return false;

= 0;

for(tmp = buf;

!= if(tmp[0] == == { не копируем его в другой буфер.

= } else •' = ;

// Повторное копирование временного буфера поверх входных данных // вызовом работать с буфером // без null.

// Переменная была увеличена на единицу // при последнем выходе из цикла, strncpy(buf, written);

buf[written] = != HULL) return foundone;

int argc, char* input;

char* end = DWORD int i, j;

// Теперь строку.

for(i i < 10000001;

i 10) 454 Часть методы создания защищенного кода input = == NULL) I assert(false);

break;

!

// Теперь строку.

// Учтите, что строку замыкает // запишем 2 байта после элемента // затем добавим for(] = 0;

j < i - 5;

J += 3) :

= = = // Помните, что переменная j увеличивается до // проверки логического выражения в условном операторе, + j, end, 4);

= на входе = символов, время = i, GetTickCountO - tickcount);

// Возвращаем строку в исходное состояние // это тест, j < i - 5;

j += 3) I input[j] = input[j+2] !

// Как вы помните, переменная ] увеличивается до // проверки условного оператора.

strncpy(input + j, end, 4);

tickcount = GetTickCountO;

на входе = символов, время = i, GetTickCountO - tickcount);

;

return 0;

ГЛАВА 17 Противостояние атакам типа «отказ в обслуживании» Программа отлично проверяет устойчивость к Функция тат создает тестовую и выводит информацию о производительности. Функция 1 избавляет от необходимости выделения дополнительного буфера, но ценой дополнитель ной нагрузки: число исполняемых команд пропорционально числа по вторяющихся символов обратного слеша. В функции ся дополнительный но выделение памяти компенсирует ся тем, что количество исполняемых команд становится пропорциональным строки. В табл. работы двух Таблица 17-1. Результаты выполнения CPU.DoS Example.cpp Время выполнения Время выполнения Размер строки мс мс 0 II • 0 1000 0 ! ! 100 000 306 1 000 2 170 Из таблицы видно, что поведение двух не пока длина строки не достигает величины около 10 000 При длине в 1 млн. байт, разни ца составляет 36 минут на компьютере с процессором Pentium III (частота Направив всего несколько таких взломщик «вырубит» сервер на :о длительное время, Несколько читателей первого издания этой книги указали мне на то, что кция также не очень эффективна, так как можно избежать выделе ния дополнительной памяти. Я составил версию программы, которая рас ставляет все по местам. Производительность этой версии не удается измерить с помощью — возвращается время 0 мс для строк с размером вплоть до 1 Мб. Я не использовал такой подход ранее, чтобы проиллюстрировать цию, когда с самого начала отказываются от одного решения в пользу другого из за худшей производительности, демонстрируемой в условиях. Фун кция превосходит по скорости функцию при работе с очень короткими строками, но эту разницу в производительности можно не принимать в расчет в масштабах всего приложения. Применение функции связано с дополнительными расходами, что компенсируется масштабируемостью при росте нагрузки. Мне когда рабочие характеристики приложения проверялись только в обычных и такой ошибочный подход оставлял возможность реализации DoS-атак. Наверняка вы предпочтете снижение в обычных условиях i к атакам типа в обслуживании». К сожалению, мер не без потому что существует и третий превосходящий г о скорости оба первоначальных, к тому же не подверженный Вот текст функции 16- 456 Часть III Дополнительные методы создания кода str) char* read;

char* write;

// Всегда проверяйте все возможности.

!= NULL);

if(strlen(str) < 2) // Никаких return false;

// Инициализируем оба указателя.

for(read = write = str + 1;

*read != // Если и этот, и последний символ - обратные // слеши, то на единицу увеличивается // не write, а только read.

== - 1) == continue;

else = Дописываем завершающий нуль.

= return true;

Полноценное рассмотрение алгоритмической сложности выходит за пределы этой книги, а тестирование защиты мы подробнее обсудим в главе но все-таки сейчас я познакомлю вас с некоторыми полезными инструментами, входящими в Microsoft Visual Studio, которые способны решить проблему.

На одной встрече с двумя программистами нашей группы мы обсуждали, как повысить производительность большой подсистемы. Молодой программист пред ложил оценить алгоритмическую сложность. Следует сказать, что он недавно окон чил университет и весьма ценил теоретический подход. Более опытный програм мист возразил: «Это бессмысленно. Алгоритмическую сложность системы такого масштаба мы будем вычислять целую неделю. Давайте просто запустим утилиту выявим трудоемкие а затем оптимизируем их». Дохо ГЛАВА 17 Противостояние атакам типа «отказ в дило до того, что в случаях, когда я просил Тима (старшего програм миста) ускорить какую-нибудь это заканчивалось тем, мы добавляли в код циклы ожидания, чтобы сетевое оборудование не вышло из строя по причи излишней «прыти» приложения. Его практичный, основанный на опыте, под ход всегда приносил плоды, а одним из его любимых инструментов был Для запуска профилирования приложения в Visual Studio 6 в меню Project вы берите Settings и перейдите на вкладку Link. В раскрывающемся списке Category General, а затем — Enable Profiling и щелкните ОК. Теперь запустите приложение — результаты появятся в окне вывода вкладки Profile. Я изменил при ложение, чтобы оно обрабатывало до 1000 символов (в прошлый раз, результата, я успел принять душ и и вот, что получил:

Profile: Function timing, sorted by time Date: Sat May 26 15:12:43 Program Statistics Command line at 2001 26 15:12;

Total time: 7. Time outside of functions: 6.305 millisecond Call depth: Total functions: Total hits: Function coverage:

Overhead Overhead Average Module Statistics for Time in module: 1.517 millisecond Percent of time in module:

Functions in module:

Hits in module: function coverage:

Func Hit Time Time % Count Function 1.162 76.6 1.162 76.6 3 *) 0.336 22.2 1.517 100.0 1 main 0.019 1.3 StripBackslash2(char *) 0.019 1. У таймера утилиты Profiler разрешение лучше, чем у функции и, хотя наш первый тест не показывал смог значительную в производительности и 458 Часть III Дополнительные методы защищенного кода Если слегка изменить — зафиксировать размер строки и циклически запустить код раз. — удастся сравнивать этих функций при различных размерах входной строки. Например, при длине в 10 символов, функция выполняется в дна раза дольше Но уже при размере в 100 символов впятеро превосходит по скорости Про граммисты часто тратят уйму времени на оптимизацию функций, которые и так неплохо а иногда ссылаются на важность производительности, оправ дывая использование небезопасных функций. Лучше потратить время на профи лирование только тех частей приложения, которые действительно серьезно вли яют на производительность. В совокупности профилирование и тщательное тес работы функций позволяют существенно повысить устойчивость по отношению к DoS-атакам. Теперь, когда я по воле читателей, ратующих за произ водительность приложений, добавил функцию сравним с помощью профайлера работу функций и (табл. 17-2).

17-2. Сравнение функций и Доля процессорного Доля процессорного времени времени Размер строки Соотношение 1000 2,5 1,9 1, 14, 1, 23,3 1, 1 000 000 34, 1, Интересная картина получается. Во-первых, не так уж плоха.

Соотношение не остается постоянным при изменении размера строки, так как эффективность механизма выделения памяти операционной системой и работы диспетчера кучи зависит от размеров выделяемых областей — для одних лучше, а для других хуже. С момента работы над первым изданием конфигурация моего домашнего компьютера не менялась, поэтому условия тестирования остались теми же. Нужно заметить, что в моей системе достаточно оперативной памяти. Пола гаю, результаты на системах с ОЗУ малого размера будут сильно отличаться от приведенных, так как выделение больших объемов памяти довольно ресурсоем ко. Сейчас уже выпускаются процессоры, которые в три раза производительнее в однако важно помнить: зачастую старые системы луч ше подходят для обнаружения DoS-атак и атак, приводящих к перегрузке сора.

Примечание Profiler больше не поставляется в составе Visual Studio но его свободно распространяемый вариант доступен на Web-странице По этой ссылке вы также найдете другие с большим количеством функций, который можно купить в Интернет-магазине ГЛАВА 17 Противостояние атакам типа «отказ в Атаки, вызывающие нехватку памяти атаки активную системной памяти. При запасов физической памяти одна надежда — на выгрузку содержимого в странич ный файл на диске. Программисты слишком уж часто забывают проверять ность выделения памяти функцией просто предполагая, что памяти всегда более чем И еще: при нехватке памяти некоторые функции иниции руют исключения — например, функции и хотя в XP/.NET Server ведет себя иначе. Учтите: при работе с драйверами устройств невыгружаемый пул представляет собой более ограниченный ресурс, чем обычная память, Дэвид (David Meltzer) нашел показательный пример, работая в ком пании Internet Security Systems. Он обнаружил, что каждое подключение к компь ютеру под Windows NT 4 и с Terminal Server Edition требует ния одного мегабайта памяти (в базе знаний Microsoft Knowledge Base есть ста тья с описанием этой проблемы — 38/6/0 О ASP). На маломощной машине Дэвида, которую он применял для тес тирования, рост числа подключений быстро приводил почти к полному «зависа нию* компьютера. Если компьютер с Terminal Server настроить корректно (то есть с учетом объема памяти, приходящегося на одного пользователя), то эта проб, ма превращается в проблему нехватки ресурсов (описанную в следующей части) — из-за ограничения на число доступных сеансов затруднен доступ к серверу.

выход из этого — не создавать пока не уста новлено, на другом конце подключения находится правомочный клиент, Вы ведь не чтобы злоумышленник легко заставил приложение выполнять ресурсоемкие операции.

Атаки, вызывающие нехватку ресурсов Во время таких атак ресурсы системы расходуются вплоть до их щения. Существует много методик противодействия таким атакам, а выбираете вы сами на основании модели опасностей. Проиллюстрирую на примере обна руженной мной возможности успешной атаки. В Windows NT при запросе диспет чера локальной безопасности LSA используется объект-описатель Я специально искал способы нанесения вреда и поэтому написал ко торое запрашивало но не закрывало их. Атакуемая система смог ла предоставить приложению 2048 после чего прекратила их выдачу и другим — результате прекратился доступ в систему пользователей и перестали выполняться другие важные функции.

проблемы нехватки LSA-описателей довольно изящно, и его стоит более подробно. Итак, для каждого пользователя резервируется число Каждый отдельно взятый пользователь в состоянии израсходовать свой запас и вызвать отказ в служивании, но только по отношению «к система тупной, так как для анонимных пользователей также выделен особый пул. Отсю да извлечь важный урок: никогда не анонимным 460 Часть III Дополнительные методы создания защищенного кода лям потреблять большие объемы важных ресурсов, будь это описатели, память, дисковое пространство или даже пропускная способность сети.

Один подход к решению проблемы — установить квоты. В некоторых случаях квоты становятся причиной атаки из-за нехватки ресурсов, поэтому в этом деле необходимо соблюдать осторожность. Пример: приложение, порождающее новый рабочий поток для каждого нового подключения к Если не ограничить число рабочих потоков, грамотный взломщик запросто создаст тысячи потоков и спро памяти и процессорного времени. Если же предупредить по добную ситуацию, ограничив число порождаемых потоков, взломщик просто израсходует выделенное число при этом система успешно будет проти востоять, чего не скажешь о приложении, Проклятые взломщики! Но что же Может завести таблицу с адресами клиентов и налагать ограничения в зависимости от хоста-источника запросов.

Сколько сеансов может потребоваться хосту? Я обнаружил, что в рассматривае мой ситуации наиболее активно обслуживающий клиентов Terminal Services сер вер сотню поэтому ограничил число сеансов с од ного хоста десятью. Вы можете столкнуться с подобной проблемой, если большин ство ваших клиентов за прокси-серверами. Перед разработкой планов противостояния атакам нехватки ресурсов стоит изучить характер поведения клиентов приложения. И еще: с переходом на IPv6 у отдельных систем может быть много IP-адресов, к тому же этот протокол предусматривает анонимные адреса.

После полного перехода с IPv4 на поддержка таблиц с адресами источников потеряет смысл, так как каждый адрес займет в четыре раза больший объем памяти, Более совершенный способ — выделить квоту отдельным клиентам приложе ния. Конечно, такой подход что сначала пользователям придется пройти стадию идентификации. Если действительно решили использовать установку квот для противостояния вызывающим нехватку ресурсов, не забудьте сделать квоты настраиваемыми. Если их зафиксировать, всегда найдется клиент, которому потребуется чуть больше ресурсов.

Один из наиболее совершенных способов борьбы с нехваткой ресурсов — запрограммировать приложение так, чтобы его поведение менялось в зависимо сти от того, подвергается оно в данный момент атаке или нет. Так работает защи та от (SYN flood) в продуктах Microsoft: когда достаточно, система ведет себя нормально, если же ресурсов начинает не хватать, система отключает неактивных клиентов. В файловых службах и службах печати Microsoft [протокол (Server Message и NetBIOS] применяется аналогичная методика. При таком подходе необходимо вести список клиентов, чьи сеансы протекают нормально. В некоторых случаях прибегают и к более сложной логи ке. Например, злоумышленнику легче организовать атаку, когда аутентификация не выполняется. Поэтому можно налагать «санкции» на сеансы без аутентифика ции и завершать их, а к сеансам пользователей, которые предоставили необхо димые реквизиты, относиться доверительно. Интересный подход подавления атак на протокол TLS (Transport Level Security), вызывающих нехватку ресурсов про был представлен на посвященной безопасности конференции Security Conference. «Using Client to Protect — доклад с описанием этого подхода представили Дрю Дин (Drew Dean) из Xerox PARC и Адам Стабблфилд ГЛАВА 17 Противостояние атакам типа «отказ в (Adam из Университета (Rice University). В этой методике предусматривается работы протокола при атаке на него.

вы член сообщества то полная доклада вам доступна на странице Для борьбы с атаками также можно в совокупности и корректно настроенные тайм-ауты. Для всех упомянутых случаев можно дать только общие рекомендации. Выбор методики защиты определятся индивидуально в каждом конкретном случае и зависит от приложения и его пользо вателей, Атаки, вызывающие снижение пропускной способности сети Возможно, лучшие примеры атак, направленных на снижение про пускной способности сети, — это атаки с применением сервисов echo и chargcn (генератор символов). Первый просто возвращает в ответ полученные а второй на любого нескончаемый поток символов. Эти литы изначально предназначались для диагностики сети и оценки способности между двумя точками. Оба сервиса работают как по протоколу так и по TCP. Что же если подменит пакет, исходя щий с порта chargen, на пакет другого сервиса и направит его сервису для широковещательной рассылки? Очень скоро у нас появится несколько сис исступленно пакетами с echo- па chargen-порт. Если службы неудачно, то возможна даже подмена адреса источника на широ ковещательный адрес, причем занятая часть полосы пропускания канала будет рас ги в геометрической прогрессии с числа участвующих серверов, — мой друг называет это борьбой за Вы можете возразить, что я привел нелепый пример, но многие старые службы chargcn и echo, в том числе поставляемые в составе Windows NT 4 и более ранних Windows, были подвержены этому типу атак. Проблема решается, если применить здра вого смысла, когда вы принимаете о том, кому все-таки адресован этот бесконечный поток данных сервиса chargen. Поэтому реализаций сервисов chargcn и не отвечают на запросы с зарезервированных портов (с номером порта меньше 1024), а также на широковещательные пакеты, Дэвид о котором я уже упоминал, обнаружил этого типа атаки, предполагающую подмену UDP-пакета с порта системы под лением Windows NT другой системе Windows NT. Этот порт принадлежит службе точек вызова (RPC endpoint mapping service). Определитель просматривает пришедший пакет, его «мусорным» и отправляет в ответ пакет об ошибке. Вторая система получает об ошибке, проверяет, яв ляется ли оно ответом на известный ему запрос и в ответ первому сер веру пакет с другой ошибкой. Первый сервер опять возвращает ошибку и так да лее. Процессоры на системах входят «в ступор», а доступная полоса сети резко Недавно была обнаружена и устранена ана логичной атаки на другой 462 Часть III Дополнительные методы создания защищенного кода DoS-атакам такого типа противостоять легко — достаточно обеспечить проверку содержимого запросов перед ответом. Если поступивший пакет выглядит абсолютно лучшая линия поведения — отбросить его и ничего не посылать в ответ. Отвечайте только на те запросы, которые соответствуют правилам про токола, даже если вам придется добавить дополнительную логику для исключе ния пакетов, направленных по широковещательному адресу или на зарезервиро ванный порт. Атакам, направленным на снижение пропускной способности сети, больше всего подвержены сервисы, основанные на протоколах без создания под такие, как (Internet Control Message Protocol) и Как в реаль ной жизни не стоит отвечать на некоторые вопросы, так и здесь существуют зап росы, на которые лучше вообще не реагировать.

Резюме Очень сложно противостоять DoS-атакам, и часто невозможно решить проблему целиком. Тем не менее противостояние таким атакам должно стать частью общей процедуры обеспечения безопасности. Реализация защиты от некоторых типов атак, особенно вызывающих нехватку ресурсов, иногда требует внести существен ные изменения в проект приложения, поэтому не стоит откладывать рассмотре ния DoS-атак до последнего момента — это способно вызвать серьезные измене ния графика разработки.

Причина практически всех случаев аварийного завершения приложений — некачественно написанный код. Предотвратить такие ситуации можно, тщатель но просмотрев код и протестировав приложение подачей на его вход самых раз нообразных данных. Атаки с перегрузкой процессора вызывают проблемы с про изводительностью — они обнаруживаются при профилировании кода с подачей на вход некорректных данных. Нехватка ресурсов или памяти возникает из-за непродуманной архитектуры приложения, и она часто требует ввода дополнительных механизмов защиты для обнаружения атаки и последую щей смены поведения приложения. Проанализировав, как приложение будет ре агировать на некорректные сетевые вы сможете защититься от на снижение пропускной способности сети.

Создание безопасного кода в главу я начну с рассказа. Когда я готовился к на Microsoft Professional Developer's Conference (ноябрь 2001 один мой друг высказал положение, что скоро я окажусь без работы, потому что с управляе мого кода и Framework все проблемы с безопасностью исчезнут. Именно фраза заставила переписать код, демонстрирующий внедрение SQL-кода, с C++ па чтобы показать, что мой друг ошибся.

Управляемый код действительно избавляет разработчиков (особенно мистов на С и от многих задач по обеспечению но это не значит, что разработка приложений превратится в автоматическую цедуру. Я надеюсь, что описанные в этой главе правила проектирования и про граммирования пригодятся вам при создании ваших первых приложений для Зачем я это говорю? Да затем, что мы на пороге массового перехода на Microsoft и чем раньше начать популяризацию безопасности, тем скорее ки научатся применять безопасные методы программирования в этой среде, вы играют же от этого все. Я покажу некоторые ошибки реализации кото рых легко избежать, а также проверенные методики, которым настоя тельно рекомендую следовать при создании программ с вой среды CLR (Common Language Runtime), Web-сервисов и XML.

Имейте в виду, что многие советы из других также можно применять [ля управляемого кода, в том числе такие, как;

• не хранить секреты в коде или конфигурационных файлах • не создавать собственные алгоритмы или реализации существующих алгорит мов шифрования, а применять классы пространства имен System.Security.Cryp • никогда не доверять входным данным, пока не проверена их корректность.

464 Часть III Дополнительные методы создания защищенного кода Управляемый код в снижает общую уязвимость системы, в том числе по отношению к таким опасностям, как буфера и некоторые про блемы доверенного мобильного кода, включая элементы управления ActiveX.

диционные механизмы защиты в Microsoft Windows предусматривают только идентификацию участника безопасности. Иначе если система доверяет пользователю, код выполняется в контексте его учетной записи и обладает же привилегиями, что и сам пользователь. Технология ограниченных маркеров в Windows 2000 и последующих ОС семейства устраняет часть с этим проблем (подробнее об ограниченных маркерах — в главе 7), В предусмотрены дополнительные механизмы обеспечения безопасности:

уровень доверия коду определяется не только привилегиями пользователя, но и системной политикой и подтвержденными свойствами (цифровая подпись или сайт-источник кода) самого на основании которых принимается о предоставлении разрешений, Это очень важно, так как в мире Интернета часто приходится выполнять код, авторство которого и который не предоставляет никаких гарантий безопасности. Доверяйте пользователю чем коду (здесь речь идет об од ном из аспектов доверия на основании личности а не характере самого кода) — в этом случае высокопривилегированные пользователи, не рис куя ничем, смогут выполнять код. Наиболее типичный случай — исполнение сценариев па Web-страницах: запуск сценариев практически с любого Web-сайта (естественно, при условии безопасной реализации браузера) безопа сен, так как права сценария строго ограничены. Появившееся в понятие до верия на основе кода обеспечивает намного большую гибкость и позволяет вы баланс между защитой и широтой функциональных возможнос тей. Сейчас доверие определяется на доказанных свойствах, а не на жесткой пре допределенной модели, как в случае с Web-сценариями, Примечание По моему лучшие и наиболее безопасные приложения — те, в которые применяются оптимальные механизмы защиты, встроен ные в ОС и так как каждая «закрывает» определенный класс бре шей. Но не существует универсального подхода, поэтому важно пони мать, какие технологии оптимальны в той или иной ситуации. А для этого следует применять модели Однако внимание: вы не в полной безопасности. Это впечатление ложно! Хотя архитектура и код сводят на нет риск некоторых атак, их нельзя считать панацеей от всех бед.

Внимание! защищает от многих напастей, но это не значит, что можно программировать спустя рукава. Даже самые лучшие механизмы защи ты не если не следовать базовым принципам безопасности.

Прежде чем познакомить вас с оптимальными методиками реализации защи ты в управляемом коде, я сделаю небольшое отступление и расскажу о защите доступа к коду (Code Access Security, CAS) в ГЛАВА 18 Создание безопасного кода в Безопасность доступа к коду в картинках В этом разделе в максимально наглядной форме описан к коду в CLR. Кроме того, вы узнаете новые которые пригодятся при чтении этой главы. Однако, если вам нужен детальный разбор этой рекомендую книгу Framework Security» (см. библиографический Я не стану вдаваться в детали, а просто продемонстрирую CAS в конкретной ситуации: оформление книги в библиотеке. Дела обстоят так: Кэрол нужна книга библиотеки, в которой она не записана, поэтому она просит своих друзей и Сэнди взять книгу (рис. 18-1).

Сэнди, ты не могла ты не могла бы Я возьму для меня книгу взять для Кэрол эту книгу из библиотеки? из библиотеки?

Кэрол Вики Сэнди Рис. 18-1. Кэрол книгу из библиотеки через друзей В реальности все сложнее: если будет выдавать книги всем подряд, очень скоро фонды иссякнут, так как на свете не так уж много людей. Поэтому книги защищают правилами — их выдают только абонентам лиотеки. К сожалению. Кэрол не записана в библиотеку (рис. 18-2).

Правило те, на кого брать книги в библиотеке Кэрол Вики Рис. 18-2. В действуют правила выдачи поэтому, не будучи абонентом, Кэрол не сможет взять ни одной книги Невероятно, вы только что познакомились с основами CAS! Теперь эту же си туацию выразим в терминах Начнем с рис.

Часть III Дополнительные методы защищенного кода Политика безопасности те, на кого не могла бы ты вправе книги для меня книгу в из библиотеки?

Сэнди ', Цепь Сборка Рис. 18-3. Библиотечные правила в терминах CAS В мире способы обойти существующие в резуль тате чего Кэрол получит-таки книгу, конечно, только если соблюдаются некото рые условия, налагаемые Вики и Сэнди. Посмотрите на ситуацию на рис. 18-4, здесь добавлены некоторые модификаторы и названия в CAS.

Deny{) Я не стану для Я смогу кого бы то ни было для Кэрол книги, книги и, таким нарушать установленные после года правила Кэрол Вики Сэнди Рис. 18-4. на работу системы защиты Как я уже говорил, цель этого набега* на CAS, только чтобы вы получили общее как она работает.

Рекомендую: утилита FxCop Прежде чем рассказать вам о методиках безопасного и про считаю своим долгом сообщить о полезной утилите FxCop (она доступна на сайте которая должна быть в арсенале каж дого разработчика. FxCop — инструмент анализа который соот ГЛАВА 18 Создание безопасного кода в ветствие сборок рекомендациям по в каркасе — Framework Design Guidelines Этим средством следует проверять создаваемую сборку и устранять найденные ошибки. Как и в случае других инст рументальных то, что FxCop не находит никаких брешей защиты, отнюдь не значит, что программа абсолютно безопасна, а о неплохом на чальном состоянии кода в безопасности. На рис. 18-5 показан анализа сборки с помощью Примечание FxCop может создавать файл со списком всех ошибок в сборке.

Однако если вам нужен более удобочитаемый отчет, добавьте после пер вой строки:

такую:

I В В 0 Е 3= I Рис. обработки сборки утилитой FxCop Две стандартных обнаруживаемые FxCop — отсутствие стро гого имени сборки и отсутствие в сборке запросов Проанализиру ем каждую по отдельности, Назначение сборкам строгих имен Имена — одна из самых слабых форм аутентификации или подтверждения под линности. Если незнакомый человек предложит вам компакт-диск с файлом;

по имени excel.exe, запустите ли вы его на исполнение? Наверняка нет. Но те, кото 468 Часть Дополнительные методы создания защищенного кода рым «до нужна работы с электронными может, и подумают, что это приложение Microsoft Excel. Но как проверить, действительно ли это Microsoft Excel? В подобная проблема подмены реша ется путем назначения строгих имен, состоящих из простого текстового имени номера версии и информации о регионе, а также открытого ключа и циф ровой подписи.

имя создают, сгенерировав строгую пару ключей для имени Синтаксис таков:

SN -k Результирующий файл keypair.snk содержит закрытый и открытый ключи, пос применяется для проверки подписи сборки. (Я не стану объяснять осно вы асимметричного для этого есть масса книг по криптографии, некоторые указаны в библиографическом списке.) Если пара ключей чена не просто для экспериментов, то и относиться к ней следует соответствую щим образом, то есть со всей осторожностью.

Обратите внимание, что строгое имя основано только на паре ключей, а не на как в Будучи разработчиком, вы вправе создать пару ключей, определяющую ваше отдельное частное пространство имен. Если другие не знают закрытого ключа, им не удастся использовать это имен.

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

В дополнение к строгим именам вы вправе подписать сборку по методу Authen ticode, чтобы идентифицировать создателя программы. Для этого сначала созда ют подпись со строгим именем сборки, а затем для нее подпись Authenticode.

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

Внимание! В отличие от сертификатов, закрытые ключи строгих нельзя отозвать, поэтому следует предпринять исключительные меры предосторожности для их защиты. Неплохое решение задачи — одного который будет отвечать за закрытый ключ и хра нить его на дискете в своем сейфе.

Примечание В настоящее время в строгих именах ключи RSA.

Затем извлеките открытый ключ из пары командой:

SN -p keypair.snk Сейчас объясню, почему это так важно. Подписание происходит только в мо мент компиляции кода и генерации двоичного файла, когда вы ссылаетесь на ключ, используя директиву:

ГЛАВА 18 Создание безопасного кода в [assembly:

В обычном приложении Visual Studio эта директива хранится в или В Visual Basic она так:

Вы должны понимать, что при такой операции высока вероятность раскры тия закрытого ключа из-за неосторожности нерадивого программиста.

снизить риск, отложенное подписание, когда работает только откры тый ключ, а не вся пара. Теперь у программистов нет доступа к закрытому ключу, и весь процесс подписания выполняется до поставки кода клиенту командой:

SN -R Однако компьютеры следует настроить на про верки подписи, потому что у сборки нет строгого имени. Для этого служит ко манда:

SN Внимание! Имейте в что на сборки со строгими именами могут только другие сборки со строгими именами.

Чтобы реализовать отложенное подписание, в Visual Basic надо в сборку строку:

в эта строка так;

[assembly:

Совет Для ежедневной, работы над сборкой достаточно ной подписи открытым ключом.

Сборки со строгими именами и ASP.NET Сборки со строгими именами, поддерживающие Web-приложен следует располагать в глобальном кэше сборок (global assembly cache, GAC) серве ра с применением конфигурационного инструмента Configuration или Причина — в механизме загрузки подписанного кода в ASP.NET.

Разрешения на доступ к сборке Разрешения на к сборке — это механизм, позволяющий CLR лять, что требуется программе для выполнения ее задачи. Хотя разрешения и нео бязательны для работы и компиляции программы, причины поддержки разреше ний весьма серьезны. Когда программа требует разрешения вызовом метода De mand, CLR проверяет, есть ли у кода, вызывающего вашу программу 470 Часть III Дополнительные методы создания защищенного кода разрешения. Без запрос отклоняется. Проверка разрешений реализо вана в виде прохода стека (stack walk). Она важна как с точки зрения удобства использования, так и безопасности, программе предоставляются минималь ные необходимые для работы разрешения, а также она не получает лишние раз которые ей не нужны, Что проход стека?

Проход стека — важная часть системы защиты в среде,NET. Прежде чем доступ к защищенным ресурсам, среда исполнения проверяет, все ли функции, код, который пытается обратиться к имеют на Это проход или сто стека.

Требуйте минимальный набор разрешений Запрос разрешений повышает вероятность того, что если программе бу дет позволено выполняться, то работать она будет корректно. Если не позаботиться о минимальном наборе разрешений, потребуется дополнительный код обработ ки исключений из-за отказа в нужных разрешениях. Запрос разрешений гаран что приложению предоставляются только нужные разрешения. Следует запрашивать только те которых действительно нужны программе, и не более того.

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

[assembly:

Read = Примечание На момент должны быть известны все параметры декларативного Для определения минимального необходимого набора разрешений рекомен дуется использовать Если среда исполнения не в состоянии пре доставить приложению минимальный набор, инициируется исключение Policy Exception и приложение на исполнение не запускается.

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

[assembly: Unrestricted = [assembly: Unrestricted = ГЛАВА 18 Создание безопасного кода в Если в какой-то момент вы заподозрите приложение в участии в атаках на файловую систему или во связанных с доступом к файлам, вспомните.

что у него (без шуток), так как в нем жестко прописан отказ от доступа к файлам, Запрашивайте необязательные разрешения Система безопасности предоставляет программе возможность запро сить необязательные разрешения, то есть те, что но не необходимы для корректной работы. При этом следует позаботиться о перехвате из-за программе необязательных В качестве при мера приведу поддерживающую локальное сохранение игры и требующую необязательное разрешение Отказ в таком никак не скажется на игре, просто пользователю не удастся сохранить текущую игру. Вот пример такого кода:

[assembly: Unrestricted = Если не запрашивать необязательные программе будет предостав лен максимум разрешений, предусмотренный политикой, за вычетом от которых программа явно отказывается. Вы вправе отказаться от любых зательных вставив такую конструкцию:

[assembly: Unrestricted = В результате среда исполнения предоставит следующие разрешения:

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

Императивные и разрешения Как вы, наверное, заметили, разрешения на сборки выделяются квад ратными или угловыми скобках в и Visual Basic соответственно. Их (declarative и другой метод запроса разрешений императивный.

шения применяются для прямого запроса разреше ний и реализуются созданием в программе. Напри мер, так:

new Этот код если не получает разрешения на чте ние XML-файла. Обязательно предусмотрите перехват и обработку чений, в противном случае среда исполнения остановит исполнение граммы.

У метода свои преимущества и недостатки. Декларативные раз удобны в работе и заметны в Их можно про 'сматриватъ Permissions View для просмотра 472 Часть III Дополнительные методы создания защищенного кода аудита применяйте параметр Код проверки не удастся обойти ни при обстоятельствах, причем такие ограничения разре шается устанавливать для целых классов.

декларативных разрешений в том, что они должны быть известны на момент Примечание Запросы на разрешения сборке выясняют вызовом:

-а Он какие разрешения требуются сборке при нормальной работе. Другой способ — вызов в Framework SDK, которая показывает запрашиваемые сборкой разрешения.

Злоупотребление методом Assert Метод Assert в позволяет коду и последующим вызывающим программам по цепочке выполнять действия, на которое у кода а у вызываю щих его программ нет. Вызывая Assert, код как бы говорит: «Верьте мне — я знаю, что делаю». Далее в коде обычно следует безобидная для запроса которой вызывающей программе необходимо особое разрешение.

Внимание! Не путайте метод с кой функцией в языках С и или методом Framework. Последний вычисляет значение логического выражения и отображает диагностическое если выражение ложно.

приложению требуется считать конфигурационный или индексный файл, но у него нет разрешения на ввод/вывод файлов. Если вы уверены, что файл будет обрабатываться безопасно, вы вправе «поручиться» за вызывающий процесс и предоставить ему доступ к файлу.

Таким образом, существуют разные ситуации: в одних подтверждение безопасно, в других — нет. обычно применяется в ситуациях, когда доверенную биб лиотеку вызывает значительно менее доверенный код и необходимо пресечь проход стека. Представьте себе, что вы реализуете класс для обращения к файлам через USB-интерфейс, который называется и наследует Программа обращается к файлам, вызывая USB API Win32, но нам нужно, чтобы вызывающие программы получали разрешение не на всякий вызов неуправляе мого кода, а только на операции файлового ввода/вывода По этому UsbFileStream подтверждает право (на Win API) и требует разрешения чтобы удостовериться, что у вызыва ющей программы есть права на файловый ввод/вывод.

Однако любой код, принимающий имя файла из ненадежного источника (на пример, от и затем модифицирующий сам небезопасен. Что произойдет, если пользователь направит программе запрос на удаление Удалит ли она файл? В принципе, да, особенно если список управления доступом ГЛАВА 18 Создание безопасного кода в (ACL) файла «слабый», а приложение выполняется под административной ной записью или файл расположен на томе FAT.

При выполнении анализа программы исследуйте все случаи применения Assert, перепроверяя, действительно ли безобидны такие вызовы, Assert без Demand или с но со слабым разрешением. Например, ручательство для работы с кодом и разрешение на доступ к системной пере менной окружения, Примечание Чтобы поручиться за вызывающую программу, приложение дол жно само обладать требуемым разрешением.

Внимание! Соблюдайте особую осторожность, предоставляя на неуправляемого кода установкой в результате ошибки в программе непреднаме ренный вызов неуправляемого кода.

Подробно о Demand и При создании приложения с вызовом методов и Assert следуйте некото рым простым рекомендациям. Программа должна подтверждать одно или несколь ко разрешений, когда требуется исполнить но безопасную операцию, а вызывающим программам такое разрешение не следует. Заметьте: что бы иметь возможность подтверждать разрешение, программа должна сама обла дать им, а также свойством Assertion. Последнее — это право разрешения.

Например, если приложение подтверждает то это разрешение должно у приложения, но не у вызывающих его программ. Если же приложение подтверждает FilelOPermission, не обладая таким то при проходе стека инициируется исключение.

Как уже говорилось, метод Demand позволяет потребовать наличия одного или нескольких разрешений у вызывающей программы. Пусть приложении элект ронная почта применяется для отправки уведомлений и в приложении но нестандартное разрешение которое приложение требует у вызывающей программы. Если у нее такого разрешения нет, запрос не выпол нится, Внимание! При запросе не проверяются разрешения кода, функцию а только вызывающих его программ. Несмотря на что у функции Main ограниченные разрешения, она сможет полного доверия, так как нет вызывающих ее программ. Чтобы рить разрешения кода, нужно или войти в функцию и оттуда Demand — в этом случае разрешения вызывающей программы проверя вызвать метод который То есть инициируется проход стека. — Прим.

474 Часть III Дополнительные методы создания защищенного кода напрямую увидеть, предоставлено ли сборке разрешение (причем именно текущей сборке — у вызывающих программ его может и не быть). Это совсем не означает что вы вправе создать злонамеренный код в Main, и он будет работать! Как только код вызывает классы, выполняющие по опасные задачи, инициируется и про ход стека.

Внимание! Из соображений производительности не следует требовать разре шения при вызове кода, который сам запрашивает его. Этим вы просто вызовете излишний проход стека. Например, незачем требовать при вызове так как Framework делает это за вас.

Полезно писать подтверждающие и требующие разрешений. На пример, в приводимом сценарии рассылки сообщений по электронной почте код, который обеспечивает интерфейс с подсистемой электронной почты, может требовать у вызывающих программ разрешения (ваше пользо вательское разрешение), а затем, при записи сообщения в порт SMTP. — разреше ния SocketPermission. В такой ситуации вызывающие программы в состоянии от правлять только электронную почту, но им не направить данные в другие порты, что в принципе разрешает SocketPermission.

Где искать разрешение вызывать неуправляемый код — привилегия.

из рамок управляемой среды, код в принципе может делать на компьютере все, что угодно, — полномочи ями текущей учетной записи Так где находится разрешение Оно прячется в других Некоторые разрешения представляют собой простые решения уровня, другие сложнее. неуправляемый код — это решение двоичного уровня: программе нет управляемый код. Возможность доступа к файлам — этим управляет класс более сложна. Здесь доступа: программе может предоставляться право записи в один файл и, доступ только на к другому Это не простое решение двоичного уровня. Разрешение код различными флагами класса Вот пример;

Нельзя Assert для разрешения дважды — это вызывает исключение. Если требуется подтвердить более одного разрешения, следует создать набор из них, в него все нужные, и «поручиться» за набор целиком:

try { ps = new ГЛАВА 18 Создание безопасного кода в ps.

} catch e) // Ошибочка вышла.

Минимизация набора подтвержденных разрешений Сразу по завершении задачи, которая требует разрешения, сле дует вызвать чтобы отозвать ставленное вызовом Это пример принципа наименьших привилегий в дей ствии;

подтвержденное разрешение действует, только пока оно необходимо, и не более того, Следующий пример на демонстрирует, как применять тре и отзыв разрешений для отправки сообщений по Вызывающая программа должна иметь разрешение на отправку электронной по запросу пользователя она выполняет эту задачу через сокет хотя у нее нет разрешения на открытие какого бы то пи было сокета, using System;

using using // Это лишь часть большой // классы и пространства определяются в другом месте.

static void SendAlert(string alert) { Требуем наличия у вызывающей программы // на отправку электронной почты.

new // открывает лишь вполне определенный порт // на конкретном SMTP-сервере.

na = TransportType type = string host = int port = 25;

new SocketPermission(na, type, host, try { SendAlertTo(host, alert);

} finally { // отзывается в любом случае, даже при сбое 476 Часть III Дополнительные методы создания защищенного кода } ' Когда Assert, Deny и располагаются в одной области предпочтение отдается Deny, далее в порядке приоритетов стоит Assert и лишь затем — PermitOnly.

Представьте себе, что метод А() вызывает а тот в свою очередь вызывает кроме того запрещает разрешение В такой ситуации в состоянии подтвердить ReflectionPermission при условии, что сборка, кото рая содержит этот метод, обладает таким разрешением. Почему? Да потому, что, встретив Assert, среда исполнения останавливает проход стека и не обнаружива ет запрещение разрешения в А(). Вот простой где нет многих сборок.

private string filename = private void A() { new BO;

private void { CO;

private void C() { try { new try { = new } catch { } } finally { ;

Если убрать Assert из CQ, возникнет исключение при созда нии экземпляра класса StreamWriter из-за отказа в разрешении.

Методы Demand и Я уже демонстрировал примеры программ, требующих для нормальной работы разрешений. В большинство классов Framework уже встроено разрешений, поэтому вы не должны дополнительно запрашивать их всякий раз, когда вызывается класс, обращающийся к защищенному ресурсу Например, класс System.IO.File автоматически требует при открытии любого фай ГЛАВА 18 Создание безопасного кода в ла. Запрашивая при работе с классом Hie, вы инициируете лиш ний и довольно ресурсоемкий проход стека. Запрашивать разрешение следует только при работе с пользовательскими ресурсами, которым необходимы вательские разрешения.

Вызов инициирует проверку безопасности при (just-in-time) вызывающего метода и проверяет только вызывающую программу уровня. Если у последней нет достаточного ссылка запреща ется и среда исполнения инициирует исключение при загрузке и исполнении кода.

При обращении к LinkDemand полный проход стека инициируется, поэто му код остается подверженным (luring при которой менее код привилегированный код выполнить запрещенные первому действия. LinkDemand определяет только разрешения, непосредственно вызывающим программам, а не всем программам в цепочке вызовов. А последнее возможно только при проходе стека.

Пример бреши в защите из-за использования LinkDemand Познакомимся в проблемой поближе. Вот пример программы, Permit public string { return.

public string { return Да-да, я знаю, что этот код опасен уже тем, что ссылка на секретные данные зашита в самом тексте программы, а пароль хранится на диске, но в другом. Чтобы вызвать программа должна обладать пользователь ским разрешением Если она вызовет returnPassword, не обла дая таким разрешением, среда исполнения инициирует исключение защиты и в доступе к паролю будет отказано. Однако при обращении к вызов LinkDemand проверяет только разрешение returnPasswordWrapper по отно шению к returnPassword и не проверяет разрешений вызывающей программы по отношению к returnPassword, так как это уже второй уровень.

вызвавшая узнала пароль.

Поскольку вызовы LinkDemand выполняются только во время и проверяют разрешения у вызывающих программ только первого уровня, они работают быстрее, но за счет ослабления защиты.

Вывод: никогда не используйте LinkDemand без тщательного последующего кода. Полный проход стека занимает пару микросекунд, так что вам вряд ли удастся заметить незначительное замедление работы программы. Однако, если 478 Часть III Дополнительные методы создания защищенного кода в программе есть вызовы Link-Demand, придется тщательно перепроверить ее на предмет брешей в защите, особенно если вы не можете что все вызывающие программы пройдут должную проверку во время компоновки. С другой стороны, уверены ли вы, что при обращении к программе с ваш код не нарушит разрешения из-за отсутствия прохода стека? Наконец, когда LinkDemand относится к виртуальному производному объекту, что та кой же запрос есть у основного объекта.

Внимание! Для предотвращения неправильного употребления LinkDemand и отображения (reflection) (процесс получения информации о сборках и а также создания, вызова и получения доступа к экземплярам классов в период исполнения) уровень отображения среды исполнения инициирует полный проход стека для всего вызывающего кода с поздней привязкой. Это устраняет возможность доступа к защищенным объек там через отображение при условии, что в условиях раннего связыва ния доступ к ним запрещается. Поскольку выполнение полного прохо да стека изменяет семантику вызова LinkDemand при отображении и уменьшает быстродействие, разработчиками рекомендуется использовать вызовы Demand. В этом случае легче прогнозировать и планировать производительность, так как программы максимально точно со ответствует тому, что происходит на самом деле, Атрибут используйте с осторожностью Обычно вызов неуправляемого кода успешен только при условии, что все вызы вающие программы имеют нужное Однако специальный атрибут вызывающего неуправляемый код, проход стека. Вместо полного Demand код выполняет то есть ограниченную проверку на разрешение на доступ к коду. Это позволяет добиться значительного повышения если програм ма часто обращается к но вмесге с тем таит огромную опасность.

В примере метод отмечен атрибутом using using public class { private static extern int i);

public ГЛАВА 18 Создание безопасного кода в return } ;

В целях следует исключительно тщательно перепроверять все методы, отмеченные этим атрибутом, Внимание! Как вы, вероятно, заметили, у и много общего: с ними приходится идти на компромисс — или безопасность». Не обращайтесь к этим не убедившись, что выигрыш в быстродействии оправдывает не которое снижение надежности защиты. Если вы все-таки пользоваться следуйте следующим пра методы, которым этот атрибут, должны быть тыми (private) или внутренними (internal) и все входные параметры метода должны проходить проверку на корректность.

Удаленный вызов Знайте, что при удаленном (то есть при работе с объектами вызовов, ных от или междупроцессном вызове объектов, проверки решений, такие, как Demand, LinkDemand и не действуют.

означает, в что процедуры проверки безопасности не «проходят» по протоколу SOAP, если речь идет о Web-сервисах. Однако проверка доступа кода поддерживается между доменами приложений. Стоит также отметить, что удален ные вызовы поддерживаются только в полностью доверенных средах. Таким об разом, код, полностью доверенный в пользовательском контексте, не обязатель но правомочен в контексте сервера.

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

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

в конце концов, вы не всегда знаете.

кто создал производный класс. Имейте в виду: не следует полагаться на ключе вое которое подразумевает никакого контекста безопасности. За щищенный член класса доступен из класса, в котором объявлен, а также из любо класса, наследующего базовому, то есть точно так же, как в C++, Рекомендуется прибегать к созданию герметичных классов (в Visual Basic они называются то есть таких, которым нельзя наследовать. Гер метичный класс запрещено использовать как базовый. Таким образом исключить создание Помните: не стоит доверять коду только потому, что наследует вашим классам. Это одно из правил рованной «гигиены*.

480 Часть III Дополнительные методы создания защищенного кода Вы также ограничивать к методу из программ, назначая разрешения. Точно так же декларативные разрешения позволяют вам управлять наследованием классов. Метод позволяет потребо вать, чтобы у класса был или разрешение или чтобы классы, переопределяющие определенные обладали конкретным контекстом или разрешением. Например, можно создать который доступен только програм мам, обладающими разрешением public class Carol {.

class Brian : Carol В этом примере класс Brian наследует классу у которого должно быть разрешение EnvironmentPermission.

Требования к предоставляют множество возможностей: их при меняют для ограничения круга программ, которым разрешено переопределять виртуальные методы. Например, требовать пользовательское разрешение у любого метода, который пытается переопределить виртуальный метод public virtual void [] key) { m_key = key;

Вы также вправе ограничить доступ из сборок, указывая их строгие имена:

Или же увязать управление доступом с сервером-источником кода. Это похо же на возможность в ActiveX, о которой говорилось в главе 16. Следую щий пример демонстрирует, как это сделать, но помните: это никак нельзя счи тать заменой защиты доступа к коду. Не создавайте небезопасный код, надеясь на то, что программу удается вызвать только с определенного Web-сайта и таким образом отсечь злонамеренных пользователей. Это глупо! Если не верите, про сто вспомните об атаке с применением сценариев (cross-site private void { try { new catch (SecurityException e){ ГЛАВА 18 Создание безопасного кода в // С сайта, от Отказ от конфиденциальных данных в конфигурационных или XML-файлах Я уже говорил об этом в начале главы, но не премину повториться. Хранение ных в файлах конфигурации, например прекрасно работает, но толь ко при условии, что данные не конфиденциальны. Пароли, ключи и строки под ключения к базам данных следует хранить в местах, недоступных для о.

Размещение конфиденциальных данных в системном реестре более безопас Согласен, это нарушает принцип развертывания XCOPY (то есть простым копи рованием), но такова жизнь.

ASP.NET версии 1.1 поддерживает использование Data Protection для шиф рования секретов, хранимых в защищенном разделе реестра. (Подробно о DPAP рассказывается в главе 9.) Для этого применяются тэги и Когда такая защита задействована, файл конфигурации ет на раздел реестра и параметр, хранящий секретные данные. Для создания щищенных секретов в ASP.NET предусмотрена маленькая утилита командной строки Вот пример конфигурационного файл, который получает имя вателя и пароль для запуска рабочего процесса ASP.NET:

защищает секреты ключом шифрования машинного уровня, Хотя это и не избавляет от всех опасностей, связанных с сохранением секреток — получив физический доступ к компьютеру, взломщик в принципе получает воз можность добраться до данных, — подобный метод значительно поднимает безопасности конфигурационной информации.

Этот способ не применяется для сохранения произвольных данных приклад ной программы — только для того, чтобы обезопасить имена пользователей и па роли для идентификации в ASP.NET и данные поддержки состояния Сборки, поддерживающие частичное доверие Я прекрасно помню тот день, когда было принято решение добавить в Это продиктовано тем, что большинство атак выполняется из Интернета, где коду доверяют частично, разрешая выполнять лишь 482 Часть III Дополнительные методы создания кода отдельные задачи. Предположим, в некой компании требуется создать политику безопасности, в соответствии с которой коду из Интернета разрешается откры вать подключение через сокет на сервер, но запрещается печатать до кументы или читать и записывать файлы. Специалисты компании решили закрыть частично доверенному коду доступ к некоторым сборкам из состава и а это по умолчанию означает весь код, созданный сторонними раз работчиками, в том числе и вами. В результате «площадь приложения заметно сократится. Я хорошо помню тот день, потому что новый исклю чает случайный вызов кода потенциально враждебными Интернет-приложения ми. Установка этого атрибута — сознательное решение разработчика.

Если вы разработали программу, к которой могут обращаться частично дове ренные приложения, и выполнили весь необходимый анализ кода и тестирова ние защиты, примените на уровне сборки, чтобы разрешить вызов из частично доверенного кода:

Сборки, разрешающие доступ из частично доверенного кода, никогда не дол жны предоставлять объекты сборок, из которых доступ к частично доверенным приложениям запрещен.

Внимание! Имейте в виду, что сборки без строгих имен всегда доступны из частично доверенного кода.

Наконец, если приложение пользуется частичным доверием, то ему оказыва ется недоступным код, разрешающий доступ к себе только полностью доверен ных вызывающих программ, например сборки со строгими именами и без Вы должны также что следующая ситуация, когда сборка отказывает в разрешении.

У сборки со строгим именем А нет атрибута 2. Сборка со строгим именем В запрашивает разрешения и не получает их, та ким образом становясь частично доверенной.

3. В больше не может вызывать код Л, так не разрешает частично доверен ных вызывающих программ.

Внимание! следует применять только после тщательного анализа программы па предмет возможных послед ствий для защиты и принятия необходимых мер защиты от атак.

Проверка корректности управляемого кода, служащего оберткой для неуправляемого Вызывая неуправляемый код, а многие так и делают, так как это дополнительную гибкость, не забудьте удостовериться, что вызывающий код ка чественно написан и безопасен. Если вы устанавливайте атрибут ГЛАВА 18 Создание безопасного кода в позволяющий управляемому коду вызывать неуправля емый без прохода стека, еще раз спросите почему безопасно не у открытых вызывающих программ разрешения на доступ к неуправляемому коду Сложности с делегатами Делегаты в похожи на указатели на функции в C/C++ и в Framework для поддержки событий. Если программа принимает априори ничего нельзя сказать, каков делегат, кто его создал или каковы намере ния программы. Все, что вам известно: делегат вызывается при возникновения в вашей программе соответствующего Также неизвестно, что за код стрирует делегат. Пусть ваш событие;

рирует делегат АррА вызовом В принципе, делегатом может оказаться любое в том числе то, что приостанавливает или закрывает с, вызывая В этом случае после возникновения или сделает что похуже.

Есть способ защититься от подобных злонамеренных действий. В поддерживается строгий контроль поэтому если программа разрешает делегаты только с сигнатурой:

public delegate string count, string name, DateTime то зарегистрировавшая делегат, потерпит сбой при попытке вы зова так как его сигнатура не соответствует критерию.

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

чтобы разрешить делегату только читать конкретную системную и ничего более, вставьте в программу такие строки перед кодом ирования события:

new что применяется к коду делегата (то есть коду, мому по событию), а не к программе, которая его зарегистрировала. Поначалу вы будете в этом путаться.

Проблемы с сериализацией Особое внимание следует уделить классам, реализующим интерфейс если класса может содержать конфиденциальную Видите ли вы потенциальную дыру в следующей программе?

public void file) { Password p = new Stream stream = = new p);

!

484 Часть III Дополнительные методы создания защищенного кода public class Password: ISerializable { private String public :

// Конструктор public Password info, context) { sensitiveStuff = ;

// Функция public void GetObjectData info, StreamingContext context) { sensitiveStuff);

} У нет прямого доступа к данным, хранимым но он в состоянии вынудить приложение записать секретную информацию в файл (в произвольный файл, а это в любом случае очень доступ вызывающих программ можно, потребовав нужные Роль изолированного хранилища В некоторых ситуациях предпочтительнее использовать изолированное храни лище, а не обычный файловый ввод/вывод. Преимущество его в том, что оно состоянии изолировать данные от отдельных пользователей и сборок или пользо вателей, доменов и сборок. В первом случае изолированное хранилище, как пра вило, содержит данные пользователя, например имя пользователя, которые необ ходимы многим приложениям. В примере на показано, как это делается.

using IsolatedStorageFile = Во втором случае — изоляции в разрезе пользователя, домена и сборки — га рантируется, что только код определенной сборки получит к изолирован ным данным при выполнении следующих условий: когда приложение, применя ющее сборку, уже выполнялось в момент создания сборкой хранилища и когда пользователь, для которого создавалось хранилище, уже работал с приложением, Следующий пример на как создать такой объект.

ГЛАВА 18 Создание безопасного кода в Imports Dim isoStore As = _ Or Or Nothing, Nothing) Имейте в что хранилище также поддерживает емые профили, для чего достаточно установить флаг Перемещаемые пользовательские профили — это особенность Microsoft Windows (доступна в Windows NT/2000 и некоторых обновленных системах под управле нием Windows 98), которая обеспечивает перемещение данных пользователя при его перемещении с компьютера на компьютер.

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

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

XSLT Хотя XSLT не является уникальной особенностью Framework, она широко используется и пространстве имен Может что XSLT всего язык стилей, но на самом деле язык Поэтому XSLT следует про верять же любой другой или модуль кода, и обеспечить проверку корректности данных и отсеивания, к при меру, неожиданных типов Отключение трассировки и отладки перед развертыванием приложения Необходимость этой операции кажется очевидной, но, к сожалению, многие бывают о ней. Это плохо по двум причинам: получает слишком много информации и выполнение дополнительных операций отрицательно сказывает ся на быстродействии.

Есть три способа отключить перечисленные возможности. Первый — удаление действия DEBUG на странице свойств (Internet Information Services) (рис. 18-6).

486 Часть III Дополнительные методы создания защищенного кода Рис. 18-6. Следует операцию DEBUG из всех типов файлов которые не требуется, в данном случае речь идет о Отключить отладку и трассировку можно в самом приложении ASP.NET, доба вив в соответствующие страницы тэг Page Третий способ — изменение конфигурационного файла приложения:

enabled = debug = Отключение режима отображения подробной информации при удаленных вызовах По умолчанию параметр конфигурации ASP.NET устанавливается в что означает подробную информацию при локальном вызове и ни каких сведений при удаленных вызовах. Для облегчения приложения разработ чики обычно изменяют этот на промежуточных установочных серве но забывают восстановить значение по умолчанию непосредственно перед развертыванием. Этот параметр необходимо установить в remoteOnly (значение по умолчанию) или On. Значение не годится для серверов, эксплуатируемых в режиме.

<еггог ГЛАВА 18 Создание кода в Десериализация данных из ненадежных источников Никогда не выполняйте данных из ненадежных источников. Это тот же «Все входные пока не доказано но применительно к В есть классы в пространстве имен Serialization для упаковки и распаковки объектов посредством процесса се Однако ни в коем случае не должно данные, полученные из ненадежного так как воссозданный объект будет пользоваться на локальной машине тем же доверием, что и само приложение.

Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |   ...   | 10 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.