Защита REST API без необходимости изобретать велосипед

Question

Защита REST API без необходимости изобретать велосипед

75

При разработке REST API обычно используется аутентификация пользователя в первую очередь?

Типичный пример использования, который я ищу, это:

Пользователь хочет получить данные. Конечно здорово, что мы хотели бы поделиться! Получить общедоступный ключ API и прочесть!
Пользователь хочет хранить/обновлять данные... woah wait up! кто вы, можете ли вы это сделать?

Я хотел бы создать его один раз и разрешить использовать веб-приложение, приложение для Android и приложение для iPhone.

API REST представляется логичным выбором с такими требованиями, как

Чтобы проиллюстрировать мой вопрос, я буду использовать простой пример.

У меня есть элемент в базе данных, который имеет атрибут рейтинг (целое число от 1 до 5).

Если я правильно понял REST, я бы выполнил запрос GET, используя язык по своему выбору, который возвращает csv, xml или json следующим образом:

http://example.com/product/getrating/{id}/

Скажем, мы выбираем JSON, который мы возвращаем:

{
  "id": "1",
  "name": "widget1",
  "attributes": { "rating": {"type":"int", "value":4} }
}

Это отлично подходит для API, ориентированных на пользователей. Я получаю эту часть.

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

Я попытаюсь использовать другой пример, используя тот же элемент/рейтинг.

Если пользователь "JOE" хочет добавить рейтинг в элемент

Это можно сделать, используя:

http://example.com/product/addrating/{id}/{givenRating}/

В этот момент я хочу сохранить данные, говорящие, что "JOE" дал продукт {id} рейтинг {givenRating}.

Вопрос: Как узнать, что запрос пришел из "JOE" , а не "BOB".

Кроме того, что, если это было для более разумных данных, таких как номер телефона пользователя?

То, что у меня есть до сих пор:

1) Используйте встроенную функцию HTTP для аутентификации при каждом запросе, либо в обычном HTTP, либо в HTTPS.

Это означает, что каждый запрос теперь принимает форму:

https://joe:[email protected]/product/addrating/{id}/{givenRating}/

2) Используйте такой подход, как Amazon S3 с закрытым и открытым ключом: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

3) В любом случае используйте файл cookie и разбивайте аганированную часть REST.

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

Это очень похоже на использование сеанса в типичном веб-приложении и переписывание всего стека самостоятельно, что обычно для меня означает "вы делаете это неправильно", особенно при работе с безопасностью.

EDIT: Думаю, я должен был упомянуть OAuth.

jfrobishow 30 авг. 2011, в 03:23

Источник

4

Если вы отправляете имя пользователя и пароль при каждом запросе, используйте HTTPS .
Matt Ball 30 авг. 2011, в 02:51
52

Ничего общего с безопасностью, но RESTful API не будет использовать getrating и andrating ; это будет просто rating , и вы получите GOT, POST, PUT или DELETE для этого ресурса.
Duncan 31 янв. 2013, в 09:27

Теги:

security

rest

web-services

api

3 ответа

21

Не беспокойтесь о том, чтобы быть "RESTful", беспокоиться о безопасности. Вот как я это делаю:

Шаг 1: Пользователь выполняет проверку подлинности с учетными данными.

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

Шаг 3: добавьте вызов точки входа в начало каждой веб-службы script, которая проверяет идентификатор отпечатка и идентификатор сеанса для каждого запроса веб-службы.

Шаг 4: Если идентификатор отпечатка пальца и идентификатор сеанса недействительны или имеют тайм-аут, перенаправление на аутентификацию.

ПРОЧИТАЙТЕ ЭТО:

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

Daniel Pereira 30 авг. 2011, в 04:41

3

Но тогда вы не заставляете пользователя входить в систему до доступа к API каждый раз, когда заканчивается «сессия»? В случае мобильного устройства, что вы делаете? Дать им постоянный «ключ», чтобы им не приходилось входить в систему каждый раз, когда они используют приложение, используя API?
jfrobishow 30 авг. 2011, в 12:34
1

Я заставляю их войти в систему. Это либо так, либо они используют cookie, либо сопоставляют отпечаток пальца с их UDID, но вещь UDID означает, что пользователь должен получить доступ к службе с того же устройства.
Daniel Pereira 31 авг. 2011, в 05:57
0

