Безобразный login asp. Обеспечение безопасности cookie-наборов аутентификации

Если посмотреть на приведенный код, то возникает один вопрос: если при настройке шаблона приходится писать настолько много кода пользовательского интерфейса (или проектировать его в визуальном конструкторе), так почему бы ни написать собственную страницу входа, не применяя элемента управления Login?

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

С правильными элементами управления и корректными значениями идентификаторов для этих элементов управления не понадобится писать код обработки событий. Код работает обычным образом, за исключением того, что вы определяете набор элементов управления и их компоновку. В действительности элемент управления Login требует как минимум двух текстовых полей с идентификаторами UserName и Password. Если эти два текстовых поля отсутствуют (или имеют другие значения идентификатора), то Login сгенерирует исключение. Все остальные элементы управления не обязательны, но если вы указываете соответствующее значение идентификатора (такое как Login для кнопки входа), то Login автоматически обработает их события, и будет вести себя так, как тогда, когда применяется компоновка по умолчанию.

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

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

Можно также добавлять элементы управления с другими идентификаторами, которые вообще не имеют отношения к Login. В показанном выше коде применялись элементы RequiredFieldValidator и RegularExpressionValidator для проверки полей имени пользователя и пароля.

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

DestinationPageUrl

VisibleWhenLoggedIn

• MembershipProvider

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

Программирование элемента управления Login

Элемент управления Login поддерживает несколько событий и свойств, которые можно применять для настройки его поведения. Они предоставляют полный контроль над тонкой настройкой элемента управления Login (наряду с другими средствами настройки, такими как шаблоны и свойства стиля). Элемент управления Login поддерживает события, перечисленные в таблице ниже:

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

Protected void Page_Load(object sender, EventArgs e) { if (!this.IsPostBack) ViewState["LoginErrors"] = 0; } protected void Login1_LoginError(object sender, EventArgs e) { // Если состояние LoginErrors не существует, создать его if (ViewState["LoginErrors"] == null) ViewState["LoginErrors"] = 0; // Увеличить счетчик неудачных попыток входа int ErrorCount = (int)ViewState["LoginErrors"] + 1; ViewState["LoginErrors"] = ErrorCount; // Проверить количество неудачных попыток if ((ErrorCount > 3) && (Login1.PasswordRecoveryUrl != string.Empty)) Response.Redirect(Login1.PasswordRecoveryUrl); }

Элемент управления Login генерирует события в порядке, представленном на рисунке ниже:

Как упоминалось ранее, если вы перехватываете событие Authenticate, то должны добавить собственный код проверки имени пользователя и пароля. Свойство Authenticate поддерживает экземпляр AuthenticateEventArgs списка параметров. Этот класс аргумента события поддерживает одно свойство по имени Authenticated. Если установить его в true, то элемент управления Login предполагает, что аутентификация прошла успешно, и инициирует событие LoggedIn. Если же установить это свойство в false, будет отображен FailureText и инициировано событие LoginError:

Protected void Login1_Authenticate(object sender, AuthenticateEventArgs e) { if (Membership.ValidateUser(Login1.UserName, Login1.Password)) { e.Authenticated = true; } else { e.Authenticated = false; } }

Как видите, имеется прямой доступ к введенным значениям через свойства UserName и Password, которые содержат текст, введенный в соответствующие текстовые поля. Если вы используете шаблонные элементы управления и хотите получить значение из другого элемента, в дополнение к элементам с идентификаторами UserName и Password, то для этого можете использовать метод FindControl() для получения этого дополнительного элемента. Этот метод принимает идентификатор нужного элемента и возвращает экземпляр System.Web.UI.Control. Затем полученный объект просто приводится к типу требуемого элемента управления и читается значение, необходимое специальному методу проверки удостоверения пользователя.

Аутентификация с помощью форм

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

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

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

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

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

Почему стоит использовать аутентификацию с помощью форм?

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

Вы получаете полный контроль над кодом аутентификации.

Вы получаете полный контроль над внешним видом формы входа.

Она работает с любым браузером.

Она позволяет выбирать способ хранения информации о пользователях.

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

Контроль над кодом аутентификации

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

Контроль над внешним видом формы входа

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

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

Работа с любым браузером

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

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

Хранение информации о пользователях

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

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

Когда не следует применять аутентификацию с помощью форм?

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

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

Вы должны поддерживать каталог удостоверений пользователей.

Вы должны предпринимать дополнительные предосторожности против вмешательства в сетевой трафик.

Более подробно об этом пойдет речь в последующих разделах. Первые два недостатка можно устранить за счет применения интерфейса Membership API, предоставляющего предварительно разработанные элементы управления и схему хранения удостоверений с готовым решением на основе SQL Server.

Создание собственного интерфейса регистрации

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

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

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

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

Обслуживание информации о пользователях

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

Платформа Membership API поставляется с предварительно созданной схемой для хранения удостоверений в базе данных SQL Server. За счет использования этой готовой схемы можно сэкономить массу времени. Более того, схема является расширяемой. Однако вы отвечаете за безопасное резервное копирование хранилища удостоверений - так, чтобы его можно было восстановить в случае сбоя системы.

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

Перехват сетевого трафика

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

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

Но что если злоумышленник перехватит незашифрованный трафик, извлечет из него cookie-набор (который уже зашифрован) и воспользуется им в своих целях? Расшифровывать его ему не понадобится - достаточно просто снабдить им собственные пересылаемые запросы. Противостоять такой атаке повтором можно только за счет применения SSL для всего сайта.

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

Почему бы ни реализовать cookie-аутентификацию самостоятельно?

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

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

Cookie-наборы аутентификации являются защищенными.

Аутентификация с помощью форм - тщательно протестированная система.

Аутентификация с помощью форм интегрирована с классами безопасности.NET.

Обеспечение безопасности cookie-наборов аутентификации

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

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

Аутентификация с помощью форм тщательно протестирована

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

Интеграция с платформой безопасности ASP.NET

Все типы аутентификации ASP.NET являются частью общей согласованной платформы. Аутентификация с помощью форм полностью интегрирована с этой платформой безопасности. Например, она наполняет объект контекста безопасности (IPrincipal), как и должна это делать. Это позволяет легко настроить поведение аутентификации с помощью форм по своему усмотрению.

Классы аутентификации с помощью форм

Наиболее важная часть платформы аутентификации с помощью форм - FormsAuthenticationModule. Это класс HttpModule, который обнаруживает билеты аутентификации с помощью форм, присутствующие в запросе. Если такой билет недоступен, а пользователь запросил защищенный ресурс, то запрос автоматически перенаправляется на страницу входа, указанную в файле web.config, еще до того, как исполняющая среда даже просто коснется этого защищенного ресурса.

Если билет присутствует, модуль автоматически создает контекст безопасности, инициализируя свойство HttpContext.Current.User экземпляром GenericPrincipal по умолчанию, который включает экземпляр FormsIdentity с именем текущего зарегистрированного пользователя. В основном напрямую работать с этим модулем не придется. Интерфейс для взаимодействия с модулем состоит из классов, перечисленных в таблице ниже, которые определены в пространстве имен System.Web.Security:

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