Веб-приложения как правило работают в глобальной сети Интернет. Это означает, что потенциально к этому приложению имеет доступ любой человек, подключенный к сети Интернет. Как известно, среди пользователей могут встречаться злоумышленники, которые могут иметь намерение деструктивно воздействовать на приложение. При этом существует определенный набор угроз, которым может быть подвержено веб-приложение. Злоумышленники могут иметь различные предпосылки для взлома веб-приложения. В некоторых ситуациях злоумышленник может попытаться вывеси приложение из строя, в другом случае – получить доступ к конфиденциальным данным, и т.д. Так или иначе всегда следует помнить о возможных "узких местах" приложения и немедленно исправлять недостатки.
К основным, наиболее популярным видам угроз относятся:
Существует еще ряд угроз, однако они менее критичны, чем перечисленные выше угрозы.
DoS-атака (denial of service, отказ в обслуживании) – это вид атаки на приложение, при котором генерирует большое число одновременных запросов к приложению. Цель этой атаки вывести приложение из работоспособного состояния (или существенно снизить производительность).
В момент осуществления DoS-атаки на приложение, к нему генерируется большое количество одновременных запросов. Поскольку ресурсы каждого веб-сервера, обслуживающего это приложение ограничены, в какой-то момент времени веб-сервер начинает не справляться с обработкой очередных запросов и производительность приложения снижается. Если в какой-то момент времени сервер не способен обработать запрос, он возвращает пользователю сообщение о невозможности обращения к ресурсам приложения. Таким образом, пользователи не смогут корректно работать с приложением. Защита от DoS-атаки производится путем блокирования IP-адресов, от которых поступает большое число запросов. В этом случае сервер не тратит ресурсы на обработку этих запросов и начинает функционировать нормально. Однако сложность подобных атак заключается в том, что злоумышленники могут атаковать сервер одновременно с нескольких IP-адресов. В этом случае необходимо заблокировать диапазон IP-адресов злоумышленников.
Самые сложные DoS-атаки предполагают осуществление атаки не с одного компьютера, а с целой сети. Для этого злоумышленники могут распространить недоброкачественный программный код (вирус) на большое число компьютеров. Действие этого кода будет заключаться в том, что в определенный момент времени все компьютеры, зараженные этим вирусом начнут атаковать приложение. В этом случае защититься от атаки простым блокированием адресов сложно, поскольку это достаточно большой диапазон адресов. При осуществлении подобных атак, к вопросу защиты подходят индивидуальным образом, учитывая особенности приложения. Например, приложение может попросить пользователя ввести специальный код, отображаемый на изображении.
Атака, связанная с перехватом конфиденциальной информации производится с целью получить какую-либо информацию, передаваемую между клиентом и сервером с целью дальнейшего ее использования. Обычно к такой информации относятся пароли, используемые для доступа к приложениям, номера счетов в банке, номера кредитных карт и т.д.
При осуществлении подобной атаки злоумышленник используя специализированное программное обеспечение, перехватывает весь трафик, передаваемый между сервером и клиентом. В этом случае злоумышленник может анализировать передаваемые данные и изымать нужную информацию с целью дальнейшего использования.
Для защиты от подобных атак обычно используется шифрование канала, по которому передается информация. В этом случае злоумышленник не в состоянии перехватить информацию. Для шифрования трафика, передаваемого по протоколу HTTP обычно используется модификация протокола – HTTPS. В этом случае клиент и сервер безопасно обмениваются ключами шифрования информации, после чего используя этот ключ шифруют все передаваемые данные. Злоумышленник не в состоянии анализировать зашифрованные данные, если только он не получит ключ шифрования. В целом, использование протокола HTTPS является надежной защитой от данного вида угроз.
Угрозы, связанные с неправомочным доступом к информации похожи на предыдущий вид атак. Отличие заключается в том, что в данном случае получает доступ к закрытым ресурсам приложения. Это может быть доступ к базе данных, в которой хранятся данные, доступ к администраторской части приложения, физический доступ к веб-серверу и т.д. При получении доступа к закрытому ресурсу злоумышленник может исследовать ресурс на наличие необходимых для него данных.
Общего сценария осуществления подобных атак нет. Обычно они связаны с получением прав доступа к ресурсу (пароля). Пароль может быть получен злоумышленником по неосторожности администратора или перехвачен путем анализа передаваемых данных (предыдущий вид атак). Кроме того, злоумышленник может получить пароль для доступа к ресурсу путем перебора паролей из заранее заготовленного словаря.
Обычно для защиты от подобного вида атак следует использовать сложные устойчивые к перебору пароли (использовать буквы, цифры и знаки). Кроме того, следует периодически изменять пароли для доступа к ресурсу. Наконец, следует не хранить конфиденциальную информацию в открытых местах, куда возможен потенциальный доступ злоумышленника.
Неправомочная модификация информации перекликается с предыдущим видом атак. Отличие этой атаки состоит в том, что злоумышленник не просто получает доступ к информации, но и модифицирует ее. Примером такой атаки может служить доступ злоумышленника к базе данных банка с целью изменения информации о его счете в этом банке (например, увеличение количества средств на его счете).
Для защиты от подобных атак следует использовать рекомендации, приведенные для защиты от предыдущего вида атак.
Наконец атака, связанная с подменой данных заключается в том, что злоумышленник изменяет данные, которые отправил клиент серверу. Это один из сложных видов атак. В этом случае, при обращении клиента к серверу злоумышленник может подменять некоторую информацию, которую передает клиент серверу. В этом случае приложение предполагает, что эти данные отправил сам клиент и выполняет какие-либо операции.
Примером такой атаки является следующая ситуация. Например, клиент, используя браузер обращается к веб-приложению банка. Клиент вызывает операцию перевода денег на другой счет. В этом случае злоумышленник может подменить номер счета, и банк перечислит деньги на другой счет.
Для защиты от подобных атак следует также прибегать к шифрованию трафика. В этом случае злоумышленник не сможет подменить данные, передаваемые серверу.
Как видно, существует большое количество угроз. Поэтому при разработке веб-приложений всегда следует помнить в потенциальной возможности атаки приложения и строить приложение в соответствии с требованиями безопасности.
Веб-приложения работают в глобальной сети Интернет, в которой к приложению может обратиться любой пользователь сети Интернет. При этом существует ряд угроз, которым подвержено приложение. В общем случае следует внимательно относится к конфиденциальной информации (паролям для доступа к ресурсам), а также шифровать канал передачи данных при передаче секретной информации. Для этого обычно используется протокол HTTPS.
Модель безопасности ASP.NET имеет встроенные механизмы по обеспечению безопасности приложения. При этом она базируется на основе понятия стража. Модель стражей применяет модель конвейера к организации инфраструктуры безопасности. Такая модель предполагает, что безопасное приложение всегда имеет больше механизмов защиты, чем необходимо. Каждый из этих механизмов реализован как страж, отвечающий за проверку конкретных условий защиты. Если один из таких стражей не сработает, то злоумышленник столкнется со следующим стражем в конвейере. Чем больше таких стражей содержится в приложении, тем труднее злоумышленнику деструктивно воздействовать на приложение.
Как уже упоминалось, каждый страж выполняет проверку на одно условие. При этом как видно из приведенной схемы, в конвейере присутствуют несколько стражей, каждый из которых обеспечивает свой алгоритм защиты. Таким образом, с помощью одного или нескольких стражей можно реализовать каждый из уровней безопасности. ASP.NET включает в себя базовую инфраструктуру безопасности, в рамках которой обеспечивается безопасность на следующих уровнях:
| Аутентификация. | Этот уровень безопасности отвечает за определение текущего пользователя и отвечает на вопрос "Кто работает с приложением?"; |
| Авторизация. | Этот уровень безопасности отвечает за определение полномочий текущего пользователя и отвечает на вопрос "Какие операции данный пользователь может выполнять?"; |
| Конфиденциальность. | Этот уровень безопасности отвечает за то, чтобы данные, передаваемые от сервера клиенту, не были прочитаны третьими лицами. Обычно этот уровень реализуется за счет применения шифрования канала с использованием протокола HTTPS; |
| Целостность. | Этот уровень безопасности отвечает за то, чтобы данные передаваемые от клиента серверу не были подменены третьими лицами. Обычно этот уровень реализуется за счет использования цифровых подписей. |
В рамках инфраструктуры безопасности ASP.NET поддерживаются механизмы аутентификации, авторизации и хранения пользовательской информации на сервере.
Аутентификация в приложениях на базе ASP.NET может осуществляться следующими способами:
Самым простым способом аутентификации является аутентификация формами. При таком подходе пользователь должен ввести имя пользователя и пароль на странице ASP.NET.
Аутентификация Windows позволяет определить пользователя на основе корпоративной политики. Например, в качестве хранилища информации о пользователях может быть Active Directory.
Аутентификация с помощью паспортов предусматривает наличие третьей стороны, которая гарантирует, что пользователь является именно тем, за кого он себя выдает. Примером подобной аутентификации является служба Live ID и Open ID.
Можно разработать специфичный механизм аутентификации, реализуя соответствующий провайдер. В этом случае разработчик сам определяет процесс аутентификации.
Для того чтобы использовать встроенный механизм аутентификации формами, необходимо его настроить. Для этого используется файл "web.config". Конфигурационный файл содержит секцию "authentication", которая содержит всю необходимую информацию.
Как видно, при настройке задается имя формы, адрес страницы для ввода имени пользователя и пароля, а также таймаут, по истечении которого сервер "забудет" про аутентифицированного пользователя и ему нужно будет указать имя и пароль еще раз.
После задания указанных настроек необходимо определить место хранения учетных данных пользователей. Одним из таких мест может быть файл конфигурации.
В этом примере атрибут "passwordFormat" секции "credentials" определяет способ хранения пароля. Значение "clear" указывает на то, что пароль хранится в открытом виде. Кроме этого, пароль можно хранить в виде хэша MD5 или SHA1.
После задания всех настроек можно воспользоваться механизмом аутентификации формами. Для этого необходимо воспользоваться классом FormsAuthentication и его статическими методами Authenticate, SignOut, RedirectFromLoginPage и RedirectToLoginPage. Таким образом, программный код для выполнения входа в систему может выглядеть следующим образом.
Теперь, на каждой странице становится возможным проверить выполнен ли вход в систему и, если выполнен, то кем. Для этого можно воспользоваться свойствами IsAuthenticated и Name объекта IIdentity, доступ к которому можно получить, используя текущий контекст - HttpContext.Current.User.Identity.
Несмотря на то, что аутентификация формами закладывает только базовый механизм реализации аутентификации, задачи, которые приходится решать в процессе создания безопасных приложений, как правило, одни и те же. Такими операциями могут быть операции входа в систему и выхода из нее, наделение полномочиями того или иного пользователя, заведение новых пользователей и т.д. В то же время механизм аутентификации формами позволяет выполнить только процесс аутентификации, и не предоставляет возможности выполнить другие описанные операции.
Именно поэтому в ASP.NET существует механизм Membership API. По сути, Membership API – это интерфейс, который позволяет:
Таким образом, Membership API – это интерфейс для реализации различных поставщиков для хранения информации о пользователях. Такое абстрагирование на уровне интерфейса позволяет быть независимым от конкретной реализации поставщика и одинаково работать, например, с поставщиком на основе базы данных или Active Directory. ASP.NET включает ряд готовых поставщиков для SQL Server и Active Directory. Это позволяет хранить данные о пользователях и ролях в SQL Server или в Active Directory. Кроме того, можно разработать собственный поставщик, который в качестве хранилища будет использовать другой источник (например, файл на жестком диске). Для этого необходимо создать класс-наследник MembershipProvider из пространства имен "System.Web.Security" и указать его в конфигурационном файле.
Для того, чтобы использовать Membership API в своих приложениях необходимо выполнить несколько шагов:
Наиболее часто в качестве хранилища данных используется база данных на основе SQL Server. Для SQL Server разработана готовая схема данных, которая позволяет хранить пользователей, пароли, роли и т.д. Для того чтобы создать подобную схему данных в вашей БД необходимо воспользоваться утилитой aspnet_regsql, которая расположена в папке "C:\Windows\Microsoft.NET\Framework\v2.0.50727". Эта утилита поддерживает два режима работы – консольный и графический. Для запуска утилиты в консольном режиме необходимо указать параметры:
В этой команде указывается имя сервера "(local)" и имя базы данных "MyDB". Кроме того, можно запустить эту утилиту без параметров, тогда она будет работать в графическом режиме. В этом случае необходимо указать мастеру нужные параметры, после чего будет создана нужная схема данных.
Для создания указанной схемы данных необязательно пользоваться утилитой aspnet_regsql. В папке "C:\Windows\Microsoft.NET\Framework\v2.0.50727" расположены скрипты для SQL Server, которые позволяют создать или удалить эту схему данных. Поэтому для создания базы данных можно вручную запустить эти SQL-скрипты. Список файлов для создания и удаления схемы:
После создания схемы данных необходимо сконфигурировать провайдер Membership API. Для этого в секции "system.web" необходимо создать секцию "membership", внутри которой указать нужных провайдеров. Кроме того, в атрибуте "defaultProvider" секции "membership" необходимо задать имя текущего провайдера. Таким образом, конфигурационный файл может выглядеть следующим образом.
Как видно, при добавлении нового поставщика задается его имя, тип и строка соединения с базой данных, которая задается в секции "connectionStrings".
После этого Membership API готов к работе. Для создания новых пользователей и удаления старых, можно воспользоваться статическими методами CreateUser и DeleteUser класса Membership
После выполнения аутентификации следует процесс авторизации. Сам процесс авторизации может поддерживаться на двух уровнях:
Таким образом, инфраструктура ASP.NET содержит ряд готовых механизмов по обеспечению безопасности приложения.
Модель безопасности ASP.NET построена на понятии стражей. Каждый страж выполняет проверку на определенное условие. Если при обработке запроса хотя бы один страж отказал в обслуживании, пользователю сообщается об ошибке. Механизмы безопасности ASP.NET обеспечивают полный цикл по обеспечению безопасности приложения, включая процессы аутентификации и авторизации. Для обеспечения работы с информацией о пользователях используется механизм Membership API.
Модель безопасности ASP.NET предлагает готовые механизмы по организации безопасности приложения, предоставляя для этого нужные объекты, позволяя их настраивать и адаптировать под потребности приложения. Для того, чтобы пользователь мог взаимодействовать с системой безопасности, необходимо построить для нее пользовательский интерфейс. Это означает, что если приложение использует при работе механизм аутентификации, то пользователь должен иметь возможность указать имя и пароль. Кроме того, часто требуется отобразить пользователю информацию о том, выполнен ли вход в систему, или пользователь еще не аутентифицирован.
Для этих задач можно разработать собственный интерфейс пользователя, используя базовые элементы управления ASP.NET. Однако, в этом случае программисту необходимо будет разработать программный код для обеспечения взаимодействия этих элементов управления и системы безопасности. Для облегчения этой задачи платформа ASP.NET содержит ряд готовых элементов управления, в которых уже реализована вся необходимая логика.
При использовании Membership API можно использовать стандартные элементы управления для визуализации работы с аутентификацией пользователя и управления данными безопасности. Для этого существует набор стандартных элементов управления по управлению безопасностью:
Login предназначен для входа в систему. Он представляет собой два поля ввода – для имени пользователя и пароля, и кнопку входа в систему;LoginView позволяет отображать различную информацию в двух режимах – если пользователь аутентифицирован или если пользователь анонимный. Для каждого случая можно задать собственный шаблон;PasswordRecovery представляет собой элемент, который позволяет восстановить забытый пароль и, используя Membership API, отправить его пользователю по электронной почте;LoginStatus позволяет вывести ссылку с текстом "Вход", если вход не выполнен или ссылку с текстом "Выход", если вход выполнен. Обычно такая ссылка располагается на каждой странице;LoginName позволяет отобразить имя активного пользователя, который вошел в систему;CreateUserWizard представляет собой мастер для создания нового пользователя, в который входят все необходимые поля;ChangePassword представляет собой элемент управления для смены пароля. В рамках этого элемента управления содержатся поля для ввода текущего и нового пароля с подтверждением.Наиболее часто используется элемент управления Login. Он позволяет пользователю ввести имя пользователя и пароль. Для размещения элемента управления используется следующая несложная разметка.
Если провайдер Membership API сконфигурирован корректно, то для работы элемента управления Login не требуется никаких дополнительных настроек. Если для входа в систему требуется использовать провайдер, отличный от провайдера, используемого по умолчанию, то его имя можно указать в свойстве MembershipProvider.
Внешний вид элемента управления Login представляется следующим образом.
Если при работе приложения требуется отображать какую-либо специфическую информацию в зависимости от того, выполнен ли вход в систему, можно использовать элемент управления LoginView. Этот элемент управления позволяет определить содержимое для двух случаев:
Для обеих ситуаций этот элемент управления содержит шаблоны, которые можно переопределить – AnonymousTemplate и LoggedInTempalte. В зависимости от того, вошел ли пользователь в систему будет выбран тот или иной шаблон.
При определении шаблонов также можно использовать другие вложенные элементы управления.
Если в приложении требуется отобразить имя текущего пользователя, то можно использовать элемент управление LoginName. Этот элемент управления также использует текущий провайдер MembershipAPI для определения имени пользователя.
Наконец, если пользователь еще не вошел в систему, необходимо сделать ссылку на страницу, в рамках которой он сможет ввести имя пользователя и пароль. Для реализации этого сценария можно использовать элемент управления LoginStatus.
Логика этого элемента управления заключается в следующем:
Таким образом, платформа ASP.NET содержит набор необходимых элементов управления, которые позволяют минимизировать работу по построению пользовательского интерфейса для управления системой безопасности.
Несмотря на наличие базовых элементов безопасности ASP.NET, разработчику приложения также требуется создать пользовательский интерфейс, который позволит взаимодействовать пользователю с системой безопасности. Для облегчения этой работы платформа ASP.NET содержит базовый набор элементов управления для взаимодействия с системой безопасности. Используя эти элементы управления, разработчик может за несколько простых действий позволить пользователь войти в систему, увидеть текущее имя пользователя и состояние аутентификации и др.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.