Iis о шифровании


Содержание

Использование SSL при работе с web-сервисами

Одним из элементов безопасности современного предприятия является использование защищенных каналов связи. Защищенные каналы связи позволяют предотвратить несанкционированный просмотр и изменение данных. Одним из наиболее популярных протоколов, реализующих защищенный канал, является протокол SSL . Данная статья описывает, как можно использовать протокол SSL при работе с web -сервисами «1С:Предприятия».

SSL ( Secure Socket Layer ) — протокол, использующийся для обеспечения защищенного взаимодействия между клиентом и сервером. SSL базируется:

· на в заимной аутентификации клиента и сервера для того, чтобы и клиент, и сервер были уверены в том, что они те, за кого себя выдают;

· цифровых подписях, для обеспечения целостности данных (защиты данных от несанкционированного изменения);

· шифровании, для обеспечения конфиденциальности данных (защиты данных от несанкционированного просмотра).

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

SSL — протокол использует SSL — сессию для установки защищенного соединения между клиентом и сервером. Сессия устанавливается путем обмена между клиентом и сервером последовательностью сообщений. При установке сессии могут выполняться такие действия, как:

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

· установка сессионного ключа;

· аутентификация сервера на клиенте;

· аутентификация клиента на сервере.

SSL — сессия может быть переиспользована между клиентом и сервером.

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

Одним из наиболее общеупотребимых применений протокола SSL является его использование для передачи HTTP -запросов ( HTTPS — протокол). В этом случае URL — схема адресации для таких ресурсов — https , а порт по умолчанию – 443.

Механизм web -сервисов «1С:Предприятия» позволяет как использовать, так и реализовывать https web -сервисы.

Клиентская часть механизма web -сервисов автоматически по URL -схеме ( https ) расположения web -сервиса определяет, что взаимодействие с таким web -сервисом должно вестись по защищенному каналу связи. Клиентская часть также требует, чтобы с сервером был связан валидный сертификат, выданный известным клиенту Центром Сертификации.

Сертификат сервера является валидным, если его цифровая подпись соответствует содержимому сертификата, его дата действия не просрочена и веб-сайт, на который выдан данный сертификат, соответствует веб-сайту сервера. Если сертификат не является валидным, например, веб-сайт сертификата не соответствует веб-сайту сервера, то клиент не сможет взаимодействовать по протоколу SSL с web -сервисами этого сайта.

Чтобы сертификат сервера был принят клиентом, нужно поместить его или сертификат Центра Сертификации, выдавшего данный сертификат сервера, в файл cacert . pem , который находится в каталоге bin «1С:Предприятия». В этом файле перечислены все сертификаты, которым доверяет данный клиент. Файл имеет формат PEM ( Privacy Enhanced Mail ) — текстовый формат, в котором сертификаты закодированы в base 64 последовательности.

https web -сервисы разрабатываются так же, как и обычные http web -сервисы, но требуют дополнительной настройки веб-сервера. Для IIS веб-сервера настройка заключается в привязке к веб-сайту серверного сертификата и настройке виртуальной директории web -сервиса. Серверный сертификат может быть получен от Центра Сертификации, в качестве которого может выступать любой Windows Server 2003 с установленным сервисом сертификатов. После того как сертификат связан с веб-сайтом, для виртуальной директории web -сервиса нужно указать, что доступ к ней осуществляется по защищенному каналу связи (см. документацию по IIS ).

Для Apache web -сервера также нужно указать серверный сертификат и признак работы по защищенному каналу. Сертификат может быть получен при помощи утилиты openssl (см. документацию по mod _ ssl ).

Улучшение безопасности IIS

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

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

На рынке существуют различные продукты, которые, как утверждается, могут сделать ваш сервер более защищенным, но не ограждают от всех возможных видов атак. Существует весьма распространенное заблуждение о том, что безопасность веб-сайта можно улучшить посредством ревизии исходного кода. Это не всегда соответствует действительности. Помимо написания безопасного кода, сайт, созданный средствами ASP.NET, следует также надежно защитить со стороны IIS-сервера. В этой статье будут различные аспекты безопасности IIS, чтобы оградить ваш сайт от незаконного проникновения.

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

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

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

По сути, IIS представляет собой набор различных WWW-служб, обрабатывающих запросы, которые поступают на различные TCP/IP порты (например, за 80-м портом обычно закреплен протокол HTTP). Перед тем как до ASP.NET дойдут запросы, происходит верификация (аутентификация, авторизация и т. д.) в соответствии с настройками IIS. В IIS есть различные возможности (см. рисунок ниже) для ограничения доступа и запрета некоторых типов запросов.

Рисунок 1: Средства безопасности в IIS

Регулирование прав доступа

IIS позволяет выборочно запрещать или разрешать доступ к файлам, папкам, сайту или серверу. Системный администратор может определять, какой удаленный компьютер может подключаться к IIS, а какой нет. В отношении каждого IP-адреса или DNS-имени можно настроить отдельные ограничительные правила. Допустим, если в коде на ASP.NET есть уязвимость, то, по сути, злоумышленник имеет неограниченный доступ к веб-сайту. Однако если выставить запрет на доступ со стороны IIS, появится следующее сообщение ‘Forbidden: IP address of the client has been rejected (403.6)’ или ‘DNS name of the client is rejected (403.8)’. Соответствующий HTTP-статус будет отражен в журнале. В связи с ограничением прав существуют два термина, касающиеся настройки IIS: IP Restriction и Domain Restriction.

Запрет на соединение предпочтительнее конфигурировать на как можно более низком уровне в модели OSI.

Чтобы сконфигурировать политику относительно DNS для разрешения доступ всем, кроме специально указанных адресов, кликните на ‘Edit Feature Settings’. Появится окно ‘IP Address and Domain Restrictions’.

Рисунок 2: Запрет на доступ определенным клиентам

Затем вы можете создать правила для определенных хостов или подсетей. Чтобы создать правило, разрешающее доступ для конкретного клиента или подсети, кликните на “Allow Entry” и укажите отдельный IP-адрес или диапазон IP-адресов.

Рисунок 3: Разрешение на доступ определенным хостам

MIME предотвращает хранение на сервере неизвестных типов файлов и позволяет загружать только те файлы, которые указаны явным образом. Хотя конфигурационные и информационные файлы обычно не хранятся в корневой директории, если злоумышленник попытается загрузить файл, не разрешенный в настройках, возникнет ошибка 404.3 и HTTP-статус запишется в лог. Если вы хотите разрешить загрузку определенных типов файлов, добавьте новый MIME type, как показано на рисунке ниже.

Рисунок 4: Добавление нового MIME type

IIS позволяет настраивать наборы правил для разрешения и запрета определенных типов запросов. Фильтрация позволяет пропускать запросы для определенного пространства имен и жестко интегрирована в систему журналирования событий. Запросы могут фильтроваться по параметрам HTTP-заголовка, расширениям файлов, размеру запроса и подстроке, входящей в URL.

При фильтрации по параметрам HTTP-заголовка в секции «verbs», например, можно разрешить только GET- или POST-запросы. Следующий набор XML-тегов как раз позволяет отфильтровать HTTP-заголовок по типу запроса (необходимо добавить этот код в конфигурационный файл):

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

Запрос также может быть отклонен при превышении определенного размера запроса.

И последний пример, в котором запросы фильтруются на основе подстрок (в данном случае – «. .»), входящих в URL.

Настройка пула приложений

Когда необходимо получить информацию из внешнего источника, может возникнуть конфликт, поскольку довольно сложно разделить между собой пулы веб-приложений. Иначе говоря, код, запущенный внутри одного пула, будет влиять на работоспособность другого пула. Чтобы в некоторой степени предотвратить этот конфликт, в IIS предусмотрена настройка пула приложений. Каждый пул приложений имеет свой конфигурационный файл, которых хранится в папке %systemdriver\inetpub\temp\appPools, и дополнительный идентификатор безопасности (SID), инжектируемый в соответствующий процесс w3wp.exe. Соответственно, каждый конфигурационный файл пула закреплен за своим SID’ом через права доступа.

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

Рисунок 5: Добавление пула приложений

Используя ISAPI, разработчики часто пишут дополнительные модули, чтобы расширить функционал сервера во время запроса определенного типа файла. Например, сайты на PHP могут работать на IIS-сервере при помощи расширения PHP ISAPI. Соответственно, сайты на ASP.NET (или файлы .aspx) по умолчанию привязаны к расширению ASP.NET ISAPI. Когда клиент запрашивает файл с расширением .aspx, дальнейшая обработка происходит через расширение IIS ISAPI, которое уже определяет, какие дополнительные действия должны быть предприняты.

В IIS можно запретить или разрешить те или иные расширения ISAPI. Если расширение запрещено, при запросе файла соответствующего типа в лог заносится статус 404.2, поскольку злоумышленник может удаленно внедрить и выполнить вредоносный код. После добавления новых расширений в дальнейшем необходимо провести аудит безопасности сервера. Чтобы добавить расширение, укажите имя фильтра и путь к библиотеке DLL.

Рисунок 6: Добавление нового расширения

Хакеры часто проводят DOS-атаки, отправляя на сервер огромные запросы, что в свою очередь может сказаться на размере логов. При помощи логов, например, можно выявить факты неправомерного доступа. В ОС Windows имеет встроенная функция записи в журнал важной информации: время авторизации, попытки подбора пароля и т. д., что является одним из признаков атаки. Для каждого сайта можно настроить систему фиксации событий в формате W3C.

Рисунок 7: Настройка логов

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

Настройка страниц ошибок

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

Рисунок 8: Неудачный пример страницы с ошибкой

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

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

Рисунок 9: Настройка страниц ошибок

Даже после грамотной настройки IIS не следует забывать о безопасности приложений. В последнее время много внимания уделяется уязвимостям в веб-приложениях: SQL-инъекциям, межсайтовому скриптингу, воспроизведению сессий (session replay), RFI и многим другим. С каждым днем злоумышленники становятся все более изощренными. Таким образом, свои позиции следует защищать со всех фронтов.

В статье мы рассмотрели способы защиты приложения посредством грамотной конфигурации IIS, включая ограничение доступа по IP-адресу, настройку MIME-Type, фильтрацию запросов, настройку пула приложений, ISAPI и страниц ошибок. Таким образом, на данный момент у вас должно появиться более полное понимание относительно безопасности в целом и в частности относительно настроек, повышающих безопасность IIS.

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Шифрование

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

О цифровых сертификатах

IIS использует цифровые сертификаты для реализации должного уровня защиты и поддерживает метод SSL -шифрования/аутентификации на веб-сайтах.

