Авторизация и защита веб-ресурсов в ASP.NET


Оглавление (нажмите, чтобы открыть):

Авторизация и защита веб-ресурсов в ASP.NET

С.Н. Фисун, доцент, канд. техн. наук,

А.И. Копылов, магистрант

Севастопольский национальный технический университет

АУТЕНТИФИКАЦИЯ И АВТОРИЗАЦИЯ В ПРИЛОЖЕНИЯХ ASP.NET

Рассматриваются способы обеспечения безопасности в Web-приложениях ASP.NET. Основное внимание уделено провайдерам аутентификации и авторизации платформы ASP.NET. С использованием этих провайдеров на языке программирования C# было разработано Web- приложение, которое реализует процесс регистрации и входа пользователей на Web-страницу.

Ключевые слова: защита информации, аутентификация, авторизация, платформа .NET.

На сегодняшний день информация имеет очень большое значение, часто утечка даже самого незначительного её количества может оказаться огромной потерей. Во избежание подобных инцидентов нужно уметь её защищать. Для этого есть множество способов и средств, начиная от обычного шифрования информации методом Цезаря (перемещение каждого символа на 3 позиции) и заканчивая максимально безопасными, но в то же время более дорогостоящими программно-аппаратными средствами, такими как карты доступа и средства биосканирования. Наряду с такими дорогими и высокотехнологичными системами безопасности существуют технологии более низкого ранга, но всё же способные обеспечить безопасность на программном уровне [1]. Среди них можно выделить криптографические сервисы .NET и Java. Данные сервисы можно рассматривать как альтернативу интерфейсу CryptoAPI корпорации Microsoft, который подробно рассматривается в работе [1]. Они позволяют использовать различные криптографические алгоритмы для шифрования данных, такие как AES, DES, 3DES, MD5, RSA и многие другие [2]. Из всех вышеназванных алгоритмов шифрования наибольший интерес для данной работы представляет алгоритм MD5, поскольку именно данный алгоритм, в большинстве случаев, применяется для шифрования паролей в процессе аутентификации и авторизации пользователей. В данной статье рассматриваются средства, которые наиболее распространены в среде ASP.NET и платформе .NET Framework. Основное внимание будет уделено таким аспектам безопасности ASP.NET как аутентификация и авторизация пользователей.

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

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

Проектируя приложение, необходимо понимать связь между аутентификацией Internet Information Services (IIS) и архитектурой защиты Microsoft® ASP.NET. Тогда вы сможете правильно аутентифицировать пользователей и получать корректный контекст защиты в приложении. Стоит обратить внимание на то, что параметры защиты ASP.NET-приложения и IIS никак не связаны между собой и могут использоваться как независимо друг от друга, так и в сочетании.

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

Взаимосвязь между IIS и ASP.NET показана на рисунке 1:

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

Рисунок 1 — Взаимосвязь средств защиты IIS и ASP.NET

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

Passport Authentication (аутентификация через Passport). Это централизованная служба аутентификации, предоставляемая Microsoft и предлагающая участвующим сайтам механизмы единой Michael Howard регистрации и подписки на сервисы. ASP.NET в сочетании с Microsoft Passport SDK предлагает пользователям Passport функциональность, аналогичную Forms Authentication;

Windows Authentication (аутентификация через Windows). Этот провайдер пользуется возможностями IIS. После того как IIS проводит аутентификацию, ASP.NET использует маркер аутентифицированной идентификации для авторизации доступа [3].

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

1. Пользователь запрашивает доступ к защищенной Web-странице.

2. Сервер проверяет, включен ли в этот запрос authentification cookie. Если да, то происходит авторизация. При этом сравнивается имя пользователя, которое включено в cookie, с параметрами авторизации в web.config и на основании этого принимается решение — пускать пользователя или нет.

3. Если authentification cookie не встроен в запрос, то ASP.NET перенаправляет пользователя на logon page (путь к нему определяется в файле конфигурации приложения). На этой странице пользователь должен ввести имя и пароль.

4. Код приложения на logon page проверяет введенное пользователем имя и пароль, и, если информация корректна, то пользователя допускают к сеансу authentification cookie (п.2). Если нет — выдается сообщение о том, что доступ запрещен.

Описанный способ аутентификации может быть представлен в виде следующей диаграммы последовательностей (рисунок 2):

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

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

Для реализации вышесказанного на практике пропишем в файл web.config для приложения следующий код:

) для проверки прав доступа вызывающего к запрашиваемому файлу или директории;

2. Другой модуль Windows аутентификации — FileAuthorizationModule (так же системный HTTP модуль) проверяет полномочия вызывающего на доступ к требуемому ресурсу. Этот модуль задействуется только в случае конфигурирования Windows аутентификации для ASP.NET приложения. Полученный от IIS маркер доступа Windows проверяется с ACL который защищает ресурс;

3. Роли .NET так же могут быть использованы (декларативно или программно) для обеспечения вызывающему необходимого доступа к запрашиваемому ресурсу или операции.

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

Основными этапами процесса авторизации пользователя в ASP.NET приложении являются следующие.

1. Уровень IIS. При выключенной Anonymous аутентификации IIS разрешает доступ только пользователям, которых он может аутентифицировать в собственном домене или в доверяемом домене. Для статических файлов (файлы, для которых нет соответствия в ISAPI расширении — например, .jpg, .gif, .htm) IIS использует NTFS разрешения, ассоциированные с запрашиваемым файлом.

2. Уровень ASP.NET.

— UrlAuthorizationModule

Примечание. Правила записи имен пользователей и групп могут зависеть от выбранной схемы аутентификации.

— FileAuthorizationModule

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

Данный класс осуществляет проверки только для запрашиваемого в процессе web запроса файла. Он не проверяет доступ к файлам, к которым обращение происходит из кода ASPX страницы (или вызываемых из нее компонент). Например, при обращении в коде ASPX страницы к gif файлу. В ACL к ASPX странице запрещается доступ определенному пользователю и gif файл не может быть получен через обращение к ASPX странице этим пользователем. Но при обращении к Gif файл напрямую через web запрос проверка будет осуществляться только IIS и, если доступ к gif файлу разрешен, запрос будет обработан успешно.

— Запросы на доступ для Principal и явные проверки на принадлежность ролям. Этот механизм обеспечивает система безопасности доступа кода — Code Access Security (CAS). Вы можете использовать запросы доступа для Principal в коде декларативно и программно как дополнительный авторизационный механизм. Проверки на доступ для Principal позволяют контролировать доступ к классам, методам или индивидуальным фрагментам кода на основе идентификации пользователя и принадлежности его к группам, что определяется IPrincipal объектом, присоединенным к текущей нити процесса. Проверки на доступ для Principal приводят к генерации исключения в случае запрещения доступа. Этим обработка таких проверок отличается от IPrincipal.IsInRole метода, просто возвращающего булево значение.

При Windows аутентификации ASP.NET автоматически присоединяет WindowsPrincipal объект, который представляет аутентифицированного пользователя, к текущему web запросу (в свойстве HttpContext.User). При Forms и Passport аутентификации создается GenericPrincipal объект с соответствующим идентифицированным пользователем (без ролей — они должны быть добавлены кодом пользователя в событии AuthenticateRequest объекта Application) и записывается в HttpContext.User [3].

Рассмотрим простейший пример конфигурирования авторизации в ASP.NET приложении. Для этого в файле web.config нужно указать для какого файла или каталога кому будет открыт доступ. Для этой цели используется тег location:

Если в атрибуте path будет указан каталог, то настройки распространятся на все файлы в этом каталоге и подкаталогах. Если будет указан конкретный файл (Web-форма), то настройки будут распространены только на эту Web-форму.

означает, что запрещен доступ всем анонимным пользователям.

Чтобы разрешить доступ пользователю User, код может быть таким:

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

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

Библиографический список использованной литературы

1. Фисун С.Н. Использование криптодрайверов для защиты информации от несанкционирован- ного доступа / С.Н. Фисун, О.И. Куржеевская / Зб. наук. праць Севастопольського військово-морського Ордена Червоної Зірки iнст. iм. П.С. Нахiмова. — Севастополь, 2008. — Вип. 2 (15) — С. 29—33.

2. Фисун С.Н. Использование криптографических сервисов .NET и Java для защиты информации от несанкционированного доступа / С.Н. Фисун, А.И. Копылов / Вестник СевНТУ. Серия Информатика, электроника, связь: сб. науч. тр. — Севастополь: СевНТУ, 2011. — Вып. 114/2011. — С. 81—86.

