Рекомендации по защите REST API / веб-службы [закрыто]

При разработке REST API или службы существуют ли лучшие рекомендации по работе с безопасностью (аутентификация, авторизация, управление идентификацией)?

При создании SOAP API у вас есть WS-Security в качестве руководства, и существует много литературы по этой теме. Я нашел меньше информации о защите конечных точек REST.

Хотя я понимаю, что REST намеренно не имеет спецификаций, аналогичных WS- *, я надеюсь, что появились лучшие практики или рекомендуемые шаблоны.

Любая дискуссия или ссылки на соответствующие документы будут очень благодарны. Если это имеет значение, мы будем использовать WCF с сериализованными сообщениями POX / JSON для наших REST API / Services, созданных с использованием v3.5 .NET Framework.

11.08.2008 05:44:42
Знаете ли вы какое-нибудь полноценное реальное приложение, использующее хорошие шаблоны и практики с REST API и веб-сервисами в github?
PreguntonCojoneroCabrón 6.02.2016 20:15:29
18 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

298
11.08.2008 08:45:13
SSL является важной частью безопасности, но не все приложения требуют такого уровня шифрования. Если кто-то ворует транзитом то, что вы собираетесь опубликовать в Твиттере, это такой существенный недостаток? Для большинства API шифрование SSL будет предпочтительным. Требования SSL к инфраструктуре несколько выше, чем для открытого текста, и никакие промежуточные (читай здесь краевые) серверы кэширования не могут участвовать в кэшировании многократно доступного контента. Помните, что ваша масштабируемость может пострадать, если вам абсолютно необходимо предлагаемое шифрование.
Norman H 1.01.2013 22:19:39
@NormanH: Ваш аргумент является показным, потому что если кто-то сможет увидеть всю транзакцию, которую я использую для публикации в Твиттере, то он может выдать себя за меня и опубликовать свои собственные сообщения под моим именем.
Greg Hewgill 2.01.2013 00:51:14
Цитируя википедию о дайджест-аутентификации: «Дайджест-аутентификация с доступом является одним из согласованных методов, которые веб-сервер может использовать для согласования учетных данных с веб-браузером пользователя. Он применяет хеш-функцию к паролю перед его отправкой по сети, которая безопаснее, чем обычная аутентификация доступа, которая отправляет открытый текст. что будет одним из стандартных способов выполнения того, что я упоминал выше. (Подробнее см. En.wikipedia.org/wiki/Digest_access_authentication )
Norman H 2.01.2013 18:45:00
"sending plaintext passwords over the net is almost universally a bad thing"- Можете ли вы уточнить на «почти»? Когда это не плохая идея?
toniedzwiedz 29.05.2014 05:23:59
@GregHewgill даже в частной сети, я бы не хотел, чтобы мои пользователи могли перехватывать пароли друг друга. Единственная ситуация, в которой я могу себе представить, - это нормально отправлять пароль по сети, когда пользователь один в сети. Тот факт, что такие вещи происходят где-то в другом месте, вряд ли является причиной для этого.
toniedzwiedz 29.05.2014 08:53:11

Для REST нет никаких стандартов, кроме HTTP. Там созданы службы REST. Я предлагаю вам взглянуть на них и почувствовать, как они работают.

Например, мы заимствовали много идей из сервиса Amazon S3 REST при разработке собственной. Но мы решили не использовать более продвинутую модель безопасности, основанную на сигнатурах запросов. Более простой подход - HTTP Basic auth over SSL. Вы должны решить, что лучше всего работает в вашей ситуации.

Кроме того, я настоятельно рекомендую книгу RESTful Web Services от O'reilly. Он объясняет основные концепции и предоставляет некоторые передовые практики. Обычно вы можете взять модель, которую они предоставляют, и сопоставить ее с вашим собственным приложением.

115
1.11.2010 13:47:00
RESTful Web Services, безусловно, отличная книга. Необходимо прочитать в этой области. Это было совершенно вдохновляюще.
EdgarVerona 9.01.2009 21:34:22
Как получилось, что @aehlke получил так много голосов за этот комментарий, учитывая, что (1) нет такой вещи, как спецификация REST и (2) в Защитной диссертации по архитектурным стилям и проектированию сетевых программных архитектур явно упоминается REST и HTTP в 6.3: REST применяется к HTTP.
user4903 15.04.2012 00:37:02
HTTP не является обязательным требованием для REST.
nategood 16.05.2013 19:21:07
Книгу RESTful Web Services можно бесплатно получить на их веб-сайте: crummy.com/writing/RESTful-Web-Services
icc97 5.06.2018 15:08:01
Я планировал прочитать книгу, а затем понял, что она в основном предназначена для формата XML. Должен ли я использовать эту книгу, учитывая популярность JSON? Или это не зависит от формата обмена данными. Нужно руководство.
Bhargav Jhaveri 14.07.2018 00:43:04