Используются три типа сертификатов.

  • Сертификаты сервера. Обеспечивают метод шифрования данных, передаваемых через сеть (посредством SSL), и методы идентификации для сервера. Эти методы дают клиенту уверенность в том, что сайт, который он посетил, является именно тем сайтом, за который он себя выдает.
  • Сертификаты клиента. Обеспечивают идентификацию клиента на сервере, что позволяет серверу определить, кем на самом деле является клиент. Это более мощная аутентификация по сравнению с базовой. Сертификаты клиентов не поддерживают шифрование данных.
  • Сертификаты подписывания кода. Обеспечивают метод цифрового «подписывания» приложения посредством цифрового идентификатора, созданного на основе содержимого приложения. Если в приложении происходят какие-либо изменения, то цифровой идентификатор становится не соответствующим этому приложению, о чем пользователь получает уведомление. Сертификаты подписывания кода не поддерживают шифрование приложения.

Ключи сертификатов

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

Примечание. Ключ – это фрагмент данных, используемый шифром для преобразования открытого текста в шифрованный текст. Шифром является математический алгоритм, выполняющий шифрование или дешифрование данных.

Существует два типа шифрования с использованием ключей. Они используются примерно в одинаковой степени.

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

  • Шифрование на открытом ключе. Более сложный процесс с точки зрения использования ключей. IIS предоставляет на выбор два алгоритма шифрования на открытом ключе – DH (Diffie-Hellman) и RSA (сокр. от имен разработчиков Ron Rivest, Adi Shamir и Leonard Adleman). RSA используется чаще всего, поэтому в данной лекции мы рассмотрим именно этот алгоритм. При шифровании на открытом ключе создается пара ключей – открытый ключ и секретный ключ.

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

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

По сравнению с шифрованием на симметричном ключе шифрование на открытом ключе требует выполнения большего объема работы и является не столь эффективным. При шифровании больших объемов данных использование этого метода отрицательно сказывается на производительности. Тем не менее, можно использовать шифрование на открытом ключе для зашифровки симметричного ключа, после чего применить более эффективное симметричное шифрование для зашифровки остальных данных. Именно этот процесс лежит в основе функционирования SSL.

Мощность шифрования

Мощность шифрования зависит от длины ключа и типа шифра, используемого для шифрования. Сообщения, созданные при помощи 128-битного ключа, взломать в 3х10 26 раз сложнее, чем сообщения, созданные при помощи 40-битного ключа. Это в некоторой степени объясняет то, почему правительство США раньше не разрешало экспортировать технологию, поддерживающую ключи длиной более 40 бит. В целях безопасности, правительство США отталкивалось от того факта, что оно сможет дешифровать перехваченные зашифрованные данные. Это гораздо сложнее сделать при использовании 128-битных ключей! Многое зависит и от того, какой именно шифр используется при шифровании данных. Например, данные, зашифрованные при помощи симметричного шифра (например, шифра DES – Data Encryption Standard ) с применением 64-битного ключа, сопоставимы по уровню защищенности с сообщением, зашифрованным при помощи RSA на ключе длиной в 512 бит.

Примечание. В настоящее время правительство США разрешает экспорт 128-битных шифров во все страны, на которые не наложено соответствующее эмбарго.

Цифровые подписи

Теперь подумаем, как можно подтвердить подлинность отправителя данных и как проверить, что эти данные не были искажены в процессе передачи? Ответом на оба вопроса является использование цифровых подписей. Цифровые подписи состоят из двух компонентов: односторонний хэш и криптосистема с открытым ключом.

Односторонний хэш. Односторонний хэш (иногда называется анализом сообщения) представляет собой набор данных для проверки полученного документа на предмет того, что он не был изменен с момента создания хэша. Алгоритм одностороннего хэша создает для документа набор уникальных данных. Документ отправляется вместе с созданным односторонним хэшем. При получении документ повторно обрабатывается алгоритмом хеширования . Новый хэш сопоставляется с хэшем, полученным вместе с документом. Если выявляются различия, то это означает, что документ был искажен. Добавление в документ одного-единственного символа или пробела основательно изменит результирующий хэш. Не существует способа восстановления документа только из одного хэша, по этой причине хэш и называется односторонним. Наиболее распространенными алгоритмами одностороннего хэширования являются алгоритм обработки сообщений MD5, созданный профессором института MIT Роном Ривестом (соавтором алгоритма шифрования RSA), и алгоритм безопасного хэширования SHA , разработанный Национальным институтом стандартов и технологий США ( NIST ) и Управлением национальной безопасности США ( NSA ). Алгоритм MD5 генерирует 128-битное значение, а алгоритм SHA – 160-битное.

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

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

Бюро сертификатов и доверие. Как убедиться в том, что открытый ключ, используемый для шифрования отправляемых данных, заслуживает доверия? Когда пользователь создает пару ключей открытый/секретный для использования на веб-сайте, он, по существу, запрашивает сертификат SSL x.509 (x.509 является стандартом, определенный в RFC 2459) у бюро сертификатов (т.е. у сервера, выпускающего сертификаты). Бюро сертификатов может авторизовать (уполномочить) любое количество подчиненных бюро сертификатов, те, в свою очередь, – другие бюро сертификатов и т.д. Первое бюро сертификатов в этой цепочке называется корневым бюро сертификатов. Возможно наличие только одного корневого бюро сертификатов в цепочке. При выпуске сертификата SSL создающее его бюро сертификатов проверяет корректность информации, отправленной запрашивающей стороной. Подробности этой проверки индивидуальны для каждого бюро сертификатов.

Использование бюро сертификатов на компьютере клиента

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

Проверка списка бюро сертификатов браузера. Можно просмотреть список бюро сертификатов, являющихся доверенными для браузера. Рассмотрим на примере Internet Explorer 6. Выполните следующие действия.

  1. В Internet Explorer выберите Tools\Internet Options (Сервис\Свойства браузера).
  2. Откройте вкладку Content (Содержание).
  3. В области Certificates (Сертификаты) нажмите на кнопку Certificates (Сертификаты).
  4. В окне Certificates (Сертификаты) (см. рис. 10.1) откройте вкладку Trusted Root Certification Authorities (Доверенные корневые бюро сертификатов); здесь присутствует перечень доверенных корневых бюро сертификатов.

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

Для добавления доверенного корневого бюро сертификатов в Internet Explorer выполните следующие действия.

шифрования сервера ColdFusion 9 и IIS

У нас есть разработчик ColdFusion, который утверждает, что только путем добавления нескольких строк кода в файле Application.cfm заявления, что он хочет быть зашифрованы, что он может заставить веб-сервер IIS для шифрования всех сообщений, связанных с этого приложения. Так, например, давайте предположим, что ColdFusion приложений этого разработчика заключается в www.ThisIsIt.com/xyz/. Он включает в себя условный оператор в его Application.cfm файле (см ниже), чтобы заставить веб-браузер, чтобы предварить URL для его применения с HTTPS.

В то же время в Internet Information Services (IIS), каталог хуг не установлен требовать SSL. Если вы посещаете https://www.ThisIsIt.com/xyz/ , это будет на самом деле быть предисловием HTTPS, но как содержание его применения, а также связь между сервером и клиентским веб — браузере быть зашифрованы , если веб -узел IIS сервер не проинструктирован / сконфигурирована для шифрования каталога а, и почему веб — браузер указует на шифрованную связь? Является ли это просто уловка или законное средство для шифрования приложения ColdFusion?

В основе применения правил работы путем обнаружения, что SSL не используется и перенаправляет пользователя на защищенный домен HTTPS. Действительный сертификат SSL требуется, чтобы быть настроен иначе отображается сообщение о безопасности.

ЗАЩИТА IIS: мифы и факты

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

Илон Маск рекомендует:  Что такое код asp put