3. Троелсен Э. Язык программирования C# 2010 и платформа .NET 4.0 / Э. Троелсен. — М.: Вильямс, 2011. — 1392 с.

Поддержка и настройка защиты сервисов ASP.NET Web API

Посетителей: 1851 | Просмотров: 2365 (сегодня 0) Шрифт:

Для наиболее распространенного сценария — JavaScript-код в веб-странице обращается к сервису Web API на том же сайте — обсуждать защиту ASP.NET Web API, в общем-то, излишне. При условии, что вы аутентифицируете своих пользователей и авторизуете доступ к Web Forms/Views, содержащим JavaScript, который работает с вашими сервисами, можно считать, что вся необходимая защита сервисов у вас есть. Это результат того, что ASP.NET посылает файлы cookie и информацию об аутентификации, используемые для проверки запросов страниц, как часть любого JavaScript-запроса на клиентской стороне, адресованного методам вашего сервиса. Однако имеется одно важное исключение: ASP.NET не защищает вас автоматически от атак с подделкой кросс-сайтовых запросов (Cross-Site Request Forgery, CSRF/XSRF) (подробнее об этом — позже).

Помимо CSRF, существует два сценария, в которых действительно имеет смысл обсуждать защиту сервисов Web API. Первый сценарий — сервис используется клиентом, отличным от страницы того сайта, где находятся ваши ApiController. Эти клиенты не проверяются средствами аутентификации на основе форм (Forms Authentication) и не получают файлы cookie и маркеры, используемые ASP.NET для управления доступом к вашим сервисам.


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

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

Один подвох: Web API предоставляет вам несколько вариантов аутентификации и авторизации, но защита начинается либо с IIS, либо с хоста, который вы создаете при наличии резидентной среды хостинга (self hosting). Если вы, например, хотите гарантировать приватность коммуникаций между сервисом Web API и клиентом, то должны, как минимум, включить SSL. Однако это обязанность не столько разработчика, сколько администратора сайта. В этой статье я проигнорирую все, что относится к хосту, и сосредоточусь на том, что может и должен сделать разработчик для защиты сервиса Web API (средства, рассматриваемые здесь, будут работать независимо от того, включен SSL или нет).

Предотвращение атак с подделкой кросс-сайтовых запросов

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

Чтобы предотвратить атаки CSRF, вам потребуется генерировать на сервере маркеры, стойкие к подделке, и встраивать их в страницу, которая будет использоваться при вызовах с клиентской стороны. Microsoft предоставляет класс AntiForgery с методом GetToken. Этот метод генерирует маркеры, специфичные для пользователя, который выдал запрос (конечно, таковым может быть анонимный пользователь). Его код создает два маркера и помещает их в ASP.NET MVC ViewBag, откуда их можно использовать в View:

Любые JavaScript-вызовы сервера должны возвращать эти маркеры как часть запроса (у CSRF-сайта нет этих маркеров, и он не сможет вернуть их). Этот код (он находится в View) динамически генерирует JavaScript-вызов, который добавляет маркеры в заголовки запроса:

Чуть более сложное решение позволит вам использовать незаметный JavaScript-код за счет встраивания маркеров в скрытые поля в View. Первый шаг в этом процессе — добавление маркеров в словарь ViewData:

Теперь в View можно встроить данные в скрытые поля. Для генерации подходящего тега нужно просто передать методу Hidden в HtmlHelper значение ключа в ViewDate:

Конечный тег input будет использовать ключ ViewData для атрибутов name и id и помещать данные, извлеченные из словаря ViewData, в атрибут value. Тег input, сгенерированный на основе предыдущего кода, выглядел бы так:

Затем ваш JavaScript-код (который хранится в файле, отдельном от View) может получать значения из тегов input и использовать их в вызовах ajax:

Вы можете добиться тех же целей на сайте с ASP.NET Web Forms, используя метод RegisterClientScriptBlock объекта ClientScriptManager (извлекается из свойства ClientScript объекта Page), чтобы вставить JavaScript-код с помощью встраиваемых маркеров:

Наконец, вам понадобится проверять маркеры на сервере при их возврате JavaScript-вызовом. Разработчики, обновившие Visual Studio 2012 пакетом ASP.NET and Web Tools 2012.2, обнаружат, что новый шаблон SinglePage Application (SPA) включает фильтр ValidateHttpAntiForgeryToken, который можно использовать в методах Web API. В отсутствие этого фильтра вы должны получать маркеры и передавать их методу Validate класса AntiForgery (этот метод будет генерировать исключение, если маркер недопустим или был создан для другого пользователя). Код на рис. 1, используемый в методе сервиса Web API, получает маркеры из заголовков и проверяет их.

Рис. 1. Проверка CSRF-маркеров в методе сервиса

Применение ValidateHttpAntiForgeryToken (вместо кода в методе) переносит эту обработку на более ранние этапы в цикле (например, до связывания модели), что, безусловно, хорошо.

Почему нет ни слова об OAuth?

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

Кроме того, начальная версия OAuth не слишком хорошо подходит для Web API. Очевидно, что одна из основных причин появления Web API — использование «облегченных» запросов на основе REST и JSON. Эта цель делает первую версию OAuth непривлекательным вариантом для сервисов Web API. Маркеры, формируемые первой версией OAuth, слишком объемистые и основаны на XML. К счастью, в OAuth 2.0 ввели спецификацию для облегченных маркеров JSON, более компактных по сравнению с маркерами из прошлых версий. Методики, рассматриваемые в этой статье, можно было бы использовать и для обработки любых OAuth-маркеров, посылаемых сервису.

Базовая аутентификация

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

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

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

В этом примере использования HTTP-модуля я исхожу из того, что IIS использует базовую аутентификацию и удостоверения, применяемые для аутентификации пользователей, содержат имя и пароль пользователя и посылаются клиентом (в этой статье я буду игнорировать сертификацию в Windows, но рассмотрю применение клиентских сертификатов). Кроме того, я предполагаю, что сервис Web API защищается с использованием атрибута Authorize, например:

Первый шаг в создании собственного HTTP-модуля авторизации — добавление в проект сервиса класса, который реализует интерфейсы IHttpModule и IDisposable. В методе Init этого класса вы должны подключать два события от объекта HttpApplication, передаваемые методу. Метод, подключаемый к событию AuthenticateRequest, будет вызываться при получении удостоверений клиента. Но вы также должны подключить метод EndRequest, чтобы генерировать сообщение, заставляющее клиент посылать вам свои удостоверения. Кроме того, мне необходим метод Dispose, но вам не нужно ничего помещать в него для поддержки кода, используемого здесь:

Мастер Йода рекомендует:  8 методов, с которыми ты точно оценишь срок проекта

HttpClient будет посылать удостоверения в ответ на заголовок WWW-Authenticate, включаемые вами в HTTP-ответ. Вы должны включать этот заголовок, когда запрос приводит к генерации кода 401 (ASP.NET будет генерировать код ответа 401, когда доступ клиента к защищенному сервису отклоняется). Заголовок должен содержать указание на то, какой метод аутентификации используется, и область, в которой будет применяться аутентификация (областью может быть любая произвольная строка, и она используется как флаг при просмотре различных областей на сервере). Код, посылающий это сообщение, помещается в метод, подключаемый к событию EndRequest. В следующем примере генерируется сообщение, которое указывает, что используется базовая аутентификация в области PHVIS:

В методе, где вы подключились к методу AuthenticateRequest, вы должны получить заголовки Authorization, которые клиент посылает в результате приема вашего сообщения 401/WWW-Authenticate:

Определив, что клиент передал элементы заголовка Authorization (мы по-прежнему предполагаем, что сайт использует базовую аутентификацию), вы должны разобрать данные, содержащие имя и пароль пользователя. Имя и пароль кодируются по основанию Base64 и разделяются двоеточием. Следующий код извлекает имя и пароль в строковый массив:

Как демонстрирует этот код, имя и пароль передаются открытым текстом. Поэтому, если вы не включили SSL, ваши имя и пароль можно легко перехватить (этот код работает, даже если SSL включен).

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

Чтобы передать информацию идентификации по конвейеру, вы создаете объект GenericIdentity с именем идентификации, которую вы хотите назначить пользователю (в коже ниже я предполагаю, что это имя пользователя, переданное в заголовке). Создав объект GenericIdentity, вы должны поместить его в свойство CurrentPrincipal класса Thread. Кроме того, ASP.NET поддерживает второй контекст защиты в объекте HttpContext, и, если вашим хостом является IIS, вы тоже должны поддерживать его, сохраняя объект GenericIdentity в свойстве User свойства Current объекта HttpContext:

Если вам нужно поддерживать защиту на основе ролей, тогда вы должны передавать массив имен ролей как второй параметр конструктора GenericPrincipal. В этом примере каждому пользователю назначаются роли manager и admin:

Для интеграции HTTP-модуля в конвейер обработки на сайте используйте в файле web.config своего проекта тег add в элементе modules. Атрибуту type тега add должна быть присвоена строка, состоящая из полного имени класса, за которым следует имя сборки вашего модуля:

Созданный вами объект GenericIdentity будет работать с ASP.NET-атрибутом Authorize. Кроме того, вы можете обращаться к GenericIdentity из метода сервиса для выполнения операций, связанных с авторизацией. Например, вы могли бы предоставлять разные сервисы для зарегистрированных и анонимных пользователей, определяя, аутентифицирован ли данный пользователь. Для этого проверяйте свойство IsAuthenticated (IsAuthenticated возвращает false для анонимного пользователя):

Вы можете получить объект GenericIdentity более простым способом через свойство User:

Создание совместимого клиента

Чтобы работать с сервисами, защищаемыми этим модулем, клиент, отличный от JavaScript, должен предоставить правильные имя и пароль пользователя. Для передачи этих удостоверений через .NET-объект HttpClient вы сначала создаете объект HttpClientHandler и указываете в его свойстве Credentials объект NetworkCredential, содержащий имя и пароль пользователя (или устанавливаете свойство UseDefaultCredentials объекта HttpClientHandler в true, чтобы задействовать Windows-удостоверения текущего пользователя). Затем вы создаете объект HttpClient, передавая объект HttpClientHandler:

Закончив конфигурирование, вы можете отправить запрос сервису. HttpClient не предоставит удостоверения, пока доступ к сервису не будет отклонен и не будет получено сообщение WWW-Authenticate. Если удостоверения, переданные HttpClient, не принимаются, сервис возвращает HttpResponseMessage со StatusCode его Result, установленным в «unauthenticated».

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

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

Работа с клиентскими сертификатами

В HTTP-модуле вы получаете объект клиентского сертификата (и проверяете, что он допустим и вообще имеется) с помощью такого кода:

Далее по конвейеру обработки, например в методе сервиса, вы получаете объект сертификата (проверив, что он имеется) с помощью следующего кода:

Если сертификат есть и он допустим, вы можете дополнительно проверить специфические значения в свойствах сертификата (скажем, субъект или эмитент).

Чтобы передать сертификаты с HttpClient, первым делом создайте объект WebRequestHandler вместо HttpClientHandler (WebRequestHandler поддерживает больше конфигурационных параметров, чем HttpClientHandler):

Вы можете сделать так, чтобы HttpClient автоматически вел поиск в хранилищах сертификатов клиента, установив свойство ClientCertificateOptions объекта WebRequestHandler в Automatic (значение и перечисления ClientCertificateOption):

Однако по умолчанию клиент должен явно присоединять сертификаты к WebRequestHandler из кода. Вы можете получить сертификат от одного из хранилищ сертификатов клиента так, как это делается в следующем примере, где сертификат извлекается из хранилища CurrentUser по имени эмитента:

Если пользователю был отправлен клиентский сертификат, который по какой-то причине не добавляется в хранилище сертификатов этого пользователя, то вы можете создать объект X509Certificate на основе файла сертификата:

Независимо от того, как создается X509Certificate, последние операции на клиентской стороне заключаются в добавлении сертификата к набору ClientCertificates объекта WebRequestHandler и последующем использовании сконфигурированного WebRequestHandler для создания HttpClient:

Авторизация в резидентной среде

Хотя использовать HttpModule в резидентной среде (self-hosted environment) нельзя, процесс защиты запросов на ранних стадиях конвейера обработки в такой среде все тот же: получаем удостоверения из запроса, используем эту информацию для аутентификации запроса и создаем идентификацию, передаваемую в свойство CurrentPrincipal текущего потока. Простейший механизм — создать средство проверки (validator) имени и пароля пользователя. Чтобы делать нечто большее, чем проверять комбинацию имени и пароля пользователя, можно создать делегирующий обработчик (delegating handler). Для начала рассмотрим интеграцию средства проверки имени и пароля пользователя.

Чтобы создать средство проверки (по-прежнему предполагается, что вы применяете базовую аутентификацию), вы должны создать класс, производный от UserNamePasswordValidator (вам потребуется добавить в проект ссылку на библиотеку System.IdentityModel). Единственный метод базового класса, который вам нужно переопределить, — Validate, который будет передавать имя и пароль пользователя, отправленные клиентом сервису. Как и раньше, проверив имя и пароль, вы должны создать объект GenericPrincipal и использовать его для задания свойства CurrentPrincipal класса Thread (поскольку вы не используете IIS в качестве хоста, вам не нужно устанавливать свойство User объекта HttpContext):

Следующий код создает хост для контроллера Customers с конечной точкой http://phvis.com/MyServices и указывает новое средство проверки:

Обработчики сообщений

Чтобы делать нечто большее простой проверки имени и пароля пользователя, вы можете создать обработчик сообщений Web API. Такие обработчики имеют несколько преимуществ в сравнении с HTTP-модулем: 1) обработчики сообщений не привязаны к IIS, поэтому защита, применяемая в обработчике, будет работать с любым хостом, 2) обработчики сообщений используются только Web API, а значит, они обеспечивают простой способ выполнения авторизации (и назначения идентификаций) для ваших сервисов, применяющих процесс, который отличается от используемого страницами вашего веб-сайта, и 3) вы также можете назначать обработчики сообщений конкретным маршрутам (routes), чтобы ваш код защиты вызывался, только когда в этом есть реальная необходимость.

Первый шаг в создании обработчика сообщений — написание класса, производного от DelegatingHandler, переопределение его метода SendAysnc:


Внутри этого метода (я исхожу из того, что вы создаете индивидуальный обработчик для каждого маршрута) можно настроить свойство InnerHandler объекта DelegatingHandler так, чтобы этот обработчик можно было связать в один конвейер с другими обработчиками:

В этом примере я предполагаю, что корректный запрос должен иметь простой маркер в своей строке запроса (пару «имя-значения» в виде «authToken=xyx»). Если маркер отсутствует или ему не присвоено значение xyx, возвращается код состояния 403 (Forbidden).

Сначала я преобразовываю строку запроса в набор пар «имя-значение», вызывая метод GetQueryNameValuePairs объекта HttpRequestMessage, переданного методу. Затем с помощью LINQ извлекаю маркер (или null, если маркера нет). Если маркер отсутствует или недопустим, я создаю HttpResponseMessage с подходящим кодом состояния HTTP, обертываю его в объект TaskCompletionSource и возвращаю:

Если маркер присутствует и имеет правильное значение, я создаю объект GenericPrincipal и использую его для настройки свойства CurrentPrincipal класса Thread (чтобы этот обработчик сообщений мог работать и в IIS, я также задаю свойство User объекта HttpContext, если этот объект не равен null):

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

Если ваш обработчик сообщений должен использоваться в каждом контроллере, вы можете добавить его в конвейер обработки Web API, как и любой другой обработчик сообщений. Однако, чтобы ограничить ваш обработчик использованием лишь на определенных маршрутах, вы должны добавить его через метод MapHttpRoute. Сначала создайте экземпляр своего класса, а затем передайте его как пятый параметр в MapHttpRoute (приведенный ниже код требует выражения Imports/using для System.Web.Http):

Вместо того чтобы настраивать InnerHandler в DelegatingHandler, можно настроить это свойство на диспетчер по умолчанию при определении вашего маршрута:

Теперь ваш InnerHandler вместо распределения среди нескольких DelegatingHandler управляется вами из единого места, где вы определяете свои маршруты.

Расширение участника системы безопасности

Если авторизации по имени и роли недостаточно, можно расширить процесс авторизации, создав собственный класс участника системы безопасности (principal); при этом вы должны реализовать интерфейс IPrincipal. Однако, чтобы задействовать преимущества своего класса, вам придется создать пользовательский атрибут авторизации или добавить код в методы вашего сервиса.

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

