Книги, научные публикации
Pages: | 1 | 2 | 3 | 4 | 5 | -- [ Страница 1 ] --
том 2 альманах програ иста Тематический сборник материалов Library и Magazine ASP.NET Web-сервис Web-приложения альманах программиста Составитель Ю. Е.
Москва 2003 Оглавление 215 Дэвид Чеппел Новые технологии защиты Web-сервисов 216 Шохуд Проектирование Способность Web-сервисов к взаимодействию и формат XML-сообщений 237 Тим Доступ к передаваемым при взаимодействии с Web-сервисами 251 Тим Эвалд Web-сервисы Обязательные заголовки в Web-сервисах ASP.NET 264 Сринивасан XP Обмен информацией между документами Office и 276 Кен Спенсер Основы и тонкости Автоматизированное создание Web-сервиса 292 Web-приложения 301 Пол ASP.NET Быстрое освоение приемов разработки с помощью ASP.NET Starter Kits 302 Лефевр и Роберт Лэр ASP.NET Средства аутентификации и проверки форм в приложениях электронной 321 Яо и Дэвид Беспроводная Web Создание Web-приложений, способных взаимодействовать с любыми мобильными устройствами 340 Джеф и Кит Кларк Рекомендации по тестированию Web-приложений под нагрузкой Гарри Пирсон Скины для сайтов Настройка визуального представления сайта ASP.NET на основе XML-классов,... От составителя Уважаемый читатель!
Альманах программиста представляет собой тематический сборник статей из Microsoft Library и журнала MSDN по наиболее ак туальным и перспективным технологиям разработки программного обес печения. Он выпускается издательством Русская Редакция периодичес ки, по мере накопления материалов. Альманах избавляет вас от поисков нужной информации, опубликованной в отдельных номерах журнала MSDN Magazine или документах MSDN Library за 2001-2003 гг. Пер вый том был посвящен работе с базами данных, а второй Ч адресован про граммистам, имеющим представление о технологиях ASP/ASP.NET и же лающим не только углубить свои знания этих технологий, но и научиться применять их на практике.
Второй том альманаха состоит из трех тематических рубрик.
Х Microsoft ASP.NET. Аутентификация в ASP.NET, безопас ного ASP.NET-кода, обнаружение попыток несанкционированной мо дификации ASP.NET-приложений, состояние отображения (view state) концепция отделенного кода програм мирование форм в ASP.NET, потоки и асинхронные обработчики в сер верном Web-коде, перехват Web-запросов через HTTP-фильтры в ISAPI и ASP.NET, HTTP-конвейеры, развертывание ASP.NET-прило жений с помощью Visual Studio Х Web-сервисы. Технологии защиты Web-сервисов, взаимодействие между формат используемых ими сообщений, опреде ление обязательных заголовков в обмен информа цией между документами Office XP и Web-сервисами, автоматизиро ванное создание Web-сервиса в Visual Studio Х Другие Web-приложения. ASP.NET Starter Kits для быстрого осво ения приемов разработки Web-сайтов, средства аутентификации и проверки форм в приложениях электронной коммерции, создание Web-приложений, взаимодействующих с любыми мобильными уст ройствами, тестирование Web-приложений под нагрузкой, настройка визуального представления сайта ASP.NET на основе XML-классов.
От составителя Исходный код для статей альманаха можно скачать по ссылке, указанной в конкретной статье или в полном комплекте (для всех статей альманаха) с Web-сайта издательства Русская по ссылке zip.
Третий том альманаха будет посвящен тематике, связанной с базовыми концепциями и функциональностью Framework, в том числе систе ме типов, моделям защиты, механизмам отражения (reflection) и удален ного взаимодействия (remoting), криптографическим сервисам и сервисам взаимодействия с неуправляемым кодом.
В дальнейшем планируется выпуск альманахов по специфике языков граммирования, поддерживающих отладке и тестированию и другим темам. Если вас интересует какая-то специфическая тематика из материа лов Magazine или Library, обращайтесь на сайт издатель ства www.rusedit.ru или по адресу almanah@rusedit.ru. Мы постараемся учесть ваши пожелания в будущих выпусках альманаха.
Керчер Аутентификация в ASP.NET:
руководство по защите в В статье показывается, насколько важно учитывать вопросы безопасности при разработке серверных приложений. Как Microsoft Internet Information так и ASP.NET модели защиты, позволяющие при необходимости и получать правильный контекст защиты в приложении, Введение И разработчики, и архитекторы приложений уделяют большое внимание проблемам защиты. Приложения, хранящие конфиденциальную информа цию, необходимо защищать от атак злоумышленников и от конкурентов, пытающихся похитить информацию или интеллектуальную собствен ность. Проектируя модель защиты своего приложения, вы должны знать требования к безопасности с точки зрения бизнеса, а также понимать ог раничения, налагаемые выбранной моделью защиты на производитель ность, масштабируемость и Рекомендации защите Если вы разрабатываете серверное в его спецификацию сле дует включить раздел, посвященный защите. В функциональной специфи кации приложения нужно рассмотреть и, возможно, решить следующие вопросы.
Jeff Kercher. Authentication in ASP.NET: Security Library. Microsoft Corporation. 2001. August. Ч Прим.
в руководство по a Х Задачи защиты. Вы должны понять, что защищаете, а затем убедить ся, можете ли вы описать это на бумаге.
Х Риски. Оцените уязвимые места приложения. Кроме проанали зируйте значимость потенциальных угроз по отношению к бизнесу.
Х Аутентификация. Это прием удостоверений (credentials) от пользова теля и их проверка выбранными средствами. Пользователь (или при ложение/компьютер) рассматривается как участник системы безопас ности (security principal). Клиент должен предоставить удостоверения, позволяющие серверу проверить идентификацию участника. Опреде лив идентификацию, приложение может авторизовать участника для доступа к ресурсам системы. (Критерии выбора механизма аутентифи кации рассматриваются в следующем разделе этого документа.) Х Авторизация. Это процесс, в ходе которого выясняется, разрешен ли доступ к конкретному ресурсу по подтвержденной идентификации.
Х Защита передачи данных. Шифрование данных гарантирует невоз можность их прочтения или подмены при передаче по сети. Вы долж ны принять решение о требуемом уровне защиты данных при передаче.
Х Олицетворение (impersonation). Механизм, позволяющий серверно му процессу работать с удостоверениями защиты клиента. Б этом слу чае все операции выполняются сервером с использованием удостове рений клиента. Олицетворение не позволяет серверу обращаться к удаленным ресурсам от имени клиента. Подобный процесс требует де легирования.
Х Делегирование. Как и олицетворение, делегирование обеспечивает ра боту серверного процесса с использованием удостоверений защиты клиента. Однако делегирование Ч более мощный механизм, оно дает возможность серверному процессу обращаться к другим компьютерам, выдавая себя за клиента.
Х Защита средствами операционной системы. В этой части следует со здать соответствующие списки управления доступом (Access Control Lists, ACL) и продумать сетевую защиту, чтобы предотвратить несан доступ к защищенным ресурсам. Назначьте подходя щие соответствующим ресурсам, разрешая доступ только выбран ным участникам системы безопасности.
Х Физическая защита. Размещение серверного компьютера в защищен ном помещении. Не упускайте из виду этот базисный принцип.
Х Защита по правам доступа кода (code access security). Уровень дове рия к коду зависит от его источника и других характеристик. Вы дол жны знать, как создать собственные разрешения на доступ.
Microsoft Взаимосвязь IIS и ASP.NET Проектируя приложение, вы должны понимать связь между аутентифика цией Internet Information Services (IIS) и архитектурой защиты Microsoft ASP.NET. Тогда вы сможете правильно пользователей и получать корректный контекст защиты в приложении. Обратите внима что параметры защиты AS P.NET-приложения и IIS никак не связаны между собой и могут использоваться как независимо друг от друга, так и в сочетании.
Web-клиенты IP-адрес и домен разрешены?
Доступ запрещен Нет Нет Пользователь Запустить IIS Включен ли олицетворения в ASP.NET-приложение выполняется под идентификацией локального компьютера Да ASP.NET-приложение предполагает использование идентификации клиента Успешна ли проверка доступа?
(например ASP.NET Да Доступ разрешен Рис. 1. Взаимосвязь средств IIS и ASP.NET Аутентификация в ASP.NET: руководство по в IIS хранит параметры конфигурации, связанные с в метабазе. В свою очередь ASP.NET хранит параметры защиты (как и все остальные) в конфигурационных XML-файлах. Хотя обычно это облегчает развертыва ние приложений с точки зрения безопасности, выбранная в приложении модель защиты потребует правильной настройки как так и вашего (через его конфигурационный файл Взаимосвязь между IIS и ASP.NET показана на рис.
Провайдеры аутентификации ASP.NET и защита IIS Б ASP.NET аутентификация осуществляется на основе провайдеров аутен тификации, которые представляют собой модули проверяющие удо стоверения и реализующие прочие функции защиты, например генерацию cookie. ASP.NET поддерживает следующие провайдеры аутентификации.
Х Forms Authentication на основе При приме нении этого провайдера все запросы перенап равляются на указанную HTML-форму путем клиентской переадреса ции. После этого пользователь может ввести свои учетные данные (удостоверения защиты) и отправить форму обратно на сервер. Если приложение аутентифицирует запрос (логика проверки специфична для конкретного приложения), ASP.NET генерирует cookie, содержа щий удостоверения или ключ для повторного получения идентифика ции клиента. Последующие запросы содержат этот cookie в своем за головке, поэтому никакая аутентификация больше не требуется.
Х Passport Authentication (аутентификация через Passport). Это цен трализованная служба аутентификации, предоставляемая Microsoft и предлагающая участвующим сайтам механизмы единой регистрации и подписки на сервисы. ASP.NET в сочетании с Microsoft Passport SDK предлагает пользователям Passport функциональность, аналогичную Forms Authentication.
Х Windows Authentication (аутентификация через Windows). Этот провайдер пользуется возможностями IIS. После того как IIS проводит аутентификацию, ASP.NET использует маркер идентификации для авторизации доступа.
Чтобы активизировать конкретный провайдер аутентификации для ASP.NET-приложения, создайте в конфигурационном файле этого прило жения такую запись:
// Файл mode = Microsoft Помимо аутентификации, ASP.NET предоставляет механизм олицетворе ния, позволяющий настроить маркер защиты (security token) для потока приложения. Чтобы получить корректный маркер, нужно соответственно настроить аутентификацию IIS, провайдеры аутентификации ASP.NET и параметры олицетворения в ASP.NET. На рис. 2 показаны наиболее рас пространенные сочетания аутентификации IIS и провайдеров ASP.NET.
Вы скорее всего воспользуетесь Если вы применяете этот провайдер следующим способом аутентификации ASP.NET...
ASP.NET Forms Базовый Интегрированный Хэш Passport Сопоставление сертификатов Нет Анонимный (нестандартная аутентификация) Рис. 2. Взаимосвязь настроек защиты ASP.NET и IIS Аутентификация с помощью учетных Windows Если вы планируете аутентифицировать пользователей по учетным запи сям, хранящимся на контроллере домена Microsoft Windows NT или в службе каталогов Microsoft Windows 2000 Active Directory, то должны ис пользовать аутентификацию [IS в сочетании с провайдером Windows Authentication для ASP.NET, как показано на рис. 2. Тогда вам не придет ся писать никакого специфического кода для аутентификации. Когда аутентификация осуществляется этим способом, ASP.NET создает объект Windows Principal и связывает его с контекстом приложения для Аутентификация в ASP.NET: руководство по защите в пользователя. В результате ASP.NET-поток выполняется от имени аутентифицированного пользователя и может получить членство в его группе.
В некоторых случаях нужно обходить аутентификацию IIS и реализовать собственный способ. В ASP.NET это допустимо. Например, вы можете со здать свой проверяющий удостоверения пользователя в Active Directory, и самостоятельно создавать объект Windows Principal.
Существуют и другие способы, но тогда придется писать больше кода, чем при прямом использовании без применения учетных записей Windows Если вы планируете пользователей на уровне прило жения и при этом у нет учетных записей в Windows, то ско рее всего вы настроите IIS на анонимную аутентификацию. В этом случае рассмотрите следующие модули Х Без аутентификации. Применяйте, когда аутентификация пользовате лей вообще не проводится или когда она осуществляется специфичес ким модулем вашей разработки.
Х Формы. Применяйте, если хотите предоставить пользователям стра ницу для входа (logon page).
Х Passport. Применяйте при использовании служб Passport.
Олицетворение и делегирование За счет олицетворения ASP.NET-приложения могут при необходимости выполняться под идентификацией от имени которого они дей ствуют. Обычно олицетворение реализуется для управления доступом к ресурсам. Тщательно взвесьте, нужно ли оно в вашем случае, так как на олицетворение расходуются дополнительные ресурсы сервера. Делегиро вание Ч более мощная форма олицетворения, позволяющая серверному процессу обращаться к удаленным ресурсам от имени клиента.
При включенном олицетворении ASP.NET получает соответствующий маркер (token) от IIS. олицетворения по сравнению с аналогичным механизмом в традиционном ASP позволяет добиться в Web-приложениях более тонкого контроля за олицетворением. Для этого в файле Web.config приложения поддерживается специальный параметр.
Этот параметр может принимать три значения.
Х Олицетворение разрешено. ASP.NET подменяет маркер, полученный от IIS и выданный либо аутентифицированному пользователю, либо анонимной учетной записи Интернета.
ASP.NET Х Олицетворение разрешено и задана конкретная идентификация.
ASP.NET подменяет маркер, сгенерированный с использованием за данной идентификации. В этом случае маркер клиента не использует ся, даже если он есть.
В табл. 1 показан маркер потока, используемый ASP.NET для выполнения запроса в зависимости от трех настройки Заметьте, что учетная запись соответствует учетной записи, настро енной для анонимного доступа по текущему URL, и что такая запись не обязательно должна быть типа Учетная запись процесса Ч это учетная запись, под которой выполняется рабочий приложения (по умолчанию Ч System Account). Табл. 1. Маркер ASP-потока для конфигураций ASP и IIS Приложение В IIS указан IIS не указан размещено Олицетворение анонимный анонимный на ASP.NET доступ доступ UNC-pecypce Запрещено Учетная запись Учетная запись процесса процесса Разрешено IUSR_SERVER UNC-маркер IIS пользователь Разрешено, но задан Jeff* пользователь Jeff Советуем запускать рабочий процесс приложения ASP.NET под специальной учетной записью с меньшими привилегиями, чем у учет Аутентификация ASP.NET: руководство по в ной записи System по умолчанию. Это вызвано двумя основными причи нами. при взломе защиты злоумышленник не получит досту па с правами администратора. Во-вторых, это позволяет провайдерам про граммных сервисов (Application Service Providers, ASP) запускать при ложения под более учетными записями, благодаря чему эти приложения не смогут целостность сервера или выполнять дей ствия, требующие административных привилегий. Чтобы запустить рабочий процесс ASP под определенной учетной запи сью, добавьте элемент Кроме того, вы можете присвоить атрибуту одно из двух специ альных значений Ч SYSTEM или MACHINE. В обоих случаях для атри бута password следует указать так как конкретные удосто верения не требуются. Значение SYSTEM (задается по умолчанию) запус кает рабочий процесс под учетной записью System, a MACHINE Ч под особой учетной записью с префиксом ASPNET. Эта учетная запись анало гична учетной записи IWAM_MACHINENAME, используемой IIS для за пуска экземпляров при выполнении обычных ний. Учетная запись ASPNET создается при установке Если вы используете нестандартную учетную запись, то должны указать для нее права доступа к следующим каталогам. Х Доступ для чтения/записи к каталогу Tempo rary Files. В его подкаталогах размещаются динамически компилируе мые файлы. Х Доступ для чтения/записи к каталогу Необходим компиля торам при динамической компиляции. Х Доступ для чтения к каталогу приложения. Х Доступ для чтения к иерархии каталога так как в ней хранятся системные сборки. Обратите что АСЕ, требуемые для учетной записи ASPNET, создаются в процессе установки. При использовании специально настроенной учетной записи процесса помните об ограничениях, налагаемых в этом случае на применение оли цетворения. Хотя подменять идентификацию клиента по-прежнему мож но, задействовать расширенную форму олицетворения, при которой в фай 16 ASP.NET ле приложения определяется особая учетная запись олицетво рения, нельзя. Дело в том, что при таком варианте рабочему процессу нуж на привилегия SE_TCB_NAME (разрешающая ему действовать как ком поненту операционной системы), которой обычно нет у процессов с более идентификациями. Олицетворение для индивидуальных зап росов по-прежнему действует, так как IIS создает сеанс входа (logon ses sion) и передает маркер олицетворения (impersonation token) непосред ственно рабочему процессу. что это ограничение касается толь ко Windows 2000 и Windows NT 4. Расширения, введенные в Microsoft Windows XP, позволяют создавать определенные сеансы входа без этой привилегии. Дополнительную информацию см. в следующих главах из руководства Framework Developers Guide: Х How ASP.NET Security Х Х ASP.NET Configuration Concepts; Х Using IIS Authentication ASP.NET Impersonation. Дополнительные сведения об аутентификации в IIS 5.0 см. в статье Inter net Information Services 5.0 Authentication Methods Способы аутентификации Существует множество способов аутентификации в Web-приложениях Например, можно задействовать один из механизмов, поддерживае мых IIS, либо выполнять аутентификацию в коде приложения. При выбо ре способа аутентификации следует принять во внимание некоторые или все факторы из перечисленных: Х операционные системы на сервере и клиенте; тип клиентского браузера; Х число пользователей, а также тип и местонахождение базы данных с именами и паролями; Х условия развертывания (где работает приложение Ч в Интернете или интрасети, находится ли оно за брандмауэром и т. д.); Х тип приложения (например, интерактивный Web-сайт или неинтерак тивный Web-сервис); Х степень защищаемых данных; Х факторы, влияющие на производительность и масштабируемость; Х требования к авторизации приложения; например, приложение может быть доступно всем или же какие-то его части должны Аутентификация в ASP.NET: руководство по защите a быть доступны зарегистрированным пользователям, а остальные только администраторам. Выбор способа аутентификации Схема, приведенная в приложении А, поможет определить наиболее под ходящий способ аутентификации в зависимости от требований конкретно го приложения. Для этого ответьте на вопросы, клиент скую базу и модель развертывания. Проанализировав схему, изучите следующие подразделы, каждый из кото рых содержит более подробные сведения о различных способах аутенти фикации и схему дальнейших действий, которые помогут принять оконча тельное решение. В конце этого раздела вы сможете выбрать наилучший способ аутентификации. Что представляют собой выбора на 1. Должны ли пользователи регистрироваться? Требуется ли имя поль зователя и пароль для доступа к сайту или сервису? 2. Нужна ли Предоставляет ли сайт персонализиро ванный контент без регистрации пользователей? 3. Учетные записи пользователей? Хранятся ли они в домене Windows NT, Active Directory или где-то в другом месте, например в реляцион ной базе данных, альтернативной службе каталогов (Lightweight Directory Access Protocol) или в XML-файле? 4. Единый (single sign-on) или автоматический вход (seamless logon)? Вы хотите, чтобы пользователи регистрировались на соответствующей странице, или же вам нужна автоматическая аутентификация? Авто матическая аутентификация может потребоваться, например, для авто матического выполнения 5. Нужен ли защищенный вход? Следует ли максимально затруднить злоумышленникам перехват имен и паролей пользователей при их пе редаче по сети? Обычно решение принимается в зависимости от сте пени конфиденциальности данных, размещенных на сайте. 6. Будет ли приложение работать в Интернете? Предназначено ли ложение для работы за брандмауэром (тогда пользователи не аутентифицируются в домене) или для работы в интрасети (в таком случае пользователи, возможно, уже в домене)? 7. Нужно ли делегировать контекст защиты? Надо ли выполнять биз нес-компоненты под идентификацией вызвавшей их программы? Если да, потребуется олицетворение. Более того, если вам нужен доступ к таким системным ресурсам, как очереди сообщений, базы данных или файловые системы на удаленных компьютерах, вам понадобится оли цетворение на уровне делегата (delegate-level impersonation). 8. Работают ли серверы и клиенты только под управлением Windows 2000? Состоит ли ваша среда только из компьютеров под управлени ем Windows,2000, или же в ней есть клиенты, работающие под управ лением других операционных например Windows или Win dows NT 4.0? Анонимная аутентификация При анонимной аутентификации сервер не требует от клиента передачи пользовательских Это хороший выбор, если сайт или сер вис общедоступен и идентификация запрашивающего вас не интересует. В таком случае на браузеры не накладываются ограничения, вызванные не совместимостью с выбранным механизмом аутентификации. Когда сайт настроен на анонимную аутентификацию, доступ разрешается всем поль зователям. Важно что, даже если IIS настроен на анонимную аутентификацию, аутентификация может осуществляться на уровне ASP.NET, и тогда это нельзя настоящей анонимной аутентифика цией. В этом разделе предполагается, что как так и приложение не требуют регистрации. сценарии Анонимная аутентификация подходит, если: Х вам не нужно знать имя и/или пароль пользователя для входа или компонентов бизнес-логики; Х информация считается общедоступной. Анонимная аутентификация не годится, если: Х доступ пользователей ограничен по имени и паролю. Прочие соображения Выбирая анонимную аутентификацию, примите во внимание следующие соображения. содержащие только персонализированный контент Если вы разрабатываете сайт, содержащий только персонализированный контент, анонимная аутентификация может стать неплохим выбором. Пример Ч новостной сайт, предлагающий местные новости в зависимос ти от места проживания пользователя, но при этом не требующий явной регистрации. Персонализация может выполняться на основе cookie от дельно от аутентификации. Подробнее о cookie см. раздел Cookie далее в этом документе. Аутентификация в ASP.NET: руководство по защите в Олицетворение При анонимной аутентификации поток приложения будет выполняться под одной из следующих учетных записей: Х встроенной анонимной учетной записью Интернета Ч NENAME; Х учетной записью, настроенной в IIS для анонимного пользователя; Х системной учетной записью IIS. Если приложение использует другие ресурсы, такие как базы данных, очереди сообщений или общие файловые ресурсы с под держкой UNC, вам придется выдать соответствующие разрешения ано нимному пользователю. В этом случае рассмотрите следующие варианты. Х Создайте контроллер домена, в который входят все Web-серверы и сер веры приложений. Укажите, что анонимный пользователь обладает правами пользователя домена с соответствующими разрешениями на доступ к ресурсам. Это поможет централизации управления учетными записями. Х Если у вас нет домена, вы можете создать пользователя с одинаковым именем и паролем на каждом Web-сервере и сервере приложений. Од нако этот вариант не рекомендуется в силу сложности управления дуб лирующимися учетными записями. Анонимный Web-сайт, не использующий олицетворение ASP.NET, обладает самой высокой производительностью, но является наименее защищенным, Реализация Чтобы реализовать анонимную аутентификацию, настройте на нее IIS и сконфигурируйте соответствующую анонимную учетную запись. Настрой те ASP.NET через файл на отключение аутентификации. // Файл /> Базовая аутентификация IIS, настроенный на базовую аутентификацию, требует от браузера пере дачи удостоверений пользователя по HTTP. При этом пароли и имена пользователей кодируются по основанию Base64. Однако пароль считает ся небезопасным, так как раскодировать его сравнительно нетрудно. Бра узер диалоговое окно для входа, а затем повторно посылает ис 20 Microsoft ASP.NET ходный анонимный запрос с указанными удостоверениями, в том числе с именем и паролем пользователя. Всплывающее диалоговое окно входа может как устроить вас, так и не устроить Ч все зависит от требований вашей реализации UI. Большинство браузеров поддерживает базовую аутентификацию. сценарии применения Подумайте о базовой аутентификации, если: Х у ваших пользователей имеются учетные записи в домене Windows NT или службе каталогов Active Directory; Х нужна поддержка браузеров нескольких типов, в том числе Netscape Navigator и всех версий Internet Explorer (включая версии для плат форм Pocket PC и Windows CE); Х требуется поддержка аутентификации через Интернет; Х в коде приложения необходим доступ к паролям в незашифрованном виде; нужна поддержка делегирования. Базовая аутентификация не годится, когда: Х нужен защищенный вход и при этом не используется защищенный ка нал вроде Secure Sockets Layer (SSL); Х информация о ваших пользователях хранится в нестандартной базе данных и у них нет учетных записей в Windows; Х в качестве входной страницы применяется адаптируемая под разных пользователей форма. Прочие соображения Выбирая базовую аутентификацию, примите во внимание следующие со ображения. Делегирование при базовой аутентификации При использовании базовой аутентификации можно делегировать полно мочия от одного компьютера другому (но не далее). Делегирование проис ходит, так как сервер IIS локально регистрирует пользователя, вызывая LogonUser. IIS известен пароль пользователя, он может отвечать на вызовы от удаленных компьютеров, что позволяет Web-серверу действовать от имени клиента. Если требуется делегировать контекст защиты другим компьютерам (расположенным за маршрутизато рами), придется локально регистрировать пользователя на всех компьюте рах в цепочке вызова. При базовой аутентификации это возможно, пото му что у вас есть доступ к имени пользователя и незашифрованному па Аутентификация в руководство по защите в -NET ролю, которые можно передать другим приложениям, напри мер, на базе ISAPI или CGI. Защита при базовой аутентификации Следует помнить, что раскодировать пароль относительно легко, поэтому применять базовую аутентификацию в чистом виде можно только для не защищаемых или (в крайнем случае) частично защищаемых приложений. Базовую аутентификацию можно сделать более безопасной, сочетая ее с SSL. Это предотвратит расшифровку паролей. Сегодня во многих Интер нет-приложениях базовая аутентификация сочетается с Реализация Для реализации базовой аутентификации настройте на нее IIS и убеди тесь, что у пользователей есть привилегия локальной регистрации на Web сервере. Если вам нужно запускать от имени аутен тифицированного базовым способом измените конфигура цию файла Web.config: // Файл /> Аутентификация с хэшированием Аутентификация с хэшированием (digest authentication) появилась толь ко в Windows 2000 и IIS 5.O. В этом случае пароль пользователя шифрует ся и предоставляется механизм, предотвращающий некоторые распростра ненные типы атак на серверы, например атаки с повторением пакетов (replay attacks). В отличие от базовой аутентификации учетные данные не посылаются по сети открытым текстом. Вместо этого применяется меха низм хэширования разработанный RSA (см. The Message Digest Algorithm по ссылке Хотя это вполне жизнеспособный вариант для Интернет-приложений, его широкое применение ограничено требованиями к серверу и клиенту. В отличие от базовой аутентификации и по аналогии с NTLM и при аутенти фикации с хэшированием IIS не регистрирует пользователя локально на Web-сервере, что исключает возможность делегирования. сценарии применения Подумайте об аутентификации с хэшированием, если: * ваш Web-сервер работает под управлением Windows 2000 и у пользо вателей есть учетные записи Windows, которые хранятся в Active Directory; 22 ASP.NET Х клиенты используют либо либо Internet Explorer Х вам требуется более стойкое шифрование пароля, чем это возможно при базовой Х нужна поддержка аутентификации через Интернет. Аутентификация с хэшированием не годится, если: Х клиенты не используют ни ни Internet Explorer 5.0 (или выше); Х у пользователей нет учетных записей Windows, хранящихся в Active Directory; Х требуется делегирование. Х Прочие соображения Выбирая аутентификацию с хэшированием, примите во внимание следу ющие соображения. Более безопасная аутентификация с хэшированием Цель аутентификации с хэшированием Ч предоставить механизмы входа, более защищенные по сравнению с базовой аутентификацией. Однако она не столь безопасна, как базовая аутентификация в сочетании с SSL, или аутентификацией с сертификатами. Безопасное решение Ч комбинировать аутентификацию с хэшированием и SSL, но применение такого способа в настоящее время ограничено тре бованиями к развертыванию. Требования к платформе, аутентификацией с хэшированием Аутентификация с хэшированием требует, чтобы клиенты использовали или Internet Explorer 5.x. Учетные записи пользователей должны храниться в Active Directory, которая должна быть сконфигурирована на поддержку аутентификации с хэшированием, Реализация Настройте IIS на аутентификацию с хэшированием. Детали см, в статье из Microsoft Knowledge Base Setting Up Digest Authentication Use with Internet Information Services 5.0 ( Если вам нужно запускать приложение ASP.NET под учетной записью, данным способом, измените конфигурацию файла Аутентификация в руководство по защите в // Файл /> Чтобы задействовать аутентификацию с хэшированием в Windows 2000, сервер получить доступ к серверу Active Directory, настроенному на аутентификацию с хэшированием. Подробнее об аутентификации с хэшированием см. в RFC 2069 (http; // www.ietf.org/rfc/rfc2069.txt). Интегрированная Windows-аутентификация Интегрированная Windows-аутентификация (использующая либо запрос ответ либо Kerberos) подразумевает аутентификацию пользовате ля в домене Windows NT или в Active Directory. В отличие от базовой и аутентификации с хэшированием зашифрованный па роль по сети не передается, что делает этот способ весьма безопасным. Если на сервере установлена Active Directory, а браузер совместим с про токолом Kerberos V5, применяются и этот протокол, и протокол запроса ответа (challenge/response); в ином случае используется только последний вариант. Такая аутентификация лучше всего подходит для где клиентские и серверный компьютеры находятся в одном домене, а адми нистраторы гарантировать, что на каждом компьютере установлен браузер Microsoft Internet Explorer версии не ниже 3.01. сценарии применения Подумайте об интегрированной Windows-аутентификации, если: Х у ваших пользователей есть учетные записи в домене Windows NT или в Active Directory; Х приложение работает в интрасети (за брандмауэром); Х все клиенты используют браузер Internet Explorer версии не ниже 3.01; Х требуется делегирование (для этого нужен Kerberos); Х вы должны обеспечить автоматический вход для пользователей доме на (например, без всплывающих диалоговых окон входа). Интегрированная Windows-аутентификация не годится, когда: Х учетные записи пользователей хранятся во внешней базе данных, а не в базе данных домена Windows NT или в Active Directory; Х требуется поддержка аутентификации через Интернет; Х клиенты используют Netscape Navigator или другие сторонние браузе ры (не от Microsoft); Х вам нужно получать клиентский пароль в незашифрованном виде. Прочие соображения Выбирая интегрированную Windows-аутентификацию, примите во внима ние следующие соображения. Уровень защиты Kerberos Оба этих протокола считаются высокозащищенными. В случае их приме нения пароль по сети не передается. В NTLM используется механизм зап роса-ответа. Протокол Kerberos считается еще более защищенным, так как поддерживает взаимную аутентификацию (mutual authentication), т. е по зволяет клиентам проверять сервер, с которым они взаимодействуют. Проблемы делегирования Протокол NTLM не поддерживает делегирование. После того как удосто верения клиента переданы серверу IIS, их нельзя передать какому-то дру гому серверу для аутентификации. Однако Kerberos поддерживает делеги рование, что позволяет передавать удостоверения клиента другим процес сам или компьютерам. Например, используя Kerberos, можно передавать удостоверения на промежуточный уровень СОМ+, а через него базе данных Microsoft SQL Server, настроенную на использова ние интегрированной В Active Directory аутен тификация Kerberos по умолчанию выключена. Прежде чем использовать Kerberos в качестве механизма делегирования, убедитесь, что ваша среда поддерживает этот протокол. Применение в Интернете Как NTLM, так и Kerberos редко применяются в Интернете. Главная про блема с использованием Kerberos в Интернете в том, что служба защиты должна быть централизована и доступна всем пользователям. А для этого нужна соответствующая инфраструктура. Кроме того, эти протоколы под держивают только браузеры от Microsoft, что может стать ограничиваю щим фактором в зависимости от вашей клиентской базы. Производительность и масштабируемость Kerberos быстрее NTLM. Однако оба эти медленнее базовой аутентификации и некоторых нестандартных способов аутентификации. Если вы рассчитываете, что множество пользователей будут регистриро ваться одновременно, тщательно спроектируете конфигурацию Active Directory. Когда число потенциальных пользователей приближается к миллиону, для хранения имен пользователей паролей может потребо ваться высокопроизводительная база данных, например SQL Server. При делегировании контекста защиты в многоуровневом приложении вы, веро ятно, столкнетесь с проблемами масштабирования. А точнее, вам не ASP.NET: руководство по защите в тся воспользоваться такими решениями промежуточного уровня tier solutions), как пул соединений с базой данных. Реализация Для реализации Kerberos или настройте IIS на интегрированную Если вам нужна поддержка клиентов, отлич ных от Internet Explorer, то, вероятно, придется использовать базовую аутентификацию в сочетании с или Kerberos. При настройке Kerberos обратите внимание на то, что: Х клиентские и серверный компьютеры должны работать под управлени ем Windows 2000 в домене Windows 2000; Х для пользовательской учетной записи клиента должно быть разреше но делегирование; Х для учетной записи сервиса должно быть разрешено Если ASP.NET-приложение должно выполняться под учетной записью пользователя, проверяемого IIS через интегрированную Windows-аутенти фикацию, измените конфигурацию // Файл /> Подробнее о Kerberos см. по ссылкам: Х Kerberos Components in Windows ( Х Kerberos ( kerberos.asp). Аутентификация с сертификатами Сертификат Ч это цифровой установленный на компьютере. Ког да компьютер пытается обратиться к серверу, этот ключ автоматически передается серверу; по нему и пользователь. Клиент ские сертификаты можно сопоставлять с учетными записями Windows в домене или в Active Directory. При использовании Windows Authentication Provider в ASP.NET поток приложения выполняется от имени пользовате ля, с учетной записью которого сопоставлен сертификат. Кроме в ASP.NET можно реализовать нестандартную аутентификацию, при кото рой например, используете адрес электронной почты (или аналогичное уникальное поле), содержащийся в сертификате. Для клиента аутентифи кация проходит незаметно, так как регистрации на странице ввода не 26 Microsoft буется. Благодаря этому сертификаты Ч довольно привлекательный вари ант аутентификации для автоматизированных бизнес-процессов. Типичные сценарии применения Аутентификация с сертификатами подходит, если: Х конфиденциальность защищаемых данных считается высокой и вам нужно очень безопасное решение; Х требуется взаимная аутентификация; Х нужна возможность управления связью между сервером и владельцем сертификата третьей стороной; Х требуется незаметное для клиента взаимодействие, например для авто матизированного обмена данными в В2В-решении. Аутентификация с сертификатами не когда: Х издержки выдачи клиентских сертификатов и управления ими переве шивают выгоды от большей Прочие соображения Выбирая аутентификацию с сертификатами, примите во внимание следу ющие соображения. Развертывание Вы должны установить клиентские сертификаты на клиентские компью теры. Для существуют различные способы Ч от до установки с компакт-диска. Именно проблемы развертывания в основ ном и являются причиной того, сертификаты не так распространены, как другие способы аутентификации, применяемые в сочетании с SSL. Сопоставление с учетными Windows Сертификаты можно сопоставлять с учетными записями в домене или Active Directory. Если требуется аутентификация на индивидуальной ос нове, можно применить сопоставление типа лодин к при котором сертификат сопоставляется с конкретной учетной записью. Ограничений на такое сопоставление при использовании Active Directory нет. Если же нужна аутентификация всех пользователей из некоей группы или организации, применяйте сопоставление типа многие к одному, при ко тором все содержащие, например, название одной и той же компании, сопоставляются с одной учетной записью. Для примера рассмотрим следующий В2В-сценарий. Аутентификация в по защите я 1. Компания А разрешает сотрудникам партнерской компании В про сматривать определенные разделы своего внутреннего Web-сайта. 2. На компьютерах компании В установлен сертификат. 3. Сопоставление многие к приводит к что ASP.NET-при выполняется под универсальной учетной записью Windows Подробнее о сертификатах см. в книге Майкла Говарда (Michael Howard) Designing Secure Web-Based Applications for Microsoft Windows Реализация Настройте IIS на аутентификацию с сертификатами. Подробнее о сопос тавлении сертификатов открытых ключей с учетными записями Windows 2000 см. в Guide to Mapping Certificates to User ( Аутентификация через Passport Passport Ч централизованная служба аутентификации, предоставляемая Microsoft- При ее использовании вам не придется реализовать собствен ный аутентифицирующий код, входную страницу, а иногда и таблицу пользователей (user table). Passport основан на механизме поддержки cookie. Если клиент уже аутентифицирован в Passport, ему разрешается доступ к вашему сайту. Иначе он автоматически переадресуется на сайт Passport для аутентификации. Passport Ч хороший выбор, если вам нужен единый вход в нескольких доменах, поддерживающих Passport. Кроме эта служба предоставля ет дополнительные сервисы, в том числе управление профилями и серви сы оплаты. На платформе Windows 2000 нельзя напрямую интегрировать с каким бы то ни было встроенным механизмом аутентификации и автори зации. Хотя Framework проверяет создаваемые при этой ав торизации, поддержка собственной базы данных пользователей потребует от вас написания кода, определяющего, какому из ваших пользователей соответствует пользователь Passport, а также реализации своего механиз ма аутентификации. применения Подумайте об аутентификации через Passport, если: Х ваш сайт используется совместно с другими поддерживающи ми Passport, и вы хотите предоставить единый вход на все эти сайты; 28 Microsoft Х вы не хотите поддерживать базу данных с именами и паролями пользо вателей. Аутентификация через Passport не годится, когда: Х вы хотите задействовать и пароли, уже хранящиеся в вашей базе данных или Active Directory (хотя, написав дополнительный код, вы могли бы сопоставлять идентификаторы Passport с учетными записями); Х клиентами являются компьютеры, программно к сайту. Прочие соображения Выбирая аутентификацию через Passport, примите во внимание следую щие соображения. Поддержка Passport Применение аутентификации через Passport требует регистрации сайта в службе Passport и установки Passport SDK на вашем сервере. Делегирование В Windows 2000 нельзя делегировать другому серверу удостоверения за щиты, полученные от Passport. Сопоставление с учетными записями пользователей Идентификатор пользователя Passport (Passport User ID, Ч всего лишь идентификация. Если учетные записи ваших пользователей опреде лены в Active Directory или другой базе данных и нужно сопоставлять с учетными записями, вам придется написать для этого собствен ный код. Поддержка такого может быть встроена в буду щие версии Windows. Защита Passport Зашифрованные cookie делают службу Passport безопасной, когда она ис пользуется как отдельный механизм аутентификации. Однако, чтобы пре дотвратить атаки с повторением пакетов и обеспечить высший уровень безопасности, применяйте Passport в сочетании с Реализация Для реализации Passport установите на сервере Passport SDK. Кроме того, зарегистрируйтесь на использование службы Passport. При этом файл следует настроить так: // Файл Аутентификация в ASP.NET: руководство по защите в /> Дополнительные сведения о службе Passport см. по ссылкам: Х The Passport Authentication ( Х спецификация Passport Х информация для разработчиков Passport com/ Аутентификация на основе форм Аутентификация на основе форм (forms authentication) подразумевает со здание собственного принимающего удостоверения поль зователя, например его имя и пароль. Сейчас многие Интернет-приложе ния предлагают пользователям регистрироваться в таких формах. Имейте в виду, что форма сама по себе не выполняет аутентификацию и предназ начена исключительно для получения учетных данных. Аутентификация вы полняется кодом, который обращается к базе данных с именами и паролями. После аутентификации пользователя сервер обычно предоставляет клиен ту тот или иной способ сообщать, что при дальнейших запросах выполнять аутентификацию не нужно. При необходимости можно заставить клиент аутентифицироваться при каждом запросе, но это отрицательно сказыва ется на производительности и масштабируемости. Есть два основных спо соба идентифицировать ранее зарегистрированный клиент. Х Cookie. Небольшой блок данных, изначально передаваемый сервером клиенту. Затем в каждом HTTP-запросе эта строка передается обрат но на сервер. Наличие такого блока может указывать, что клиент уже аутентифицирован. ASP.NET предоставляет в модуле CookieAuthenti cationProvider механизм, позволяющий использовать cookie при аутен тификации на основе форм. Cookie поддерживаются большинством в том числе Internet Explorer и Netscape Navigator. Х Собственный способ. Вы можете реализовать свой механизм иденти фикации клиента. Так, если у клиентов отключены cookie, вы можете хранить уникальные идентификаторы в каждой строке URL-запроса. Или использовать скрытые поля формы, которые хранятся в постоян ном невидимом фрейме или во фрейме верхнего уровня. В любом слу чае вам придется убедиться, что хакер не сумеет программно выдать себя за аутентифицированного пользователя. 30 Microsoft ASP.NET Cookie широко применяются на сайтах, реализующих аутентификацию на основе форм. Первая версия -NET поддерживает аутентификацию на ос нове форм только через cookie. сценарии применения Аутентификация на основе форм подходит, если: Х имена пользователей и пароли не хранятся в учетных записях Win dows (но аутентификация на форм не запрещает применение учетных записей Windows); Х вы развертываете приложение через Интернет; Х требуется поддержка всех браузеров и клиентских операционных систем; Х нужна собственная в качестве входной страницы. Аутентификация на основе форм не годится, когда: Х вы развертываете приложение в корпоративной и хотите ис пользовать преимущества интегрированной Windows-аутентификации; Х нет возможности проверить имя пользователя и пароль. Прочие соображения Выбирая аутентификацию на основе форм, примите во внимание следую щие соображения. Защита при аутентификации на основе форм Пароли, посылаемые с входной страницы, можно защитить от перехвата с помощью SSL. Учтите, что cookie, хранящие идентификацию пользовате ля между запросами, можно с помощью программы сетевого мониторинга. Единственный способ полностью защитить сайт при исполь зовании cookie Ч применение SSL. Для большинства коммерческих сайтов это непрактично, так как связано со значительным падением производи тельности. В ASP.NET можно заставить сервер повторно генерировать cookie по истечении некоего времени. Такая политика предотвращает си туацию, когда при доступе к сайту предоставляют cookie. масштабируемость При разработке Web-сайта с интенсивным трафиком следует учесть вли яние аутентификации пользователей на производительность. Чем больше ожидаемое число одновременно входящих пользователей, тем быстрее должна выполняться проверка удостоверений. заметно ухудшает производительность из-за дополнительных издер жек на шифрование. Возможно, для достижения требуемого уровня про Аутентификация в ASP.NET: руководство по защите в придется отделить серверы, отвечающие за защищенный вход, от серверов контента в Web-ферме. Проверка на наличие В проверка на наличие cookie выполняется автоматически. Но если БЫ не используете то можете выбрать один из двух основных подходов. Х Реализовать который подтверждает наличие cookie в запросе, доказывающего, что клиент уже прошел аутентификацию. Если такой файл существует, запрос можно обрабатывать. Нет Ч кли ент следует перенаправить на страницу входа. Пример такого ISAPI фильтра реализован в Microsoft Commerce Server 2000. Х Добавить в начало каждой Web-страницы код, проверяющий наличие cookie или другой строки, переданной странице. Если ничего такого нет, код перенаправляет пользователя на входную страницу. Такая ре ализация проста, но позволяет защищать лишь а не ресурсы вроде файлов изображений. В ASP.NET можно задействовать преимущества встроенной функциональ предоставляемой аутентификацией на основе форм. Аутентификация на основе форм в сочетании с учетными записями Windows Если вы развертываете Интернет-приложение и у ваших пользователей есть на сервере учетные записи Windows, то можете задействовать аутен тификацию на основе форм (в том числе, в комбинации с как альтер нативу базовой аутентификации или аутентификации с хэшированием. Для приложений интрасети с интегрированной ей это решение может оказаться не слишком удачным. Кроме того, корпо ративная политика безопасности может запрещать пользователям вводить пароли в HTML-формы. Реализация Чтобы реализовать аутентификацию на основе форм, создайте собствен ную входную страницу и перенаправляйте на нее все клиенты, не прошед шие аутентификацию. Вам также понадобится собственная схема просмот ра учетных записей. В ASP.NET используйте следующий файл Web.config: // Файл /> 32 Microsoft ASP.NET При самостоятельной реализации аутентификации IIS, как правило, на страивают на анонимный доступ. Более подробные сведения о реализации см. в следующих статьях: Х Untangling Web Security: Getting the Most from IIS ( Х IIS 5.0 Security в Internet Information Services 5.0 Resou rce Guide. Cookie Cookie Ч это небольшой текстовый файл, помещаемый на ваш жесткий диск Web-сервером. Его предназначение Ч дать возможность серверу опознать повторного посетителя. Cookie применять как с аутентификацией, так и без Возможны следующие варианты: Х применение в сочетании с аутентификацией на основе форм. После аутентификации сервер генерирует для клиента cookie, используемый для проверки последующих запросов; Х применение только для контента. ASP.NET предоставляет механизм для создания cookie и автоматической их наличия в клиентских запросах. Cookie, созданные ASP.NET, можно шифровать по алгоритму Triple DES, поддерживаемому Fra mework. Кроме того, вы можете сами реализовать провайдер cookie и ис пользовать его совместно с аутентификацией на основе форм. Более подробные сведения о cookie см. по ссылке Прочие соображения Браузеры некоторых типов накладывают ограничения на размеры cookie. В RFC 2019 определено ограничение в 4 Кб. В Internet Explorer 5 ограни чений на размер нет. Чтобы браузеры корректно работали с cookie, нужно соответствующим образом настроить параметры безопасности. Защита в Web-сервисах Web-сервис Ч это основанное на инфраструктуре ASP.NET приложение, которое можно программно вызывать через Интернет. Его защита анало гична защите интерактивных Web-сайтов. Для этого служат те же меха низмы, что и для других ASP.NET-ресурсов (например, IIS и провайдеры аутентификации ASP.NET). Однако при разработке следует учесть ряд дополнительных факторов. в по защите в Х Взаимодействие с клиентами. Web-сервис может работать не с инте рактивными которые указывают свои удостоверения защиты, а с приложениями. Х Защита на уровне методов. Вам может авторизация пользователей на уровне отдельных методов, чтобы ограничить доступ к некоторым методам. Для этого применяются те же способы, что и при аналогичной защите в Х Делегирование. Web-сервису может понадобиться обращение к дру гим сервисам с сохранением контекста защиты исходного вызывающего. Аутентификация в Web-сервисам нужно так или иначе принимать удостоверения лей. Если сервис не является он должен либо получать маркер защиты (security token) от приложения, либо предо ставлять соответствующие позволяющие передавать удостовере ния. Следующие способы аутентификации просты в применении и не тре буют от пользователя ввода учетных данных (благодаря этому они хоро шо подходят для Web-сервисов с программным доступом): Х с и интегрированная Windows-аутентификация; Х аутентификация с сопоставлением сертификатов; Х или для конкретного приложения аутен тификация. В принципе вы могли бы использовать и такие средства, как: Х Internet Protocol Security; Х Passport. учетных Windows и Изучите материалы, представленные в разделе Способы аутентифика Такая реализация потребует наименьшего объема кода и, кроме того, позволит контролировать доступ к другим с помощью Применение сертификатов и их сопоставление При применении аутентификации с сертификатами взаимодействие кли ента и сервера происходит незаметно, т. е. клиенту не нужно программно сообщать имя пользователя и пароль. Кроме того, это высокозащищенный механизм. например отправка заказов на явля ются идеальным сценарием для такой аутентификации. Сопоставляя сер тификаты с учетными записями Windows, вы также можете использовать для авторизации доступа к другим ресурсам. 2- 34 Microsoft NET Нестандартная аутентификация Вы можете реализовать собственную аутентификацию. Ее преимущества перед интегрированной в том, что приложени ям не придется поддерживать отдельные учетные записи Windows для каждого пользователя. Вы можете вообще отказаться от ции и включить в код Web-сервиса собственный метод аутентификации, оптимизированный под конкретные задачи приложения. К возможным способам собственной аутентификации в Web-сервисах от носятся: Х прием имени пользователя и пароля как параметров при вызове метода; Х создание метода входа, который вызывается до любых других методов. Чтобы убедиться, вызывался ли метод входа, можно задействовать фун кциональность cookie, поддерживаемую Microsoft Framework; Х хранение удостоверений в или в теле Х создание собственного HTTP-заголовка или тела для хранения удос товерений. Internet Protocol Security Если вам известен IP-адрес клиентского компьютера (например, Web-сер вера, который обращается к бизнес-логике, инкапсулированной в Web-сер висах на промежуточном то Internet Protocol Security может оказаться полезным вариантом. Этот механизм позволяет отфиль тровывать компьютеры, соединяющиеся с вашим Web-сервисом, по их IP адресам, В Интернет-сценариях такой подход не годится, так как IP-адреса клиен тов заранее не известны. Применение Passport с Иногда Web-сервис может использовать для аутентификации службу Passport. Однако ее применение ограничено из-за необходимости перенап равлять неаутентифицированных клиентов на сайт Passport. Перенаправ ление способно создать проблемы для неинтерактивных клиентов, если только те не запрограммированы на обработку такого перенаправления. Авторизация После аутентификации пользователей для доступа к Web-сервису может понадобиться их Вот несколько вариантов авторизации на основе: Х Windows ACL; в руководство по защите в Х URL; Х Principal Objects. Авторизация на основе Windows ACL В этом случае вы можете создать разрешения файловой системы на доступ к конкретным файлам приложения. Этот подход работает, если ваш Web сервис пользователей по учетным записям Windows и применяет олицетворение. Авторизация на основе URL Модуль сопоставляет пользователей и роли с элементами внутри пространства имен В модуле реализованы как разрешительные, так и запретительные условия. То есть модуль может как запрещать, так и разрешать отдельным пользователям обращаться к ка ким-либо элементам пространства имен URI, например, в зависимости от их принадлежности к определенной роли. В следующем примере доступ разре шен нескольким пользователям домена, а всем остальным Ч запрещен. /> /> Универсальный объект Principal На основе ролей, определенных вами, можно создать универсальный объект Principal. Он применяется, когда у вас есть собственная база дан ных пользователей и ролей. Данные в него записываются при событии В обработчике этого события вы можете сопоставить соб ственную таблицу с учетными записями Windows. В любом случае для каждого пользователя можно создать свой объект Principal. 36 ASP.NET Для уже пользователя объект Principal можно вос создать на основе cookie. Роли и уровня методов Защита уровня методов нужна, чтобы ограничить вызов некоторых мето дов только определенными участниками системы безопасности (princi pals). Такая защита реализуется несколькими способами. При наличии учетных записей Windows определите для своих пользова телей роли в виде групп Windows. Так как ASP-поток будет олицетворять клиент и вам будет доступен объект Windows Principal: Х создайте для защищаемых ресурсов, к которым обращает ся Х вызывайте метод объекта Windows Principal из каждого мето чтобы проверять, есть ли у вызвавшего необходимые разрешения. Кроме того, вы можете написать в коде логическое выражение, вызы вающее конкретную подпрограмму в зависимости от к рой относится клиент. Если вы используете универсальный объект Principal, созданный на осно ве ролей, которые хранятся в базе данных: Х программно проверяйте принадлежность к роли, вызывая метод Role объекта Principal точно так же, как и для описанного выше объек та Windows Principal. Если объект Principal вас не устраивает, есть другие варианты. Х Принимать удостоверения пользователя в качестве параметров при вызове метода и выполнять поиск в базе данных. Х Х Х Проверять наличие cookie в начале каждого метода. Х Создать метод входа, некое ключевое значение. Ос тальные методы принимают это значение в качестве параметра. Такой подход аналогичен использованию cookie, поддерживаемых браузером, но применим и в тех случаях, когда клиент не поддерживает cookie. Делегирование Все, что говорилось о делегировании для Web-сайтов ASP.NET, относится и к Web-сервисам. Чтобы делегировать контекст защиты Web-сервису, понадобится либо аутентификация Kerberos, либо передача удостовере ний, чтобы Web-сервисы, выполняемые на других компьютерах, могли вызывать если они работают под управлением Windows, или эквивалентную функцию при наличии другой операционной системы. Аутентификация в ASP.NET: по защите Доступ клиентов Для программного доступа к Web-сервису используйте преимущества.NET-классов, обеспечивающих клиентам возможность соединений. Кли енты поддерживают следующие протоколы аутентификации: Х Basic (базовую); Х Digest (с хэшированием); Х Windows Integrated (интегрированную в Windows) и Kerberos); Х Certificate (с сертификатами); Х Custom (нестандартную). Защита по правам доступа кода Code Access Security (CAS) (защита по правам доступа кода) Framework защищает компьютер от вредоносного кода и обеспечивает бе зопасное выполнение мобильного кода. Так как CAS Ч функциональность подсистемы защиты она применима к любому управляемому коду, в том числе к ASP.NET. Но в следующих случаях может понадобиться написание специфического кода для поддержки CAS: Х разработка элементов управления, выполняемых в браузере; Х хостинг сторонних приложений; Х хранение сборок от разных поставщиков на общем сервере; Х запрет доступа из определенных сборок к некоторым функ циям, например к API-функциям записи в файл. CAS устанавливает разные уровни доверия к коду в зависимости от поли тики безопасности, источника кода и других параметров его идентифика ции, например строгого имени сборки. CAS уменьшает вероятность того, что вашим кодом какой-то другой, вредоносный код. Эта модель защиты позволяет указывать операции, которые разрешается вы полнять вашему коду, и операции, для него запрещенные. В частности, CAS поддерживает механизм разрешений; через него код может явно зап росить одни разрешения и явно отказаться от других, которые ему никог да не понадобятся. Полномочия кода Защита по правам доступа кода основана на концепции разрешений. Каж дое разрешение соответствует праву на доступ кода к защищенному ресур например к файлу, каталогу или записи в реестре, либо праву на выпол нение защищенной операции вроде вызова неуправляемого кода. Код мо жет затребовать определенные разрешения, а политика безопасности ис 38 ASP.NET полняющей среды определяет, какие из них можно выдать. Полный спи сок разрешений см. в Code Access ( позволяет администраторам назначать приложениям предопределен ный набор разрешений. Эти наборы различаются в зависимости от уров ня доверия к приложению. По умолчанию уровень доверия зависит от цифровой подписи источника и местонахождения приложения. Так, выполняемые на (в зоне безопасности Intranet), получают набор разрешений Local Intranet, а приложения, рабо на локальном компьютере (в зоне безопасности Ч набор разрешений FullTrust. ASP.NET можно настраивать еще детальнее, присваивая им уровни доверия. Для этого служат элементы в конфигурацион ном файле. | High | Low | None" /> Каждый уровень присваивает приложению разрешения, состав которых определен в XML-файле политики безопасности. Каждый уровень сопос тавлен со своим файлом. Сопоставления по умолчанию в ASP.NET таковы. Х High (Высокий) Ч соответствует Разрешения этого уровня предоставляют приложению права на доступ для чтения и записи в каталог приложения (в зависимости от разрешений, опре деленных в операционной системе) и позволяют ему заменять объект участника (authentication principal object). Кроме того, они запрещают приложению вызывать неуправляемый код. Х Low (Низкий) Ч соответствует Этот уровень по зволяет читать каталог приложения и ограничивает сетевые соедине ния. Приложения могут подключаться к своему хост-сайту при усло вии правильной настройки атрибута originUrl элемента Х None (Нет) Ч соответствует Этот уровень предос тавляет базовые разрешения на выполнение кода и позволяет прило жению использовать изолированное хранилище (механизм, который дает возможность безопасно код с сохраненными данными). Заметьте, что с уровнем доверия Full не связан какой-либо конфигураци онный файл, поскольку этот уровень позволяет приложению использовать все ресурсы (в зависимости от разрешений, определенных в операционной системе), что равносильно его выполнению без CAS (хотя для управляе мого кода CAS отключить нельзя). Вы можете переопределить эти сопос тавления в элементе Более подробные сведения см. по ссылкам: Х Security in Enforce Code Access Rights with the Common Lan guage ( 1/ 40 Microsoft ASP.NET Х Code Access Security Защита на уровне каналов Каналы передают сообщения через границы удаленно взаимодействую щих процессов и В Framework есть два канала: HTTP и TCP. Чтобы защитить конфиденциальную информацию, передаваемую по этим протоколам, используйте защищенный канал. Иначе с помощью программ сетевого мониторинга незашифрованную информацию легко перехватить и прочесть. Вот некоторые из основных особенностей канальной защиты. Х HTTP-канал в IIS поддерживает передачу и прием данных, защищен ных с помощью SSL SSL Ч наиболее распространенный механизм со здания защищенного коммуникационного канала и настраивается в IIS, Х Даже при использовании незащищенного канала, например HTTP по порту 80 или TCP, вы можете вручную шифровать данные через Cryp tographic API. Х Можно реализовать механизм канальной защиты ниже транспортного уровня. В Windows 2000 дая защиты данных при передаче прозрачно для приложения можно использовать Internet Protocol Security Х При использовании ASP.NET совместно с СОМ- или нентами и применении DCOM в качестве механизма удаленного вза имодействия обратите внимание на уровень аутентификации ОМ Packet Privacy, позволяющий шифровать данные, передаваемые через DCOM. Более подробные сведения см. по ссылкам: Х Secure Web в Microsoft Windows 2000 Server Reso urce Kit (Microsoft Press); Х спецификацию удаленного взаимодействия в Framework Deve loper Х разделы MSDN по настройке защиты DCOM и NT. Дополнительные сведения Дополнительную информацию по вопросам безопасности, рассмотренным в данном см. в: в руководство по защите в Х Understanding Digital Certificates в Microsoft Windows 2000 Server Resource Kit (Microsoft Press); Х Framework SDK ( Х статью в Microsoft Knowledge INFO: Security Ramifica tions for IIS Applications ( x?scid=kb; en-us; 158229); Х A Blueprint for Building Web Sites Using the Microsoft Windows Plat form ( print.asp). Подробнее о защите Web-сервисов см. по ссылкам: Х Secure Web Services Using the SOAP Х Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press); Х Secure Internet Information Services 5 Checklist ( soft.com/TechNet/prodtechnol/iis/tips/iis5chk.asp); Х статью в Microsoft Knowledge Base List of NTFS Permissions Required for IIS Site to Work ( x?scid=kb; en-us; 187506). Общие сведения о защите см. в: Х Microsoft Security Благодарности Выражаю глубокую признательность всем, кто внес свой вклад в подготов ку этого документа, и рецензентам: Rob Howard, Erik Olson, Venkat Chilakala, Michael Monteiro Kandula (Sapient), Chris Edward Jezierski, Alex David Mowers, Amitabh Steve Busby, Kenny Jones. Чтобы лучше освоить передовой опыт применения вы можете обра титься к экспертам по технологиям в Центре технологий Microsoft в ва шем регионе. За более подробной информацией, пожалуйста, обращайтесь на Web-страницу Microsoft Technology Centers Приложение А Рис. З. Схема, помогающая выбрать оптимальный способ аутентификации Кит Браун Безопасный код Вопросы безопасности Эта статья посвящена в ASP.NET. Автор размышляет о том, как найти оптимальный баланс между безопасностью и легкостью доступа на защищен ные детально рассматривает рабочий процесс ASP.NET и расска зывает, как правильно выбрать контекст защиты Кроме того, автор поясняет разницу между потоками в Win32 и CLR и то, как это отражается на инфраструктуре защиты. В заключение поясняется, что такое принцип наименьшей привилегии и почему не следует разрабатывать приложения под администраторской учетной записью, выдающей максимум привилегий создаваемому коду. Начиная серию статей, посвященных защите в Microsoft Framework, я подумал, что лучше всего начать с одной из наиболее популярных тех нологий этой платформы Ч с ASP.NET. Безопасность и легкость доступа Существует огромное количество Web-сайтов разных типов, у каждого из которых свои требования к безопасности. Некоторые (например поиско вые системы) не собирают сведения о своих пользователях, и содержимое этих сайтов общедоступно. Слабая защищенность ничем не вредит таким сайтам, их делают максимально простыми в использовании. Другие (ска сайты онлайновых банковских операций) для предоставления своих услуг собирают демографические данные, номера кредитных карт и дру гую конфиденциальную информацию о своих пользователях. Этим сайтам нужна куда более жесткая политика безопасности. Они содержат секрет в MSDN Magazine/Русская Редакция. 2002. № 5 (ноябрь). Ч Прим. изд. 44 Microsoft ную информацию и заставляют пользователей преодолевать определенные препятствия. защита отдельных областей сайта через SSL (Secure Sockets Layer) существенно увеличивает нагрузку на сервер и вре мя его отклика. Установление SSL-сеансов ведет к серьезным издержкам. Важно отметить, что, хотя поисковые системы не имеют дела с личной или закрытой информацией, они могут просто игнорировать проблемы за щиты. Есть много людей и организацией, которые гордятся тем, что суме ли успешно атаковать популярные или неприятные им Web-сайты. Вспом ните бесчисленные сайты, чьи основные страницы це ликом заменялись злоумышленниками, а также распределенные атаки типа лотказ в обслуживании (distributed denial of service, DDoS) против многих компаний из списка Fortune Сегодня у каждого разработчика общедоступного Web-сайта должна быть стратегия защиты от кибер-террористов. Чтобы только приступить к вы работке такой стратегии, надо сначала понять, как работает платформа, на которой будет строиться сайт. Именно поэтому я начну с объяснения принципов размещения ASP.NET-приложений на сервере и настройки некоторых параметров важных для защиты сайтов. Учтите: когда я писал эту статью, платформа была на стадии второй бета-версии. В ее финальной версии какие-то детали могли немного измениться. Как разработчик, понимающий значимость безопасности, вы должны по заботиться о контексте защиты, в котором работает ваш код. В противопо ложность тому, во что предпочитает верить большинство, код всегда луч ше выполнять с минимальными привилегиями. Это правило называется принципом наименьшей привилегии, и его стоит придерживаться всем разработчикам, потому что никто из нас несовершенен. Помните, что пло хой парень обязательно воспользуется многими, если не всеми, ошибками в вашем приложении. Выполняя код лишь с абсолютно необходимыми ему привилегиями, вы позволите операционной системе сделать свою работу и защитить вас от вашего же несовершенного кода. Так что первое, о чем мы с вами поболтаем, Ч защиты (security context), в котором выполняется ASP.NET Ч это Загрузите Internet Services Manager (утилиту администрирования IIS) и создайте новый виртуальный каталог. Щелкните этот каталог правой кнопкой мыши и выберите а затем нажмите кнопку Configu ration. Вы увидите диалоговое окно (рис. управляющее сопоставлени ем URL с Например, URL, заканчивающийся на обрабатывается ASP.DLL. Если вы установили платформу вы Вопросы заметите несколько новых URL-суффиксов, в том числе Запросы к этим страницам IIS передает в Рис. 1. Сопоставления в Тот факт, что приложение ASP.NET ISAPI упаковано в DLL, не означает, что оно запускается непосредственно в основном процессе INETINFO.EXE. Начиная с IIS 4.0 разработчики могут выбирать уровень защиты своих приложений, как показано на рис. 2. настро енное на любой уровень защиты, кроме Low, размещается в суррогатном процессе СОМ+, запущенном под учетной записью IWAM_MACHINE с очень скромными привилегиями. Сравните это с выполнением внутри процесса Web-сервера, который выполняется под учетной записью SYS TEM! Рис. 2. Настройка Злоумышленник, сумевший получить доступ к неконтролируемому буфе ру во сможет запускать любой код под учетной записью SYSTEM, имеющей максимум привилегий. И тогда песенка вашего сервера спета (а если вы не сразу обнаружите проникно вение, то и всей вашей системы). Так что, с точки зрения безопасности, Microsoft ASP.NET настройка своего кода на выполнение вне Ч отличная идея. Однако в ASP.NET это еще не Рабочий процесс ASP.NET На самом деле мало что делает. И конечно же, не выполняет ASP.NET-код, а просто пересылает запрос через именованный канал другому процессу, То есть настройка виртуального каталога IIS на запуск вне процесса никак не вли яет на то, где исполняется ваш управляемый код. Интересно, что этот па раметр не влияет даже на контекст защиты ASPNET_ISAPI.DLL, так как при это приложение добавляется в свойство InProcessIsapiApps метабазы IIS и поэтому всегда запускается Следователь но, при создании нет смысла тратить время на на стройку параметров его защиты в IIS. Эти параметры совершенно не вли яют на выполнение управляемого кода. Но где же выполняется рабочий процесс ASP.NET? В то время, когда я писал эту статью, он функционировал как SYSTEM. Ха-ха! Базовая архи тектура показана на рис. 3, и, хотя вы, уже видели подобную здесь больше внимания уделяется контекстам защиты. Пока вы не слишком разволновались, позвольте сказать, что файл machine.config по зволяет полностью контролировать контекст защиты этого рабочего про цесса. System канал Рис. 3. Рабочий процесс ASP.NET Вот как это делается. Сначала откройте файл machine.config в каталоге: Затем найдите элемент Именно здесь вы управляете па раметрами рабочего процесса. На момент написания статьи значения по умолчанию для параметров, контролирующих контекст защиты процесса, были таковы: Вопросы безопасности ASP.NET Те же значения вы получите, если просто опустите эти два атрибута. На деле поле password в данном случае вас не поскольку asp net_isapi.dll для запуска рабочего процесса вызывает а так как эта DLL всегда выполняется в сеансе SYSTEM, рабочий процесс дей ствует там же. Эти параметры можно изменить двумя способами. явно ука зать имя пользователя и пароль: На момент написания статьи по умолчанию доступен кому угодно, так что предыдущие настройки явно нежелательны. Еще один до кументированный вариант таков: Тогда aspnet_isapi.dll вызовет функции и CreateProcessAsUser, поместив рабочий процесс в сеанс с крайне ограниченными привилегия ми. То же самое вы получаете для стандартных ISAPI или неуправляемых настроенных на внепроцессное выполнение. В IIS изо лированные приложения работают под специальной учетной записью с очень ограниченными привилегиями Ч В ASP.NET учетная запись с теми же полномочиями называется ASPNET. Такой вари ант наиболее предпочтителен, но на момент написания статьи он работал нестабильно, и команда ASP.NET активно занималась этой проблемой. вы недоумеваете, а нужно ли вообще беспокоиться о таких ошибках, как неконтролируемые буферы, раз уж вы пишете управляемый код. Если верификация кода (code verification) не отключена, исполняю щая среда должна анализировать код до его в исполняе мый код и запуска. Ну, все это только в теории, а на практике следует по мнить, что в течение какого-то времени вам, по-видимому, еще придется пользоваться DLL-библиотеками сторонних разработчиков через меха низм COM Interop или He забудьте, что такие DLL загружают ся прямо в рабочий процесс, если только вы не прибегнете ко всяким ухищрениям вроде размещения этих DLL в суррогатных процессах СОМ или Именно поэтому вам следует беспокоиться о контексте защи ты рабочего процесса. Кроме того, в будущем могут быть выявлены ошиб ки в самой исполняющей среде. Запуская рабочий процесс с минимальны ми привилегиями, вы усиливаете защиту от атак на неуправляемый код в своей системе. 48 ASP.NET IIS и олицетворение В нормальных условиях IIS запускает применяя мар кер олицетворения (impersonation token), и обычно он предназначен для анонимного Интернет-пользователя но если выбраны другие параметры аутентификации, этот маркер может представлять дру гого участника системы безопасности (principal). Значит, для неуправля емых и доступно два кон текста защиты процесса и потока. По умолчанию почти все функции Windows API для проверки прав доступа используют маркер потока, т. е. если IIS олицетворяет ему разрешается лишь то, что Однако олицетворение в Windows предназначено для использования в доверяемых (trusted) серверных процессах. И если вы, вызывая какую-то случайную DLL, что она будет выполняться с привилеги ями вас ждет большой сюрприз. Ничто не мешает этой DLL просто удалить маркер потока, вызвав RevertToSelf, и запуститься в контексте защиты процесса. Еще раз подчеркиваю: механизм олицетворе ния был создан в расчете на применение только в доверяемом коде. Вот почему так важно правильно выбрать контекст защиты процесса (незави симо от того, какое приложение вы разрабатываете Ч управляемое или неуправляемое). Всегда исходите из того, что ненадежная DLL может уда лить маркер потока в попытке повысить свой уровень привилегий. Как же это отражается на управляемых По умол чанию олицетворяемый IIS маркер остается внутри IIS. Он вообще не ис пользуется в рабочем процессе. Так что ASP.NET-приложению доступна единственная идентификация (identity) Ч учетная запись процесса (если только вы не настроите свое Web-приложение ASP.NET на поддержку оли цетворения). В файле web.config приложения можно сконфигурировать ASP.NET на передачу маркера олицетворения от aspnet_isapi.dll рабочему процессу. Тогда физический поток, исполняющий ваш управляемый код, будет ис пользовать олицетворение так же, как это обычно делает IIS. Конфигура ция выглядит следующим образом: Чтобы посмотреть, как это работает на практике, скачайте мой компонент Token Dump с сайта ( в разделе за ноябрь). Вопросы безопасности Создайте виртуальный каталог, указывающий, скажем, на c:\temp. Устано вите и зарегистрируйте запустите чтобы получить его управляемую оболочку, и поместите ее в каталог c:\temp\bin. Теперь создайте такую в Если вы загрузите эту страницу в браузер по то иници ируете пересылку маркера по всей цепочке Ч через INETIFNO в неуправ ляемое потом в рабочий процесс через именованный канал, далее в управляемый код, автоматически скомпили рованный из и, наконец, в мою DLL, которая покажет данные из маркера вызывающего процесса и потока. Информация о пото ке будет, только если он работает под чужой записью. Иначе го воря, если вы видите данные только маркера процесса, значит, поток не использовал олицетворение в момент вызова На рис. зан результат, полученный до олицетворения, а на рис. 5 Ч результат пос ле настройки (через на поддержку олицетворения. Обратите внимание: я оставил рабочий процесс под учетной записью SYSTEM. Ве роятно, я буду по-прежнему тестировать свой код под этой учетной запи сью, пока не исправят ошибки с - [ Token dump performed on 15:57.40 Process Token: User Name: SYSTEM Рис. 4. Результат без олицетворения Физические и До сих пор, говоря о создании управляемых ASP.NET-приложений, я рас сматривал исключительно те аспекты защиты, которые относятся к неуп равляемому коду. Тому есть веская причина: я хочу, чтобы вы поглубже вникли во внутренние механизмы. В CLR (Common Language Runtime) существует совершенно отдельная инфраструктура защиты, которая раз мещается поверх любой операционной системы. На платформе Windows NT процессы и потоки создаются самой операционной системой, и каждо му из них присваиваются свои маркеры. Чем закончится попытка выпол нить какое-либо действие вроде открытия файлов, определяется полити кой безопасности операционной системы. CLR не освобождает вас от нее. dump performed on Thread Token: Name: 1993962763-842925246-1343024091-1001) Process Token: User SYSTEM Рис. 5. Результат при олицетворении А как обстоят дела в Windows 98 или, скажем, на мобильных устройствах? В этих системах нет инфраструктуры защиты. В Windows 98 можно от крыть любой файл. Но даже на таких платформах есть инфраструктура защиты CLR. Так что защита по правам доступа кода (code access CAS) и защита на основе участников системы безопасности (principal based security) все равно действуют, поскольку эти модели полностью аб страгированы от нижележащей операционной системы. Абстрагирование означает, что в защищенных операционных системах вы должны обращать внимание на два контекста а не на один. Ска занное демонстрирует листинг на рис. 6. Теперь я настрою IIS на неаутентифицированных запросов, тем самым навязывая аутентификацию средствами Windows. Я добавлю в файл одну строку, чтобы явным образом управлять тем, как ASP.NET выполняет аутентификацию: Security Context performed on Aug Thread Token: User Name: 1993962763-842925246-1343024091-1011) Process Token: User Name: SYSTEM Рис. 7. Два разных контекста защиты \ Результат показан на рис. 7. хотя у физического потока имеется маркер для реального, пользователя, для тока нет такого понятия. Поэтому я добавил строку в свой файл web.con fig Ч но только ради того, чтобы переопределить параметр в который по умолчанию синхронизирует идентификации (из двух мо делей защиты). Чтобы детальнее показать два разных контекста защиты, я добавил к Web странице после директив импорта следующий код: <х = = s> Результат представлен на рис. 8. Привыкайте к такого рода вещам Ч по началу они могут сбить с толку. В данном случае CLR видит поток, Managed Security Context User is Authenticated? True User Name: Security Context dump performed on 06 17 03: Thread Token: User Name: Process Token: User Name: SYSTEM Рис. Дополнительные различия между двумя контекстами защиты Вопросы безопасности ASP.NET под учетной записью а значит, любой управляемый код, зна ющий о концепции участников системы безопасности, будет считать уча стником именно alice. Заметьте, что код, о котором я говорю, скорее всего будет вашим, так как лишь в отдельных применяется модель защиты на основе участников системы безопасности. Но самое интересное, как только этот поток обратится к неуправляемому коду, последний будет считать, что вызов сделан под учетной записью Пример из реальной жизни: попробуйте открыть например c:\temp\ foo.txt, с помощью объекта Этот объект ничего не знает о защи те на основе участников системы безопасности в CLR, и ему глубоко без различно, что выполняется под учетной записью alice. Его вол нует только CAS, поэтому он требует, чтобы все сборки в стеке вызова имели права на доступ к c:\temp\foo.txt. Однако, когда наш объект откры вает файл, ему приходится вызывать функции операционной системы как в добрые старые времена Win32. Чтобы открыть описатель файла, он вызывает CreateFile, и угадайте, какую идентификацию (учетную запись) увидит операционная система? Правильно Ч kbrown, ведь операционная система ничего не знает о потоках и участниках системы безопасности в CLR. Ее интересуют маркеры, и она видит маркер потока с иден тификацией kbrown. To есть, хотя участником системы безопасности потока является alice, файл можно открыть, только если это разрешает политика CAS и учетной записи kbrown выданы права на доступ к этому файлу. Принцип наименьшей привилегии О'кэй, на мы, пожалуй, закончим разговор о головоломках защиты ASP.NET. Но под занавес хочу бросить вам, Постоянный Читатель, вызов. Я уже давно занимаюсь разработкой ПО под Windows. Собственно, я вы рос на платформе PC и должен что за последние несколько лет, в течение которых я постоянно изучал компьютерную безопасность, мно гие мои представления о ПО кардинально переменились. Одна из идей, которой я хочу с вами поделиться, Ч это миф о том, что для раз работки программ нужны права администратора. Да, это миф, и, каюсь, до недавнего времени я тоже способствовал его распространению. Я никогда особо об этом не задумывался, пока не занялся разработкой одной из первых реализаций SOAP (Simple Object Access Protocol) под Linux, используя один из любимых языков программирования Ч Perl. Программистская культура на той стороне мира (я имею в виду Unix во обще, а не только Linux) невероятно отличается от той, к которой мы при выкли в Windows, На платформе Unix редкий программист работает под учетной записью root (эквивалент учетной записи Administrator в Win Такой стиль стал возможным благодаря тому, что в Unix (изначаль но созданной исключительно для инженеров, студентов и прочих техна рей) много крошечных утилит, позволяющих с легкостью работать с ми нимально возможным набором прав. Одна из наиболее полезных Ч ути лита суперпользователя или утилита переключения пользователя. Благодаря ей обычный может писать и компилировать код. И в самом деле: почему для редактирования текстового файла обязатель но надо быть администратором? Когда вам требуется установить код, вы меняете пользователя на root, временно поднимая уровень своих привиле гий, указываете пароль для root и выполняете установку. А затем тут же возвращаетесь к обычному логину. Когда я веду класс или выступаю на конференциях по проблемам безопас ности, я часто спрашиваю разработчиков, кто из них обычно работает на своих компьютерах под учетной записью администратора. Так вот, руки поднимают чуть ли не все. Единственный бедолага, которому не разреша ют работать как администратору, съеживается в кресле, надеясь, что его никто не заметит. Что если бы я говорил с Unix-разработ чиками и задал им тот же вопрос, они дали бы прямо противоположный ответ. И в кресле съежился бы уже кто думал, будто работать все вре мя под Ч хорошая идея. Поймите меня правильно, я не хочу сказать, что Unix-разработчики умнее Windows-разработчиков. Просто они вырос ли совсем в другой культуре. Итак, хочу предложить вам вот что. Я уже давно пишу программы под учетной записью обычного пользователя. А как я устанавливаю код и на страиваю системные службы вроде IIS? Я использую утилиту (экви валент su), встроенную в Windows 2000: Enter password for Эта строка запускает новую командную оболочку в новом сеансе под учет ной записью Administrator, и любая программа, запущенная из этой обо лочки, будет работать как Administrator. Если у меня появляется настрое ние запустить что-то прямо из меню Start, я выбираю соответствующую команду (например, Internet Services Manager) и, удерживая клавишу Shift, щелкаю команду правой кнопкой мыши. Появляется контекст ное меню с чудесной Run As... Попробуйте. Думаю, вам понравится. Почему я предлагаю вам это? По двум причинам. Во-первых, так вы буде те куда меньше рисковать своей безопасностью, просматривая Web, откры вая вложение электронной почты и т. д. Во-вторых, вы поможете мне из менить менталитет Windows-программистов. А то слишком уж много кода, нормально только под учетной записью Administrator, пото Вопросы безопасности ASP.NET му что его писали и тестировали с администраторскими правами. Написа ние кода, способного работать в другом контексте защиты, конечно, по сложнее, ведь устанавливать его будет администратор, а запускать Ч обыч ный пользователь. Например, записывать что-то в SER при установке совершенно бесполезно, так как администратор вряд ли станет запускать вашу программу после ее установки. Должен сказать, что в этом смысле программы от Microsoft лучше всех остальных. Большинство программ Microsoft (в том числе среда ки) прекрасно работают под учетными записями обычных пользователей. Мое недовольство вызывает лишь несколько программ, которые, будучи запущенными не под администраторской учетной записью, иногда входят в Дарвиновский цикл. (Дарвин Ч кодовое название технологии Micro soft Installer, а Ч это когда система снова и снова выводит диалоговое окно установки, а вы неистово нажимаете Cancel.) Наш нынешний менталитет требует фактического снятия защиты на вре мя разработки и резкого усиления ее перед поставкой готового Проблема с таким подходом в том, что, разработав всю систему без каких либо ограничений, сузить ее привилегии ужасно трудно. Для этого может понадобиться полная переработка или даже удаление отдельных функций. Так как я много думал о проблемах безопасности, то теперь твердо уверен, что строгие ограничения защиты надо вводить сразу, еще на первых этапах разработки, а затем слегка ослаблять их Ч и то лишь в том случае, если это действительно нужно. Привыкайте проектировать функции, не забывая о безопасности. Но самое главное Ч с вашими программами будет легче работать по прин ципу наименьшей привилегии. Если мы хотим изменить стереотипное представление о том, что в мире Windows мало заботятся о безопасности, то, по-моему, мы и должны начать революцию, меняя свои привычки и культуру Давайте делать это вместе! Кит Браун (Keith Brown) работает в как исследователь, технический писатель и преподаватель. Разъясняет программистам ции безопасного кода. Автор книги Windows Security (Addison 2000), соавтор Effective COM. С ним можно связаться через Джейсон Алгоритмы хэширования позволяют выявлять попытки модификации кода приложений* Криптографические генерируют последовательности ванной длины из входных данных размера. Одни и те же входные данные всегда дают один и тот же результат, который называется (hash code). С помощью этих алгоритмов вычислять и проверять получая таким образом гарантию, что мый на компьютере, не был образом модифицирован. ASP.NET предоставляет программный механизм проверки для страницы, запрашиваемой клиентом, В этой статье автор как хэш-коды в для распознавания попыток модификации приложения и запуска вредоносного кода. Каждый опасается, что некий злоумышленник изменит код, развернутый на Web-приложения. В идеале служба Microsoft Internet Information Services должна быть установлена в неприступ ной данных data fortress) Ч на компьютере, взло мать который невозможно и где никакой злоумышленник, троянская про грамма или червь никогда не сумеет модифицировать код Web-приложе ния. надеясь на лучшее, надо готовиться к худшему и предусматривать легко реализуемую и управляемую Если бы могли автоматически обнаруживать неавторизованные изменения и бло кировать доступ к измененным файлам, вы напрочь исключили бы один из Публиковалось в MSDN Редакция. 2002. № 3 (сентябрь). Ч Прим. Алгоритмы хэширования попытки худших вариантов развития событий. К счастью, создавать такие приложе ния в ASP.NET довольно легко. Независимо от того, являетесь вы провайдером Web-хостинга, обеспечива ющим безопасность точек публикации (publishing points), где заказчики развертывают код, или сами развертываете код на собственном оборудова нии, вы хорошо что такие точки уязвимы перед атаками и нужда ются в защите от несанкционированного доступа. захва тивший управление точкой публикации, наносит ущерб не только взло манному сайту, но и любому другому сайту или серверу, на который он может передать зараженный вирусом код. Так что главный в защите данных Ч предотвратить возможность выполнения опасного кода при публикации в IIS. Я покажу, как это делается в ASP.NET. Снятие цифровых отпечатков приложения Отпечатки пальцев Ч не слишком надежное биометрическое средство идентификации. Их можно подделать, ведь это всего лишь следы на повер хности предметов. С цифровой информацией дело обстоит иначе. Мы мо жем обработать все данные по алгоритму, который формирует из них бо лее короткие последовательности фиксированной длины. Таким образом, цифровой отпечаток создается на основе не каких-то внешних признаков, а всего потока данных. Процедура, создающая цифровой отпечаток, назы вается а сам цифровой отпечаток Ч хэш-кодом. Для применения верификации на основе описанной в этой ста тье, вы должны сначала закончить разработку файлов ASP.NET-приложе ния, используя доверяемую рабочую станцию. Затем вычислить каждого файла приложения и разместить их на сервере одновременно с файлами. Чтобы не допустить изменения хэш-кодов, храните их отдельно от файлов приложения Ч не в точке публикации. Рис. 1 иллюстрирует архитектуру модуля верификации хэш-кода и ее связь с ASP.NET. Здесь в точке публикации развернут единственный файл приложения ASP.NET вместе с хэш-кодом этого файла. Заметьте, что хэш-код на рис. 1 совпадает с хэш-кодом в исходном коде верификационного модуля (рис. 2). ASP.NET выполняет такой модуль не в процессе приложения, а в рабочем процессе ASP.NET и ищет его сборку в GAC (кэше глобальных сборок) на основе информации, прописанной в Пространство имен которое является частью Microsoft Framework Common Language Runtime (CLR), содержит классы, реализующие Эти алгоритмы идеально подходят для обнаружения модификаций в коде приложения или в наборах так как малейшее изменение информации на входе влечет за собой изменение хэш-кода. Microsoft 6. GET. Рис. 1. Уровень чэширует каждый запрос Рис. 2. Модуль верификации для using using using using { public : { void context) void public void sender, e) { app *. f = hash flid5Hasher.CofnputeHash(f); ex) { Processing flequest app. Алгоритмы хэширования попытки модификации На рис. 3 показано, как с помощью HashAlgorithm в консоль ном приложении, написанном на С#, вычисляются и выводятся для каждого файла в текущем каталоге. Экземпляр класса HashAlgorithm создается его статическим методом Create, а чтобы получить объект, пред ставляющий текущий каталог, используется GetFiles возвращает набор и в С# вы перебираете его элементы оператором работает с потоком ввода вывода, a BitConverter используется в моей программе для отображения битов хэша в форме. Код на рис. 3 просто перебирает все файлы, последовательно открывая, хэшируя и закрывая каждый из них. Рис. 3. Консольное приложение, генерирующее хэш-код (на С#) System; {> hash; fi Di recto recto f fi) { try fs = hash = + + ex) Код, показанный на рис. 3, можно адаптировать под вашу процедуру раз вертывания, чтобы автоматизировать обновление безопасного хранилища хэш-кодов. А для обновления такого хранилища вручную можно исполь зовать непосредственно мое консольное приложение. При этом вам потре буются права администратора IIS. Самые важные строки в коде на рис. 3 Ч вызов метода ComputeHash применительно ко входному потоку (детали см. по ссылке Класс используется для удобства чтения хэш-кодов но Microsoft му важно лишь то, что метод кодирования совпадает с методом автомати ческой проверки хэш-кодов. Если вы не станете вычислять хэш-коды для каждой исполняемой про граммы или сценария и не будете периодически их проверять, вы не смо жете быть уверены, чей именно код выполняет ваш компьютер. Вот вам двадцать вторая уловка для автоматизированных систем, которым нужно динамически проверять хэш-коды: для проверки аутентичности хэш-коды должны быть доступны в режиме реального времени. Но если сами хэш коды могут подвергнуться то как же их аутентифицировать? Хотя каждый хэш-код можно подписывать цифровой подписью и проверять по ней аутентичность каждого вы тем самым просто спихнете про блему на другой уровень. Чтобы проверять цифровую подпись, автоматизированной системе нужен доступ к ключу верификации подписи (signature verification key) в реаль ном времени, а этот ключ тоже может быть изменен. Если хэшировать ключ, его сертификат и всю цепочку доверия, то как их всех аутентифи цировать? Любой из этих элементов может быть изменен, если только и они, и соответствующая логика не встроены в непрограммируемое обору дование. Однако в дополнительных уровнях проверки оп ределяется требуемым уровнем защиты данных. Один из способов повысить безопасность данных, обеспечиваемую хэш и проверкой подписей, Ч подключить к компьютеру устрой ство ROM-памяти для хранения в нем хэш-кодов или ключа. Но тогда возникает проблема, как защитить логику (машинный код) проверки хэ шей или подписей, поскольку может взломать эту логи ку и изменить механизм хэш-кодов так, чтобы он извлекал данные не из устройства ROM-памяти, а из какого-то другого хранилища, нужного злоумышленнику. В общем, лучше (да и проще) выбрать сравни тельно надежное хранилище для хэш-кодов и смириться с что на про граммируемых компьютерах абсолютная защита недостижима. Процесс обновления хэш-кодов в безопасном хранилище должен отли чаться от процесса развертывания логики приложения. Этот дополнитель ный уровень авторизации требует публикации в IIS: сначала вы публикуете исполняемый код на сервере, затем Ч хэш-коды в безопас ном которое выдает разрешение IIS на запуск исполняемого кода. Вы можете спокойно положиться на то, что злоумышленник, полу чивший доступ к одному из этих мест (IIS или хранилищу), не получит доступ ко второму. А тот, кто сумеет получить доступ к ним обоим, спосо бен обойти любой программный механизм защиты данных, полностью перепрограммировав компьютер. Алгоритмы хэширования выявлять попытки модификации Автоматическое предотвращение попыток модификации сценариев Для большей безопасности на компьютере должны выполняться только те программы, которым разрешено на нем работать. На большинстве совре менных платформ процессор исполняет любой совместимый код. Возмож но, в будущем мы увидим процессоры, которые на аппаратном уровне про веряют цифровые подписи и перед выполнением машинных инструкций. А до тех пор обеспечение безопасности останется задачей разработчиков и администраторов. Чтобы автоматически обнаруживать изменения, надо предусмотреть спе циальный уровень кода, проверяющий пересчетом хэша про граммы при каждой попытке ее запуска. Каждый файл вашего ASP.NET приложения является отдельной программой, и каждый запрос клиента к одному из таких файлов вызывает его выполнение. Закончив программи рование и отладку, вычислите хэш-коды для каждого исходного файла, который вы собираетесь развернуть, и сохраните их. Для этой цели вам пригодится код, уже показанный на рис. 3. Вы должны хранить хэш-коды вне URL-пространства тогда они будут надежно защищены даже в том случае, если взломщик получит доступ к файлам приложения на сервере через обычную точку их публикации. Но не стоит чересчур увлекаться защитой хэш-кодов, ведь любой злоумыш ленник, получивший полный контроль над вашим сервером, сумеет легко удалить ваш код, обнаруживающий изменения. Поэтому достаточно убе диться, что хэш-коды недоступны через какую-либо точку публикации. Действия злоумышленника, который получил доступ для публикации сво его кода на вашем сервере, но не получил полного контроля над ним, ус пешно блокируются при использовании описанной в этой статье методи ки. А чтобы остановить злоумышленника, захватившего полный контроль над нужны совсем другие меры. В ASP.NET есть механизм проверки цифровых отпечатков (хэш-кодов) для каждой страницы, запрашиваемой клиентом. Чтобы пользовательский модуль, обрабатывающий запросы от клиентских брау зеров, отредактируйте Ч файл, который контролирует кон фигурацию ASP.NET для конкретного ящика IIS (IIS box). Интерфейс модуля Ч HTTP-обработчика в ASP.NET определен в Module. С#-код, который создает новый класс такого модуля, автомати чески проверяющего хэш-коды, приведен на рис. 2. Этот обработчик надо зарегистрировать в подразделе кроме того, их можно загружать и выгружать, не перезапуская 3.IS. Любой HTTP-модуль, применяемый в ASP.NET, должен реализовать ин терфейс При установке ASP.NET автоматичес ки конфигурируются стандартные HTTP-модули, в том числе и UrlAllthorizationModule. Каждый стандартный модуль регистрируется в одном или нескольких делегатах обработчиков событий (event handler delegates) объекта приложения ASP.NET. интерфейса IHttpModule в том, что два его метода Ч и Dispose Ч вы зываются благодаря чему модуль может регистрироваться как обработчик любых нужных ему событий (и снимать себя с регистрации). Init вызывается до обработки любых запросов ASP.NET, a Dispose Ч когда ASP.NET требуется удалить модуль из цепочки обработки (processing pipeline). Класс IHttpModule на рис. 2 в делегате события Authorize приложения. вводит в процесс обработки каждого запроса этап авторизации, на котором вычисляется для запрошенной клиентом страницы и сравнивается с вычисленным ранее. С этой целью модуль открывает для после чего хэширует входной поток, используя Algorithm. Что бы код, приведенный на рис. 2, стал реальным модулем верификации хэш кодов, добавьте в него процедуру получения аутентичного хэш-кода из надежного хранилища. Вы можете хэш-коды сценариев вашего приложения в HashVeri ficationModule Ч тогда при каждой установке нового кода в точке публи кации потребуется развертывать новую версию Как раз этот подход и иллюстрирует рис. 2: единственный хэш-код в код. Однако обратите внимание, что хэш-код: приведен на рис. 2 лишь в целях Ч использовать его в реальном HashVerificationModule не следует. В настоящем приложении замените его на список всех файлов и добавьте в модуль код, который в зависимости от значения или другого ана логичного идентификатора ресурса определяет, какой хэш надо использо вать для проверки. Весь этот процесс показан на рис. 1. хэширования позволяют выявлять попытки Конечно, такое решение работает, но выглядит неуклюже. Помимо всего прочего, при каждом изменении исходных файлов ASP.NET-приложения и пересчете их хэш-кодов с помощью какой-либо утилиты вроде консоль ного приложения, приведенного на рис. 3, вам придется изменять и хэш зашитые в такая зависимость даже полезна для защиты данных. Мой HashVerificationModule можно рас ширить, дополнив его проверкой Ч конфигурацион ного файла ASP.NET-приложения. Тогда злоумышленник, получивший доступ к корневой точке публикации приложения, не сможет изменить содержимое этого файла. Развертывание HTTP-модуля Классы, реализующие интерфейс развертываются в ASP.NET через раздел соответствующего конфигурационного XML файла. Вы можете ограничиться развертыванием этих модулей только для конкретного приложения, добавив их к файлу web.config, но тогда ваша система окажется более уязвимой, чем в том случае, когда HTTP-модули регистрируются на уровне Модификация требует куда более высокого уровня разрешений по сравнению с модифи кацией поэтому модули, обеспечивающие защиту данных, име ет смысл развертывать только через Чтобы зарегистриро вать HashVerificationModule в присвойте сборке этого мо дуля строгое имя (strong name) и измените раздел можно криптографически подписать, используя класс Asym например RSA или DSA. Производные от него классы и содержат метод шифрующий хэш-код с применением закрытого ключа, и метод проверяющий подпись по открытому ключу. Для полной уве ренности в том, что файлы вашего ASP.NET-приложения не изменены, вы можете подписывать хранящиеся в соответствующей базе дан ных, и вызывать VerifyHash перед верификацией хэш-кодов. Если вы бу дете делать именно так, то злоумышленнику Ч чтобы обойти HTTP-мо дуль верификации хэш-кодов, загружаемый в каждое приложение ASP.NET через Ч понадобится украсть ваш секретный ключ и взло мать не только защиту точки публикации, но и базу данных или другое их хранилище. с цифровой подписью создает дополни тельный уровень защиты в тех случаях, когда аутентификация осуществ ляется автоматически. Это гораздо лучше простого создания и проверки хэш-кодов. Взломщик, который может модифицировать ваше защищенное хранилище хэш-кодов, сумеет заменить аутентичные на свои (если он зна ет, какой алгоритм хэширования был использован вами). Алгоритм хэши рования с например от KeyedHashAlgorithm, тоже создает дополнительный уровень так как атакующему придется узнать не только секретный ключ, примененный в (чтобы правильно подписать свои хэш-коды), но и ключ, использованный в KeyedHashAlgorithm для вычисления этих кодов. Джейсон (Jason Coombs) Ч соучредитель некоммерчес кого исследовательского института судебной компьютерной науки (forensic computer science), а также президент DigitalMarketplace.com, фирмы, которая на проблематике безопасности Интернета и защиты данных. С автором можно связаться по Джеф Изощренный код Ваш путь к вершинам мастерства в ASP.NET* В этой рубрике автор делится с читателями своими любимыми трюками программирования под ASP.NET, как локализовать Web-приложе ния десятью строчками кода, динамически генерировать изображения на Web-страницах с применением HTTP-обработчиков, использовать кэш приложения, поддерживаемый в ASP.NET, связывать со на клиентской стороне и сохранять данные между запросами. Одна из активно рекламируемых возможностей Microsoft Framework Ч упрощение программирования (не только для Web, но и прикладного в целом). И вряд ли кто стал бы спорить, что вся эта шумиха не оправдан на. Библиотека Framework> Но если бы вы положились исключительно на эту библиотеку классов, у вас могло бы создаться ложное впечатление, что в Framework мень ше возможностей для искусных программистов сделать нечто грандиоз ное. Напротив, один только размер Framework говорит о том, что в ней наверняка есть крупицы бесценных возможностей. Чтобы не быть го лословным, я продемонстрирую пять жемчужин, которые помогут Публиковалось в Magazine/Русская 2002. № 2 (август). Ч Прим. изд. 3- ASP.NET взойти к вершинам мастерства. Все они из мое го багажа любимых трюков под ASP.NET. И думаю, они пригодятся вам не меньше, чем мне. Локализация Web-приложений десятью строчками кода Как и все управляемые программы, ASP.NET-приложения опираются на классы из А многие поддерживают концепцию культур (culture-aware). Так, DateTime-метод формати рует даты на основе информации о выбранной культуре. использует ту же информацию для форматирования денежных единиц и других строк с числовыми значениями. Если вы создадите объект Culture Info, представляющий какую-нибудь культуру, и присвоите этот объект свойству Current Culture вызвавшего потока, эти методы соответственно изменят формат данных. Web-приложение может принимать запросы со всего мира. ASP.NET-при ложения способны извлекать информацию о предпочтительной для поль зователя культуре (user's preferred culture) из заголовков в HTTP-запросах. Данные в заголовках доступны через свойство объекта Допустим, пользователь указывает в бра узере, что французский является основным языком, а английский (США) Ч вторым. Тогда заголовок переданный браузе ром, выглядел бы так: fr, В возвращающем строковый массив, эта информа ция была бы представлена парой строк: Следующее выражение создает объект, который представляет указанную в первой строке UserLanguages. Оно одинаково хоро шо работает и с нейтральной культурой (neutral culture) (в строке вроде fr задается только язык, но не страна или регион), и с точно определен ной (specific culture) (строка наподобие задает как язык, так и страну/регион). Culturelnfo ci = А это выражение назначает Culturelnfo текущему потоку, заставляя методы, которые поддерживают концепцию культур, соответственно изме нять формат возвращаемых данных: Ваш путь к вершинам в ASP.NET = ci; Поступая так в каждом запросе, вы сделаете первый шаг к введению мно гоязыковой поддержки в ASP.NET. В некоторых случа ях больше ничего и не требуется, чтобы приложение поддерживало кон цепцию культур. Программа-пример на рис. i и рис. 2 демонстрирует, как применить на практике то, что вы узнали. Date.aspx Ч простая Web-страница, на которой показывается текущая дата и время. содержит обработчик со бытия вызываемого в начале каждого запроса. Код в обработчике получает предпочтительную для пользователя культу ру из запроса и назначает соответствующий объект потоку, который в данный момент обрабатывает этот Web-запрос. Рис. 1. Date.aspx Page (}); Рис. 2. Global.asax e) if > 0) { не ft был неудачным I Чтобы увидеть, как файл Global.asax влияет на вывод в скопи руйте оба файла на Web-сервер, поддерживающий ASP.NET. Потом запу стите браузер и введите Date.aspx. (Если браузер работает на Web-сервере и нужные файлы находятся в каталоге на серве ре, URL должен быть таким: Если вы Ч пользо ватель из США, то увидите страницу в том виде, в каком она показана на рис. 3. Edit i 5/21/ Рис. З. английского Теперь идите в Tools Internet Options General и щелкните кнопку Langua ges. Добавьте язык French (France) и переместите его в самый верх списка. Снова запросите Date.aspx, и страница будет выглядеть иначе (рис. 4). Включайте во все свои обработчик Applica вроде приведенного на рис. 2, и вы бесплатно добьетесь того, чтобы они различали 3 Fie Tods 21/05/ Рис. 4. Локализация для для динамической генерации изображений Для включения изображения на Web-страницу достаточно вставить тэг Секрет отображения динамически генерируемых изображений на страни цах ASP.NET Ч в HTTP-обработчике. Такой обработчик является классом, который обрабатывает запросы на данный ресурс или тип ресурсов. Ког да вы запрашиваете какой-нибудь ASPX-файл, именно HTTP-обработчик загружает и исполняет эту страницу. Он сопоставляется с в разделе файла Есть и другие встроенные HTTP-обработчики Ч они обрабатывают запросы на и фай лы прочих типов, поддерживаемых ASP.NET. Вы можете расширить ASP.NET, написав собственный HTTP-обработчик. На рис. 5 представлен исходный код базового HTTP-обработчика, кото рый генерирует изображения размером 128 ? 128 пикселов и возвращает его в HTTP-ответе как JPEG. Всякий раз, когда запрашивается ресурс, зарегистрированный за этим обработчиком, ASP.NET вызывает его метод ProcessRequest. Рис. 5. Генерация карты public : { public { // карту размером 128 на = (128, 128, // объект для // на этой карте g * // используйте // // тип контента в ответе; см. след. стр. Рис. 5. Генерация битовой // Записываем в HTTP-ответ Очистка (); (); public // Если мы данного класса // можно в пуя и // А false, повторно // true; Process Request создает битовую карту (экземпляр в памяти и может рисовать на ней, используя объект phics. Замените TODO соответствующим и вы получите HTTP-обработчик, генерирующий изображения Программа на рис. 6 и рис. 7 демонстрирует, как применить новые знания в Web-приложении. Чтобы посмотреть ее в установите файлы на Web-сервере, ASP.NET. Затем запросите PieChart.aspx в браузере, введите четыре числа и щелкните кнопку Show Chart. В окне браузера появится круговая диаграмма, отражающая соотношение введен ных вами значений (рис. 8). Рис. 6. PieChart.aspx Ваш к вершинам ASP.NET Рис. 6. след. стр. Рис. 7, using using using ; public void // Извлекаем входные иа строки запроса vals vals[2] = fleqлest["q3"]); - flequeetE"q4"]); int width = = // Создаем карту, диаграмму // и ее в // Bitmap new (width, height, g = (g, height); // // <); public get { return void (Graphics a, vals, int int // фон см. след. стр. путь к вершинам мастерства в Рис. 7. Ьг new (Ьг, О, О, height); (); // массив кистей SolidBrush[] = new SoiidBrush new SoiidBrush = new SoiidBrush new SoiidBrush - SoiidBrush new SoiidBrush // значения decimal total = in total val; // Строим // start end O.Of; current 0.0m; 1=0; * (current / total) % &], O.Of, O.Of, start, - start); // Очистка // (SoiidBrush brush in brushes) (); ASP.NET 3 Х Tools Рис. 8. Сгенерированная круговая диаграмма Как работает Эта страница включает элемент управления Image, в котором изначально нет изображения, потому что его свойство ImageUrl не определено. Щелчок кнопки Show Chart активизи рует метод OnShowChart на сервере. формирует URL, до полняя его строкой запроса, в которой содержится пользовательский ввод, и присваивает его элементу управления Image. Если ввести в четыре тек стовых поля значения 100, 200, 300 и 400, получится следующий Обратите внимание на ресурс, идентифицируемый на PieChart.ashx. В PieChart.ashx находится который генерирует круго вые диаграммы на основе данных, передаваемых в строке запроса. Дирек тива @ в начале файла информирует ASP.NET о том, что в PieChart.ashx содержится HTTP-обработчик. Когда поступает запрос на ASP.NET автоматически компилирует и запускает этот обра ботчик. Дополнительной регистрации не требуется, потому что в ne.config сопоставлены с обработчиком, знающим, как ком пилировать и запускать другие HTTP-обработчики. Вы можете экстраполировать этот пример на любое ото бражающее динамически генерируемые изображения. Лично я совсем не давно воспользовался им. создавая клиентский Web-интерфейс для Micro soft TerraServer. Это приложение передает HTTP-обработчи ку, который извлекает спутниковые снимки с TerraServer и сшивает их в единое изображение. Ваш путь к мастерства в Использование кэша приложения знают, что такое состояние приложения (application state): глобальное хранилище в памяти для данных, доступных всем час тям этого приложения. ASP.NET, по-прежнему поддерживая состояния приложений в стиле ASP, предлагает кое-что получше: кэш приложения (application cache). Кэш приложения уменьшает число обращений к базе данных и другим файлам и тем самым увеличивает производительность. Вы можете определять правила устаревания элементов, хранящихся в кэше, и создавать зависимости между элементами кэша и файлами. Вы даже получаете уведомления, когда элементы удаляются из что по зволяет вам заменять их элементами с более новыми данными. В качестве примера, демонстрирующего, как использовать кэш приложе ния для повышения производительности, рассмотрим Web-страницу на рис. 9. При каждом запросе она считывает массив строк из текстового файла и отображает одну строку, выбираемую случайным обра зом. Файл Quotes.txt Ч он здесь не показан, но включен в исходный код, который можно скачать к этой статье (см. ссылку в конце статьи), Ч содер жит коллекцию цитат. Скопируйте aspx и Quotes.txt в вирту альный каталог на своем Web-сервере. Потом затребуйте из браузера и попробуйте несколько раз обновить страницу. При каждом об новлении должна появляться новая цитата (рис. 10). Рис. 9. flunAt="server" /> try { reader new for (); != null; line reader, см. след. стр. Рис. 9. Random = (); index (0, - 1); finally if (reader Edit View Help, I '.. ; С it easy to shoot yourself in the foot; C++ it harder, when you do, it blows whole leg. I Done Рис. 10. цитаты из кэша И что же неправильного в Ничего Ч если производи тельность вам безразлична. При каждом запросе DumbQuotes.aspx щается к физическому файлу и считывает его содержимое в Обращения к файлам и базам данных Ч наиболее часто встре чающиеся узкие места в Эта страница работала бы куда быстрее, если бы считывала Quotes.txt только раз и помещала его в кэш (в памяти). В дальнейшем цитаты было бы извлекать из а не из файла на диске. Более совершенная версия той же страницы (теперь она называется Smart aspx), читающая цитаты из кэша приложения, показана на рис. 11. Сопутствующий файл (рис. 12) инициализирует кэш при за пуске приложения, считывая Quotes.txt и помещая полученный ArrayList в кэш приложения. Кроме того, он настраивает ASP.NET так, чтобы она вызывала локальный метод Refresh Quotes, если в Quotes.txt вносятся ка кие-то изменения. реагирует на изменение файла, повтор но считывая его содержимое и добавляя в кэш обновленный ArrayList. Страницы DumbQuotes.aspx выглядят в браузере оди Ваш путь к наково, но последняя работает гораздо быстрее за счет уменьше ния числа обращений к файлу на диске. Рис, 11. /> void quotes = (ArrayList) if { fiandoffl rand new {); Index (0, - 1); = } { if данный запрос поступил после // ArrayList из кэша и до в // нового что // занят; страницы решает = "Server Рис. 12. Cache static string null; void (> { = = quotes - {); new см. след. стр. 78 ASP.NET 12. new static key, Object { quotes static ArrayList { ArrayList quotes - new (); * try reader = flew for * (); null; ()) finally if null) } Связывание со сценарием на клиентской стороне По-видимому, DataGrid самый универсальный Web-элемент в О нем пишут чаще всего, но и вопросов он вызывает немало. Вот один из типичных: Как создать DataGrid. который выводит окно, где у пользова теля перед удалением какой-либо записи Отвечаю: связать кнопки DataGrid с атрибутами которые исполь зуют JavaScript-функцию подтверждения (она выводит соответствующее окно). Самое сложное Ч как реализовать такое связывание. Web-страница на рис. 13 как это делается. Ваш путь к вершинам мастерства в ASP.NET Рис. 13. ConfirmDelete.aspx false" Header /> ID" /> /> right" /> /> /> (Object sender, { if { см. след. стр. Рис. 13. (); * * titles price 0". * (}; (); finally {); void sender, 8} ет if { button "return void (Object if "Deleted + ConfirmDelete.aspx DataGrid для отображения записей из таб лицы базы данных Pubs (SQL Server). DataGrid включает Button Column, который формирует дополнительный столбец кнопок Delete. Вставить атрибут OnClick в тэг ButtonColumn нельзя, потому что Button Column его не поддерживает. Но вы можете обрабатывать события Item Created, которые генерирует DataGrid при создании строк из источника данных, и программно добавлять атрибуты OnClick. На рис. 13 оператор: hSc регистрирует метод OnAttachSeript, который должен вызываться всякий раз, когда создается строка. В свою очередь OnAttachSeript получает Ваш к вершинам в на элемент управления (button control) в крайнем левом поле строки: button = и добавляет DHTML-атрибут OnClick, выполняющий следующее выраже ние на JavaScript: ("onclick", "return confirm ( you Этот JavaScript-код выводит окно подтверждения и блокирует отправку страницы обратно на сервер, если пользователь выбирает Cancel вместо ОК. Поскольку метод активизируемый при щелчке кноп ки Delete, является обработчиком событий на серверной стороне, он не вызывается, если страница от клиента не возвращается. Можете сами убедиться в этом, запросив в своем бра узере. Щелкните одну из кнопок Delete для вывода окна подтверждения (рис. Затем щелкните ОК, чтобы имитировать удаление записи, или Cancel, чтобы оставить ее нетронутой. OnDeleteRecord на самом деле не удаляет запись. Он просто записывает ее поле title в элемент управле ния Label внизу страницы. И в нем не появляется никакого текста, когда вы выбираете Cancel, а это что OnDeleteRecord в таком слу чае не вызывается. The Busy Internet Can ! Delete] I -But Is It User ] of rtr "J Рис. 14. DataGrid и окно подтверждения 82 ASP.NET Сохранение данных между запросами Одна из самых больших сложностей в написании Web-приложений, спо собных сохранять состояния, связана с тем, что HTTP Ч протокол, не под держивающий состояния (stateless protocol). вы хотите создать страницу с который позволяет сортировать и листать данные. Более того, при (paging) DataGrid вам нужно запоминать, как он был отсортирован в прошлый раз, чтобы не нарушить порядок сор тировки. Соответствующую информацию хранить на самой странице нельзя Ч попробуйте, если хотите, только у вас ничего не потому что два запроса одной и той же страницы обрабатываются двумя разными объектами страницы (page Ч зато можно записать ее в состояние отображения. Состояние отображения (view Ч это простой в программировании механизм для сохранения информации между двумя HTTP-запросами. Элементы управления его для запоминания данных между обращениями к ним (invocations); то же самое могут делать и страницы. Класс Page в ASP.NET включает открытое свойство Оно предоставляет прямой доступ к состоянию отображения. В ASPX-файле оператор: = "Price"; записывает строку в отображения и индексирует ее по ключу, в роли которого выступает строка При последу ющем запросе оператор: string exp = (string) считывает записанную строку. сохраняет эту строку между зап росами, отправляя ее клиенту, а потом в скрытом элементе уп равления с именем VIEWSTATE. Web-страница на рис. 15 демонстрирует, как применить состояние отобра жения для реализации с поддержкой сортировки и ния. Метод OnSort не только сортирует содержимое DataGrid, но и сохра няет последнюю отсортированную запись в состоянии отображения. При пролистывании DataGrid метод извлекает информацию о сор тировке предыдущей страницы и использует ее для сортировки который связан с DataGrid, В итоге вы можете листать DataGrid, не теряя порядок сортировки. путь к вершинам мастерства в Рис, 15. S> Dat r " /> uct nit P ASC" A аи. след. стр. . 15. - /> = string query "select * sender, if { adapter = SqlDataAdapter DataSet = new DataSet (}; (); i void sender, i SqlDataAdapter * new connstr); DataSet ds = new DataSet (); DataView = new DataView = : = view; void (Object e) = adapter - new SqlDataAdapter (query, connstr); DataSet ds - new DataSet (>; (ds); DataView view = new DataView см. след. стр. Ваш путь к в ASP.NET Рис. 15. exp = if (exp 1 * = view; Исходный код для этой статьи можно скачать по ссылке load.microsoft.com/download/msdnmagazine/code/Aug02/WXP/EN-US/ WickedCode0208.exe. Джефф Просиэ Prosise) зарабатывает на жизнь, программы для Windows и других делать то же самое. Является соучредителем Winteltect Ч которая занимается консалтингом и обучением разра ботчиков программированию на платформе Автор книги Programming Microsoft (Microsoft 2002). С ним можно связаться по адресу wicked@microsoft.com. Ди Эспозито На переднем крае Состояние отображения в NET Состояние отображения используется для контекста вызова и сохранения значений между запросами к одной и той же странице. Автор о реализации состояния отображения в ASP.NET и как предохранить Web-страницы от веса и сделать их чуточку безопаснее. Состояние отображения (view state) страницы ASP.NET Ч это ее состоя ние на момент последней обработки на сервере. Оно используется для формирования контекста и сохранения значений между последо запросами к одной и той же странице. По умолчанию состоя ние записывается на клиенте в скрытом поле, добавляемом к странице, и восстанавливается на сервере перед обработкой запроса к этой странице. Хотя состояние отображения передается между клиентом и сервером вме сте со страницей, оно не представляет и не содержит никакой информа ции, связанной с внешним страницы на клиентской машине. Сегод ня я расскажу о реализации отображения в ASP.NET и покажу, как предохранить Web-страницы от лизбыточного и сделать их чу точку безопаснее. Использование состояния отображения: за и против У состояния отображения есть свои плюсы и минусы, которые следует тщательно взвесить, прежде чем решиться его использовать. С одной сто роны, оно не требует дополнительных серверных ресурсов для хранения Публиковалось в Magazine/Русская Редакция. 2003. 2 (февраль). Ч Прим. Состояние ASP.NET информации о состоянии и несложно в реализации. С другой Ч состояния отображения все же отнимает часть вычислительных мощностей и повышает нагрузку на канал связи из-за пересылки дополнительных данных. Поскольку физически состояние отображения является частью страницы, его легко извлечь, но это можно расценивать и как слабость, которую легко использовать во Состояние отображения в страницу, поэтому оно неиз бежно увеличивает размер страницы на несколько килобайт. Так, сложная страница реального сайта запросто может получить дове сок к HTML-коду, пересылаемому браузеру, Ч особенно если состояние отображения используется на ней нерационально и без должного контро ля. Поскольку состояние отображения состоит из чисто текстовых оно может быть модифицировано злоумышленником. Хотя программис не рекомендуется хранить в состоянии отображения конфиденциаль ные данные (вроде номеров кредитных карт, паролей или строк чения), о возможности атак на сервер через состояние отображения никто не говорит. Само по себе состояние отображения не является дырой в но подобно строкам запросов и другим скрытым полям способно переносить вредоносный код. Правда, состояние отображения кодируется, защищается и проверяется, поэтому оно все же безопаснее других скрытых полей, применяемых программистами. Состояние отображения является одним из важнейших средств ASP.NET и не столько по его технической целесообразности, сколько из-за того, что оно делает возможной магию Web Forms. Однако при бесконтрольном применении оно становится просто лишней обузой. Класс State Bag Класс StateBag реализует состояние отображения и управляет данными, которые страница ASP.NET и встроенные в нее элементы управления со храняют между отправками на сервер одного и того же ее экземпляра. Этот класс работает как объект-словарь и реализует интерфейс Его базовые классы Page и Control открывают доступ к состоянию отобра жения через свойство поэтому вы можете добавлять и удалять элементы из StateBag так как и из любого объекта-словаря: = value; Записывать данные в состояние отображения можно только после сраба тывания события для запроса страницы, а читать Ч на любом этапе жизненного цикла страницы, но до ее рендеринга (до генерации события Свойства и методы StateBag перечислены в табл. 1. Табл. 1. Свойства и методы Bag Свойство Описание Count Возвращает число элементов в объекте Item позволяет получить или задать значение элемента, в объекте Keys Позволяет объект-набор (collection object), содержа щий ключи, которые определены в объекте Values Позволяет содержащий все значения, которые хранятся в объекте Метод Описание Add Добавляет в набор новый объект если такой элемент уже существует, он обновляется Clear Удаляет все элементы текущего состояния отображения Возвращает объект, перечислять все в State Bag Указывает, ли при обработке запроса элемент с заданным ключом Remove Удаляет заданный объект из Каждый элемент в StateBag представлен объектом Stateltem. Экземпляр этого объекта неявно когда вы задаете значение для свойства индексатора или вызываете метод Add. Элементы, добавляемые к объекту StateBag, отслеживаются до тех пор, пока состояние отображения не со храняется методом Если элемент состояния не сохранен, свойство IsDirty объекта Stateltem равно True (это свойство неявно ис пользуется методом IsItemDirty). Содержимое набора StateBag в строку, затем коди руется по основанию Base64 и, наконец, записывается в скрытое поле стра отправляемой клиенту. Состояние отображения страницы Ч куму лятивное свойство, формируемое из содержимого свойства этой страницы и состояния отображения всех размещенных на ней элементов управления. Проблемы безопасности С архитектурной точки отрицать важность состояния отображе ния нельзя, поскольку это ключ к механизму автоматического управления состоянием в ASP.NET. Тем менее оно вызывает несколько проблем, которые, судя по задаваемым вопросам, касаются в первую очередь безо пасности и производительности. Разберемся для начала с безопасностью. Состояние в Многие разработчики сомневаются, стоит ли использовать состояние ото бражения, поскольку оно хранится в скрытом поле и находится на клиен те, где оно уязвимо перед злоумышленниками. Как показано на рис. 1, информацию из него можно прочитать, открыв исходный текст страницы. в ее HTML-код. Следующее выражение выводит изображение из файла Ваш путь к вершинам мастерства в ASP.NET Все прекрасно, пока Logo.jpg содержит статичное изображение, которое можно сгенерировать, не обращая внимания на пользовательский ввод. А если вы захотите создать Web-страницу, которая показывает изобра жения, формируемые в период выполнения на основе пользовательского ввода страницу, где строится диаграмма по значениям, предо ставленным пользователем или полученным из базы данных)? Самый простой ответ: создавайте на сервере изображение и возвращайте тэг
, ссылающийся на него. Но это легче сказать, чем сделать, если толь ко вы Ч не ASP.NET-программист.
см. след. стр. fiuRAt="server" Chart Chart" /> raRat="server"> sender, { Рис. 7. PieChart.ashx System; Книги, научные публикации