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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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

Ниже перечислены интересные ресурсы:

• веб-сайт OASIS XACML
• Стандарт NIST ABAC

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

В Github:

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

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

• Используйте функции Max Retry и jail в Login.

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

JWT (JSON Web Token)

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

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

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

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

OAuth

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

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

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

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

Доступ

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

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

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

Вход

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

• Подтвердите заголовок content-type on request Accept (Content Negotiation), чтобы разрешить только ваш поддерживаемый формат (например, 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 для включения кеширования, политики Rate Limit (например, квоты, спайки, ограничения параллельного тарифа) и динамического развертывания ресурсов API.

Обработка

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

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

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

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

• Если вы анализируете файлы XML, убедитесь, что расширение сущности не включено, чтобы избежать использования миллиардной лупы/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 и т.д.).

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

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

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

Ответ 17

Как @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 для предотвращения повторов (которые могут быть атаками или кто-то просто передает одни и те же данные дважды). Эта часть может обрабатываться только на уровне приложения.

Ответ 18

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