Поиск предложений по созданию безопасного REST API в Ruby on Rails

Я начинаю создавать REST API для проекта, над которым я работаю, и это привело меня к небольшому исследованию относительно наилучшего способа создания API с использованием RoR. Я довольно быстро обнаруживаю, что по умолчанию модели открыты для всего мира и могут быть вызваны через URL, просто поместив ".xml" в конец URL-адреса и передав соответствующие параметры.

Итак, появился следующий вопрос. Как защитить приложение, чтобы предотвратить несанкционированные изменения? Проводя некоторые исследования, я нашел пару статей, рассказывающих о attr_accessible и attr_protected, и о том, как их можно использовать. Конкретный URL-адрес, который я нашел, говорил об этом, был опубликован в мае 2007 года (здесь).

Как и все рубины, я уверен, что с тех пор все сложилось. Поэтому мой вопрос заключается в том, что это лучший способ защитить REST API в RoR?

Если нет, что вы предлагаете в сценарии "нового проекта" или "существующего проекта"?

ОТВЕТЫ

Ответ 1

Существует несколько схем аутентификации запросов API, и они отличаются от обычной проверки подлинности, предоставляемой плагинами вроде restful_authentication или act_as_authenticated. Самое главное, что клиенты не будут поддерживать сеансы, поэтому нет понятия входа в систему.

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

Вы можете использовать базовую HTTP-аутентификацию. Для этого клиенты API будут использовать обычное имя пользователя и пароль и просто поместите его в URL-адрес следующим образом:

http://myusername:[email protected]/

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

Один недостаток здесь заключается в том, что вы просите пользователей указать свое имя пользователя и пароль в ясности в каждом запросе. Выполняя это через SSL, вы можете сделать это безопасным.

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

Ключ API

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

Один недостаток заключается в том, что если кто-то получит ключ API другого пользователя, он может делать запросы в качестве этого пользователя. Я думаю, что, заставив все ваши запросы API использовать HTTPS (SSL), вы можете немного компенсировать этот риск.

Другой недостаток заключается в том, что пользователи используют одни и те же учетные данные аутентификации (ключ API) во всем мире. Если они хотят отменить доступ к клиенту API, их единственным вариантом является изменение их ключа API, который также отключит всех других клиентов. Это можно смягчить, разрешив пользователям создавать несколько ключей API.

Ключ API + секретный ключ

Устаревший (вид) - см. ниже OAuth

Значительно сложнее подписать запрос с помощью секретного ключа. Это то, что Amazon Web Services (S3, EC2 и т.д.). По сути, вы даете пользователю 2 ключа: их ключ API (то есть имя пользователя) и их секретный ключ (то есть пароль). Ключ API передается с каждым запросом, но секретный ключ отсутствует. Вместо этого он используется для подписи каждого запроса, обычно путем добавления другого параметра.

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

Недостатком здесь является сложность. Правильная работа этой схемы - боль, как для разработчика API, так и для клиентов. Ожидайте множество вызовов поддержки и сердитых писем от разработчиков-клиентов, которые не могут заставить работать.

OAuth

Для борьбы с некоторыми проблемами сложности с ключом + секретным подписанием появился стандарт: OAuth. В основе OAuth лежит вкус ключа + секретного подписания, но большая часть его стандартизирована и включена в библиотеки для многих языков.

В целом, как разработчику, так и потребителю API гораздо проще использовать OAuth, а не создавать собственную систему ключей/подписи.

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

В частности, для Ruby существует OAuth gem, который обеспечивает поддержку как для производителей, так и для потребителей OAuth. Я использовал этот камень для создания API, а также для использования API OAuth и был очень впечатлен. Если вы считаете, что ваше приложение нуждается в OAuth (в отличие от простой схемы ключей API), то я могу с легкостью рекомендовать использовать драгоценный камень OAuth.

Ответ 2

Как защитить приложение, чтобы предотвратить несанкционированные изменения?

attr_accessible и attr_protected полезны для управления способностью выполнять массовые присвоения в модели ActiveRecord. Вы определенно хотите использовать attr_protected для предотвращения атак типа инъекций; см. Используйте attr_protected или мы взломаем вас.

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

Смотрите Руководство по безопасности Ruby on Rails (часть проекта документации Rails) для более подробной информации.

Ответ 3

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

Я предлагаю убедиться, что только атрибуты, которые могут быть отредактированы пользователем, отмечены attr_accessible. Это создаст белый список атрибутов, которые могут быть назначены с помощью update_attributes.

Что я делаю, это примерно так:

   class Model < ActiveRecord::Base  
       attr_accessible nil  
   end

Все мои модели наследуют от этого, так что они вынуждены определять attr_accessible для любых полей, которые они хотят присвоить массе. Лично я хотел бы, чтобы был способ включить это поведение по умолчанию (может быть, и я не знаю об этом).

Просто, чтобы вы знали, что кто-то может массово назначить свойство не только с помощью REST api, но и с помощью регулярного сообщения формы.

Ответ 4

Другим подходом, который экономит само по себе, является использование http://www.3scale.net/, который обрабатывает ключи, токены, квоты и т.д. для отдельных разработчиков. Он также анализирует и создает портал для разработчиков.

Там плагин ruby ​​/rails ruby ​​API plugin, который будет применяться к политикам для трафика по мере их поступления - вы можете использовать его в сочетании с oAuth gem. Вы также можете нам это, отбросив лак перед приложением и используя мотив лакового lib: API-интерфейс Varnish.