Asp передача контекста безопасности


Передача веб-контекста в «службу» в приложении ASP MVC

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

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

Пример того, что я хотел бы достичь:

Одна из основных проблем, которые у меня есть, это отсутствие IHttpContext, контекст .net http — это подкласс абстрактного класса, который нельзя издеваться (легко?).

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

Я мог бы сделать класс static и потребовать, чтобы Context передавался каждой функции, так как он называется i.e.

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

Я открыт для ВСЕХ предложений — особенно тех, которые знают люди, облегчает тестирование tdd. Как люди предложили бы решить эту проблему?

Вот почему были введены HttpContextBase и HttpContextWrapper. Вероятно, вы хотите использовать HttpContextBase и при передаче реального контекста, используйте new HttpContextWrapper( httpContext ) , хотя, я думаю, что то, что доступно вам в контроллере, уже имеет тип HttpContextBase. Я бы каждый раз создавал один из них в своем контроллере, вместо того чтобы пытаться ссылаться на текущий контекст из статического глобального экземпляра HttpContext.Current. Если вам это нужно в своем представлении, передайте ссылку на свой строго типизированный контекст в ViewData.

Я часто тестирую HttpContextBase в своих тестах.

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

IHttpContext — это что-то, что есть в MVC, и, похоже, один день будет в веб-формах. Надеюсь, в этот день будет .net 4

Передача контекста логического вызова из конвейера OWIN в контроллер WebApi

17 Iravanchi [2015-03-22 16:15:00]

Я пытаюсь передать контекстуальную информацию в контексте логического вызова (используя CallContext.LogicalSetData(CallContextKey, value) ) согласно сообщению Стивена Клири http://blog.stephencleary.com/2013/04/implicit-async-context-asynclocal.html; и вдохновлен кодом в https://github.com/neuecc/OwinRequestScopeContext.

Значение будет доступно через конвейер OWIN, но оно недоступно, если вызов входит в контроллер WebApi, значение не задано.

Я также заметил, что при установке контрольной точки в контроллере я не вижу конвейер OWIN в стеке вызовов. По-видимому, ASP.NET делает вызовы контроллеров в отдельном контексте вызова.

Почему (и как) ASP.NET изолирует контекст вызова от конвейера OWIN до контроллера WebApi?

Как передать контекстные данные из Pipeline в контроллер?

c# asynchronous asp.net asp.net-web-api owin

2 ответа

7 Решение Stackia [2020-04-23 16:36:00]

Мне потребовалось несколько дней, чтобы узнать, почему CallContext ясен в контроллере API, пока я не прочитал эту статью: http://www.asp.net/aspnet/overview/owin-and-katana/owin-middleware-in-the-iis-integrated-pipeline

Если два промежуточного программного обеспечения работают на разных этапах IIS, у них будет другой CallContext.

Если вы размещаете OWIN в IIS и хотите иметь тот же контекст запроса во всех средах, используйте вместо этого старый HttpContext.Current .


Я не уверен, что вы подразумеваете, передавая контекстные данные из Pipeline в контроллер, но, возможно, если вы уже используете Microsoft.AspNet.Identity, вы можете использовать использование IAppBuilder.CreatePerOwinContext, чтобы зарегистрировать ваш объект в конвейере.

Я использую что-то подобное, когда хочу передать свой контекстный объект через Owin Pipeline для контроллеров WebApi:

Asp передача контекста безопасности

340 просмотра

2 ответа

129 Репутация автора

Существует ли способ передачи защищенных данных (пользовательских данных) между двумя или более проверками безопасности в адаптере Java IBM MobileFirst Platform 8.0

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

Ответы (2)

1 плюс

1675 Репутация автора

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

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

и использовать UserLogin проверку безопасности для аутентификации пользователей.

плюса

129 Репутация автора

Модель MobileFirst, основанная на безопасности OAuth, не предлагает 1. Доступ к защищенной или пользовательской информации на основе сеансов из незащищенного или незащищенного ресурса. 2. Обеспечение безопасности и незащищенности ресурса во время выполнения.

