1. дома
  2. Вопрос и ответ
  3. Как мне защитить свой SPA и Web.API?

Как мне защитить свой SPA и Web.API?

2013-04-29 2 views
4

Я должен реализовать веб-сайт (MVC4/Single Page Application + knockout + Web.API), и я читал множество статей и форумов, но я до сих пор не могу разобраться в некоторых вопросах безопасности/аутентификации и чтобы продвигаться вперед при защите страницы входа и Web.API.Как мне защитить свой SPA и Web.API?

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

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

  1. Какой метод будет лучше для моего приложения с точки зрения безопасности: Basic/SimpleMembership? Любые другие возможности?
  2. Объект Principal/IPrincipal должен использоваться только с базовой аутентификацией?
  3. Насколько я знаю, если я использую SimpleMembership, из-за использования файлов cookie, разве это не нарушает парадигму RESTful? Итак, если я создаю REST Web.API, не следует ли мне избегать использования SimpleMembership?
  4. Я проверял ThinkTecture.IdentityModel, с жетонами. Является ли это типом аутентификации, например Basic, Forms или Auth, или это то, что можно добавить к другим типам проверки подлинности?

спасибо.

источник

2013-04-29 Scheveningen

ответ

4

Скорее всего, этот вопрос будет закрыт как слишком локализованный. Даже тогда я вложу несколько указателей. Это не ответ, но раздел комментариев слишком мал для этого.

  1. Какой метод и как вы аутентифицируете, полностью зависит от вашей подсистемы. Нет ни одного способа, который будет работать лучше всего для всех. SPA не отличается от других приложений. Вы по-прежнему будете предоставлять доступ к определенным ресурсам на основе аутентификации. Это могут быть API с настраиваемым атрибутом авторизации, может быть значением заголовка, основанным на токенах, кто знает! Что бы вы ни думали, лучше.
  2. Я предлагаю вам прочитать больше об этом, чтобы понять, как это работает.
  3. Использование файлов cookie никоим образом не указывает на то, что он разбивает REST. Вы найдете массу статей по этому конкретному предмету. Куки-файлы будут переданы с вашим запросом, точно так же, как вы передаете какую-либо конкретную информацию, необходимую серверу, чтобы она давала вам данные. Если отправка файлов cookie прерывает REST, то отправка параметров в ваш API также должна нарушать REST!
  4. Теперь очень распространенный подход (и вовсе не подход «ОДИН И ВСЕ») - это использование системы на основе токенов для SPA. Причина, по которой многие, проще всего объяснить, состоят в том, что ваши сервисы (веб-API или что-то еще) могут размещаться отдельно, а ваш клиент работает как клиент CORS. В этом случае вы проверяете подлинность в любой форме, которую вы выбираете, создаете защищенный токен и отправляете его клиенту, а каждый ресурс, который нуждается в аутентифицированном пользователе, проверяется на токене. Токен будет отправлен как часть вашего заголовка с каждым запросом. Никакой токен не приведет к простому 401 (неавторизованному) или недействительному токену может привести к 403 (Запрещено).

Никто не говорит, что SPA должен быть все статическим HTML, с привязкой данных, это может быть ваш сайт MVC, возвращающий частичные нагрузки (что-то, что я делал в прошлом). Что касается работы только с HTML и JS (Durandal конкретно), есть способы защитить даже клиентское приложение.В конечном счете, заблокируйте данные с сервера и направьте клиента на экран входа в тот момент, когда вы получаете 401/403.

Если ваша проблема связана скорее с условиями XSS или запросом ковки, есть способы предотвратить это даже с помощью только HTML и JS (хотя и не так просто, как сбросить токен анти-подделки с MVC).

Мои два цента.

источник

2013-04-29 17:07:44

+0

Sujesh, спасибо за ваш ответ. Я знаю, что SPA не отличается от любого другого приложения, я просто попытался установить сценарий, чтобы сделать его более ясным для возможных ответов. Я понимаю, что вы подразумеваете под ответом 1, но я предполагаю, что каждый способ сделать аутентификацию будет иметь преимущества/недостатки. О вашем последнем комментарии о токенах, я имел в виду использование атрибута AntiForgeryToken, и я знаю, как его использовать, но если я решит пойти на аутентификацию на основе токенов, значит ли это, что я должен отправить в мой запрос на API, два токена? (аутентификация и AntyForgery). – Scheveningen

+0

Правильно. Как правило, токен antiforgery - это не что иное, как скрытое поле с токеном, которое затем отправляется с каждой формой submit. В этом случае, если вы работаете только с HTML, вы будете явно читать токен (выпустите маркер на свой основной индекс или придумайте способ, он зависит от аутентификации), а затем отправьте его как часть ваших заголовков в вас запрос ajax. –

3

Если вы выполняете «прямую» аутентификацию - это означает, что вы можете проверить пароли напрямую - вы можете использовать базовую аутентификацию.

Я писал об этом здесь: http://leastprivilege.com/2013/04/22/web-api-security-basic-authentication-with-thinktecture-identitymodel-authenticationhandler/

Кроме того, вы можете рассмотреть возможность использования сессии маркеры, чтобы избавиться от пароля на клиенте: http://leastprivilege.com/2012/06/19/session-token-support-for-asp-net-web-api/

источник

2013-04-30 05:52:49 leastprivilege

+0

Спасибо, я сделаю это. – Scheveningen

Смежные вопросы

 Смежные вопросы