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

https://stackoverflow.com/questions/7551

08-06-2019
|

Вопрос

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

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

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

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

Решение

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

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

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

Другие советы

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

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

А еще я очень рекомендую книгу RESTful веб-службы из О'Рейли.В нем объясняются основные концепции и приводятся некоторые лучшие практики.Обычно вы можете взять предоставленную ими модель и сопоставить ее со своим собственным приложением.

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

Это очень похоже на подход, принятый фликр и вспомни молоко «rest» API (не обязательно хорошие примеры restful API, но хорошие примеры подхода на основе токенов).

На сайте есть отличный контрольный список Гитхаб:

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

Не изобретайте велосипед в области аутентификации, генерации токенов и хранения паролей.Используйте стандарты.
Использовать Max Retry и функции тюрьмы при входе в систему.
Используйте шифрование для всех конфиденциальных данных.

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

Используйте случайный сложный ключ (JWT Secret), чтобы сделать перебор токена очень трудным.
Не извлекайте алгоритм из полезной нагрузки.Примените алгоритм на серверной стороне (HS256 или RS256).
Окончание срока действия токена (TTL, RTTL) как можно короче.
Не храните конфиденциальные данные в JWT полезная нагрузка, ее можно легко декодировать.

OAuth

Всегда проверяйте redirect_uri на стороне сервера, чтобы разрешить только URL-адреса из белого списка.
Всегда старайтесь обменивать код, а не токены (не разрешайте response_type=token).
Используйте параметр состояния со случайным хешем, чтобы предотвратить CSRF на OAuth процесс аутентификации.
Определите область по умолчанию и проверьте параметры области для каждого приложения.

Доступ

Ограничьте запросы (Throttling), чтобы избежать DDoS/атак методом перебора.
Используйте HTTPS на стороне сервера, чтобы избежать MITM (атака «человек посередине»)
Использовать HSTS заголовок с SSL, чтобы избежать атаки SSL Strip.

Вход

Используйте правильный метод HTTP в соответствии с операцией: GET (читать), POST (создавать), PUT/PATCH (заменить/обновить) и DELETE (чтобы удалить запись) и ответьте 405 Method Not Allowed если запрошенный метод не подходит для запрошенного ресурса.
Проверка типа контента по запросу Accept заголовок (согласование контента), чтобы разрешить только поддерживаемый формат (например, application/xml, application/json, и т. д.) и ответьте 406 Not Acceptable ответ, если не совпадает.
Подтвердить content-type опубликованных данных по вашему усмотрению (например, application/x-www-form-urlencoded, multipart/form-data, application/json, и т. д).
Проверяйте вводимые пользователем данные, чтобы избежать распространенных уязвимостей (например,XSS, SQL-инъекция, удаленное выполнение кода и т. д.).
Не используйте конфиденциальные данные (учетные данные, пароли, токены безопасности или ключи API) в URL-адресе, а используйте стандартные Authorization заголовок.
Используйте службу API Gateway для включения кэширования, Rate Limit политика (например,Квота, запрет скачков, ограничение одновременной скорости) и динамическое развертывание ресурсов API.

Обработка

Проверьте, защищены ли все конечные точки аутентификацией, чтобы избежать нарушения процесса аутентификации.
Следует избегать использования идентификатора собственного ресурса пользователя.Используйте /me/orders вместо /user/654321/orders.
Не увеличивайте идентификаторы автоматически.Вместо этого используйте UUID.
Если вы анализируете XML-файлы, убедитесь, что анализ сущностей отключен, чтобы избежать XXE (атака на внешний объект XML).
Если вы анализируете файлы XML, убедитесь, что расширение сущности не включено, чтобы избежать бомбы Billion Laughs/XML посредством атаки экспоненциального расширения сущности.
Используйте CDN для загрузки файлов.
Если вы имеете дело с огромным объемом данных, используйте Workers и Queues для обработки как можно большего объема в фоновом режиме и быстрого возврата ответа, чтобы избежать блокировки HTTP.
Не забудьте повернуть ОТЛАЖИВАТЬ Режим выключения.

Выход

Отправлять 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, и т. д).

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

Все в этих ответах упустили из виду настоящий контроль доступа/авторизацию.

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

врачи могут ПОЛУЧИТЬ медицинскую карту пациента, с которым у них есть отношения по уходу
никто не может ОТПРАВЛЯТЬ медицинские данные вне часов практики (например,с 9 до 5)
конечные пользователи могут ПОЛУЧИТЬ медицинские записи, которыми они владеют, или медицинские записи пациентов, для которых они являются опекунами.
медсестры могут ОБНОВЛЯТЬ медицинскую карту пациента, который принадлежит к тому же отделению, что и медсестра.

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

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

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

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

Ниже приведены интересные ресурсы:

ОАЗИС XACML Веб-сайт
тот Стандарт NIST ABAC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прошло много времени, но вопрос по-прежнему актуален, хотя ответ, возможно, немного изменился.

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

Экспресс-шлюз.ио является более новым и также является шлюзом API.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow