Подтвердить что ты не робот

Авторизация запросов REST

Я работаю над сервисом REST, который имеет несколько требований:

  • Он должен быть безопасным.
  • Пользователи не должны создавать запросы.

Мое текущее предлагаемое решение состоит в том, чтобы создать собственный заголовок авторизации, который выглядит так (это так же, как работают веб-службы amazon):

Authorization: MYAPI username:signature

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

Приложение, которое будет использовать эту услугу, - это приложение для iPhone, поэтому я думал, что мы можем использовать открытый ключ в приложении, с которым мы можем сделать дополнительную подпись, но означает ли это, что нам нужно будет иметь два подписи, один для ключа пользователя и один для ключа приложения?

Любые советы будут очень признательны, я бы очень хотел, чтобы это было в первый раз.

4b9b3361

ОТВЕТЫ

Ответ 1

Я думаю, что самый простой способ сделать это правильно - это использовать аутентификацию клиента HTTPS. На этом сайте Apple есть thread.

Изменить: для обработки авторизации я создавал бы отдельный ресурс (URI) на сервере для каждого пользователя и разрешал бы только этому (аутентифицированному) пользователю манипулировать этим ресурсом.

Edit (2014): Apple изменила свое программное обеспечение на форуме за последние шесть лет; поток теперь находится в https://discussions.apple.com/thread/1643618

Ответ 2

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

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