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

Question

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

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

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

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

Answer 1

Существует несколько схем аутентификации запросов API, и они отличаются от обычной аутентификации, предоставляемой такими плагинами, как restful_authentication или act_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, а также для использования API OAuth и был очень впечатлен.Если вы считаете, что вашему приложению нужен 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 драгоценный камень.Вы также можете использовать его, поместив лак перед приложением и используя мод библиотеки лака: Модуль API лака.