Таким образом, есть два варианта выполнения требования 1. Простым и простым способом является создание двух адаптеров или двух методов в одном адаптере: один с включенным OAuth и один с отключенным OAuth, и пусть мобильное приложение решает, какой из них вызвать 2. Если мы хотим использовать только один Адаптер или метод только тогда, i) Адаптер или, более конкретно, метод должен быть незащищенным или защищенным только с помощью Default_Scope для MobileFirst, поскольку проверка безопасности для Default_Scope MFP проходит при запуске мобильного приложения. Ii ) Получать информацию, специфичную для пользователя, если пользователь вошел в систему из серверной системы, аналогично той, которая использовалась в тесте безопасности. Iii) Использовать информацию, специфичную для пользователя, чтобы получить данные, специфичные для пользователя.

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

Asp передача контекста безопасности

В этом разделе будут рассмотрены базовые элементы обобщенного интерфейса безопасности GSS-API.

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Если токены являются структурой, закрытой для приложений, то структура имен, употребляемых при формировании контекста безопасности (имеются в виду имена партнеров по общению), закрыта для функций GSS-API. Имена рассматриваются этими функциями просто как последовательности байт, интерпретируемые, вероятно, коммуникационными компонентами приложений.

В GSS-API предусматривается наличие трех типов имен — внутренних, печатных и объектных. Как правило, аргументами функций GSS-API служат внутренние имена. Интерфейс GSS-API предоставляет функции для преобразования имен и выполнения некоторых других действий над ними.

Илон Маск рекомендует:  Iis создание каталога публикации

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

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

Как передать context в класс ASP.NET MVC CORE

Не могу разобраться, как все таки правильно, с контроллера передавать данные из БД в класс или все таки в классе получать доступ к БД? Например: Мой класс:

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

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

1 ответ 1

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

Поскольку у вас проект asp.net core — то в Startup.cs уже настроен проброс контекста во все нужные классы.

Собственно на контроллеры будете передавать ваш класс RssFeedsRepository на конструктор, тут лучше объявить интерфейс:

PS А когда/если вам надоест писать однотипный код — используйте антипаттерн generic repository, вынеся всю однообразную логику в интерфейсы. Пример по ссылке, которую вам дал @Bulson в комментариях.

Неподскажите, какая строчка в startup отвечает за это?

Вот типовой файл, который генерирует студия:

Это проект в котором поставлена галка использовать identity, в нём уже сразу настроен доступ к базе. В строке с services.AddDbContext происходит создание контекста с дефолтным connection string.


А вот регистрацию репозиториев нужно будет настраивать — в самом простом варианте каждый вручную:

Либо регистрируя одним махом:

Либо используя ваш любимый (подставить название) DI фреймворк.

Защита ваших приложений ASP.NET

В этой статье обсуждается бета-версия Microsoft Anti-Cross Site Scripting Library (AntiXSS).

Продукты и технологии:

ASP.NET, SQL Server, Microsoft Anti-Cross Site Scripting Library

В статье рассматриваются:

  • кросс-сайтовые скрипты;
  • поддержка кросс-сайтовых запросов.

В предыдущем номере я рассказал, как важно встраивать средства защиты в веб-приложения, и рассмотрел некоторые типы атак, в том числе со встраиванием SQL-кода и модификацией параметров, а также пояснил, как предотвратить их (msdn.microsoft.com/magazine/hh580736). В этой статье мы детально обсудим еще две распространенные атаки: с использованием кросс-сайтовых скриптов (cross-site scripting, XSS) и подделкой кросс-сайтовых запросов (cross-site request forgery, CSRF).

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

Кросс-сайтовые скрипты

Что это такое? XSS — это атака, при которой в пользовательский сеанс просмотра сети вводится злонамеренный скрипт, и, как правило, пользователь об этом ничего не знает. Такие типы атак стали достаточно известны многим людям из-за инцидента, который произошел в одной крупной социальной сети. Она подверглась XSS-атаке, и от имени ее пользователей стали публиковаться сообщения без их ведома. Если атакующий отправляет злонамеренный скрипт и ему удается заставить браузер выполнить его, этот скрипт работает в контексте сеанса жертвы, фактически позволяя атакующему делать с DOM все, что угодно, в том числе выводить фальшивые диалоги входа или красть файлы cookie. При такой атаке возможна даже установка HTML-перехватчика нажатий клавиш (key logger) в текущей странице для постоянной передачи ввода из этого окна на удаленный сайт.

Результат атаки XSS используется несколькими способами, каждый из которых опирается на вывод без escape-символов или с некорректными escape-символами.

Как эксплуатируется результат этой атаки? Результат атаки XSS используется несколькими способами, каждый из которых опирается на вывод без escape-символов или с некорректными escape-символами. Давайте рассмотрим случай с приложением, которому нужно отображать пользователю простое сообщение о состоянии. Обычно это сообщение передается в строке запроса, как показано на рис. 1.

Рис. 1. Сообщение со строкой запроса

Этот прием часто используется после перенаправления (redirect), чтобы показать пользователю какое-то сообщение о состоянии, например сообщение Profile Saved на рис. 1. Сообщение считывается из строки запроса и записывается прямо на странице. Если вывод не кодируется в HTML, любой может легко встроить JavaScript-код вместо сообщения о состоянии. Этот вариант называют отраженной XSS-атакой (reflected XSS attack), так как при этом осуществляется рендеринг любого содержимого строки запроса непосредственно в странице. Злонамеренный скрипт в случае постоянной атаки сохраняется обычно в базе данных или в файле cookie.

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

На рис. 1 видно, что этот URI принимает параметр msg. Веб-страница для этого URI содержала бы, например, следующий код для простой записи этой переменной в страницу без кодирования:

Если заменить «Profile Saved» скриптом, показанным на рис. 2, в браузере будет показана функция alert из скрипта, включенного в строку запроса. Здесь эксплуатируется главным образом то, что результаты не кодируются в HTML, поэтому тег «

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

Кодирование вывода в HTML убивает эту атаку в зародыше. В табл. 1 перечислены основные варианты кодирования опасных данных.

Табл. 1. Варианты кодирования в HTML

К сожалению, в синтаксис связывания с данными пока не встроен синтаксис кодирования; такой синтаксис появится в следующей версии ASP.NET в форме . А пока используйте:


Из AntiXSS Library в пространстве имен Microsoft.Security.Application:

Эти варианты предотвращают разновидность атаки, показанной в примере, и должны использоваться в ваших приложениях.

AntiXSS Library подверглась весьма основательной переработке.

Важно знать свои элементы управления. Какие из них кодируют данные в HTML за вас, а какие — нет? Например, TextBox кодирует в HTML визуализируемый вывод, но LiteralControl этого не делает. Это важное различие. Если текстовому полю присвоить

то он выполняет корректный рендеринг текст для страницы:

Здесь на странице будет отображена JavaScript-функция alert, подтверждая уязвимость перед XSS-атаками. Устранить эту уязвимость довольно легко:

При использовании связывания с данными в Web Forms устранить уязвимость немного труднее. Посмотрите на следующий пример:

Он уязвим? Нет. Хотя кажется, что подставляемый в строку код мог бы записать скрипт или вырваться за границы кавычек, он на самом деле кодируется.

А как насчет этого:

Он уязвим? Да. Синтаксис связывания с данными не обеспечивает кодирования в HTML. Вот исправление:

Имейте в виду: если вы используете Bind в этом сценарии, вы не сможете обернуть его в Server.HtmlEncode из-за того, что «за кулисами» Bind компилируется как два раздельных вызова. Этот блок кода неправильный:

Если вы используете Bind и не присваиваете текст элементу управления, который кодирует его в HTML (например, элементу управления TextBox), подумайте о его замене на Eval, чтобы вызов можно было обернуть в Server.HtmlEncode, как в предыдущем примере.

Аналогичная ситуация со связыванием с данными и в ASP.NET MVC, где вы должны знать, кодируют ли текст вспомогательные HTML-методы (helpers). Такие методы для меток и текстовых полей выполняют кодирование в HTML. Так, следующий код:

Ранее я упоминал об AntiXSS. Текущая версия — 4.1 beta 1. AntiXSS Library подверглась весьма основательной переработке, и, что касается защиты, предоставляет более эффективный HTML-кодировщик, чем тот, который входит в состав ASP.NET. Не то чтобы с Server.HtmlEncode что-то не в порядке, но его основное предназначение — обеспечение совместимости, а не безопасности. В AntiXSS применяется другой подход к кодированию. Узнать больше можно по ссылке msdn.microsoft.com/security/aa973814.

