Ищете предложения по созданию безопасного REST API в Ruby on Rails

Question

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

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

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

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

Answer 1

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

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

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

http://myusername:mypass@www.someapp.com/

Я считаю, что 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 выполняет это, беря все параметры в запрос и упорядочивая их по имени параметра. Затем эта строка хэшируется с использованием секретного ключа пользователя в качестве ключа хеширования. Это новое значение добавляется в качестве нового параметра к запросу до его отправки. На стороне Amazon они делают то же самое. Они принимают все параметры (кроме подписи), упорядочивают их и хэшируют с использованием секретного ключа. Если это соответствует подписи, они знают, что запрос является законным.

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

OAuth

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

То, что я делаю, выглядит примерно так:

   class Model < ActiveRecord::Base  
       attr_accessible nil  
   end

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

Точно так же вы знаете, что кто-то может массово назначить свойство не только с помощью API REST, но и с помощью обычной публикации.

Answer 4

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

Существует плагин ruby ​​/ rails плагин ruby ​​API , который будет применяться к политикам трафика по мере его поступления - вы можете использовать его вместе с oAuth gem . Вы также можете использовать его, сбросив лак перед приложением и используя lib lib mod: Модуль API лака .