Рис. 2. Создание собственного участника системы безопасности с дополнительными свойствами

Для использования преимуществ этого нового класса (который будет работать с любым хостом) достаточно создать его экземпляр, а затем с его помощью задать свойства CurrentPrincipal и User. Следующий код ищет значение в строке запроса, сопоставленное с именем «region». Получив это значение, код настраивает свойство Region участника системы безопасности и для этого передает данное значение конструктору класса:

Если вы работаете с Microsoft .NET Framework 4.5, то вместо реализации интерфейса IPrincipal вы должны наследовать от нового класса ClaimsPrincipal. Этот класс поддерживает обработку на основе заявок и интеграцию с Windows Identity Foundation (WIF). Однако этот вопрос выходит за рамки моей статьи (на эту тему мы поговорим в будущей статье, которая будет посвящена защите на основе заявок).

Авторизация собственного участника системы безопасности

Располагая новым объектом участника системы безопасности, можно создать атрибут авторизации, использующий преимущества новых данных, которые содержатся в этом объекте. Сначала создайте класс, производный от System.Web.Http.AuthorizeAttribute, и переопределите его метод IsAuthorized (этот процесс отличается от того, который принят в ASP.NET MVC, где вы создаете новые атрибуты Authorization расширением System.Web.Http.Filters.AuthorizationFilterAttribute). Методу IsAuthorized передается HttpActionContext, свойства которого можно использовать в процессе авторизации. Однако в этом примере достаточно извлечь объект участника системы безопасности из свойства CurrentPrincipal класса Thread, привести его к собственному типу участника и проверить свойство Region. Если авторизация проходит успешно, код возвращает true. В ином случае вы должны помещать в свойство Response объекта ActionContext свой ответ перед возвратом false, как показано на рис. 3.

Рис. 3. Фильтрация собственного объекта участника системы безопасности

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

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

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

Документация по создании авторизации на сайте с помощью asp.net mvc webapi?

Taras_Kovalenko: Identity то, что нужно. Если используется провайдер Microsoft.AspNet.Identity.EntityFramework то данные пишутся базу в таблички AspNet. можно внедрить свой Store (унаследоваться от UserStore) и писать куда угодно, можно пойти дальше и заменить провайдера.

Права доступа обычно раздаются Role т.е. нужно добавить использование ролей в приложение (www.dotnetfunda.com/articles/show/2898/working-wit. ). После на action или controller целиком вешается атрибут :

// GET: Requests/Create
[Authorize(Roles = «Admin, Customer»)]
public ActionResult Create()

Аутентификация в приложениях ASP.NET

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

ASP.NET исполняет web-приложения под учетной записью ASPNET. Это означает, что при выполнении задачи, не предусмотренной привилегиями пользователя (например, запись файла на диск), приложение получает отказ в доступе.
Идентификация пользователей применяется в тех случаях, когда нужно предоставить доступ к разделам web -приложения только для определенных пользователей. Это может быть Internet -магазины, форумы, закрытые разделы в корпоративных Intranet -сайтах и так далее.
Безопасность в приложениях ASP.NET основана на трех операциях:

  • Аутентификация – процесс идентификации пользователя для предоставления доступа к какому-то ресурсу приложения (разделу сайта, странице, базе данных, …). Аутентификация основана на проверке сведений о пользователе (например, имени и пароля);
  • Авторизация – процесс предоставления доступа пользователю на основе данных аутентификации;
  • Олицитворение (impersonalisation) – предоставление серверному процессу ASP.NET прав доступа клиента.

Существует три способа аутентификации пользователей в приложениях ASP.NET:

  • аутентификация Windows — применяется для идентификации и авторизации пользователей в зависимости от привилегий учетной записи пользователя. Работает аналогично обычным механизмам сетевой безопасности Windows и выполняется контроллером домена;
  • аутентификация Forms — пользователь вводит логин и пароль в Web -форме, после чего авторизация происходит по списку пользователей, хранящемуся, например, в базе данных. Применяется на большинстве Internet-сайтов при регистрации в Inernet -магазинах, форумах, пр;
  • аутентификация Passport — все пользователи имеют единое имя и пароль, используемые для сайтов, использующих данный тип авторизации. Пользователи регистрируются в службе Microsoft Passport.

Важно отметить, что аутентификация ASP.NET применяются только для web -форм (.aspx -файлы), контролов (.ascx -файды) и прочих ресурсов ASP.NET. HTML-файлы не входят в этот список. Для авторизации доступа к HTML -файлам нужно их зарегистрировать вручную!
Тип аутентификации указывается в конфигурационном файле Web.config :

По умолчанию применяется тип аутентификации Windows. Значение None имеет смысл устанавливать если используется собственная схема аутентификации или анонимный доступ (для повышения производительности).
Аутентификация Windows. Существует 4 типа аутентификации Windows : обычная ( basic ), краткая ( digest ), встроенная ( integated ) и на основе клиентских сертификатов SSL. Обычную и краткую аутентификацию применяют для идентификации имени пользователя и пароля, указываемом в диалоговом окне. Они хорошо работают в Internet , так как данные передаются по HTTP. Базовая аутентификация передает пароль и имя пользователя в кодировке Base 64, которую легко раскодировать. Для повышения безопасности можно использовать базовую аутентификацию совместно с SSL. Базовую аутентификация поддерживают большинство браузеров.
Краткая аутентификация является более безопасной, так как пароль шифруется по алгоритму MD 5. Она поддерживается браузерами Internet Explorer 5.0 и выше, либо на клиентской машине должен быть установлен. NET Framework. Кроме этого, учетные записи пользователей должны храниться в Active Directory.
Встроенная аутентификация применяется для идентификации учетных записей Windows и не может применяться в Internet , так как клиент и сервер должны пройти проверку контроллером домена. При этом пароли по сети не передаются, что увеличивает безопасность приложения. Этот тип аутентификации блокируется файрволами и работает только с Internet Explorer. Встроенная аутентификации немного медленнее, чем базовая или краткая.
Применение сертификатов SSL так же обычно применяется в Intranet , т.к. требует раздачи цифровых сертификатов. При этом типе аутентификации пользователям не нужно регистрироваться. Сертификаты можно сопоставить учетным записям пользователей в домене или Active Directory.

Для указания способа аутентификации нужно выполнить следующие действия:
1. Запустить диспетчер IIS
2. Щелкнуть правой кнопкой мыши по приложению и выбрать в контекстном меню Свойства.
3. В появившимся диалоге перейти на вкладку Безопасность каталога и нажать кнопку Изменить в разделе Анонимный доступ и проверка подлинности.

4. В диалоге Методы проверки подлинности указать тип аутентификации.

5. Указать права доступа к папке или отдельным файлам в папке Web -приложения. Обязательно нужно разрешить доступ для пользователя ASPNET.

Для поддержки URL-авторизации при Windows-аутентификации для защиты содержимого папок применяются Web.config файлы, находящиеся в этих папках. Структура файла такова (cимвол «*» означает всех пользователей):

В данном случае разрешен доступ для пользователя DENIS и запрещен доступ для всех остальных. Вместо имени пользователя может быть и название роли, к которой принадлежат пользователи – администраторы, менеджеры, …:

Если мы хотим защитить он неаутентифицированных пользователей папку полностью (например, папку, содержащую формы для администрирования сайта), то нужно разместить в ней файл Web.config с таким содержанием (cимвол «?» означает анонимных неавторизированных пользователей):

Если же мы хотим защитить только один файл (например, для подтверждения заказа в Internet -магазине), то в Web.config из корневой папки нужно добавить такие строки:

Приложение извлекает данные пользователей с помощью свойства Identity класса User. Это свойство возвращает объект, содержащий имя пользователя и роль.

bool authenticated = User.Identity.IsAuthenticated ;
string name = User.Identity.Name;
bool admin = User.IsInRole(«Admins»);

Forms-аутентификация

При использовании Forms-аутентификации запрос параметров регистрации (например, логина и пароля) происходит в web-форме. Регистрационная страница указывается в файле Web.config. При первом обращении к защищаемым страницам ASP.NET перенаправляет пользователя на страницу для ввода пароля. При успешной регистрации аутентификационные данные сохраняются в виде cookie и при повторном обращении к защищенным страницам регистрация не требуется.
Для того, чтобы использовать Forms-аутентификацию в файле Web.config в корневой папке приложения нужно указать страницу для ввода пароля:

При попытке просмотра защищенной страницы ASP.NET проверяет, есть ли аутентификационных cookie в запросе. Если cookie нет, то запрос перенаправляется на страницу для регистрации, если есть — ASP.NET дешифрует cookie и извлекает из него регистрационную информацию.

На форме находятся поля для ввода логина и пароля и флажок для сохраняемой регистрации. При нажатии кнопки «Войти» происходит поиск пользователя с таким логином и паролем. Если такой пользователь найден, вызывается функция FormsAuthentication.RedirectFromLoginPage (), в которой указывается идентификатор пользователя и флаг для сохраняемой регистрации. Если же нет – выводится сообщение об ошибке.

protected void btnLogin_Click(object sender, System.EventArgs e)
<
if (!IsValid) // проверяем правильность введенных данных
return;

OleDbConnection connection = GetDbConnection();

OleDbCommand command = new OleDbCommand(string.Format(«SELECT «, login, password), connection);

OleDbDataReader reader = command.ExecuteReader();
if (!reader.Read()) // пароль или логин неверны
<
lblError.Text = «Неверный пароль – попробуйте еще раз»;
return ;
>

string >
FormsAuthentication.RedirectFromLoginPage(id, chkbRememberLogin.Checked);
>
catch (OleDbException ex)
<
lblError.Text = «Ошибка базы данных»;
>
finally
<
connection.Close();
>
>

Аутентификации на основе ролей

Затем при каждом запросе нужно связывать учетные записи пользователей и роли. Обычно это делается в обработчике события AuthenticateRequest в файле Global.asax.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
<
HttpApplication appl = (HttpApplication)sender;

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

Параметры аутентификации

Когда сеансовый cookie возвращается в следующих после регистрации запросах, он автоматически обновляется, если время жизни истекло больше чем на половину. Время же жизни сохраняемых cookie равно 50 годам.
Можно указать имя аутентификационных cookie , поместив его в атрибут name (имя по умолчанию — ASPXAUTH ):

Мастер Йода рекомендует:  Дополнительные символы и второй заголовок в объявлениях от Яндекс.Директ


По умолчанию аутентификацонные cookie шифруются и проверяются. Уровень защиты можно указать через атрибут protection , значение по умолчанию которого All. Значение Validation предписывает только проверку cookie , а значение Encript – только шифрование. Полностью отключить защиту можно указав значение None. Отключать защиту имеет смысл если данные передаются по протоколу HTTPS.

Сброс forms-аутентификации

Сброс регистрации можно увидеть на многих сайтах. Для сброса аутентификации применяется метод FormsAuthentication.SignOut (). Он устанавливает дату окончания действия cookie на прошедшее время и cookie автоматически уничтожается.

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

Для использования Passport аутентификации в web -приложении нужно установить Passport SDK. Passport SDK предоставляется бесплатно для тестирования, но для коммерческого использования на сайте необходимо приобретать лицензию.
При обращении к приложению с Passport аутентификацией проверяется наличие cookie с данные Passport. Если такого файла нет, пользователь перенаправляется на страницу для регистрации Passport.
Для включения данного режима аутентификации в файле Web. config нужно указать следующее:

Для обязательной регистрации всех посетителей сайта в разделе autorization нужно запретить доступ неавторизированным пользователем:

Авторизация и защита веб-ресурсов в ASP.NET

Обновлен: Ноябрь 2007

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

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

Существует множество угроз безопасности и мер противодействия им, применяемых при защите приложений ASP.NET. Настоятельно рекомендуется изучить и применять инструкции и контрольные списки, представленные в статьях Improving Web Application Security: Threats and Countermeasures и Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication на веб-узле шаблонов и рекомендаций корпорации Майкрософт.

Сведения об инфраструктуре безопасности в ASP.NET и возможностях ASP.NET по проверке подлинности, авторизации и олицетворению процесса.

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

Сведения о выдаче разрешений различным пользователям для выполнения разных задач в приложении.

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

Руководство по созданию веб-приложения, которое назначает пользователям роли, ограничивающие использование веб-узла.

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

Описание использования Windows Communication Foundation (WCF) для проверки подлинности пользователей веб-узла.

Описание использования WCF для предоставления службы роли для веб-узла.

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

ASP.NET Web API своя авторизация

Добрый день! Интересует следующее. Есть готовая база данных с таблицей пользователей. Есть ли возможность, использовать эту таблицу для авторизации пользователей? Искал в интернете, везде предлагают использовать Individual Accounts, но в этом случае будут созданы таблицы самим ASP. А так как база уже в продакшене, этого не хотелось бы, а хотелось бы использовать свою таблицу.

Вообще, идя проекта такова:
есть страница, на которой пользователи смогу вводить цены товаров в магазинах (необходимо для статистики). Веб сервер с самой страницей будет находиться отдельно от севера SQL, это раз, а второе, он будет в DMZ зоне. Вот тут я и задумался, как лучше реализовать получение данных из базы. Сначала была идя писать WCF сервис, который сможет запрашивать данные от базы, а результат отображать на странице. И все изминения в базу писать через сервис. Вроде не сложно, но тоже не смог разобраться, как сделать авторизацию пользователей. До этого делал страницы для внутренней сети, в которой использовалась Windows Auth и небыло разграничений прав на странице. Как это реализовать в вебе пока не знаю.
С WCF не понятен один момент, как к нему оброщаться из ASP. (Пока были идея использовать HttpClient)
Если не сложно, то может натолкнете на идеи? Хотя бы в какю сторону смотреть!

Примечание.
01.09.2020, 14:21

ASP.NET .NET Core Web Api — почему параметры всегда null?
Что я делаю не так? using Microsoft.AspNetCore.Mvc; namespace WebApiServer.Controllers < .

Установка Angular 2.3 на ASP .Net Core Web Api
В интернете куча примеров установки ангуляра, но старых версий. Они не подходят для установки с.

Asp.net web api 2 обработка параметра как в MVC
Привет. Приходит такая строка из вне (форма). Для сути проблемы сократил лишние параметры .

ASP.NET Core + Web API. Как работает эта магия?
Собственно, чешу репу. Положил перед собой книгу Фримена, открыт сайт metanit, в закладках лежит.

ASP.NET Core Web API — не приходят данные [FromBody] Post/Put запросов
Всем привет! Столкнулся в ASP.NET Core Web API с ситуацией, когда в Action не приходят данные.

04.09.2020, 10:20 2

Полез я сейчас в изучение Angular 2 и делаю тестовый проект с авторизацией через WebApi.

Со стороны сервера все очень просто, проще подключить Identity , чем городить костыли. А в Вашем случае можно еще проще, работать не с Identity в проекте с Individual Accounts, а с авторизацией на основе куки.

С Identity станет проблема с запросами WebApi, в частности с токенами. Ну, даже если это не такая и большая проблема, то я сейчас ее решаю.

04.09.2020, 12:01 3
05.09.2020, 08:43 [ТС] 4

Вам спасибо за ответы! Буду смотреть и куки и Identity.

А что лучше использовать, WebAPI или на сервере поднимать WCF сервис и к нему обращаться с сайта? Я так понял, что WebAPI удобен когда кросплатформенные клиенты. У меня точно будет только WEB, так что может мне WebApi и не нужен вовсе?

05.09.2020, 08:43
05.09.2020, 10:19 5
07.09.2020, 12:21 6

laviritel, Используйте систему авторизации Identity — специально для этого и создана.

07.09.2020, 13:21 7
07.09.2020, 13:26 8

Кто сказал такую гадость?

freeba, Работает и очень даже прекрасно. Просто нужно уметь пользоваться.

07.09.2020, 14:05 9
07.09.2020, 14:44 10

4 класса, так например:

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

07.09.2020, 15:23 11
07.09.2020, 16:01 12

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

То что я написал выше — стандартное решение от microsoft, используемое по-умолчанию в ASP.NET MVC 5 проектах, которое годится и для WEB API 2 проектов. В стандартном решении так же есть асинхронные ф-ции, которые я не посчитал нужным показывать в примере, чтобы было меньше кода.

Где костыль-то? Если не разбираетесь в вопросе не нужно идти на провокации.


Сразу видно, что вы вообще Identity в глаза не видели

Добавлено через 12 минут