Эта бета-версия доступна по ссылке bit.ly/gMcB5K. Пока AntiXSS не вышла за рамки бета-версии, скачивайте код и компилируйте его. Джон Гэллоуэй (Jon Galloway) опубликовал отличную статью на эту тему (bit.ly/lGpKWX).

Чтобы задействовать кодировщик AntiXSS, просто поставьте такой вызов:

В ASP.NET MVC 4 добавлена отличная новая функциональность, которая позволяет переопределять исходный ASP HTML-кодировщик и заменять его на кодировщик из AntiXSS. На момент написания этой статьи, вам нужна версия 4.1; поскольку сейчас это бета-версия, вы должны скачать код, скомпилировать его и добавить библиотеку к своему приложению как ссылку — на все это уходит пять минут. Затем добавьте в свой web.config в раздел такую строку:

Теперь любой HTML-кодированный вызов, инициированный с использованием любого синтаксиса, перечисленного в табл. 1, в том числе синтаксиса ASP.NET MVC 3 Razor, будет кодироваться библиотекой AntiXSS. Неплохо для подключаемой функциональности?

Эта библиотека также включает объект Sanitizer, который можно использовать для чистки HTML перед его сохранением в базе данных, что очень удобно, если вы предоставляете WYSIWYG-редактор, с помощью которого пользователь может редактировать HTML. Этот вызов пытается удалить скрипт из строки:

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

В ASP.NET MVC 4 добавлена отличная новая функциональность, которая позволяет переопределять исходный ASP HTML-кодировщик.

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

Что это такое? Подделка кросс-сайтовых запросов (cross-site request forgery, CSRF) (произносится как «sea-surf») — атака, при которой некто использует отношения доверия между вашим браузером и неким веб-сайтом для выполнения команды в сеансе невинного пользователя. Эта атака немного сложнее в понимании без знания деталей, поэтому перейдем сразу к ним.

Как эксплуатируется результат этой атаки? Допустим, Джон аутентифицируется как администратор на сайте PureShoppingHeaven. Этот сайт имеет URL, доступный только администратору, и на него можно передавать информацию для выполнения какой-либо операции, например создания нового пользователя, как показано на рис. 6.


Рис. 6. Передача информации на URL

Если атакующий сможет одним из множества методов заставить Джона запросить этот URL, его браузер запросит данный URL от сервера и отправит на него любую аутентификационную информацию, которая может быть кеширована браузером Джона или использоваться им, например аутентификационные cookie или другие аутентификационные маркеры, в том числе от Windows Authentication.

Это простой пример, но CSRF-атаки могут быть куда более изощренными и могут включать команды POST для форм в дополнение к запросам GET, а также одновременно использовать другие атаки вроде XSS.

Так задумано, что браузер будет отправлять любые корректные cookie или аутентификационную информацию.

Предположим, Джон посещает уязвимую социальную сеть, сайт которой эксплуатируется злоумышленниками. Возможно, атакующий разместил немного JavaScript-кода на странице, задействовав уязвимость к XSS-атаке, и теперь она запрашивает URL-адрес AddUser.aspx в сеансе Джона. Следующий дамп утилиты Fiddler (fiddler2.com) после посещения Джоном той веб-страницы показывает, что браузер также передал модифицированный аутентификационный cookie (custom site-authentication cookie):

Все это происходит без ведома Джона. Важно понимать: так задумано, что браузер будет отправлять любые корректные cookie или аутентификационную информацию. Вы когда-нибудь замечали, что ваш почтовый клиент, как правило, не загружает изображения по умолчанию? Одна из причин этого — предотвращение CSRF. Если вы получаете HTML-сообщение электронной почты со встроенным тегом image, как показано ниже, то данный URL будет запрошен и сервер выполнит соответствующую операцию при условии, что вы аутентифицированы на том веб-сайте:

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

