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

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

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

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

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

18 ответов


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

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

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


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

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

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


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

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


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


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

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

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

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

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

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

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

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


есть большой контрольный список, найденный на Github:

проверка подлинности

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

  • использовать Max Retry и особенности тюрьмы В логине.

  • шифрование всех конфиденциальных данных.

помощью JWT (JSON веб Токен)

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

  • не извлекайте алгоритм из полезной нагрузки. Алгоритм силу в backend (HS256 или RS256).

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

  • не храните конфиденциальные данные в JWT полезная нагрузка, ее можно расшифровать легко.

протокол OAuth

  • всегда проверять redirect_uri на стороне сервера разрешать только URL-адреса из белого списка.

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

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

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

открыть

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

  • используйте HTTPS на стороне сервера, чтобы избежать MITM (человек в середине атаки)

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

вход

  • использовать правильный метод 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-адресе, но используйте standard Authorization заголовок.

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

обработка

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

  • пользователь ID ресурса следует избегать. Используйте/me / orders вместо /пользователей/654321/заказы.

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

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

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

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

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

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

выход

  • отправить .

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

  • отправить .

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

  • силу content-type для вашего ответа, если вы вернетесь application/json тогда ваш тип содержимого ответа application/json.

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

  • возврат соответствующего кода состояния к завершению операции. (например,200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed и т. д.).


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

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


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


Спасибо за отличный совет. В конечном итоге мы использовали пользовательский HTTP-заголовок для передачи маркера идентификации от клиента службе, готовясь к интеграции нашего RESTful API с предстоящей платформой идентификации Zermatt от Microsoft. Я описал проблему здесь и решение здесь. Я тоже взял tweaktсовет и купил RESTful Web Services - очень хорошая книга, если вы создаете 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/


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

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


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


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


Я хочу добавить(в соответствии с stinkeymatt), самым простым решением было бы добавить SSL-сертификаты на ваш сайт. Другими словами, убедитесь, что Ваш url-адрес HTTPS://. Это покроет вашу транспортную безопасность (bang for the buck). С RESTful url, идея состоит в том, чтобы держать его простым (в отличие от WS* security/SAML), вы можете использовать OAuth2 / openID connect или даже базовая аутентификация (в простых случаях). Но вам все равно понадобится 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 предоставляет собственный API REST администратора, который можно использовать для управления пользователями.

Экспресс-шлюз.Ио более свежие, а также шлюз по API.