Спасибо за отличный совет. Мы закончили тем, что использовали собственный HTTP-заголовок для передачи токена идентификации от клиента сервису, в процессе подготовки к интеграции нашего RESTful API с будущей платформой Zermatt Identity от Microsoft. Я описал проблему здесь и наше решение здесь . Я также воспользовался советом tweakt и купил RESTful Web Services - очень хорошую книгу, если вы создаете RESTful API любого рода.

15
23.05.2017 11:54:41
Этот подход звучит подозрительно для меня. Что мешает злоумышленнику использовать маркер идентификации для маскировки клиента? HTTPS не защищает URL или заголовки в прошлый раз, когда я проверял ...
Gili 3.10.2008 18:10:14
Хм ... не уверен, что ты прав насчет этого. Я считаю, что за исключением нескольких заголовков, необходимых для понимания того, какой тип шифрования требуется, все остальные заголовки шифруются.
Nathan 29.10.2008 23:23:50
Это не правильно. HTTPS защищает ВСЕ. Идет: TCP handshake ... TLS handshake ... <ENCRYPTED> GET / foo 200 OK ... teardown </ ENCRYPTED>.
Mark Renouf 4.02.2009 13:31:41
Обратите внимание, что вы также можете передать токен как cookie (вместо пользовательского заголовка). Это хорошо работает в браузерах, так как использует заголовок HTTP со стандартным поведением в большинстве наборов инструментов и приложений. Что касается обслуживания, куки не должны относиться к сеансу, вы можете использовать их для передачи любого токена, который вы пожелаете.
Bruce Alderson 10.11.2011 19:51:55
Wayback Machine - прекрасная вещь: описание проблемы и решение
cjc343 23.10.2012 20:03:53

Возможно, вы также захотите взглянуть на OAuth , новый открытый протокол для авторизации на основе токенов, специально предназначенный для http apis.

Это очень похоже на подход, принятый flickr, и помните, что apis молока "rest" (не обязательно хорошие примеры успокоительного apis, но хорошие примеры подхода, основанного на токене).

72
18.09.2008 02:55:07
Но, похоже, что двуногий oAuth, который, как мне кажется, здесь нужен, не покрывается (недостатком информации) так же, как трехногий.
redben 11.11.2010 00:04:49
OAuth - это делегирование авторизации, т.е. я владелец информации / учетной записи, позволяющей сервису A взаимодействовать с моими данными в сервисе B (например, я позволил Твиттеру писать на моем фейсбуке). Это не авторизация в более широком смысле, которая касается контроля того, что пользователи могут делать с ресурсами (данными, информацией, услугами ...). Вот где вступает XACML. XACML позволяет вам определять политики авторизации о том, кто что может делать.
David Brossard 24.09.2013 22:15:48

Один из лучших постов, которые я когда-либо встречал, касающийся безопасности, поскольку он касается REST, закончился на 1 RainDrop . MySpace API использует OAuth также для обеспечения безопасности, и у вас есть полный доступ к их пользовательским каналам в коде RestChess, с которым я провел много исследований. Это было demo'd на Mix, и вы можете найти пост здесь .

17
18.09.2008 20:53:16
Спасибо за ссылку (1 RainDrop) - очень интересное обсуждение безопасности в части, касающейся SOAP v REST
Nathan 13.10.2008 23:07:23

Я использовал OAuth несколько раз, а также использовал некоторые другие методы (BASIC / DIGEST). Я искренне предлагаю OAuth. Следующая ссылка - лучший учебник, который я видел по использованию OAuth:

http://hueniverse.com/oauth/guide/

25
30.03.2016 08:31:53
Хотя это очень старый ответ, касающийся OAuth 1.0, стоит отметить, что автор ссылки, которую вы цитируете , сказал об OAuth 2.0 следующее : «Я пришел к выводу, что OAuth 2.0 является плохим протоколом ... По сравнению с OAuth 1.0, спецификация 2.0 является более сложной, менее функциональной, менее полезной, более неполной и, что наиболее важно, менее безопасной ". , Чтобы было ясно, комментарий, который я цитирую, был сделан через несколько лет после того, как вы опубликовали свой ответ.
skomisa 22.01.2019 20:29:43

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

43
25.09.2009 19:39:38
На самом деле мы используем это для некоторых интеграций, а также для зашифрованных туннелей vpn для поддержки старых систем, которые мы не контролируем и которые не могут обмениваться данными через https.
Casey 5.09.2012 13:55:35
Клиентские сертификаты могут создавать проблемы, когда вам требуется балансировка нагрузки ... это можно сделать, но это не так просто.
Jeremy Logan 15.10.2012 18:11:41
@fiXedd - Мой опыт работы с клиентскими сертификатами был противоположным, потому что они действительно не имеют статуса. Соединения, прошедшие проверку подлинности с помощью сертификата клиента, могут быть сбалансированы по нагрузке с помощью простого балансировщика нагрузки без учета залипания соединений, поскольку они требуют абсолютно нулевого общего состояния между клиентом и сервером.
stinkymatt 15.10.2012 19:25:10
О, вы можете сделать это .... вы можете просто настроить балансировщик нагрузки для пересылки трафика TCP, но вы не можете, например, использовать балансировщик нагрузки в качестве точки завершения для SSL.
Jeremy Logan 19.10.2012 16:12:26
Все еще безопасно, если клиентские сертификаты и его корневые полномочия являются самозаверяющими? Корневой центр будет импортирован в доверенные корневые центры сертификации клиента.
Joyce 18.03.2015 17:17:59

Я много искал о безопасности restful ws, и мы также использовали токен через cookie от клиента к серверу для аутентификации запросов. Я использовал Spring Security для авторизации запросов в сервисе, потому что мне приходилось аутентифицировать и авторизовать каждый запрос на основе указанных политик безопасности, которые уже были в БД.

6
15.05.2012 10:36:28

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

4
24.11.2012 09:09:29

Я бы порекомендовал OAuth 2/3. Вы можете найти больше информации на http://oauth.net/2/

7
14.03.2013 00:59:38
Не могли бы вы уточнить, почему вы бы порекомендовали версию 2, когда она остается в основном неполной? ИМХО, версия 1.0a остается солидным решением для большинства приложений.
Butifarra 20.03.2013 22:57:37

Каждый в этих ответах упустил из виду истинный контроль доступа / авторизацию.

Если, например, ваши API-интерфейсы REST / веб-службы предназначены для публикации / получения медицинских карт, вы можете определить политику контроля доступа о том, кто может получить доступ к данным и при каких обстоятельствах. Например:

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

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

Другие стандарты здесь для следующего:

  • OAuth: идентификатор федерация и делегирование полномочий, например, разрешение службе действовать от моего имени в другой службе (Facebook может публиковать в моем Twitter)
  • SAML: федерация идентификации / веб-служба единого входа. SAML очень много о том, кто пользователь.
  • Стандарты WS-Security / WS- *: они фокусируются на связи между сервисами SOAP. Они специфичны для формата обмена сообщениями на уровне приложений (SOAP) и имеют дело с такими аспектами обмена сообщениями, как надежность, безопасность, конфиденциальность, целостность, атомарность, события ... Ни один из них не охватывает управление доступом, и все они относятся к SOAP.

XACML не зависит от технологий. Его можно применять к Java-приложениям, .NET, Python, Ruby ... веб-службам, API-интерфейсам REST и многим другим.

Следующие интересные ресурсы:

38
24.09.2013 22:22:33
Я не понимаю, почему вы не можете просто внедрить систему токенов, которая получит пользователя и его разрешения, которые по сути будут одним и тем же?
Stan 31.12.2013 15:23:02
Вы можете использовать маркерный подход. Это тоже хорошо работает, но вам все еще нужна логика, которая определяет, какие разрешения пользователи получают, другими словами, какие разрешения вставлять в токен. Это то, что XACML может помочь вам достичь. Это также позволяет избежать раздувания токенов.
David Brossard 2.01.2014 07:44:37
В качестве дополнительного комментария, что «9 до 5» способствует безопасности? Как будто злоумышленники активны только ночью? Не говоря уже о серьезных последствиях использования, как будто врачи работают только «с 9 до 5».
Roland 11.07.2016 13:43:21
Это общее требование в сценариях здравоохранения. Проверьте HL7 например. Существуют также и сценарии, когда врачу нужен доступ в нерабочее время. Что касается хакеров, как только они во всех ставках не действуют
David Brossard 11.07.2016 14:44:55
Некоторые из моих коллег действительно это расследуют. Спасибо @SimplyG.
David Brossard 9.05.2018 12:00:18

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

Что касается среды .NET я не помогу, но «веб - сервисам здания с Java» (кирпич с ~ 10 авторами) сделала помощь мне много в понимании WS- * архитектуры безопасности и, в особенности, его причуда.

6
21.11.2013 14:19:04

OWASP (Open Web Application Security Project) имеет несколько шпаргалок, охватывающих все аспекты разработки веб-приложений. Этот проект является очень ценным и надежным источником информации. Что касается услуг REST, вы можете проверить это: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

14
24.02.2014 18:41:39

Я хочу добавить (в соответствии с stinkeymatt), самое простое решение было бы добавить сертификаты SSL на ваш сайт. Другими словами, убедитесь, что ваш URL-адрес HTTPS: //. Это покроет вашу безопасность на транспорте (удар за доллар). С URL-адресами RESTful идея состоит в том, чтобы сделать его простым (в отличие от WS * security / SAML), вы можете использовать oAuth2 / openID connect или даже Basic Auth (в простых случаях). Но вам все равно понадобится SSL / HTTPS. Пожалуйста, проверьте безопасность ASP.NET Web API 2 здесь: http://www.asp.net/web-api/overview/security (Статьи и видео)

4
1.03.2014 01:04:58

В результате @Nathan получил простой заголовок HTTP, а некоторые из них назвали OAuth2 и клиентские SSL-сертификаты. Суть в том, что ... ваш REST API не должен обрабатывать безопасность, поскольку это действительно должно выходить за рамки API.

Вместо этого следует установить уровень безопасности, будь то заголовок HTTP за веб-прокси (общий подход, такой как SiteMinder, Zermatt или даже Apache HTTPd), или такой же сложный, как OAuth 2.

Главное, чтобы запросы работали без какого-либо взаимодействия с конечным пользователем. Все, что нужно, это убедиться, что соединение с REST API аутентифицировано. В Java EE у нас есть понятие a, userPrincipalкоторое можно получить на HttpServletRequest. В дескрипторе развертывания также указывается, что шаблон URL может быть безопасным, поэтому код REST API больше не нужно проверять.

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

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

3
17.07.2014 15:37:15

Что касается безопасности веб-приложений, вам следует взглянуть на OWASP ( https://www.owasp.org/index.php/Main_Page ), в котором представлены листы для различных атак безопасности. Вы можете включить как можно больше мер для защиты своего Приложения. Что касается безопасности API (авторизация, аутентификация, управление идентификацией), существует несколько способов, как уже упоминалось (Basic, Digest и OAuth). В OAuth1.0 есть петли, поэтому вы можете использовать OAuth1.0a (OAuth2.0 не получил широкого распространения из-за проблем со спецификацией)

3
6.10.2014 06:05:08

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

API-шлюз будет гибким и легко настраиваемым решением. Я немного протестировал и использовал KONG, и мне очень понравилось то, что я увидел. KONG предоставляет собственный API REST администратора, который вы можете использовать для управления пользователями.

Express-gateway.io является более новым и также является шлюзом API.

2
11.08.2017 21:51:08

На Github найден отличный контрольный список :

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

  • Не изобретайте колесо в аутентификации, генерации токенов, хранении паролей. Используйте стандарты.

  • Использование Max Retryи тюрьма функции в логине.

  • Используйте шифрование на всех конфиденциальных данных.

JWT (веб-токен JSON)

  • Используйте случайный сложный ключ (JWT Secret), чтобы сделать грубое форсирование токена очень сложно.

  • Не извлекайте алгоритм из полезной нагрузки. Принудительно использовать алгоритм в бэкэнде (HS256 или RS256).

  • Сделать срок действия токена ( TTL, RTTL) как можно короче.

  • Не храните конфиденциальные данные в JWTполезной нагрузке, они могут быть легко декодированы.

OAuth

  • Всегда проверяйте на redirect_uriстороне сервера, чтобы разрешить только URL из белого списка.

  • Всегда пытайтесь обменять на код, а не на токены (не разрешайте response_type=token).

  • Использование параметра состояния со случайной хэш , чтобы предотвратить CSRFна OAuthпроцесс аутентификации.

  • Определите область по умолчанию и проверьте параметры области для каждого приложения.

Доступ

  • Ограничьте количество запросов (регулирование), чтобы избежать DDoS / атак методом перебора.

  • Используйте HTTPS на стороне сервера, чтобы избежать MITM (Man In the Middle Attack)

  • Используйте HSTSзаголовок с SSL, чтобы избежать атаки SSL Strip.

вход

  • Используйте правильный метод HTTP в соответствии с операцией: GET(чтение), POST(создание), PUT/PATCH(замена / обновление) и DELETE(для удаления записи) и ответьте, 405 Method Not Allowedесли запрошенный метод не подходит для запрошенного ресурса.

  • Проверьте тип содержимого по Acceptзаголовку запроса (согласование содержимого), чтобы разрешить только ваш поддерживаемый формат (например application/xml, application/jsonи т. Д.), И отвечайте 406 Not Acceptableответом, если он не соответствует.

  • Validate content-typeиз размещены данные , как вы принимаете (например application/x-www-form-urlencoded, multipart/form-data, application/jsonи т.д.).

  • Проверяйте пользовательский ввод, чтобы избежать распространенных уязвимостей (например, XSS, SQL-инъекция, удаленное выполнение кода и т. Д.).

  • Не используйте конфиденциальные данные (учетные данные, пароли, маркеры безопасности или ключи API) в URL-адресе, но используйте стандартный Authorizationзаголовок.

  • Используйте службу API-шлюза для включения кэширования, Rate Limitполитик (например, Quota, Spike Arrest, Concurrent Rate Limit) и динамического развертывания ресурсов API.

обработка

  • Проверьте, все ли конечные точки защищены за аутентификацией, чтобы избежать прерывания процесса аутентификации.

  • Следует избегать идентификатора собственного ресурса пользователя. Используйте / me / orders вместо / user / 654321 / orders.

  • Не увеличивайте автоматически идентификаторы. Вместо этого используйте UUID.

  • Если вы анализируете XML-файлы, убедитесь, что синтаксический анализ сущностей не включен, чтобы избежать XXE (атака внешней сущности XML).

  • Если вы анализируете XML-файлы, убедитесь, что расширение сущностей не включено, чтобы избежать бомбардировки Billion Laughs / XML с помощью экспоненциальной атаки на расширение сущностей.

  • Используйте CDN для загрузки файлов.

  • Если вы имеете дело с огромным количеством данных, используйте Workers and Queues для максимально возможной обработки в фоновом режиме и быстрого возврата ответа, чтобы избежать блокировки HTTP.

  • Не забудьте выключить режим DEBUG .

Вывод

  • Отправить X-Content-Type-Options: nosniffзаголовок

  • Отправить X-Frame-Options: denyзаголовок

  • Отправить Content-Security-Policy: default-src 'none'заголовок

  • Удалить заголовки отпечатков пальцев - X-Powered-By, Serverи X-AspNet-Versionт. Д.

  • Принудительно content-typeза ваш ответ, если вы вернетесь, application/jsonто ваш тип контента ответа application/json.

  • Не возвращайте конфиденциальные данные, такие как учетные данные, пароли, токены безопасности.

  • Верните правильный код состояния в соответствии с выполненной операцией. (например 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowedи т.д.).

60
28.12.2017 16:38:45
Хороший список, хотя и немного самоуверенный - и он начинается с бессмысленного imho: «Не используйте обычную аутентификацию Используйте стандартную аутентификацию (например, JWT, OAuth)». Вы не можете получить более стандартную, чем Basic Auth, и она имеет свое место, особенно для API, где клиенты не являются браузерами (для браузеров JWT обычно более подходит). OAuth, с другой стороны, использует целый ряд других компромиссов для аутентификации и на самом деле не сравним с Basic Auth и JWT.
johndodo 24.12.2017 19:43:52
Вы правы, BasicAuth с HTTPS является обычным явлением, но это горячо обсуждается - security.stackexchange.com/questions/988/… . Я все равно уберу эту точку.
Andrejs 28.12.2017 16:38:21