Все же опишу метод вызываемый в методах действий WEB API2:

07.09.2020, 22:18 13

Асинхронные операции тут совсем не при чем. Вы даже не поняли о чем я говорил. Попробую объяснить.

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

Тот пример что вы привели — калька с обычного ASP.NET MVC и там он будет работать (чуть-чуть допилить SessionStateProvider и система сможет работать в любом количестве воркеров на любом количестве серверов), но он слабо годится для WebApi.

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

Поэтому никто в здравом уме и не использует Identity вместе с WebApi, не дружат они, хотя при желании и их можно поженить, насильно так сказать.

Средства безопасности ASP.NET. Часть 2 — Авторизация

Первая часть статьи была посвящена аутентификации. В ней были рассмотрены теория аутентификации, разобраны все три способа аутентификации в среде .NET Framework. Во второй части статьи будет рассмотрен ещё один аспект компьютерной безопасности — авторизация. Для начала напомним, что же такое авторизация. Авторизация — это проверка прав доступа к определённому ресурсу, или проверка привилегий на выполнение определённых действий. В качестве примера можно привести ограничение прав доступа к определенным файлам. Давайте посмотрим на вопрос авторизации не глазами пользователя, а глазами программиста, который сам диктует правила игры.

Среда ASP.NET предоставляет два способа авторизации:

  1. Авторизация доступа к файлу
  2. Авторизация доступа к URL

Авторизация доступа к файлу

Суть авторизации доступа к файлу (File Authorization) заключается в настройке политики безопасности для конкретного файла в отдельности. При этом все параметры зависят от поддерживаемых средств безопасности Windows.

При авторизации доступа к файлу применяются списки контроля доступа ACL (Access Control List), в которых содержится информация о том, кому разрешён доступ к определённому ресурсу. Список контроля доступа последовательно просматривается на совпадение текущего зарегистрировавшегося пользователя с компонентами списка, если совпадений не будет, то система вернёт сообщение о том, что нет права доступа к данному ресурсу.

В связи с тем, что авторизация доступа к файлу основывается на системных механизмах ОС, при аутентификации тоже необходимо использовать аутентификацию Windows. Для этого в файле конфигурации проекта должна присутствовать следующая строка: Этот атрибут в проекте ASP.NET Web Application установлен по умолчанию, поэтому нет необходимости вручную вносить изменения в файл конфигурации.

Чтобы посмотреть, как действует этот механизм, создайте новый проект типа ASP.NET Web Application, переименуйте страницу ASP.NET в default.aspx и введите следующий код (листинг 1).

Листинг 1. default.aspx

Теперь откройте Explorer и найдите этот файл (по умолчанию он должен находиться по следующему адресу: C:\Inetpub\wwwroot\ \default.aspx). Далее щёлкните по нему правой кнопкой мыши и откройте окно свойств. Перейдите на вкладку Безопасность и добавьте в список допустимых имён группу администраторов (см. рисунок 1). Запустите Web-приложение, и если текущий пользователь является членом группы администраторов, то вы увидите дружелюбное приветствие, если же нет, то соответствующее сообщение об ошибке.

Рисунок 1. Установка авторизации доступа к файлу

Авторизация доступа к URL

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

ПРИМЕЧАНИЕ

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

Для использования авторизации доступа к URL сначала нужно настроить файл конфигурации проекта. За настройку авторизации отвечает тэг , который может содержать в себе только два типа элементов:

Каждый из этих элементов поддерживает 3 атрибута:

  • users — задаёт разделённый запятыми список имён пользователей.
  • roles — задаёт разделённый запятыми список имён пользовательских групп.
  • verbs — задаёт выражения HTTP, к которым применимы тэги и . Допустимыми значениями являются: GET, HEAD, POST и *, активизирующая все вышеперечисленные режимы.

Атрибут users поддерживает два специализированных обозначения:

  • » * » — все пользователи;
  • «?» — анонимные пользователи.

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

В вышеприведённом листинге мы сначала открыли доступ для всех, но потом закрыли его для не зарегистрировавшихся пользователей, т. е. работающих анонимно, и для всех членов группы BUILTIN\Guests . Здесь BUILTIN обозначает коллекцию встроенных ролей, поддерживаемых ASP.NET. Чтобы просмотреть их полный список, вы можете обратиться к следующему перечислению в окне ObjectBrowser Visual Studio.NET:

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

ПРИМЕЧАНИЕ

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

Рисунок 2. Отказано в доступе

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

  • path — задаёт путь к ресурсу, для которого будут применены параметры авторизации;
  • allowOverride — разрешает или запрещает (значения true или false соответственно) перекрывать параметры настройки тэга location данными из других файлов конфигурации.

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

Листинг 2. Разграничения прав доступа пользователей

В данном примере параметры авторизации проекта настроены так, что в корневом каталоге доступ разрешён всем: предполагается, что в нём находится страница регистрации, через которую должен пройти каждый ещё не зарегистрировавшийся пользователь. Следующий тэг определяет настройки безопасности для файла admin.aspx, расположенного в папке admin_zone: к нему доступ открыт лишь членам группы Administrators. Далее указываются настройки безопасности для папки user_zone, куда разрешён доступ членам групп Users и Administrators. И, наконец, последний путь — это папка guest_zone: ко всем ресурсам, содержащимся в ней, могут обратиться анонимные пользователи и пользователи, являющиеся членами двух уже ранее названных групп — Users и Administrators.

Ролевая безопасность с применением аутентификации на основе формы

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

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

Листинг 3. Web.config

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

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

Листинг 7. default.aspx

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

Заимствование полномочий



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

По умолчанию режим заимствования полномочий в среде ASP.NET отключён. Для его активизации нужно добавить в файл Web.config тэг и присвоить его атрибуту impersonate значение true. Следующий фрагмент файла конфигурации проекта демонстрирует, как это должно выглядеть:

Для демонстрации работы этого режима, используйте следующий код (листинг 8) в странице default.aspx:

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

При запуске этого приложения с отключенным заимствованием полномочий ( ) перед вами появится экран, представленный на рисунке 3. Как можно наблюдать, при отключенном заимствовании полномочий в объекте WindowsIdentity содержится идентификатор системного пользователя ASPNET.

ПРИМЕЧАНИЕ

Проследите, чтобы в этом примере анонимный доступ был запрещён

Рисунок 3. Запрещённые заимствование полномочий и анонимный доступ

Теперь, если вы активизируете заимствование полномочий, то увидите результат, представленный в таблице 1.

Таблица 1. Включенное заимствование полномочий и отключенный анонимный доступ

IsAuthenticated True
Authentication type Negotiate
Name BIGDRAGON\B@k$
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\B@k$

Как видите, результаты одинаковые, поскольку оба объекта получают информацию о текущем пользователе. Но предыдущие два примера были ориентированы на условия с запрещённым анонимным доступом для аутентификации средствами Windows. Если разрешить анонимный доступ к приложению, то объект User.Identity не вернёт никакого имени пользователя, а его свойство IsAuthenticated будет иметь значение False. В этом нет ничего удивительного, т. к. если в системе аутентификации Windows разрешён анонимный доступ, то пользователь работает анонимно, то есть не проходит аутентификацию.

ПРИМЕЧАНИЕ

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

В это же время у объекта WindowsIdentity свойство IsAuthenticated будет иметь значение True, а в качестве имени пользователя будет стоять строка следующего формата: IUSR_ , как показано в таблице 2.

Таблица 2. Заимствование полномочий и анонимный доступ разрешены

IsAuthenticated False
Authentication type
Name
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\IUSR_BIGDRAGON

Свойство name объекта WindowsIdentity имеет такое значение потому, что оно возвращает идентификатор пользователя, под которым работает процесс ASP.NET, а не пользователь Web-узла. А поскольку процесс не может работать анонимно, то он получает имя от IIS, если его невозможно получить от текущего пользователя.

Если вы были внимательны при выполнении операций по разрешению/запрету анонимного доступа, то могли заметить, что в поле Имя пользователя была как раз подставлена строка вышеуказанного формата: IUSR_ (рис. 4).

Рисунок 4. В поле Имя пользователя содержится строка, определяющая имя процесса ASP.NET при анонимном доступе

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

ПРИМЕЧАНИЕ

В атрибуте userName имя пользователя указывается вместе с именем домена

В следующем фрагменте из файла Web.config, показано, как это должно выглядеть на практике:

После запуска тестового приложения с такой конфигурацией на выполнение, состояние объекта User.Identity останется неизменным, а вот в свойстве name объекта WindowsIdentity вместо строки формата IUSR_ появится имя, указанное в атрибуте userName тэга из файла конфигурации проекта, как показано в таблице 3.

Таблица 3. Процесс ASP.NET работает от имени конкретного пользователя

IsAuthenticated False
Authentication type
Name
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\AlBa

Если вы отмените анонимный доступ, то объект User.Identity будет содержать идентификатор зарегистрированного пользователя, а в объекте WindowsIdentity по-прежнему будет оставаться имя пользователя, переданное через атрибут userName.

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

Если эта тема вас действительно заинтересовала, то вы можете найти массу материала в библиотеке MSDN:

  • Темы безопасности в рамках ASP.NET доступны в следующей ветке библиотеки MSDN: .NET Development/.NET Security;
  • По вопросам безопасности всей системы в целом следует обращаться к разделу Security/Security (General)/SDK Documentation.

Если у вас нет MSDN-библиотеки, то к её самому свежему изданию можно обратиться через интернет по адресу: http://msdn.microsoft.com/library/.

В третьей, заключительной части данной статьи, мы рассмотрим очень актуальную и интересную тему — криптографию. Кроме теории и алгоритмов криптографии мы рассмотрим с различных сторон средства шифрования, предоставляемые платформой .NET Framework, и создадим простенький метод шифрования.

Как защитить веб-приложение: основные советы, инструменты, полезные ссылки

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

Если задаться целью, уязвимость в приложении найдётся. В отчете о хакерских атаках на сайты за 2020 год эксперты Google сообщили о том, что количество взломанных ресурсов увеличилось на 32% по сравнению с 2015 годом, и это не предел. Помните об этом и отбросьте заблуждения о неприступности своих веб-ресурсов, когда планируете работы по информационной безопасности.

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

Советы по защите веб-приложения от хакеров

Используйте инструменты для анализа защищенности

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

Ниже приведена подборка бесплатных инструментов.

Приложения и фреймворки

  • OpenVAS сканирует узлы сети на наличие уязвимостей и позволяет управлять уязвимостями.
  • OWASP Xenotix XSS Exploit Framework сканирует ресурс на возможность эксплуатации XSS-уязвимостей.
  • Approof от Positive Technologies проверяет конфигурацию веб-приложения, сканирует на наличие уязвимых компонентов, незащищенных чувствительных данных и вредоносного кода.

Онлайн-сервисы

  • SecurityHeaders.io проверяет на наличие и корректность заголовков ответа сервера, отвечающих за безопасность веб-приложения.
  • Observatory by Mozilla сканирует ресурс на наличие проблем безопасности. Кроме своих результатов, при выборе соответствующей опции, собирает и добавляет к отчету аналитику со сторонних сервисов анализа защищённости.
  • One button scan сканирует на наличие уязвимостей компоненты ресурса: DNS, HTTP-заголовки, SSL, чувствительные данные, используемые сервисы.
  • CSP Evaluator проверяет правильность составления политики безопасности содержимого (CSP) и устойчивость к XSS.
  • SSL Server Test выполняет анализ SSL-конфигурации веб-сервера.
  • ASafaWeb проверяет на наличие распространённых уязвимостей конфигурации сайтов, написанных на ASP.NET.
  • Snyk сканирует JavaScript, Ruby и Java-приложения на наличие уязвимостей и, при необходимости, исправляет проблемы безопасности. Интегрируется с GitHub репозиторием для проведения автоматической проверки и оповещает о найденных уязвимостях.

Перед сканированием веб-приложения онлайн-сервисами обратите внимание на условия использования. Некоторые из них публикуют отчеты о проверенных сайтах в открытом виде.

12–13 ноября в 10:00, Санкт-Петербург, 3490–15 900 ₽

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

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


Если автоматической проверки мало, попытайтесь вручную взломать свой ресурс, изменяя значения POST и GET запросов. Здесь может помочь отладочный прокси-сервер (например, Fiddler), так как он перехватывает значения HTTP запросов между браузером и сервером. Уделите отдельное внимание формам — попробуйте обойти валидацию, чтобы внедрить XSS-инъекцию.

Если на сайте есть страницы, которые доступны только после аутентификации, попробуйте выдать себя за другого пользователя. Для этого измените параметры URL (например, ID пользователя) или значения Cookie.

Защитите пользовательские данные с помощью HTTPS

HyperText Transfer Protocol Secure (HTTPS) — расширение HTTP, которое поддерживает шифрование и защищает данные пользователей при передаче в Интернете. HTTPS гарантирует целостность и конфиденциальность взаимодействия с сервером. В марте этого года популярность HTTPS достигла переломного момента, и вскоре его использование станет «нормой», а не исключением, как это было раньше.

Используйте HTTPS, если пользователи передают на сервер личные данные: информацию о кредитной карте, персональные данные и даже адреса посещённых страниц. Если при отправке данных с формы авторизации устанавливаются cookie-файлы, которые потом отправляются при каждом запросе к серверу, злоумышленник может получить их и подделать запрос к серверу. В результате он перехватит сессию пользователя. Чтобы предотвратить это, используйте HTTPS на всех страницах сайта.

Это просто: SSL-сертификат генерируется бесплатно (например, на Let’s Encrypt), для большинства платформ созданы инструменты автоматического получения и установки сертификата. Остаётся только включить на сервере поддержку HTTPS.

Примечательно, что компания Google объявила планы о предоставлении сайтам, использующим защищённое соединение, преимущества в результатах поиска. Это пряник. Кнутом станут предупреждения о небезопасном соединении в браузерах, количество которых будет расти. HTTP уходит в прошлое, поэтому самое время перейти на HTTPS.

Если HTTPS уже настроен, хорошей практикой считается использование HTTP Strict Transport Security (HSTS) — заголовка ответа сервера, который запрещает для домена использование незащищённого соединения.

Обновляйте программное обеспечение

Это жизненно важно для безопасности веб-приложения. Хакеры регулярно обнаруживают и сразу же применяют новые уязвимости операционных систем и другого программного обеспечения: HTTP-серверов или систем управления контентом (CMS).

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

Если ресурс работает на базе движка стороннего производителя (CMS или форума), устанавливайте исправления безопасности сразу после выпуска. Большинство разработчиков информируют об обновлениях через рассылку или RSS-канал с описанием исправленных проблем. WordPress и Umbraco, кроме того, уведомляют о доступных обновлениях при входе в панель управления.

Многие разработчики используют менеджеры пакетов (например, Composer, NPM или RubyGems), чтобы устанавливать зависимые компоненты для приложений. В этих пакетах также обнаруживают уязвимости, поэтому следите за их обновлением. Чтобы автоматически получать уведомления о проблемах безопасности пакетов проекта, используйте инструменты вроде Gemnasium.

Предотвратите SQL-инъекции

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

Если злоумышленник изменит значение parameter на ‘ OR ‘1’=’1 , запрос примет следующий вид:

Так как ‘1’ равен ‘1’ , атакующий получит доступ ко всем данным таблицы. Это позволит выполнить произвольный запрос, добавив в конец выражения SQL.

Уязвимость этого запроса легко устранить с помощью параметризации. Например, для приложения, написанного с использованием PHP и MySQLi, он выглядит так:

Предотвратите межсайтовый скриптинг

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

Например, если на странице комментариев нет проверки входных данных, злоумышленник внедряет вредоносный код JavaScript. В результате у пользователей, которые просматривают комментарий, выполняется код, и данные об авторизации из cookies-файлов отправляются атакующему.

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

При проверке сосредоточьтесь на пользовательском контенте, чтобы избежать некорректной интерпретации браузером. Это похоже на защиту от SQL-инъекций. При динамической генерации HTML-кода используйте специальные функции для изменения и получения значений атрибутов (например, element.setAttribute и element.textContent ), а также шаблонизаторы, которые выполняют экранизацию специальных символов автоматически.

Политика безопасности содержимого (CSP) — ещё один инструмент защиты от XSS-атак. CSP — заголовки сервера, определяющие белый список источников, откуда разрешена загрузка данных для разных типов ресурсов. Например, запрет запуска скриптов со стороннего домена или отключение функции eval() . Благодаря политикам CSP даже при внедрении вредоносного кода в страницу его выполнение становится невозможным. На официальном сайте Mozilla размещено руководство по CSP с примерами конфигураций.

