Защита RESTful API

Для моего текущего побочного проекта, который представляет собой модульную систему веб-управления (которая может содержать модули для управления базой данных, cms, управления проектами, управления ресурсами, отслеживания времени и т. д.), я хочу представить всю систему как RESTful API, поскольку я Думаю, это сделает систему более удобной. Сама система будет закодирована в ASP.MET MVC3, однако, если я сделаю все данные/действия доступными через RESTful API, это должно сделать систему очень простой в использовании с PHP, Ruby, Python и т. д. (они могут даже сделать собственный интерфейс для управления определенными данными, если они хотят).

Тем не менее, одна вещь, которую сложно сделать легко (с точки зрения пользователя, использующего RESTful API) с RESTful API, — это безопасность с функциональностью ajax. Если бы мне нужно было что-то сложное в настройке и использовании, я бы просто создал сервисы SOAP, но весь смысл использования RESTful API в том, что это очень просто. Наиболее распространенный способ защиты RESTful API с помощью ключа, связанного с пользователем. Это прекрасно работает, когда все вызовы выполняются на стороне сервера, однако, как только вы начинаете выполнять функции ajax, все меняется. Я бы хотел, чтобы API RESTful можно было вызывать непосредственно из javascript, однако любой, у кого есть firebug, мог бы легко получить доступ к ключу, который использует пользователь, разрешив этому человеку доступ к системе. Есть ли лучший способ защитить RESTful API, где он не заставляет пользователя RESTful API делать сложные вещи только для его настройки?


person ryanzec    schedule 20.12.2010    source источник
comment
См. также аутентификация REST и раскрытие ключа API.   -  person Arjan    schedule 15.12.2012


Ответы (2)


Во-первых, вы не можете запретить пользователю вашего API раскрывать свой ключ.

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

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

person Bhakta Nall    schedule 20.12.2010
comment
Я понимаю, что не могу запретить пользователю раскрывать свой ключ, я хотел бы попытаться предоставить способ как для сервера, так и для клиента делать запросы к API. Я рассмотрю аутентификацию дайджест-доступа более внимательно. - person ryanzec; 20.12.2010

Можно сделать некоторую подпись в запросе из javascript. Но я уверен, как URL-адреса «RESTfull» будут с этой дополнительной информацией. И здесь у вас та же проблема: любой, кто может видеть ваш алгоритм создания подписи, может сделать свою собственную подпись, которую ваш сервер также примет.

person sheepwalker    schedule 28.12.2010