Удивительно, как много средств компании тратят на защиту своих серверов, забывая при этом, что кто-то может получить физический доступ к машине и загрузить ее с помощью 3,5-дюймовой дискеты. В данной статье предполагается, что читатели не нуждаются в напоминаниях о контроле над физическим доступом, необходимости вовремя устанавливать исправления, выбирать сложные пароли и изменять стандартные пароли на административных системах (например, системных мониторах). Тем не менее некоторые администраторы забывают об элементарных мерах предосторожности, и именно таким образом взломщики получают чаще всего несанкционированный доступ к серверам; более подробно об этом рассказано в опубликованной институтом SANS статье «The Twenty Most Critical Internet Security Vulnerabilities (Updated) — The Experts? Consensus» (http://www.sans.org/top20).

Вооружившись знанием основ безопасности IIS, можно переходить к другим темам, таким как управление процессом идентификации, фильтрация портов, блокирование Web Distributed Authoring and Versioning (WebDAV) и использование инструмента безопасности URLScan. Но сначала следует развеять несколько мифов о безопасности IIS и познакомиться с некоторыми из наиболее эффективных методов и инструментов Microsoft для защиты Web-серверов.

Мифы о безопасности IIS

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

Анонимному пользователю необходимо право локальной регистрации (log-on-locally). В некоторых источниках указывается, что учетной записи IUSR_, используемой IIS для анонимной аутентификации, требуется право локальной регистрации. Такие сведения содержатся в Help-файлах IIS и на Web-узле компании Microsoft, в том числе в статье «HOW TO: Set Basic NTFS Permissions for IIS 5.0» (http://support.microsoft.com/?kb >

Из соображений безопасности лучше запретить анонимному пользователю локальную регистрацию, так как в этом случае злоумышленник не может воспользоваться учетной записью anonymous user для локальной регистрации, которая предоставляет пользователю больше полномочий, чем сетевая регистрация. Например, взломщик, использующий учетную запись IUSR для регистрации через Windows 2000 Server Terminal Services, запускает интерактивный сеанс регистрации и поэтому получает доступ к другим сетевым ресурсам. Возможно, придется потратить некоторое время, чтобы понять различия между локальной и сетевой регистрацией, но это знание необходимо для оптимального решения проблем безопасности. Краткий обзор процедуры аутентификации приведен в статье по адресу www.microsoft.com/technet/prodtechnol/winxppro/ reskit/prdp_log_csky.asp.

Пользователям необходимы разрешения Change на журнальные файлы. В документе Secure Internet Information Services 5 Checklist (http://www.microsoft.com/technet/security/tools/ chklist/iis5chk.asp) содержится несколько ценных рекомендаций и одна крайне неудачная идея, а именно совет предоставить группе Everyone разрешения Read, Write и Change для генерируемых IIS файлов журнала регистрации (\%systemroot%system32logfiles). Дело в том, что предоставление таких разрешений группе Everyone не помешает злоумышленникам удалить эти файлы для того, чтобы замести следы, как предполагается в документе. Правильнее было бы предоставить разрешения Full Control на файлы журнала регистрации группам Administrators и System. Единственное исключение из этого правила относится к случаям, когда для записи файлов журнала регистрации IIS используется специализированное приложение для регистрации. В подобных случаях приходится предоставлять разрешение Change.

Active Server Pages (ASP) требует разрешения NTFS Execute. Во многих документах Microsoft приводятся рекомендуемые разрешения NTFS для контента IIS. В большинстве таких документов говорится, что для сценариев необходимо разрешение NTFS Execute. Данная рекомендация нарушает важный принцип безопасности, известный как принцип минимальных полномочий. Как правило, для любого сценария, связанного с механизмом выполнения сценариев, требуется только разрешение NTFS Read.

Администраторам IIS приходится отыскивать зерно истины среди утверждений, верных лишь наполовину. Задача осложняется тем, что иногда неверная информация исходит от самой Microsoft. Тем не менее знание мер, необходимых для защиты Web-серверов, наверняка поможет разобраться.

Идентификация процессов

Одно из главных правил безопасности сервера заключается в том, что все процессы имеют свой контекст безопасности. Это означает, что каждая программа на сервере выступает в роли сущности (entity). Сущностью может быть зарегистрированный пользователь или встроенная учетная запись (например, System), а каждый процесс имеет экземпляр (Identity). Администратор IIS, уделяющий внимание проблеме безопасности, обязан всегда знать имя экземпляра процесса, который исполняет Web-приложение. В таблице приведены подробные сведения о модели процессов IIS и связанных с ними именах экземпляров.

Взломщик может использовать несколько методов для доступа к экземпляру процесса. Проведя атаку с переполнением буфера против приложения или Web-сервера, он может овладеть контекстом безопасности экземпляра процесса. Другой метод состоит в использовании функции RevertToSelf, которая может быть вызвана исполняемым файлом. Если злоумышленник может запустить такой исполняемый файл, то приложение исполняется как экземпляр процесса. Следует обратить внимание, что в Internet Information Services (IIS) 5.0 и Internet Information Server (IIS) 4.0 процесс Inetinfo работает с учетной записью System (см. таблицу). Следовательно, в целях безопасности следует избегать запуска приложений «внутри процесса» (т. е. работающих от имени процесса Inetinfo). В IIS 6.0 Web-приложения не запускаются экземпляром System, за исключением тех случаев, когда администратор явно задает этот режим или сервер настроен на работу в режиме IIS 5.0. Администратор не может запретить программе использовать экземпляр процесса, но может проанализировать двоичный файл, чтобы обнаружить вызовы RevertToSelf. Для анализа можно задействовать утилиту DumpBin, которая поставляется вместе с большинством языков программирования. Требуется ввести следующую команду:

dumpbin /imports executable name| find «RevertToSelf»

Более подробно об анализе исполняемых файлов рассказано в документе Secure Internet Information Services 5 Checklist.

Фильтрация портов

Тема фильтрации портов выходит за рамки данной статьи, но нельзя не упомянуть о некоторых основных положениях. Например, единственный порт, необходимый для работы IIS, — порт 80; все остальные порты обеспечивают дополнительную функциональность. Как правило, требуется задействовать TCP-порт 443 для SSL (Secure Sockets Layer), TCP/UDP-порт 53 для SMTP и, вероятно, другие порты для прикладных функций. Следует разрешать соединения только для необходимых служб и никогда не открывать сетевые порты приложений Microsoft (TCP/UDP-порты 137, 138, 139 и 445) подозрительным сетям. Сетевые порты и работающие через них соответствующие службы предоставляют много возможностей для нападения. Я рекомендую начать настраивать IIS с порта 80 и не открывать никаких других портов без производственной необходимости. На многих сайтах для фильтрации портов применяются брандмауэры, но я предпочитаю размещать IIS-серверы в демилитаризованной зоне (DMZ), как будто взломщик проник сквозь брандмауэр. Защита с помощью хост-машин (host-based defense), как ее иногда называют, — важный уровень эшелонированной стратегии безопасности.

Чаще всего для фильтрации портов я пользуюсь бесплатной утилитой IP Security (IPSec), которая успешно работает и запускается из командной строки. Основное назначение IPSec не фильтрация портов, а создание двухточечных взаимно аутентифицированных и зашифрованных соединений. Предположим, что установлено соединение IPSec между IIS и брандмауэром Internet Security and Acceleration (ISA) Server 2000 и другое соединение, между брандмауэром и системой Microsoft SQL Server. Эти соединения можно настроить на взаимную аутентификацию с применением сертификатов и шифрованием всего трафика. Если взломщик получает доступ к компьютеру в DMZ, то он не сможет обратиться к машине SQL Server. Для этого требуется, чтобы сертификат, хранящийся на сервере IIS, передавался компьютеру SQL Server от компьютера с IP-адресом сервера IIS. Кроме того, злоумышленнику не удастся перехватить зашифрованный трафик. IPSec обеспечивает надежную защиту, и я рекомендую именно эту утилиту.

С помощью IPSec можно реализовать и фильтрацию портов с учетом состояния (state-aware). Например, если адрес IIS-сервера — 1.1.1.1 и данный сервер соединен с машиной SQL Server с адресом 1.1.1.2, то машину 1.1.1.1 можно настроить на связь только с 1.1.1.2 и с использованием только порта 1433. Более подробная информация содержится в статье Microsoft «INF: TCP Ports Needed for Communication to SQL Server Through a Firewall» (http://support.microsoft.com/?kb >

Пользовательский интерфейс IPSec требует изучения, его подробное описание дано в статье Microsoft «Building and Configuring More Secure Web Sites» (http://msdn.microsoft.com/library/en-us/dnnetsec/html/openhack.asp). Чтобы составить правила IPSec для Windows 2000, можно воспользоваться утилитой командной строки Ipsecpol, которая доступна на сайте Microsoft по адресу http://www.microsoft.com/windows2000/techinfo/ reskit/tools/existing/ipsecpol-o.asp. Например, чтобы создать правило, разрешающее только входящий трафик через порт 80, следует ввести команду

Перед тем как использовать фильтрацию портов IPSec, нужно прочитать статью Microsoft «IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios» (http://support.microsoft.com/?kb >

Блокирование WebDAV

Немногие темы столь запутанны, как использование WebDAV совместно с IIS. WebDAV — стандарт, сформулированный в документе Request for Comments (RFC) рабочей группы Internet Engineering Task Force (IETF) (http://www.ietf.org/rfc/rfc2518.txt). Он позволяет создать на клиентской стороне Web-папку, URL которой указывает на IIS-сервер. Затем в папку можно перенести мышью контент для публикации на Web-сервере. Эта функция реализована как в IIS 6.0, так и в IIS 5.0. WebDAV стал широко применяться на серверах Microsoft с появлением Windows 2000. Тем не менее многие администраторы не представляют потенциальных возможностей и риска WebDAV. Конечно, такая мощная функция, как WebDAV, открывает широкое поле деятельности для злоумышленника. Поэтому неудивительно, что выпущено множество исправлений системы безопасности для httpext.dll, расширения http, в котором реализованы функции WebDAV.

На мой взгляд, главный недостаток реализации WebDAV в Windows 2000 заключается в том, что по умолчанию он разворачивается вместе с IIS и его нельзя отключить из пользовательского интерфейса IIS. Администраторам Windows 2000 приходится с этим мириться, но администраторам Windows Server 2003, установившим IIS 6.0, будет приятно узнать, что WebDAV блокирован по умолчанию и его можно активизировать или отключить из контейнера Web Service Extensions на консоли IIS.

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

Отказ в разрешении Execute для файла httpext.dll членам группы Everyone. Чтобы помешать первым злоупотреблениям WebDAV, специалисты Microsoft предложили лишить группу Everyone разрешения Execute на файл httpext.dll. Такой подход к блокировке WebDAV используется в инструменте IIS Lockdown. Однако у этого подхода есть два недостатка.

Во-первых, необходимо запретить Execute на всех серверах и внести это изменение при создании нового сервера. Во-вторых, удаление разрешения Execute не полностью блокирует WebDAV, что отмечается в статье Microsoft «Locking Down WebDAV Through ACL Still Allows PUT and DELETE Requests» (http://support.microsoft.com/?kb >

Добавление параметра реестра DisableWebDAV. На системах Windows 2000 SP2 и более поздних можно перейти в раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesW3SVCParameters, добавить параметр DisableWebDAV и присвоить ему значение 1, чтобы отключить WebDAV. Это эффективное решение, но его необходимо реализовать на всех машинах.

Использование URLScan для блокирования команд WebDAV. Самый надежный метод защиты IIS — установить на IIS-серверах утилиту безопасности URLScan. Данный инструмент выполняет и множество других функций, помимо блокирования WebDAV, поэтому заслуживает более подробного рассмотрения.

Реализация URLScan

URLScan — фильтр Internet Server API (ISAPI), работающий на платформах IIS 6.0, IIS 5.0 и IIS 4.0. В ходе установки инструмента IIS Lockdown на IIS 5.0 или IIS 4.0 при желании можно развернуть URLScan 2.0. Однако я рекомендую использовать версию 2.5 с расширенной функциональностью. С Web-узла Microsoft можно загрузить различные версии URLScan. Ко времени публикации данной статьи должна быть выпущена программа установки URLScan для IIS 6.0. Для использования URLScan с IIS 6.0 не существует столь веских оснований, так как IIS 6.0 уже располагает основными функциями защиты, обеспечиваемыми утилитой.

URLScan сравнивает входящий URL с правилами, задаваемыми администратором в файле urlscan.ini (который находится вместе с urlscan.dll в каталоге \%systemroot%system32inetsrvurlscan) и, соответственно, пропускает или блокирует запросы. Например, URLScan можно настроить на обслуживание только запросов к файлам с определенными расширениями. Такое простое правило защитит систему от многих известных атак, направленных против IIS.

URLScan можно настроить на блокирование всех запросов, содержащих определенные заголовки HTTP, такие как заголовки WebDAV в приведенном ниже фрагменте файла urlscan.ini (хочу выразить благодарность Марку Барнетту, дополнившему этот листинг):

Кроме того, с помощью URLScan можно блокировать URL, которые:

  • содержат символы не из заданного диапазона;
  • содержат указанные символы или последовательности символов;
  • превышают определенную длину;
  • содержат клиентские заголовки, превышающие определенную длину;
  • содержат определенные команды HTTP.

С помощью URLScan можно записать все отвергнутые запросы в файле регистрации, а затем проанализировать журнал с использованием утилиты Log Parser Tool 2.0, которую можно получить по адресу http://www.microsoft.com/downloads, или инструмента Log Parser Tool 2.1 из комплекта ресурсов Microsoft Windows Server 2003 Resource Kit. Также можно переслать все блокированные запросы на специальную .asp-страницу для обработки; принимать запросы, но заносить определенные события в журнал как блокированные запросы; удалять или изменять серверные баннеры, которые IIS посылает клиенту.

URLScan может блокировать URL, длина которых превышает определенную величину, но большинство URL для IIS недостаточно длинны, чтобы вызвать переполнение буфера. Проанализировав длину URL, необходимую для конкретных Web-узлов, и установив правило URLScan, блокирующее все запросы, не отвечающие требованиям, можно существенно повысить безопасность сервера. С помощью одного этого правила можно снизить угрозу для серверов, так как взломщик должен послать URL, соответствующий некоторым требованиям (например, с конкретным расширением; содержащий лишь определенные команды HTTP; не содержащий таких компонентов, как символы не из заданного диапазона, дополнительных символов или косых черт; длиной менее 400 символов).

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

Защита, защита и еще раз защита

Защищая Web-серверы от потенциальных взломщиков, важно понимать процесс идентификации и знать, какие приложения каких разрешений NTFS требуют. Важность фильтрации портов также трудно переоценить, но если брандмауэр взломан, настроен некорректно, или поражен другой сервер в демилитаризованной зоне, то можно использовать IPSec для защиты с помощью хост-машин. Кроме того, важно контролировать доступ по WebDAV к серверам, а с помощью URLScan можно настроить правила блокировки IIS. Наиболее эффективные из этих методов — использование URLScan и ограничение длины URL. В результате применения перечисленных инструментов взломщики переносят свои усилия с Web-серверов на приложения, исполняемые Web-серверами, но это уже тема для другой статьи.

Бретт Хилл — организатор узла http://www.iistraining.com, консультант по Microsoft IIS, IIS MVP; автор и преподаватель курсов IIS. С ним можно связаться по адресу: brett@iisanswers.com

Поделитесь материалом с коллегами и друзьями

Модель безопасности ASP.NET

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

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

С появлением ASP.NET 2.0 инфраструктура безопасности была существенно расширена за счет высокоуровневой модели управления пользователями и ролями, воплощенной как программно, так и посредством встроенных административных инструментов. Эта функциональность (доступная через программные интерфейсы Membership и Roles) строится на базе существующей инфраструктуры безопасности, которая появилась еще в ASP.NET 1.x. Но лучше всего то, что эта инфраструктура безопасности является полностью расширяемой через проектный паттерн “поставщика”, как вы увидите в главе 26. Пользовательские поставщики Membership.

В данной статье представлен общий путеводитель по средствам безопасности ASP.NET. В последующих главах 20-26 книги «Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов» вы сможете углубите свои познания по каждой теме из представленных здесь. А пока мы проведем краткое представление ключевых средств обеспечения безопасности .NET. Вы увидите, как структурированы поставщики аутентификации .NET и модули авторизации и узнаете о том, как пользовательский контекст безопасности представлен идентичностью и ведущими (principal) объектами. Более важно то, что вы получите общее представление о том, как можно встроить средства безопасности в вашу программную архитектуру и дизайн и увидите, какие факторы наиболее важны при создании безопасного программного обеспечения.


Что означает создание безопасного программного обеспечения

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

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

Понятие потенциальной угрозы

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

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

Однако моделирование угроз важно по еще одной причине. Как вы, возможно, знаете, не все потенциальные угрозы могут быть смягчены применением технологий защиты, — такими как аутентификация и авторизация. Другими словами, некоторые из них вообще невозможно разрешить технически. Например, банковское онлайновое решение может использовать SSL для защиты трафика Web-сайта. Но как пользователи могут знать, что они действительно используют банковскую страницу, а не хакерский поддельный Web-сайт? Хорошо, единственный способ убедиться в этом – проверить сертификат, используемый для установки канала SSL. Но пользователи должны быть предупреждены об этом, а потому вы должны каким-то образом их информировать. Поэтому “техника смягчения” угроз – это не только технологии защиты. Это включает требование того, чтобы все ваши пользователи знали, как проверить сертификат. (Конечно, вы не можете заставить их это делать, но ели ваша система спроектирована соответствующим образом, все же можно большинство из них стимулировать к этому). Моделирование угроз – метод анализа, помогающий выявить обстоятельства вроде этих, а не только факторы технического порядка.

Моделирование угроз – обширная тема, которая выходит далеко за пределы нашей книги. Если интересуетесь, — обратитесь к источникам: Майкл Говард (Michael Howard) и Дэвид Лебланк (David LeBlanc) «Разработка безопасного кода», второе издание (Microsoft Press, 2002) или Фрэнк Свидерски (Frank Swiderski) и Виндоу Снайдер (Window Snyder) «Моделирование угроз» (Microsoft Press, 2004).

Правила безопасного кодирования

Конечно, только безопасная архитектура и дизайн не могут сделать ваше приложение абсолютно защищенным. Это только один из наиболее важных факторов. После того, как вы разработали безопасную архитектуру и дизайн, вы должны также написать безопасный код. Опять же, «Разработка безопасного кода», второе издание (Microsoft Press, 2002) – великолепный источник подробной информации для каждого разработчика. При написании кода web-приложений вы всегда должны иметь в виду следующие правила:

  • Никогда не доверяйте пользовательскому вводу: Предполагайте, что каждый пользователь – дьявол, пока он не докажет обратного. Таким образом, всегда строго проверяйте пользовательский ввод. Разрабатывайте свой код валидации так, чтобы он проверял ввод только правильных значений, а не неправильных (Неправильных значений всегда больше, чем вы можете себе представить во время разработки приложения).
  • Никогда не используйте конкатенации строк для формирования предложений SQL: Всегда используйте параметризованные предложения, чтобы ваше приложение не было уязвимо для атак вмешательством в SQL, как описано в главе 7. Основы ADO.NET.
  • Никогда не выводите данные, введенные пользователем, на Web-страницу перед их проверкой и кодированием: Пользователь может ввести некоторые фрагменты кода HTML (например, скрипты), которые инициируют меж-сайтовую скриптовую уязвимость. Поэтому всегда используйте HttpUtility.HtmlEncode() для защиты специальных символов, — таких, как , перед выводом их на страницу, или используйте web-элемент управления, который выполняет такое кодирование автоматически.
  • Никогда не размещайте важные данные, критичную для бизнеса информацию, или данные, касающиеся внутренних правил безопасности в скрытых полях вашей Web-страницы: Скрытые поля могут быть легко изменены простым просмотром исходного кода Web-страницы, модификацией и сохранением в файле. Затем злоумышленник просто может отправить локальную модифицированную копию Web-страницы на сервер. Плагины броузеров могут сделать такой подход настолько же простым, как написание e-mail в Microsoft Outlook.
  • Никогда не сохраняйте важные или критичные для бизнеса данные в виде состояния: Вид состояния (state view) – это просто еще одно скрытое поле на Web-странице, и оно может быть легко декодировано и просмотрено. Если вы используете установку EnableViewStateMAC=true для своей страницы, то вид состояния будет подписан кодом аутентификации сообщений, созданном на базе ключа машины, находящегося в серверном machine.config. Мы рекомендуем использовать EnableViewStateMAC=true немедленно после включения данных в ваш вид состояния, который не должен быть изменен пользователями, просматривающими вашу Web-страницу. Подробнее о защите вида состояния читайте в главе 6. Управление состоянием.
  • Включайте SSL при использовании Basic-аутентификации или аутентификации форм ASP.NET: Аутентификация форм описана в главе 20. Аутентификация с помощью форм. Об SSL мы поговорим позднее в данной статтье, в разделе “Понимание SSL”.
  • Защищайте свои cookie: Всегда защищайте свои аутентификационные cookie при использовании аутентификации форм и устанавливайте таймауты насколько возможно, короткими и не длиннее, чем это действительно необходимо.
  • Применяйте SSL: Вообще, если ваше Web-приложение обрабатывает важные данные, защищайте весь Web-сайт с помощью SSL. Не забывайте защищать даже директории с графическими образами или другими файлами, которые не управляются приложением напрямую через SSL.

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

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

Понятие сторожа

Хороший способ повысить степень защиты вашего приложения – размещать компоненты в таком месте, которое требует защиты. Концептуальный паттерн сторожей (Gatekeepers) применяет модель конвейера к организации инфраструктуры безопасности. Эта модель помогает укрепить безопасность.

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

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

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

Gatekeeper 1-4 — Сторож 1-4

Protected Resource Защищенный ресурс

Рис.1. Конвейер сторожей.

Понятие уровней безопасности

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

  • Аутентификация: Прежде всего вы должны аутентифицировать пользователей. Аутентификация задает вопрос: кто идет? В конечном итоге она определяет, кто работает с вашим приложением на другом конце.
  • Авторизация: Во-вторых, как только вы узнали, кто работает с вашим приложением, ваше приложение должно решить, какие операции данный пользователь может выполнять и к каким ресурсам обращаться. Другими словами, авторизация отвечает на вопрос: каков ваш уровень допуска?
  • Конфиденциальность: Когда пользователь работает с приложением, вы должны гарантировать, что никто другой не сможет видеть важные данные, которые он обрабатывает. Таким образом, вы должны шифровать канал между броузером клиента и Web-сервером. Более того, возможно, вам придется шифровать данные, сохраняемые на заднем плане (или в форме cookie на клиенте), чтобы даже администратор базы данных или другой персонал вашей компании не мог видеть эти данные.
  • Целостность: И наконец, вы должны гарантировать, что данные, передаваемые между клиентом и сервером, не изменяются в результате неавторизованного вмешательства. Цифровые подписи позволяют снизить уровень этой угрозы.

ASP.NET включает базовую инфраструктуру для выполнения аутентификации и авторизации. Библиотека базовых классов .NET Framework включает некоторые классы в пространстве имен System.Security, предназначенные для шифрования и подписи данных. Более того, SSL – стандартизованный способ обеспечения конфиденциальности и целостности данных, передаваемых между клиентским броузером и Web-сервером. Теперь мы рассмотрим подробнее каждую из этих концепций.

Аутентификация

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

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

  • Аутентификация Windows
  • Аутентификация форм
  • Паспортная аутентификация
  • Пользовательский процесс аутентификации

В каждом случае пользователь предъявляет некоторое удостоверение при регистрации в системе. Идентичность пользователя отслеживается разными способами, в зависимости от типа аутентификации. Например, операционная система Windows использует 96-битное число, называемое SID (security identifier – идентификатор безопасности) для идентификации каждого входящего пользователя. В аутентификации форм ASP.NET (подробно описанной в главе 20. Аутентификация с помощью форм ), пользователю выдается аутентифицирующий билет формы, который представляет собой комбинацию значений, которые шифруются и помещаются в cookie.

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

Имперсонификация

Имперсонификация – процесс исполнения кода в контексте (или от имени) другого пользователя. По умолчанию код ASP.NET исполняется от имени фиксированного, специфичного для конкретной машины, пользовательского бюджета (обычно ASP.NET на IIS 5.x, или Network Service на IIS 6.0). Чтобы исполнить код, используя другую идентичность, можно воспользоваться встроенными в ASP.NET возможностями имперсонификации. Можно использовать предопределенный пользовательский бюджет, либо предположить пользовательскую идентичность, если пользователь уже был аутентифицирован с применением бюджета Windows.

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

  • Чтобы выдать каждому Web-приложению разные права: В IIS 5 для исполнения всех Web-приложений на компьютере используется бюджет по умолчанию, указанный в файле machine.config. Если вы захотите предоставить разным Web-приложениям разные права, то можете применить имперсонификацию для назначения разных бюджетов Windows каждому приложению. Это особенно важно для сценариев хостинга, когда нужно соответствующим образом изолировать Web-приложения разных заказчиков (так, чтобы, например, web-приложение заказчика A не могло получить доступ к директориям или базам данных web-приложения заказчика B).
  • Чтобы использовать существующие права доступа пользователя Windows: Например, представим приложение, которое извлекает информацию из различных файлов, для которых уже установлены специфичные для пользователей и групп наборы прав доступа. Вместо того, чтобы кодировать логику авторизации в вашем приложении ASP.NET, можно использовать имперсонификацию для установки идентичности текущего пользователя. Таким образом, Windows выполнит авторизацию для вас, проверив права доступа, как только вы попытаетесь обратиться к файлу.

Эти два сценария принципиально различны. В первом из них имперсонификация определяет один, специфический бюджет. В этом случае не важно, какой пользователь обращается к приложению, и не важно, какого рода защита уровня пользователя применяется, — код будет запущен от имени того бюджета, который вы установили. Во втором сценарии пользователи должны быть аутентифицированы IIS. Код Web-страницы будет исполнен с идентичностью соответствующего пользователя. Подробнее об этих опциях вы прочтете в главе 20. Аутентификация с помощью форм .

Авторизация

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

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

В Web-приложениях разные типы авторизации происходят на разных уровнях. Например, на самом верхнем уровне ваш код может проверять идентичность пользователя и решать, — можно ли продолжать данную операцию. На нижнем уровне можно настроить ASP.NET так, чтобы запрещать доступ к определенным Web-страницам или директориям для определенных пользователей или ролей. На еще более низком уровне, когда ваш код выполняет различные задачи, — такие, как подключение к базе данных, открытие файла запись в протокол событий, и т.п., — операционная система Windows проверяет права бюджета Windows, исполняющего данный код. В большинстве ситуаций вы не захотите полагаться на этот самый нижний уровень, поскольку ваш код всегда будет исполняться от фиксированного бюджета. В IIS 5.x этот бюджет называется ASPNET. В IIS 6.0 – это фиксированный бюджет Network Service (в обоих случаях вы можете переопределить бюджет по умолчанию, как описано в главе 18. Развертывание Web-сайтов ).

Есть несколько причин для использования фиксированного бюджет для запуска кода ASP.NET. Почти во всех приложениях права, выданные пользователю, не соответствуют правам, которые требуются приложению, работающему от имени пользователя. Как правило, ваш код нуждается в более широком наборе привилегий, чтобы выполнять задачу идентификации, и вы не захотите выдавать такие права каждому пользователю, который может обращаться к вашему приложению. Например, вашему коду может понадобиться создавать протокольные записи о возможных сбоях, даже если данному пользователю не разрешено напрямую писать в протокол событий Windows, в файл или в базу данных. Аналогично приложения ASP.NET всегда должны иметь право доступа в директорий c:\[WinDir]\Microsoft.NET\[Version]\Temporary ASP.NET Files, чтобы создавать и кэшировать версии ваших Web-страниц на машинном языке. И наконец, вы можете пожелать использовать систему аутентификации, которая вообще никак не взаимодействует с Windows. Например, приложения электронной коммерции могут проверять адреса e-mail пользователей по базе данных серверной стороны. В этом случае идентичность пользователя никак не соответствует пользовательскому бюджету Windows.

В некоторых редких случаях вы можете предоставить вашему коду временно предполагать идентичность пользователя. Такой подход чаще всего используется при создании приложений ASP.NET для локальных сетей, в которых пользователи уже имеют четко определенные наборы привилегий Windows. В этом случае вам придется пополнить свой арсенал средств защиты имперсонификацией, как это описано в главе 22. Аутентификация Windows

Конфиденциальность и целостность

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

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

Как уже упоминалось ранее, вы можете пожелать шифровать Web-приложения по двум причинам:

  • Для защиты коммуникаций (передачи данных по проводам): Например, вы хотите сделать невозможной кражу номеров кредитных карт, используемых в вашей системе электронной коммерции по открытым каналам Internet. Стандартный подход к этой проблеме заключается в применении SSL. SSL также реализует цифровые подписи для обеспечения гарантий целостности. SSL не реализуется ASP.NET. Это средство, предоставляемое IIS. Код вашей Web-страницы (или Web-службы) не зависит от того, применяется SSL или нет.
  • Для защиты постоянной информации (в базе данных или в файле): Например, вы можете пожелать сохранить номер кредитной карточки пользователя в базе данных для будущего использования. Хотя вы можете сохранять эти данные в простом тексте и надеяться, что Web-сервер не будет взломан, но это плохая идея. Вместо этого вам следует использовать шифрующие классы, которые предлагает .NET, чтобы вручную шифровать данные перед их сохранением.

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

Свяжем все вместе

Итак, как же заставить работать вместе аутентификацию, авторизацию и имперсонификацию в Web-приложении? Когда пользователи впервые заходят на Web-сайт, они анонимны. Другими словами, ваше приложение не знает (и не заботится о том), кто они такие. Если только вы не аутентифицируете их, все так и останется.

По умолчанию анонимные пользователи могут обращаться к любой странице ASP.NET. Но когда пользователь запрашивает Web-страницу, анонимный доступ к которой закрыт, выполняется несколько шагов (показанных на рис. 2):

  1. Запрос присылается на Web-сервер. Поскольку идентичность пользователя в этот момент не известна, ему предлагается зарегистрироваться (log-in), используя специальную Web-страницу или диалоговое окно регистрации броузера. Специфические детали процесса регистрации зависят от типа используемой аутентификации.
  2. Пользователь представляет свое удостоверение, которое затем верифицируется, — либо вашим приложением (в случае аутентификации формы), или автоматически средствами IIS (в случае аутентификации Windows).
  3. Если удостоверение пользователя подтверждается, ему предоставляется доступ к web-странице. Если же оно оценивается, как не легитимное, ему предлагается повторить попытку регистрации, либо он выполняется переадресация на страницу с сообщением “доступ закрыт”.

Request for Restricted Resource Запрос ограниченного ресурса
User is authenticated Пользователь аутентифицирован
Yes Да
No Нет
Resource Ресурс
Login Регистрация

Рис. 2. Запрос Web-страницы, требующей аутентификации.

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

  1. Запрос присылается на Web-сервер. Поскольку идентичность пользователя в этот момент не известна, ему предлагается зарегистрироваться (log-in), используя специальную Web-страницу или диалоговое окно регистрации броузера. Специфические детали процесса регистрации зависят от типа используемой аутентификации.
  2. Пользователь предъявляет свое удостоверение, которое проверяется приложением. Это стадия аутентификации.
  3. Удостоверение или роли аутентифицированного пользователя сравниваются со списком разрешенных пользователей и ролей. Если пользователь есть в списке, ему открывается доступ к ресурсу; в противном случае доступ закрыт.
  4. Пользователи, которым отказано в доступе, либо приглашаются на повторную регистрацию, либо перенаправляются на Web-страницу с сообщением “доступ закрыт”

Рис. 3. Запрос Web-страницы, требующей аутентификации и авторизации.

Средства безопасности Internet Information Services

Прежде, чем исполняющей системы ASP.NET даже коснется входящий запрос, IIS проверяет безопасность в соответствии со своей собственной конфигурацией. Таким образом, перед тем, как изучать подробности средств безопасности ASP.NET, вы должны познакомиться с первым сторожем в конвейере безопасности вашего Web-приложения – IIS.

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

  • Аутентификация: IIS поддерживает следующие виду аутентификации: Basic, Digest, Passport и Windows, а также сертификатную аутентификацию по каналу SSL. Любая аутентификация IIS в конечном итоге сводится к аутентификации пользователя Windows. Таким образом, IIS поддерживает только аутентификацию пользователей Windows.
  • Авторизация: IIS поддерживает встроенную поддержку ограничений IP-адресов и оценку списков доступа Windows ACL.
  • Конфиденциальность: Шифрование может быть обеспечено средствами SSL.

В последующих разделах вы познакомитесь с деталями настройки безопасности IIS. Другие последующие главы 21-26, связанные с безопасностью, будут в основном посвящены деталям инфраструктуры безопасности ASP.NET. Вы всегда должны помнить о безопасности IIS, поскольку она оказывает влияние на поведение ASP.NET при разных настройках защиты, установленных в web.config.

Например, если ваше приложение ASP.NET желает использовать аутентификацию Windows, вы должны настроить IIS на использование либо Windows, либо Basic (Digest) аутентификации. Если ваше приложение ASP.NET не желает использовать бюджеты Windows (и потому, использовать собственную аутентификацию форм), вы должны настроить IIS так, чтобы он разрешал вход анонимным пользователям.

Аутентификация IIS

Как упоминалось ранее, IIS поддерживает несколько механизмов аутентификации. Любые другие конфигурационные настройки безопасности (и, следовательно, аутентификации) устанавливаются для всего Web-сайта. Вы можете найти эти настройки на закладке Directory Security свойств виртуальных директориев. Рис. 4 показывает опции аутентификации IIS.

Конечно, анонимный доступ открывает web-страницу для всех. Он переопределяет любые другие установки аутентификации IIS, потому что IIS выполняет аутентификацию только когда это необходимо (и, конечно, если включена анонимная аутентификация, никакие дополнительные шаги не требуются). Далее, если у вас на IIS настроена анонимная аутентификация, вы можете использовать средства безопасности ASP.NET, чтобы аутентифицировать пользователей, — с помощью интегрированных механизмов ASP.NET, — таких, как аутентификация форм или аутентификация настраиваемая (пользовательская).

Windows-аутентификация настраивает IIS для валидации удостоверений пользователей по зарегистрированным пользовательским бюджетам Windows, — либо на локальной машине, либо внутри домена. Работая в домене, пользователи не обязаны вводить свои имена и пароли, если они уже зарегистрированы на клиентской машине в сети, потому что “билет” клиентской аутентификации передается для аутентификации на сервер автоматически.

IIS также поддерживает Basic-аутентификацию. Это метод аутентификации, разработанный W3C, который определяет дополнительный заголовок HTTP для передачи имен и паролей пользователей по проводам. Информация передается в кодировке Base64. Таким образом, вы должны использовать только Basic-аутентификацию с SSL. Как и в случае Windows-аутентификации, удостоверения, введенные пользователями, оцениваются по бюджетам Windows. Однако способ их передачи по проводам отличается. В то время, как Basic-аутентификация передает информацию в заголовке HTTP, Windows-аутентификация использует для передачи информации либо NTLM, либо Kerberos.

Рис. 4. Опции аутентификации IIS.

Аутентификация Digest подобна аутентификации Basic. Вместо пересылки удостоверений по кабелю в кодировке Base64, на хэширует пользовательский пароль и передает по сети хэшированную версию. Хотя это выглядит более безопасным, Digest-аутентификация не слишком распространена. В результате, она редко используется вне контролируемых сред (таких, как intranet).


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

И, наконец, IIS поддерживает один дополнительный метод аутентификации, — сертификационную аутентификацию, которой нет на рис. 3, поскольку она конфигурируется через SSL.

Примечание. Для отладки приложений ASP.NET должна быть включена Windows-аутентификация, поскольку Windows определяет, разрешено ли вам заниматься отладкой, на основе выданных вам прав внутри Windows.

Авторизация IIS

Рис 5 показывает, как можно конфигурировать ограничения IP-адресов с IIS. Ограничения IP-адресов обеспечивают возможность ограничить доступ к Web-серверу только с машин, указанный в списке разрешенных. Это имеет смысл, если вы хотите только нескольким известным партнерам по бизнесу открыть доступ к своему Web-серверу.

Рис. 5. Ограничения IP-адресов на IIS.

IIS и Протокол Защищенных Сокетов (SSL

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

IIS представляет SSL, как встроенный, готовый к использованию сервис. Поскольку SSL работает под HTTP, его использование не изменяет способа работы с HTTP-запросами. Всю шифровку и дешифровку берут на себя средства SSL программного обеспечения Web-сервера (в данном случае – IIS). Единственное отличие в том, что адрес, защищенный SSL, начинается с https://, а не http://www.realcoding.net/redir.php?url=http://. Трафик SSL также проходит через другой порт (обычно Web-серверы используют порт 443 для SSL-запросов, и порт 80 – для обычных запросов).

Чтобы сервер поддерживал SSL-соединения, он должен иметь инсталлированный сертификат X.509 (имя X.509 было выбрано для соответствия стандарту директориев X.500). Чтобы реализовать SSL, вы должны приобрести сертификат, инсталлировать его, и соответствующим образом конфигурировать IIS. В следующих разделах мы подробно раскроем все эти шаги.

Понятие сертификатов

Организация приобретает сертификат у известного центра сертификации (Certificate Authority — CA) и инсталлирует его на свой Web-сервер. Клиент доверяет CA и потому готов доверять сертификатной информации, подписанной CA. CA также сохраняет информацию о каждом зарегистрированном пользователе. Однако наличие сертификата никоим образом не гарантирует надежность сервера, безопасность приложения, или легитимность бизнеса. В этом смысле область действия сертификатов фундаментально ограничена.

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

  • Имя, наименование организации и адрес держателя.
  • Открытый ключ держателя, который будет использоваться для реализации ключа SSL-сессий, для шифровки коммуникаций.
  • Даты проверки сертификата.
  • Серийный номер сертификата.

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

Два крупнейших центра сертификации следующие:

Если вам не нужно идентифицировать функцию валидации CA (например, если ваши сертификаты будут использоваться только в локальной сети intranet), вы можете создавать и использовать свои собственные сертификаты, и настроить все клиенты, чтобы они доверяли им. Для этого потребуется служба Active Directory b Certificate Server (которые встроены в Windows 2003 Server и Windows 2000 Server). За более подробной информацией обращайтесь к специальным книгам по администрированию сетей Windows.

Понятие SSL

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

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

Симметричное шифрование – это разновидность шифрования, с которым интуитивно знакомо большинство людей. В нем один и тот же секретный ключ используется для шифровки и расшифровки сообщения. Недостаток симметричного шифрования в том, что оба участника должны знать секретное значение для того, чтобы осуществлять обмен сообщениями. Однако вы не можете передавать эту информацию по Internet, поскольку злоумышленники могут перехватить ее и в результате получить возможность расшифровывать все последующие сообщения. Главный трюк SSL в том, что он комбинирует асимметричное и симметричное шифрование. Асимметричное шифрование используется только при начальной передаче ключа, — другими словами, соглашения о секретном значении. Затем это секретное значение используется для симметричной шифровки последующих сообщений, что гарантирует наилучшую возможную производительность.

Весь процесс работает так:

  1. Клиент посылает запрос на соединение с сервером.
  2. Сервер подписывает свой сертификат и отправляет его клиенту. Это завершает фазу “рукопожатия”.
  3. Клиент проверяет, издан ли сертификат CA, которому он доверяет. Если это так, он переходит к следующему шагу. В сценарии с Web-броузером клиент может предупредить пользователя угрожающим сообщением о том, что он распознал CA и разрешает пользователю решать – продолжать ли дальше.
  4. Клиент сравнивает информацию в сертификате с информацией, присланной сайтом (включая доменное имя и его открытый ключ). Клиент также проверяет правильность сертификата стороны сервера, — что он не был отменен и издан заслуживающим доверия CA. Затем клиент принимает соединение.
  5. Клиент сообщает серверу, какие ключи шифрования он поддерживает для коммуникации.
  6. Сервер выбирает наибольшую подходящую длину ключа и информирует клиента.
  7. Используя указанную длину ключа, клиент случайным образом генерирует симметричный ключ шифрования. Он будет использован в период транзакции между сервером и клиентом. Это гарантирует оптимальную производительность, поскольку симметричное шифрование намного быстрее асимметричного.
  8. Клиент шифрует ключ сессии, используя открытый ключ сервера (из сертификата), и затем посылает зашифрованный сессионный ключ серверу.
  9. Сервер принимает зашифрованный сессионный ключ и расшифровывает его, используя свой защищенный ключ. После этого и клиент, и сервер имеют общий секретный ключ, и могут использовать его для шифрования коммуникаций в период, пока длится сессия.

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

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

Инсталляция сертификатов в IIS

При развертывании приложения возможно, вы пожелаете приобрести сертификаты от авторитетного CA, — такого, как VeriSign. Это, в частности, касается web-сайтов и Internet-броузеров, которые распознают ограниченное число центров сертификации автоматически. Если, например, вы используете тестовый сертификат для шифрования коммуникаций с защищенной частью web-сайта, то клиентский броузер отобразит предупреждение о том, что сертификат поставлен неизвестным CA.

IIS Manager позволяет автоматически формировать запрос сертификата. Для этого, прежде всего, запустите IIS Manager. Откройте группу Web Sites, щелкните правой кнопкой мышки элемент, соответствующий вашему Web-сайту (часто озаглавленному Default Web Site), и выберите Properties. На закладке Directory Security вы найдете кнопку Server Certificate (см. Рис. 6).

Рис. 6. Настройка безопасности директориев.

Щелкните кнопку Server Certificate для запуска помощника IIS Certificate Wizard (см. Рис. 7). Этот помощник запросит некоторую базовую организационную информацию и сгенерирует файл запроса. Кроме того, вы должны будете указать длину ключа в битах. Чем длиннее ключ, тем он надежнее.

Рис. 7. Создание запроса сертификата сервера.

Сгенерированный файл может быть сохранен в виде текста, но в конечном итоге он должен быть отправлен по e-mail CA. Пример файла запроса (слегка сокращенный) выглядит так:

CA вернет сертификат, который вы сможете инсталлировать в соответствии с его инструкциями. По принятому соглашению следует запускать все коммуникации SSL через порт 443, а нормальный web-трафик – через порт 80.

Кодировка информации с SSL

После того, как сертификат инсталлирован, довольно легко использовать коммуникации SSL. Единственный необходимый для этого шаг – модифицировать ваш запрос так, чтобы использовался URL, начинающийся с https:// вместо http://www.realcoding.net/redir.php?url=http://. Обычно это означает поправку в предложении Response.Redirect() вашего кода. Поскольку вся шифровка и расшифровка происходит непосредственно перед отправкой сообщения (или немедленно после его получения), вашему приложению не приходится беспокоиться о ручной дешифровке данных, манипулировании байтовыми массивами, использовании правильной кодировки символов и т.п.

На стороне сервера вы также можете инициировать соединения SSL таким образом, чтобы было невозможно взаимодействовать с web-службой без шифрования коммуникаций. Просто щелкните правой кнопкой по Web-сайту а IIS Manager, и выберите закладку Directory Security. В разделе Secure Communication щелкните кнопку Edit (которая доступна только после инсталляции сертификата). Затем выберите Require Secure Channel (см. Рис. 8).

Рис. 8. Инициализация SSL-доступа.

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

Приведем пример, проверяющий, передается ли текущий запрос по безопасному соединению, используя свойство HttpRequest.IsSecureConnection:

Примечание Общей ошибкой является использование localhost или любого другого псевдонима для имени хоста сервера в SSL-соединении. Это не будет работать, поскольку клиент пытается проверить, что часть CN (common name – общее имя) субъекта имени серверного сертификата соответствует имени хоста, содержащегося в запросе HTTP во время фазы “рукопожатия” SSL-обмена.

С SSL будет зашифрован весь трафик, а не только важные данные. По этой причине многие Web-серверы используют аппаратные ускорители для повышения производительности шифрования SSL.

Примечание Помните, что SSL не встроен в ASP.NET. Если вы хотите узнать больше об SSL, обратитесь к книгам, посвященным вопросам безопасности и IIS, — таким, как IIS Security (Osbourne/McGraw-Hill, 2002).

Архитектура безопасности ASP.NET

ASP.NET реализует концепцию сторожей (представленную выше) через модули HTTP. Каждый модуль – это класс, реализующий интерфейс IHttpModule, и каждый модуль выполняет функцию сторожа в инфраструктуре ASP.NET. Конечно, модули HTTP используются и для других задач, но многие из них связаны с безопасностью. Как видно на рис. 9, ASP.NET включает несколько модулей аутентификации и авторизации.

Поскольку Web-приложения используют бесстатусный HTTP, никакая информация не сохраняется между пользовательскими запросами. В результате пользователь должен быть аутентифицирован и авторизован в начале каждого запроса. ASP.NET справляется с этим посредством инициации глобальных событий приложения. Модули аутентификации могут обрабатывать эти события для осуществления аутентификации пользователя. Но не все запросы требуют аутентификации или авторизации. Однако события все равно инициируются всегда. Эти события обрабатываются конфигурированными модулями HTTP, как показано на рис. 9. Конечно, вы также можете обрабатывать события через глобальный класс приложения (эти события определены в классах кода заднего плана в файле Global.asax), но для большей степени повторной применяемости мы рекомендуем создавать отдельные модули HTTP, потому что это очень легко.

Рис. 9. Классы IHttpModule, в качестве сторожей безопасности ASP.NET.

Два главных события, с которыми вам нужно иметь дело, это AuthenticateRequest и AuthorizeRequest. Это не все события, которые здесь инициируются, но наиболее полезные. На рис. 10 показан порядок возникновения событий, связанных с системой безопасности.

HttpContext become available Становится доступен HttpContext
Populates the managed security context Наполняется управляемый контекст безопасности
Raised after the security context has been established Происходит после установления контекста безопасности
Handles any custom authorization needs Обрабатывает любые пользовательские нужды авторизации
Occurs after the current user request has been authorized Происходит после авторизации текущего запроса
Session state becomes accessible Становится доступно состояние сессии

Рис. 10. События приложения, связанные с безопасностью.

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

Событие AuthenticateRequest возбуждается объектом HttpApplication, когда запрос нуждается в аутентификации. Как только пользователь аутентифицирован (обычно предъявив некоторое удостоверение, — такое, как cookie с информацией о себе), следующий шаг – убедиться, что информация, идентифицирующая пользователя, полностью готова для остальной части цикла обработки страницы. Чтобы достичь этого, нужно создать новый объект с пользовательской информацией и присоединить ее к свойству User текущего HttpContext.

Событие AuthorizeRequest возбуждается после того, как пользователь аутентифицирован в событии AuthenticateRequest. Модули авторизации используют AuthorizeRequest для проверки того, авторизован ли пользователь для доступа к запрошенному ресурсу.

Аутентификация

Аутентификация реализуется в ASP.NET через специализированные модули HTTP, как показано на рис. 9 и 10. Вы выбираете модуль аутентификации, который хотите использовать, в элементе конфигурационного файла web.config. Все модули аутентификации реализуют интерфейс IHttpModule, который предоставляет доступ к событиям приложения (как описано в главе 5. Приложения ASP.NET). Это позволяет им обрабатывать событие HttpApplication.AuthenticateRequest. Каждый модуль также представляет собственное событие Authenticate, которое вы можете обработать в global.asax.

ASP.NET представляет три центральных модуля аутентификации:

  • FormsAuthenticationModule
  • WindowsAuthenticationModule
  • PassportAuthenticationModule

Следующие разделы кратко описывают каждый модуль.

FormsAuthenticationModule

Модуль FormsAuthenticationModule использует аутентификацию форм, что позволяет вам разрабатывать собственные страницы регистрации (login-pages), писать собственную логику аутентификации, при этом полагаясь на ASP.NET для отслеживания информации о пользователе и роли, используя шифрованные cookie. Модуль FormsAuthenticationModule активен, когда элемент установлен следующим образом:

Глава 20. Аутентификация с помощью форм более подробно описывает аутентификацию форм. (Вы также можете использовать аутентификацию форм с программными интерфейсами Membership API и Roles API, которые мы представим позднее в этой статтье раскроем в деталях в главе 20. Аутентификация с помощью форм).

WindowsAuthenticationModule

Модуль WindowsAuthenticationModule работает в сочетании с IIS для выполнения аутентификации Windows. Этот модуль активен, когда элемент в файле web.config установлен следующим образом:

Более подробно Windows-аутентификация рассматривается в главе 22. Аутентификация Windows .

PassportAuthenticationModule

PassportAuthenticationModule активен, когда элемент в файле web.config установлен следующим образом:

Модуль PassportAuthenticationModule представляет “обертку” для службы аутентификации Microsoft Passport. При использовании Passport пользователь аутентифицируется по информации в базе данных Microsoft Passport (та же технология, которая поддерживается бесплатной почтовой системой Hotmail). Выгода от Passport в том, что вы можете использовать существующие удостоверения пользователей (такие, как адрес e-mail и пароль), не заставляя пользователя проходить отдельный процесс регистрации. Недостаток же в том, что вы должны заключать лицензионное соглашение с Microsoft и платить за пользование этой системой.

ASP.NET не включает полную поддержку аутентификации Passport. Чтобы успешно ее использовать, вы должны выгрузить и инсталлировать на свой Web-сервер Passport .NET SDK. В этой книге мы не рассматривает Passport, но вы можете узнать больше (и выгрузить SDK) на http://www.realcoding.net/redir.php?url=http://www.microsoft.com/net/ser. .

Авторизация

Как только пользователь аутентифицирован, такая информация, как имя пользователя и контекст безопасности становится автоматически доступна посредством инфраструктуры ASP.NET. Вы можете обратиться к ней через объект HttpContext.Current.User и использовать эту информацию, чтобы реализовать авторизацию в своем коде. Более того, ASP.NET включает следующие встроенные модули для реализации авторизации:

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

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

Более того, вы можете реализовать авторизацию посредством написания специального кода в своих страницах или компонентах, используемых web-приложением. В этом случае вы ссылаетесь на объект HttpContext.Current.User и принимаете решение на основе принадлежности к ролям или непосредственно по имени пользователя. О дизайне и реализации авторизации будет рассказано подробно в главе 23. Авторизация и роли. Но прежде, чем изучать детали аутентификации и авторизации вы должны понимать значение контекста безопасности (security context)

Контекст безопасности

Независимо от системы аутентификации, ASP.NET использует в основе одну и ту же модель представления информации о пользователе и роли. Пользователям, которые регистрируются в Web-приложении, на основе предъявленных ими удостоверений выделяется принципал (principal) и идентичность. Объект-принципал представляет текущий контекст безопасности данного пользователя. Он комбинирует самого пользователя (идентичность) с информацией, сохраняемой в записях бюджета текущего пользователя, — такой, как роди, привилегии, и многое другое. Таким образом, это позволяет вам выполнять авторизацию, основанную на ролях, и представляет ссылку на соответствующий объект идентичности. Объект идентичности представляет успешно авторизованного пользователя и потому предоставляет информацию о пользователе, — такую, как его имя.

Интерфейс IPrincipal


Все объекты-принципалы реализуют интерфейс IPrincipal, который определяет центральный набор функциональности. Когда вы обращаетесь к свойству User текущей Web-страницы (System.Web.UI.Page), или из текущего контекста HTTP (HttpContext.Current), то получаете доступ к объекту IPrincipal, представляющему контекст безопасности текущего пользователя.

Интерфейс IPrincipal определяет единственное свойство по имени Identity, которое извлекает объект IIdentity, представляющий информацию о текущем пользователе. Интерфейс IPrincipal также определяет единственный метод по имени IsInRole(), позволяющий вам проверить, является ли текущий пользователь членом специфической роли.

Приведем пример, использующий метод IsInRole() для проверки того, является ли текущий пользователь сленом роли под названием Admin:

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

Интерфейс IIdentity

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

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

  • AuthenticationType: Возвращает тип используемой аутентификации, как строку (forms, Passport, NTLM или пользовательский тип аутентификации)
  • IsAuthenticated: Возвращает булево значение, указывающее на то, был ли пользователь аутентифицирован (true), или же он является анонимным (false)
  • Name: Возвращает имя текущего пользователя в виде строки.

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

Тип объекта идентичности зависит от типа используемой аутентификации. Всего четыре класса идентичности включены в .NET Framework:

  • System.Web.Security.FormsIdentity: Представляет пользователя, который зарегистрировался, используя аутентификацию форм.
  • System.Security.Principal.WindowsIdentity: Представляет бюджет пользователя Windows.
  • System.Web.Security.PassportIdentity: Представляет класс для использования модулем PassportAuthenticationModule.
  • System.Security.Principal.GenericIdentity: Представляет обобщенную идентичность пользователя (Вы можете использовать это для создания идентичности при создании собственной системы аутентификации).

Программные интерфейсы Membership и Roles API

Как вы увидите в главе 20. Аутентификация с помощью форм, при использовании аутентификации форм, вы должны аутентифицировать своих пользователей по специальному собственному хранилищу. Это значит, что вы должны сделать намного больше, чем просто создать базовую страница регистрации для проверки имен и паролей пользователей. Конечно, вам нужен способ управления пользователями и назначения их на роли. В ASP.NET 1.x вам нужно было самостоятельно создавать такие инструменты управления и программные компоненты. ASP.NET 2.0 представляет эту инфраструктуру через программные интерфейсы Membership API, Roles API и Profiles API.

Membership API

Membership API – полная система управления пользователями. Она помогает вам создавать, редактировать и удалять пользователей, а также включает функциональность восстановления паролей. Этот API можно применять для программного выполнения этих управленческих задач, или же использовать Web-ориентированный инструмент конфигурирования ASP.NET для графического администрирования ваших пользователей. Благодаря этой инфраструктуре, вы можете сэкономить много времени, поскольку более нет необходимости создавать свои собственные приложения администрирования пользователей, потому что они уже существуют в каркасе ASP.NET 2.0. Более того, он включает также функциональность валидации комбинаций имен и паролей, вводимых пользователями.

Подробнее о Membership API вы узнаете из главе 21. Интерфейс Membership API.

Roles API

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

В главе 23. Авторизация и роли вы изучите все детали применения Roles API в ваших приложениях.

Profiles API

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

Опять же, ASP.NET 2.0 включает готовую к использованию инфраструктуру управления профилями в ваших приложениях.

Из главы 24. Профили вы узнаете, как использовать Profile API в вашем приложении.

Использование SSL при работе с web-сервисами

Одним из элементов безопасности современного предприятия является использование защищенных каналов связи. Защищенные каналы связи позволяют предотвратить несанкционированный просмотр и изменение данных. Одним из наиболее популярных протоколов, реализующих защищенный канал, является протокол SSL . Данная статья описывает, как можно использовать протокол SSL при работе с web -сервисами «1С:Предприятия».

SSL ( Secure Socket Layer ) — протокол, использующийся для обеспечения защищенного взаимодействия между клиентом и сервером. SSL базируется:

· на в заимной аутентификации клиента и сервера для того, чтобы и клиент, и сервер были уверены в том, что они те, за кого себя выдают;

· цифровых подписях, для обеспечения целостности данных (защиты данных от несанкционированного изменения);

· шифровании, для обеспечения конфиденциальности данных (защиты данных от несанкционированного просмотра).

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

SSL — протокол использует SSL — сессию для установки защищенного соединения между клиентом и сервером. Сессия устанавливается путем обмена между клиентом и сервером последовательностью сообщений. При установке сессии могут выполняться такие действия, как:

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

· установка сессионного ключа;

· аутентификация сервера на клиенте;

· аутентификация клиента на сервере.

SSL — сессия может быть переиспользована между клиентом и сервером.

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

Одним из наиболее общеупотребимых применений протокола SSL является его использование для передачи HTTP -запросов ( HTTPS — протокол). В этом случае URL — схема адресации для таких ресурсов — https , а порт по умолчанию – 443.

Механизм web -сервисов «1С:Предприятия» позволяет как использовать, так и реализовывать https web -сервисы.

Клиентская часть механизма web -сервисов автоматически по URL -схеме ( https ) расположения web -сервиса определяет, что взаимодействие с таким web -сервисом должно вестись по защищенному каналу связи. Клиентская часть также требует, чтобы с сервером был связан валидный сертификат, выданный известным клиенту Центром Сертификации.

Сертификат сервера является валидным, если его цифровая подпись соответствует содержимому сертификата, его дата действия не просрочена и веб-сайт, на который выдан данный сертификат, соответствует веб-сайту сервера. Если сертификат не является валидным, например, веб-сайт сертификата не соответствует веб-сайту сервера, то клиент не сможет взаимодействовать по протоколу SSL с web -сервисами этого сайта.

Чтобы сертификат сервера был принят клиентом, нужно поместить его или сертификат Центра Сертификации, выдавшего данный сертификат сервера, в файл cacert . pem , который находится в каталоге bin «1С:Предприятия». В этом файле перечислены все сертификаты, которым доверяет данный клиент. Файл имеет формат PEM ( Privacy Enhanced Mail ) — текстовый формат, в котором сертификаты закодированы в base 64 последовательности.

https web -сервисы разрабатываются так же, как и обычные http web -сервисы, но требуют дополнительной настройки веб-сервера. Для IIS веб-сервера настройка заключается в привязке к веб-сайту серверного сертификата и настройке виртуальной директории web -сервиса. Серверный сертификат может быть получен от Центра Сертификации, в качестве которого может выступать любой Windows Server 2003 с установленным сервисом сертификатов. После того как сертификат связан с веб-сайтом, для виртуальной директории web -сервиса нужно указать, что доступ к ней осуществляется по защищенному каналу связи (см. документацию по IIS ).

Для Apache web -сервера также нужно указать серверный сертификат и признак работы по защищенному каналу. Сертификат может быть получен при помощи утилиты openssl (см. документацию по mod _ ssl ).

Iis о шифровании

Стандартные возможности аутентификации Internet Information Server (IIS), анонимный доступ, методы аутентификации, учетная запись IUSR_

Большая часть серверов IIS работает без требований к пользователю аутентифицироваться — то есть в режиме анонимного доступа. На самом деле такие анонимные пользователи работают от имени специальной учетной записи IUSR _имя_компьютера. Конечно же, настоятельно не рекомендуется использовать эту учетную запись для каких-то других целей, добавлять ее в другие группы (кроме группы Guests ), в которой эта учетная запись находится по умолчанию и т.п.

Однако в некоторых ситуациях анонимным доступом не обойтись. Обычно аутентификация требуется в двух случаях:

1) когда на Web -сервере находятся ресурсы, доступ к которым нужен не всем пользователям (проще говоря, чтобы задействовать систему разрешений);

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

Аутентификация в IIS , к сожалению, полностью основывается на системе безопасности Windows . Фактически мы можем предоставить доступ только тем пользователям, для которых у нас создана локальная учетная запись (или доменная учетная запись, если компьютер с IIS входит в домен). Конечно, по этой причине доступ на IIS со стандартными средствами можно предоставлять только пользователям локальной сети (или, например, очень ограниченному числу внешних партнеров). Рассчитывать на организацию системы аутентификации для пользователей из Интернета стандартными средствами не приходится (поскольку для каждого пользователя учетную запись Windows не создашь). Обычно для таких целей используются или самостоятельно созданные Web -приложения, или специальные надстройки на IIS , которые обеспечивают отдельную, независимую от Windows систему аутентификации. Ниже будет рассмотрены стандартные возможности аутентификации, а затем — дополнительные средства других производителей.

Настройку аутентификации стандартными методами предписывается производить из консоли Internet Information Services Manager -> свойства Web -сайта -> вкладка Directory Security -> кнопка Edit в группе Authentification and Access Control . При нажатии на эту кнопку открывается окно Authentification Method , в котором и производятся настройки параметров аутентификации. В этом окне вы можете:

  • разрешить или запретить анонимный доступ на Web -сайт и выбрать учетную запись, которая будет использована для этой цели;
  • выбрать методы аутентификации, которые могут быть использованы для доступа на Web -сервер.

О методах аутентификации необходимо рассказать подробнее:

  • IntegratedWindowsAuthentification — единственный метод (кроме анонимного доступа), доступный по умолчанию. При использовании этого метода используются те же хэши NTLM (или Kerberos — negotiate для Windows 2000/ XP /2003), что и при обычной аутентификации в Windows (например, при обращении к файлам на файл-сервере). Конечно, ни один броузер, кроме Internet Explorer , такой аутентификации не поддерживает. Необходимо отметить, что, если прав учетной записи IUSR недостаточно (или анонимный доступ вообще отключен) следующее, что делает Internet Explorer — отсылает NTLM -хэш (его версия зависит от версии операционной системы) текущей учетной записи на сервер IIS . Если аутентификация не прошла (или прошла, но у учетной записи не оказалось прав на Web -ресурс), то открывается всплывающее окно аутентификации, в котором пользователь имеет возможность ввести данные другой учетной записи;
  • DigestAuthentification — сравнительно новая технология (появилась только в Windows 2000/ IIS 5.0), основанная на открытых Интернет-стандартах (алгоритм хэширования MD 5 и RFC 2617). При использовании этого метода аутентификации сервер посылает специальную случайную последовательность символов — nonce — клиенту (для каждого сеанса она будет сгенерирована заново). Клиент принимает эту последовательность, на основе ее и своего пароля генерирует хэш по алгоритму MD 5 и пересылает ее серверу. Сервер, который производит такую же операцию и сравнивает полученные значения. Главной проблемой применения этого метода аутентификации является то, что IIS должен получить доступ к открытым паролям пользователей, которых по умолчанию нет и на контроллерах домена. Таким образом, чтобы этот метод аутентификации заработал, необходимо для учетных записей пользователей установить параметр » Store password using reversible encryption «, что обычно в защищенных сетях недопустимо.
  • BasicAuthentification — самый простой тип аутентификации, который поддерживается практически всеми броузерами. При этом имя пользователя и пароль посылаются почти открытым текстом (на самом деле они кодируются, во избежание попадания служебных символов, по алгоритму Base 64). Те менее, конечно, расшифровать эти данные не составит никакого труда — например, при помощи утилиты Base 64 Decoder (она умеет декодировать и некоторые другие форматы) из каталога прочее на компакт-диске. Поскольку передаются таким образом на самом деле имя и пароль учетной записи Windows , то последствия могут оказаться очень серьезными (если в сети запущен сниффер). Безопасно пользоваться этим методом аутентификации можно только при использовании SSL .
  • .NETPassportauthentification — возможность использовать для аутентификации централизованную систему . NET Passport от Microsoft . Не совсем понятно, зачем эта возможность помещена на графический интерфейс IIS Manager — использовать эту возможность могут только участники программы . NET Passport , фактически — очень ограниченный круг крупных Web -коммерсантов. Существует и множество других ограничений при использовании .NET Passport .

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

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

  • IUSR _имя_компьютера — об этой учетной записи уже говорилось, она предназначена для обеспечения анонимного доступа на сервер IIS и никаких дополнительных прав ей предоставлять не рекомендуется;
  • IWAM_имя_компьютера — еще одна гостевая учетная запись, которой не нужно давать лишние права. От имени этой учетной записи запускаются внешние процессы, порождаемые процессом INETINFO (то есть процессом Web -сервера). Иногда для работы Web 0-приложения этой учетной записи необходимо предоставить дополнительные права, например, на запись в каталог.
  • IIS _WPG — эта группа предназначена для предоставления прав в операционной системе приложениям CGI и ASP . NET , работающим на Web -сервере. Если у вас таких приложений нет, выдавать какие-либо разрешения этой группе не нужно.
  • ASPNET — как понятно из названия, эта учетная запись используется приложениями ASP . NET , работающими на сервере IIS . Если у вас не используется ASP . NET (не установлена как компонент IIS ), то этой учетной записи не будет. Этой учетной записи нужно предоставлять права, например, если приложению ASP . NET необходимо подключаться к SQL Server .

При помощи группы переключателей IP address and domain name restrictions можно также ограничить доступ к сайту по IP -адресам, целым IP -сетям или именам доменов DNS . Обычно такие возможности используются только в Интранет Web -серверах.

Проблема с шифрованием Windows IIS

0 adviner [2015-05-12 20:41:00]

Используя Windows 2008 R2, я пытаюсь выяснить, как исправить проблему шифрования, которую показывает хром:

Я пытался найти решение, но, похоже, не получил четкого ответа о том, что делать. Я читал, что вам нужно получить новый сертификат, а другим — настроить параметры криптографии. Я включил свои настройки с помощью IIS Crypt, если это помогает:

Я попытался удалить все шифры SHA, но это только затормозило меня от использования RDP. Это просто, что мне нужно отключить правильный шифр?

Обновление 5/12/2015 Из предложения usr я обновил свои ключи, чтобы использовать SHA2 из GoDaddy и установил их. Сейчас все работает нормально.

Установка SSL сертификата на Microsoft IIS 7.x, 8.x

Процедура покупки/установки сертификата считается относительно сложным процессом, и требует четкого соблюдения ряда правил. Если Вам, как владельцу магазина «быстро и просто нужен сертификат», то для этого мы специально ввели услугу покупки и установки сертификата под ключ, т.е. наш специалист поддержки запросит все необходимые данные, создаст почту на домене (если требуется), зарегистрирует SSL сертификат и корректно установит его на сайт (к магазину или воронки). Вы оплачиваете один раз, и далее дело за нами, услуга доступна в разделе услуги, вот тут — https://www.advantshop.net/services

Если вы уже приобрели SSL сертификат, но не хотите, тратить время или не до конца уверены в правильности действий, то для такого случая мы так же ввели услугу установки уже купленного сертификата на ваш сайт. Специалист проверит сам сертификат на пригодность и корректно установит его на сайт, услуга «Установка SSL сертификата» доступна в разделе услуги, вот тут — https://www.advantshop.net/services

И так, всё же, если вы твёрдо решили всё сделать самостоятельно, мы по шагам расскажем как и что нужно.

Если вы используете тип хостинга выделенный сервер (VPS/VDS или Dedicated), вам нужно зайти на машину по протоколу RDP (Remote Deskstop) под учетной записью, которую выдал хостинг.

  • Нажмите Start.
  • Выберите Administrative Tools.
  • Запустите Internet Services Manager — IIS
  • Нажмите на название сервера (обычно это название компьютера) в дереве элементов слева

В главном меню кликните по кнопке «Server Certificates» в разделе «Security».

Выберите меню «Actions» (справа), нажмите на «Complete Certificate Request».

Откроется мастер Complete Certificate Request.

Введите место расположения вашего IIS SSL сертификата (нужно нажать кнопку browse для определения места расположения Вашего IIS SSL сертификата. Этот файл должен иметь название «yourdomainname.crt»).

Затем введите удобное имя сертификата. Оно не является частью самого сертификата, но используется администратором сервера для легкого различения сертификата.

Затем нажмите Ok.

Примечание: Известно, что в IIS 7 появляется следующая ошибка: «Cannot find the certificate request associated with this certificate file. A certificate request must be completed on the computer where it was created.» Вы также можете увидеть ошибку, констатирующую «ASN1 bad tag value met». Если этот тот же самый сервер, на котором Вы генерировали и CSR, то в большинстве случаев сертификат фактически установлен. Просто отмените диалог и нажмите «F5» для обновления списка сертификатов сервера. Если новый сертификат появился в списке, то Вы можете продолжать дальше. Если сертификат не появится в списке, то Вам нужно перевыпустить сертификат, используя новый CSR (смотрите наши инструкции по созданию CSR на IIS 7).

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

В главном окне Internet Information Services (IIS) Manager в меню «Connections» выберите имя сервера, В «Sites» выберите сайт, который будет защищен SSL, далее в меню «Actions»(справа), нажмите на «Bindings».

Откроется окно «Site Bindings».

В окне «Site Bindings» нажмите «Add». Тем самым Вы откроете «Add Site Binding».

В «Type» выберите https. IP адрес должен быть IP адресом сайта или * (All Unassigned), и порт, по которому будет защищен трафик посредством SSL, обычно это 443.

Сертификат, который ранее был установлен, должен быть задан в поле «SSL Certificate».

Илон Маск рекомендует:  Описание ошибок vb
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL