Популярность Web-приложений и постоянные проблемы, связанные с их защитой, привели к появлению целой индустрии, работающей, прежде всего, над вопросами защиты Web, а также над проблемами методологий открытых исходников и технических описаний как потенциальных средств атаки и защиты. В частности, организация
Решая различные специфические проблемы, всегда следует помнить об основных принципах проектирования и реализации приложений. Эти принципы не зависят от технологий и применяются к каждой части системы.
Защита является столь же важной характеристикой приложения, как и производительность или, скажем, пользовательские интерфейсы. Функции защиты проектируются согласно определенным требованиям. Это означает, что зашита и тестирование защитных функций внедряются во время жизненного
В реализации защитных функций приложения наиболее важно определить потенциальные проблемы безопасности и уязвимые места, нуждающиеся в защите. Весьма эффективным методом решения этих проблем является моделирование угроз. После профилактического моделирования реализация контрмер представляет чисто механическую задачу. Для визуализации доступа к приложениям и генерирования ситуаций вместе со списком возможных атак и контрмер можно применить инструмент Microsoft
Кроме того, на некоторых стадиях цикла разработок для проведения испытаний на проникновение целесообразно использовать программное обеспечение от независимых производителей.
Всегда проектируйте свои приложения так, чтобы они корректно работали со стандартными учетными записями. Использование учетных записей с высокими привилегиями для запуска Web-приложений считается плохим тоном программирования. Ведь Web-приложения являются непосредственными мишенями для атак, и при захвате контроля над приложением злоумышленник обычно получает такие же привилегии, с какими было запущено приложение. Вам вряд ли понравится, если хакер сразу получит привилегии Administrator или System.
Довольно часто возникают ситуации, когда для работы с различными частями приложения требуется использовать разные привилегии. Однако вы можете разделять эти части и запускать их в отдельных процессах с использованием определенного коммуникационного канала между интерфейсной частью и кодом. Данный метод является более безопасным, чем запуск целого приложения с высокими привилегиями.
Система защиты складывается не только из контрмер (то есть одной только защиты). В нее следует еше добавить механизмы для обнаружения атак и внедрить стратегию реагирования.
Обычно Web-ириложение является последней преградой между пользователями (или злоумышленниками) и внутренними ресурсами, такими, например, как корпоративная база данных. Вам следует обязательно продумать защиту внутренних систем.
Хорошим примером того, как можно подтвердить ввод данных, является работа некоторых встроенных служб ASP.NET, предназначенных для фильтрации злонамеренных данных. Однако в этом случае всегда следует применять дополнительные функции подтверждения ввода данных, а также задавать ограничения ввода в базы данных, используя типы данных, ограничения по длине и т. л.
При компиляции приложения неизвестно, какие данные будут в него вводиться. Во время работы приложение получаст данные из различных источников, в том числе от пользователей из баз данных и файлов конфигурации. Если приложение полагается на корректность функций ввода данных, вам следует обеспечить гарантии того, что ввод некорректных данных не вызовет сбоя в работе приложения независимо от источника этих данных.
Обычно разработчики основное внимание уделяют функциональности. Злоумышленники же больше интересуются состояниями ошибок.
Вспомните, сколько было протестировано в процентном соотношении обработчиков ошибок и блоков catch в вашем последнем проекте? Больше пятидесяти процентов? Очень сложно полностью протестировать каждое состояние ошибки. Тестирование элементов в комбинации с областью действия кода обеспечивает эффективный метод автоматизации испытаний и уменьшает вероятность того, что вы забудете выполнить какой-то важный тест или проверить условие.
Следует внимательно относиться к каждому проявлению ошибки и предоставлять информацию о ней пользователям. Сообщения об ошибках могут быть представлены пользователям в виде каких-то общих фраз, но для себя всегда нужно записывать в журнал подробную информацию об ошибке.
По традиции атаки DoS (
Если вы создаете приложение, которое будет инсталлироваться другими пользователями, постарайтесь протестировать настройки защиты по умолчанию. Вы должны иметь в килу, что позиция зашиты будет гораздо сильнее, если тот, кто устанавливает приложение выберет новый пароль, вместо используемого по умолчанию. Если ваше приложение содержит опциональные разделы, не инсталлируйте их по умолчанию, поскольку они могут быть не так тщательно протестированы в отличие от функциональности ядра - в таком случае они станут певыполняемыми участками программы на сервере.
Один из наиболее распространенных мифов о защите заключается в нелеших сказках о том, что криптографии гарантирует безопасность. Фраза "У нас все защищено, потому что зашифровано" у опытного взломщика может вызвать смех. Сама по себе криптография не обеспечивает зашиты — ее всегда следует использовать в комбинации с другими факторами. Например, необходимо учитывать следующее:
Брандмауэры — это средства, препятствующие проникновению в разделы
Брандмауэры могут снизить фронт атак на уровне серверов и сетей, однако не разрешают проблем, связанных с зашитой приложений.
Несмотря на то что никаких новых типов атак Web-приложений в последнее время открыто не было, настораживает сам факт возможности таких атак. Перемещение приложений из внутренних селей в Интернет всегда привлекает внимание злоумышленников, которые пытаются найти уязвимые места в коде. Поэтому следует больше уделять внимания защите таких приложений. Всегда следуйте главным принципам, перечисленным в этой главе, и применяйте их в своей работе.
Аутентификация - процеcc получения имени пользователя и пароля и проверка полученной информации (через AD, базу данных и т.п.). Если проверка прошла успешно, то пользователь относится к категории аутентифицировавшихся пользователей.
Авторизация - процесс определения того, какие права предоставлены пользователю на указанный ресурс. В итоге пользователю предоставляется доступ к указанному ресурсу или такой доступ запрещается.
В ASP.NET поддерживается три метода аутентификации:
При использовании аутентификации Windows при обращении пользователя к Web-странице Web-сервер запрашивает у него имя пользователя (с доменом) и парольный хэш. Полученная информация проверяется средствами Windows (на локальном компьютере или через контроллер домена).
При использовании аутентификации средствами Web-форм пользователю предоставляется форма, на которой он должен ввести свое имя и пароль. Полученная информация проверяется не средствами Windows, а средствами Web-приложения. Если все нормально, на компьютер пользователя передается специальная authentification cookie, которая в дальнейшем и удостоверяет права пользователя на доступ к страницам этого Web-приложения.
Работать через Microsoft
В каких ситуациях каждый режим аутентификации используется:
При использовании аутентификации Windows вам потребуется настроить аутентификацию на уровне IIS. В IIS предусмотрено четыре режима аутентификации:
Возможность зашифровать весь обмен информацией между клиентом и Web-сервером - применение SSL.
В ASP.NET предусмотрена возможность проверить, установлено защищенное соединение или нет. Для этой цели используется проверка значения свойства Request.IsSecureConnection.
Защита Web-приложения ASP.NET средствами аутентификации Windows состоит из нескольких этапов:
Web.config ;web.config.Второй пункт реализуется так: нужно открыть нужный файл web.config и вписать в раздел system.web следующую строку:
<system.web> <authentication mode="Windows" /> </system.web>
Дальше нужно настроить авторизацию, то есть указать, для какого файла или каталога кому будет открыт доступ. Для этой цели используется тег location:
<location path="default.aspx">
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location>
Если в атрибуте path будет указан каталог, то настройки распространятся на все файлы в этом каталоге и подкаталогах. Если будет указан конкретный файл (Web-форма), то настройки будут распространены только на эту Web-форму.
<deny users="?" /> означает, что запрещен доступ всем анонимным пользователям.
Чтобы разрешить доступ пользователю Mary, код может быть таким:
<authorization> <allow users="Alex" /> </authorization>
Если включить этот код в файл web.config для всего приложения, то параметры будут применены для всего Web-приложения.
В ASP.NET можно использовать имперсонацию. При применении имперсонации обращение к ресурсам идет с правами той учетной записи, которая прошла аутентификацию. По умолчанию имперсонация отключена, и обращение к ресурсам происходит от имени учетной записи ASPNET. Чтобы имперсонацию включить, можно использовать код вида
<identity impersonate="true|false"
username="username"
password="password" />
После настройки аутентификации Windows в Web-приложении при обращении к защищенной Web-странице пользователю откроется стандартное окно аутентификации, в котором пользователю необходимо ввести имя и пароль.
В коде Web-приложения вы можете получать информацию об аутентификации пользователя при помощи объекта User.Identity, например:
lblAuthUser.Text = User.Identity.Name lblAuthType.Text = User.Identity.AuthenticationType lblIsAuth.Text = User.Identity.IsAuthenticated
Теперь - про
При использовании этой аутентификации запрос пользователя все равно должен пройти через IIS (и, таким образом, отработать аутентификация Windows). Поэтому на уровне аутентификации Windows должен быть открыт доступ для анонимных пользователей. Далее работа выглядит так:
web.config и на основании этого принимается решение - пускать пользователя или нет.Как все это реализовать на практике:
Вначале обеспечиваем для Web-приложения анонимную аутентификацию средствами Windows (такой режим работает по умолчанию)
Затем прописываем в файл web.config для приложения следующий код:
<system.web>
<authentication mode="Forms">
<forms name=".namesuffix" loginUrl="login.aspx" />
</authentication>
</system.web>
То, что содержится в теге forms, относится к настройкам куки. Атрибут name - это суффикс куки, а loginURL - путь к странице аутентификации, на которую будут перенаправляться все неаутентифицировавшиеся запросы.
Далее настраивается секция авторизации в web.config (точно так же, как при аутентификации Windows).
Далее создается Web-страница codebehind кода. Об этом - ниже.
На codebehind странице для FormsAuthentification. Для него предусмотрены следующие методы:
Authentificate - этот метод принимает имя пользователя и пароль и проверяет его по указанному вами хранилищу имен и паролей;GetAuthCookie - создает authentification cookie для указанного имени пользователя. При этом куки автоматически не выдается пользователю в рамках ответа сервера - об этом нужно позаботиться отдельно;GetRedirectUrl - возвращает URL, к которому обратился неаутентифицировавшийся пользователь, прежде чем он был перенаправлен на RedirectFromLoginPage - перенаправляет пользователя на тот самый URL, к которому он обращался изначально.SetAuthCookie - то же, что и GetAuthCookie, но при этом куки автоматически выдается пользователю в рамках ответа сервера. Редирект на нужную страницу при этом не происходит.SignOut - удаляет auth cookie с пользователя (когда пользователь производит операцию sign out).Код самой
<form id="Login" method="post" runat="server">
<P>Email:
<asp:TextBox id="txtEmail" runat="server">
</asp:TextBox>
</P>
<P>Password
<asp:TextBox id="txtPassword" TextMode="password"
runat="server">
</asp:TextBox>
</P>
<P>
<asp:Button id="cmdLogin" Text="Sign In Now"
OnClick="cmdLogin_Click" runat="server">
</asp:Button>
</P>
<P>
<asp:Label id="lblInfo" runat="server">
</asp:Label>
</P>
</form>
Далее мы настраиваем код обработчика событий для единственной кнопки на этой форме.
Всю проверку выполняет у нас login, которая, если все прошло нормально, возвращает имя пользователя (непустое значение).
Необходимо помнить, что при использовании
Последняя часть нашего курса - использование аутентификации средствами Microsoft
При использовании аутентификации средствами Microsoft
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.