Как предотвратить CSRF? Чтобы предотвратить CSRF, начните со следующих правил.

  1. Убедитесь, что запрос нельзя воспроизвести простым щелчком ссылки, вызывающей запрос GET. В спецификации HTTP запросы GET предназначены только для получения информации, но не изменения состояния.
  2. Убедитесь, что запрос нельзя воспроизвести, если атакующий использует JavaScript-код для имитации запроса POST формы..
  3. Блокируйте любые операции через GET. Например, не разрешайте создания или удаления записей через URL. В идеале, эти операции должны требовать какого-то взаимодействия с пользователем. Хотя это не предотвратит более изощренные атаки на основе форм, это все же ограничит большое количество атак попроще вроде показанной на примере с тегом image в сообщении электронной почты, а также основанных на использовании базовых ссылок, встроенных на сайты, которые скомпрометированы в результате XSS-атаки.

Предотвращение атак через Web Forms реализуется несколько иначе, чем для ASP.NET MVC. В случае Web Forms можно подписать атрибут MAC для ViewState, что помогает защищаться от подделок, пока вы не устанавливаете EnableViewStateMac в false. Кроме того, стоит подписывать ваш ViewState с использованием текущего сеанса и предотвращать передачу ViewState в строке запроса, чтобы блокировать то, что некоторые называют атакой с одним щелчком (one-click attack) (рис. 7).

Рис. 7. Предотвращение атаки с одним щелчком

Безопасность приложений ASP.NET

Общие вопросы безопасности веб-приложений и виды угроз

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

К основным, наиболее популярным видам угроз относятся:

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

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

DoS-атака (denial of service, отказ в обслуживании) – это вид атаки на приложение , при котором генерирует большое число одновременных запросов к приложению. Цель этой атаки вывести приложение из работоспособного состояния (или существенно снизить производительность ).

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Краткие итоги

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

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

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

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

ASP.NET (либо MVC, либо Web Forms)
Web Forms (синтаксис ASP.NET 4)
ASP.NET MVC 3 Razor @message
Связывание с данными
Более эффективное кодирование
Аутентификация. Этот уровень безопасности отвечает за определение текущего пользователя и отвечает на вопрос «Кто работает с приложением?»;
Авторизация. Этот уровень безопасности отвечает за определение полномочий текущего пользователя и отвечает на вопрос «Какие операции данный пользователь может выполнять?»;
Конфиденциальность. Этот уровень безопасности отвечает за то, чтобы данные, передаваемые от сервера клиенту, не были прочитаны третьими лицами. Обычно этот уровень реализуется за счет применения шифрования канала с использованием протокола HTTPS;
Целостность. Этот уровень безопасности отвечает за то, чтобы данные передаваемые от клиента серверу не были подменены третьими лицами. Обычно этот уровень реализуется за счет использования цифровых подписей.

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

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

  • аутентификация формами;
  • аутентификация Windows;
  • аутентификация с помощью паспортов;

  • специализированным механизмом аутентификации.

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

Аутентификация Windows позволяет определить пользователя на основе корпоративной политики. Например, в качестве хранилища информации о пользователях может быть Active Directory .

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

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

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

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

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

В этом примере атрибут » passwordFormat » секции » credentials » определяет способ хранения пароля. Значение » clear » указывает на то, что пароль хранится в открытом виде. Кроме этого, пароль можно хранить в виде хэша MD5 или SHA1.

После задания всех настроек можно воспользоваться механизмом аутентификации формами. Для этого необходимо воспользоваться классом FormsAuthentication и его статическими методами Authenticate , SignOut , RedirectFromLoginPage и RedirectToLoginPage . Таким образом, программный код для выполнения входа в систему может выглядеть следующим образом.

Теперь, на каждой странице становится возможным проверить выполнен ли вход в систему и, если выполнен, то кем. Для этого можно воспользоваться свойствами IsAuthenticated и Name объекта IIdentity , доступ к которому можно получить, используя текущий контекст — HttpContext.Current.User.Identity .

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

Именно поэтому в ASP . NET существует механизм Membership API . По сути, Membership API – это интерфейс , который позволяет:

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

Таким образом, Membership API – это интерфейс для реализации различных поставщиков для хранения информации о пользователях. Такое абстрагирование на уровне интерфейса позволяет быть независимым от конкретной реализации поставщика и одинаково работать, например, с поставщиком на основе базы данных или Active Directory . ASP . NET включает ряд готовых поставщиков для SQL Server и Active Directory . Это позволяет хранить данные о пользователях и ролях в SQL Server или в Active Directory . Кроме того, можно разработать собственный поставщик, который в качестве хранилища будет использовать другой источник (например, файл на жестком диске). Для этого необходимо создать класс -наследник MembershipProv >System.Web.Security » и указать его в конфигурационном файле.

Для того, чтобы использовать Membership API в своих приложениях необходимо выполнить несколько шагов:

  • сконфигурировать аутентификацию формами в конфигурационном файле;
  • настроить хранилище данных для Membership API и указать его в конфигурационном файле;
  • создать пользователей в хранилище данных;

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

Наиболее часто в качестве хранилища данных используется база данных на основе SQL Server . Для SQL Server разработана готовая схема данных, которая позволяет хранить пользователей, пароли, роли и т.д. Для того чтобы создать подобную схему данных в вашей БД необходимо воспользоваться утилитой aspnet_regsql , которая расположена в папке «C:\Windows\Microsoft.NET\Framework\v2.0.50727«. Эта утилита поддерживает два режима работы – консольный и графический. Для запуска утилиты в консольном режиме необходимо указать параметры:

В этой команде указывается имя сервера » (local) » и имя базы данных » MyDB «. Кроме того, можно запустить эту утилиту без параметров, тогда она будет работать в графическом режиме. В этом случае необходимо указать мастеру нужные параметры, после чего будет создана нужная схема данных.

Для создания указанной схемы данных необязательно пользоваться утилитой aspnet_regsql . В папке «C:\Windows\Microsoft.NET\Framework\v2.0.50727» расположены скрипты для SQL Server , которые позволяют создать или удалить эту схему данных. Поэтому для создания базы данных можно вручную запустить эти SQL -скрипты. Список файлов для создания и удаления схемы:

  • InstallCommon.sql
  • InstallMembership.sql
  • InstallPersistSqlState.sql
  • InstallPersonalization.sql
  • InstallProfile.SQL
  • InstallRoles.sql
  • InstallSqlState.sql
  • InstallSqlStateTemplate.sql
  • InstallWebEventSqlProv >

После создания схемы данных необходимо сконфигурировать провайдер Membership API . Для этого в секции » system.web » необходимо создать секцию » membership «, внутри которой указать нужных провайдеров. Кроме того, в атрибуте » defaultProvider » секции » membership » необходимо задать имя текущего провайдера. Таким образом, конфигурационный файл может выглядеть следующим образом.

Как видно, при добавлении нового поставщика задается его имя, тип и строка соединения с базой данных, которая задается в секции » connectionStrings «.

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

После выполнения аутентификации следует процесс авторизации. Сам процесс авторизации может поддерживаться на двух уровнях:

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

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

Краткие итоги

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

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

Контексты безопасности (Security Associations) образуют основу криптографических сервисов безопасности на базе протоколов IPsec. Для защиты двусторонней связи между узлами сети необходимы два контекста безопасности: один — для входящих потоков, другой — для исходящих. Контексты безопасности содержат информацию об IP-адресах, типе защитного протокола ( AH или ESP ), криптографических алгоритмах, ключах для аутентификации и шифрования и периоде их действия.

Контекст безопасности уникально идентифицируется тремя элементами:

* индексом параметров безопасности ( Security Parameters Index — SPI );

* целевым IP-адресом;

* идентификатором защитного протокола.

Итак, индекс SPI — это идентификатор контекста безопасности, который указывается в протоколе AH или ESP. Целевой IP-адрес идентифицирует соединение IPsec, он может быть индивидуальным или групповым адресом либо диапазоном адресов. В настоящее время обмен ключами IKE реализован только для индивидуальных адресов, а для групповых адресов или диапазонов распределение ключей выполняется вручную.

| | Хост | Маршрутизатор или межсетевой экран |

|Хост | Транспортный режим или туннельный режим | Туннельный режим |

|Маршрутизатор или межсетевой экран | Туннельный режим | Туннельный режим |

Таблица 17.1.Режимы, используемые для разных типов соединений