Проверяйте и шифруйте пароли

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

Что касается валидации, установите ограничение на минимальную длину пароля, а также делайте проверку на совпадение с логином, e-mail и адресом сайта.

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

Контролируйте процесс загрузки файлов

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

Даже если установлено ограничение на тип (например, только изображения), относитесь к загружаемым пользователями файлам с подозрением. Расширение или MIME-тип легко подделать, чтение заголовка или использование функций проверки размера изображения не дают 100% гарантии, в большинство форматов изображений возможно внедрить код PHP, который будет выполнен на сервере.

Чтобы это предотвратить, запретите исполнение загружаемых файлов пользователями. По умолчанию веб-серверы не пытаются выполнить файлы с расширениями изображений, но не стоит полагаться только на расширение. Известны случаи, когда файл image.jpg.php обходил эту проверку.

Способы ограничения доступа:

  • переименовывать или изменять расширения файлов при загрузке;
  • изменять разрешения, например, на chmod 0666 ;
  • создать файл .htaccess (см. пример ниже), который откроет доступ только к указанным типам файлов.

Более безопасный способ –– запретить прямой доступ к загружаемым файлам, разместив их, например, вне папки корня сайта. Однако в этом случае потребуется создать скрипт (или обработчик HTTP в .NET), чтобы извлекать файлы из закрытой части и выдавать пользователю.

Меры защиты веб-приложений для владельцев собственных серверов:

  1. Настройте межсетевой экран, в том числе на блокировку неиспользуемых портов.
  2. При наличии доступа к серверу из локальной сети создайте демилитаризованную зону (DMZ), открыв доступ из внешнего мира только к портам 80 и 443.
  3. При отсутствии доступа к серверу из локальной сети используйте защищённые методы (SFTP, SSH и др.) для передачи файлов и управления сервером извне.
  4. Если возможно, выделите отдельный сервер для баз данных, который не будет напрямую доступен из внешнего мира.
  5. Отграничьте физический доступ к серверу.

Следите за сообщениями об ошибках

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

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

Проверяйте входящие данные

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

Распределяйте права доступа к файлам

Разрешения файла (file permissions) определяют КТО и ЧТО может с ним делать.

В *nix системах у файлов 3 варианта доступа, которые представляются в виде цифр:

  • «Read» (4) — чтение содержимого файла;
  • «Write» (2) — изменение содержимого файла;
  • «Execute» (1) — выполнение программы или скрипта.

Чтобы установить множественные разрешения, достаточно сложить их числовые значения:

  • «Чтение» (4) + «запись» (2) = 6;
  • «Чтение» (4) + «запись» (2) + «выполнение» (1) = 7.

При распределении прав пользователи делятся на 3 типа:

  • «Owner» (владелец) — создатель файла (изменяем, но может быть только один);
  • «Group» (группа) — группа пользователей, которые получают разрешения;
  • «Others» (прочие) — остальные пользователи.


Установка владельцу прав доступа на чтение и запись, группе — на чтение, прочим — запрет доступа выглядит так:

Идентификация в ASP.NET

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

Базовые понятия систем безопасности

Существуют два понятия, без которых невозможно обсуждение безопасности:

  • Аутентификация (authentication) – процесс определения личности пользователя, требующий верные логин и пароль, чтобы доказать, что он на самом деле тот, за кого себя выдает.
  • Авторизация (authorization) – это процесс выставления прав пользователю, прошедшего аутентификацию.

Способы аутентификации ASP.NET

Среда ASP.NET предоставляет три способа аутентификации:

  • Windows – аутентификация на основе системы диспетчера локальной сети Windows
    NT.
  • Forms – аутентификация на основе cookies.
  • Passport – аутентификация с помощью службы Passport от
    Microsoft.

Для того, чтобы выбрать тот или иной способ аутентификации потребуется внести изменения в файл конфигурации web.config следующим образом (я выбрал метод Forms — как наиболее актуальную при разработке web-приложений):

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

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

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

Небольшие пояснения: параметр loginUrl в теге authentication указывает на страницу регистрации (по умолчанию – default.aspx), а параметр passwordFormat в теге credentials означает, что логин и пароль не зашифрованы (альтернативы – использовать алгоритмы шифрования SHA1 и MD5. О них мы поговорим позже ).

Для проверки верности логина и пароля будем использовать метод
FormsAuthentication. Authenticate(string login,string pass). А для регистрации пользователя в приложение ASP.NET путем создания cookie, и перенаправления на страницу, которая была изначально запрошена пользователем, будем использовать метод
FormsAuthentication. RedirectFromLoginPage(string login, bool CreatePersistentCookie) (второй параметр указывает на то,
каким будет посланный cookie – постоянный (срок годности
— 50 лет, значение true) или нет (false)).

Вот, собственно, и сам код страницы регистрации:

Авторизация URL с идентификаторами MVC и ASP.NET

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

Первоначально казалось, что ответ UrlAuthorizationModule. Я прочитал эту статью, Понимание авторизации URL-адреса IIS 7.0, и я могу заставить модуль работать в том смысле, что он отвечает на элементы конфигурации в web.config .

Моя текущая проблема заключается в том, что я думаю принимает правила, основанные на анонимном пользователе в IIS, а не аутентифицированный пользователь в asp.net identity.

Условия тестирования

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

  • В Visual Studio 2015 .
    • Новый веб-проект .net 4.6.2
    • Шаблон MVC
    • Аутентификация = Individual User Accounts
  • IIS 8 (для тестирования вне Visual Studio)
    • Аутентификация → Анонимная аутентификация (включена)

Добавить в web.config

Добавить в структуру папок

Наблюдаемые результаты

  • В этой конфигурации все в пути Data всегда отрицается, не имеет значения, аутентифицирован ли пользователь или нет.
  • То же самое верно, если я переключу 2 строки для Deny и Allow в web.config .
  • Если я полностью удаляю строку с помощью Deny , доступ всегда разрешается даже тогда, когда пользователь не аутентифицируется.
  • Если я добавлю роль и использую roles с именем роли вместо атрибута users , роль также полностью игнорируется.

Теперь что?

Что мне не хватает? Как я могу получить модуль Url Authorization для работы с MVC/WebAPI и asp.net identity Individual User Accounts или это просто не выполнимо?

Я также открыт для альтернативных идей, может быть, ответ заключается в написании пользовательских HttpModule или HttpHandler ?

Боковые заметки

Почему и специфика

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

[TL; DR;]
Перейдите в раздел «Полный root web.config» , чтобы увидеть необходимую настройку web.config.

Проверьте это в режиме инкогнито, чтобы предотвратить проблемы кэширования браузера! И используйте Ctrl+F5 , потому что скрипты и html файлы становятся кэшированными.

Сначала запретите доступ ко всем анонимным пользователям в корневом web.config.

Здесь web.config позволяет одной папке публично доступной. Эта папка в моем примере здесь называется css и находится в корневом каталоге приложения MVC. Для папки css я добавляю следующую авторизацию в корневой web.config:

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

Пока все остальные файлы не будут доступны, пока пользователь не войдет в систему, папка css и ее содержимое всегда будут доступны.

Я также добавил статический обработчик файлов в корневой web.config, Это очень важно, так как вы хотите, чтобы запрос управлялся конвейером asp.net для определенного типа (ов) файла

Полный корневой web.config

ASP.NET по умолчанию будет применять правила allow и deny к файлам, обрабатываемым управляемым обработчиком. Статические файлы не управляются управляемым обработчиком.

Вы также можете установить: (Не делать этого, если не нужно!)

С runAllManagedModulesForAllRequests=»true» все HTTP-модули будут выполняться на каждом запросе, а не только на управляемые запросы (например,.aspx, ashx). Это означает, что модули будут выполняться на каждом запросе .jpg,.gif,.css,.html,.pdf.

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

Если вы теперь удалите, а затем снова добавите UrlAuthorizationModule в раздел модулей, он будет работать в предварительном режиме «IntegratedMode», а не под «managedHandler» больше! И, следовательно, будет иметь доступ к статическим файлам.

Вы можете протестировать это, получив доступ к файлу script в папке сценариев успешно во время выхода из системы. Нажмите Ctrl + F5, чтобы получить новую копию файла script.

Мастер Йода рекомендует:  NewTek потеряла контроль над тремя доменами
Добавить комментарий