Что касается шага 3: это означает, что если я использую инфраструктуру MVC, которая использует «Действия» внутри «Контроллеров», я должен добавить в каждое действие два дополнительных параметра (fingerprint и sessionid)?
sports 25 сен. 2014, в 01:20
0

@sports Относительно добавления функциональности в начале вызовов методов: если вы используете MVC / WebApi, перехватывайте действия с помощью OWIN. Если вы хотите разрешить что-либо через endoint, но вместо этого хотите защитить логику домена, используйте AOP, например PostSharp. Если вы катаетесь самостоятельно, просто используйте атрибуты и нарушите набор принципов, чтобы добавить функциональность в атрибуты методов, которые вы хотите защитить.
Suamere 14 июль 2015, в 12:30

Показать ещё 2 комментария

7

Редактировать 3 года спустя

Я полностью согласен с Evert, используйте OAuth2 с HTTPS и не изобретайте колесо!:-)

Более простые API REST - не предназначенные для сторонних клиентов - JSON Web Tokens могут быть хорошими.

Предыдущая версия

Использовать файл cookie в любом случае и разбить часть без сохранения состояния REST.

Не используйте сеансы, с сеансами ваша служба REST не будет хорошо масштабироваться... Здесь есть 2 состояния: состояние приложения (или состояние клиента или сеанс s) и состояние ресурса. Состояние приложения содержит данные сеанса и поддерживается клиентом REST. Состояние ресурса содержит свойства ресурса и отношения и поддерживается службой REST. Вы можете очень легко решить, является ли конкретная переменная частью состояния приложения или состояния ресурса. Если количество данных увеличивается с количеством активных сеансов, то оно относится к состоянию приложения. Так, например, идентификация пользователя текущим сеансом относится к состоянию приложения, но список пользователей или прав пользователя относится к состоянию ресурса.

Таким образом, клиент REST должен хранить коэффициенты идентификации и отправлять их с каждым запросом. Не путайте клиент REST с клиентом HTTP. Они не одинаковы. Клиент REST также может быть на стороне сервера, если он использует завиток, или он может создать, например, только HTTP файл cookie на стороне сервера, который он может предоставить службе REST через CORS. Единственное, что имеет значение для службы REST для аутентификации по каждому запросу, поэтому вам нужно отправить учетные данные (имя пользователя, пароль) с каждым запросом.

Если вы пишете клиент REST на стороне клиента, это можно сделать с помощью SSL + HTTP auth. В этом случае вы можете создать кеш credentials -> (identity, permissions) на сервере, чтобы ускорить аутентификацию. Имейте в виду, что если вы очистите этот кеш, и пользователи отправят один и тот же запрос, они получат тот же ответ, просто он займет немного больше времени. Вы можете сравнить это с сеансами: если вы очистите хранилище сеансов, тогда пользователи получат ответ status: 401 unauthorized...
Если вы пишете клиент REST на стороне сервера и отправляете идентификационные факторы службе REST через curl, у вас есть 2 варианта. Вы также можете использовать http auth, или вы можете использовать диспетчер сеанса в своем клиенте REST, но не в службе REST.
Если кто-то не доверяет, пишет ваш клиент REST, вам нужно написать приложение для аутентификации пользователей и предоставить им доступность, чтобы решить, хотят ли они предоставлять разрешения для разных клиентов или нет. Oauth - это уже существующее решение для этого. Oauth1 более безопасен, oauth2 менее безопасен, но проще, и, я думаю, есть несколько других решений для этой проблемы... Вам не нужно изобретать это. Существуют полные решения для авторизации и авторизации с использованием oauth, например: wso-сервер идентификации.

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

inf3rno 03 дек. 2013, в 14:16

1

Как это не на вершине Don't worry about being "RESTful", worry about security. ответ?
Dennis Braga 19 фев. 2014, в 17:58
0

Уже слишком поздно, и я не знаю, о чем ты говоришь, извини. : D Я прочитаю этот пост завтра, я не помню на нем ...
inf3rno 19 фев. 2014, в 22:35
2

Мне удалось прочитать пост снова. Да, я думаю, это потому, что мой пост задерживается на 2 года по сравнению с тем, который ты упомянул. Вот и все, приятного вечера! :-)
inf3rno 20 фев. 2014, в 23:29
0

Просто пытаюсь понять больше. Что вы подразумеваете под сторонним клиентом? Как JWT небезопасен для них? Благодарю.
Yaobin Then 15 нояб. 2016, в 17:32

Показать ещё 2 комментария

Ещё вопросы

Если вы отправляете имя пользователя и пароль при каждом запросе, используйте HTTPS .
Ничего общего с безопасностью, но RESTful API не будет использовать getrating и andrating ; это будет просто rating , и вы получите GOT, POST, PUT или DELETE для этого ресурса.
Но тогда вы не заставляете пользователя входить в систему до доступа к API каждый раз, когда заканчивается «сессия»? В случае мобильного устройства, что вы делаете? Дать им постоянный «ключ», чтобы им не приходилось входить в систему каждый раз, когда они используют приложение, используя API?
Я заставляю их войти в систему. Это либо так, либо они используют cookie, либо сопоставляют отпечаток пальца с их UDID, но вещь UDID означает, что пользователь должен получить доступ к службе с того же устройства.
Что касается шага 3: это означает, что если я использую инфраструктуру MVC, которая использует «Действия» внутри «Контроллеров», я должен добавить в каждое действие два дополнительных параметра (fingerprint и sessionid)?
@sports Относительно добавления функциональности в начале вызовов методов: если вы используете MVC / WebApi, перехватывайте действия с помощью OWIN. Если вы хотите разрешить что-либо через endoint, но вместо этого хотите защитить логику домена, используйте AOP, например PostSharp. Если вы катаетесь самостоятельно, просто используйте атрибуты и нарушите набор принципов, чтобы добавить функциональность в атрибуты методов, которые вы хотите защитить.
Как это не на вершине Don't worry about being "RESTful", worry about security. ответ?
Уже слишком поздно, и я не знаю, о чем ты говоришь, извини. : D Я прочитаю этот пост завтра, я не помню на нем ...
Мне удалось прочитать пост снова. Да, я думаю, это потому, что мой пост задерживается на 2 года по сравнению с тем, который ты упомянул. Вот и все, приятного вечера! :-)
Просто пытаюсь понять больше. Что вы подразумеваете под сторонним клиентом? Как JWT небезопасен для них? Благодарю.

Evert · Accepted Answer · 2011-08-30T04-37-00.000Z

Редактировать 5 лет спустя

Используйте OAuth2!

Предыдущая версия

Нет, нет необходимости использовать cookie. Это не так безопасно, как HTTP Digest, OAuth или Amazon AWS (который не сложно скопировать).

То, как вы должны смотреть на файл cookie, - это токен аутентификации, а также Basic/Digest/OAuth/какой бы он ни был, но менее подходящий.

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

Печеньки злы, перестают их использовать.

Я не считаю, что Amazon сложно копировать за слово ... как будто я не нахожу написание JavaScript с нуля "трудным", но jQuery наверняка поможет хорошо его написать. Чтение об этом заставило меня задуматься, не существует ли основы для абстрагирования этого?
Погугли это. Я написал реализацию для AWS, но я считаю, что она не завершена: code.google.com/p/sabredav/source/browse/lib/Sabre/HTTP/…
Извините, но ответ не правильный. Файлы cookie и HTTP Digest дополняют друг друга, но являются ортогональными - вы можете использовать второе для аутентификации пользователя и выдачи файла cookie. По сравнению с OAuth, защита на основе файлов cookie не будет работать, если у вас есть междоменные сервисы, или вы позволяете другим ненадежным людям писать клиент для вашей службы (участвуют третьи стороны) и хотите разрешить своим пользователям отзывать доступ к приложениям. Но в других случаях он работает точно так же, как OAuth, вы можете рассматривать cookie как токен доступа OAuth, который, кстати, вам тоже нужно где-то хранить.
Мой ответ был написан до OAuth2, когда каждый токен OAuth представлял собой дайджест информации, связанной с запросом. Это не относится к каналу-носителю OAuth2, который действительно в значительной степени сопоставляет его с токеном в Cookie.