Протоколы обеспечения аутентичности и конфиденциальности могут применяться в двух режимах: транспортном и туннельном. Обычно транспортный режим используется хостами, при этом защищается только содержимое IP-пакетов и опционально — некоторые поля заголовков. В туннельном режиме защищается весь пакет: он инкапсулируется в другой IP-пакет, при этом происходит как бы «обертывание», или заключение в конверт, передаваемой порции данных см. рис. 17.1).

Рис. 17.1. Стеки протоколов в разных режимах

В транспортном режиме заголовок протокола ( AH или ESP ) располагается в стеке протоколов после заголовка исходного IP-пакета и перед заголовками протоколов более высокого уровня см. рис. 17.1).

Как разрешить контекст текущей базы данных EF7 в ASP NET 5 из контроллера?

Вопрос

Я хочу получить один контекст для каждого запроса в приложении ASP NET 5 / EF 7, чтобы использовать его в некоторых методах (не в контроллере).

К сожалению, я не нашел ответа в шаблоне ASP.NET vNext документации и примерах aspnet / MusicStore

Принятый ответ

Вы можете использовать некоторые методы для достижения этой цели.

Добавьте свой dbContext в качестве параметра метода конструктора вашего класса (в котором вы будете использовать dbContext). Затем вам нужно получить этот класс, используя систему Injection Dependency, например, добавив его в качестве параметра конструктора контроллера.

Но если вы не хотите использовать инъекцию конструктора для получения контекста, вы можете получить необходимые зависимости с помощью GetService() (но вам нужно, чтобы в экземпляре ServiceProvider для этого, в примере ниже, я также получил его через инъекцию конструктора).

В первом методе мы можем получить HabitService помощью GetService() (не через инъекцию конструктора).

Спасибо Tseng за замечание:

Я должен отметить, что довольно плохая практика — ввести контейнер в свои объекты. Контейнер должен ссылаться только от корня состава и определенного типа фабрик (которые реализуются на уровне приложений, а не в домене / бизнес-уровне)

dbContext в HabitsController и _dbContext в HabitService — это разные контексты!

Как правильно созвать контекст EF в конроллере asp.net?

Всем добрый день!

Открывать контекст EF в методе действия контроллера — плохая практика. Плохая потому что:
1. это не соответствует трехуровневой архитектуре, а следовательно, значительно усложняет внесение изменений, масштабирование и сопровождение приложения;
2. это сразу показывает низкий уровень понимания шаблона MVC — могут даже на работу не взять;
3. EF — это модель. А контроллер по сути своей должен лишь получить данные (модель) и передать их в представление. То, каким образом формируются данные (EF, NHibernate, XML, Files, . ) — контроллер не должно волновать. Он лишь организовывает данные, чтобы передать их в представление. Часто модель разделяют на непосредственно модель и модель представления (аналог шаблона MVVM). Контроллер получает данные (модель), из них формирует модель представления и её передает в само представление. Зачем это надо — уже другой вопрос.

Далее — позволю себе не согласиться с инициализацией контекста EF на весь контроллер — можно, конечно, но это, опять-таки, плохая практика, потому что:
1. возникнут проблемы с использованием многопоточности и параллельных вычислений при работе с контекстом (библиотека TPL);
2. возникнет проблема «устаревания» данных — т.к. контекст создан на контроллер, то придется постоянно его обновлять;
3. это, опять же, показывает уровень и опыт разработчика, а следовательно, снижаются шансы при трудоустройстве (туда, где я сейчас работаю — точно не взяли бы программистов, которые практикуют формирование модели в контроллере или которые инициализируют контекст в контроллере или при запросе).

Итог: контекст EF должен существовать как можно меньшее время — ровно столько, чтобы получить данные, обработать их, сформировать из них, например, другие объекты (обертки, модели, модели представлений).

Читайте книгу «ASP.NET MVC 3/4/. Framework с примерами на C# для профессионалов» Адама Фримена и Стивена Сандерсона — там, можно сказать, приведены best practices по разработке в ASP.NET MVC с использованием EF.

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

Илон Маск рекомендует:  Формирование карты сайта для сайта с регионами на поддоменах
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL