Внедрение (безопасных) ключей API в приложении

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

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

Дело в том, что меня беспокоит аспект безопасности. Поскольку ключ Api будет отправлен на наш сервер (через GET / POST и т. Д.), Кто-то может прослушать запрос с помощью wirehark и без особых усилий получить ключ API разработчиков, верно?

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

Итак, мои вопросы

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

Что вы думаете, ребята?


php web-applications security api-key sniffing
person mpratt    schedule 15.05.2012    source источник
comment
Я случайно проголосовал за это (я даже не помню, чтобы читал это). Как я могу это отменить.   -  person Gellweiler    schedule 08.08.2014

Ответы (3)


arrow_upward
2
arrow_downward

Думаю, вы здесь пытаетесь решить кучу разных вопросов.

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

Если вы хотите создать схему лицензирования, вам необходимо разбираться в криптографии и т. Д. - это нетривиальная проблема. Например, как запретить легитимному пользователю поделиться своим лицензионным ключом со всеми своими друзьями? Как вы помешаете хакеру украсть ваш ключ и поделиться им со всеми своими друзьями?

Для этого есть несколько решений - все они причиняют определенную боль вашим пользователям. Например, вы можете запустить свою службу по HTTPS; это останавливает отслеживание, но снижает производительность. Вы можете выпускать «токены» для своих услуг, срок действия которых истекает после определенного количества использований; для получения новых токенов требуется криптографический обмен (который может проверить ваш IP-адрес). Вам может потребоваться логика типа «запрос / ответ» (включая проверку IP-адреса). Все эти шаги усложняют жизнь вашим пользователям; они, вероятно, не будут вас сильно благодарить за дополнительную работу, которую им нужно сделать.

person Neville Kuyt    schedule 15.05.2012

arrow_upward
2
arrow_downward

Что касается сниффинга, ваша проблема может быть решена с помощью HTTPS на вашем сервере.

person i4k    schedule 15.05.2012

arrow_upward
1
arrow_downward

определенно имеет смысл поставить некоторую аутентификацию в API, если вы хотите ограничить доступ + потенциальные ограничения скорости использования. Если вы используете ключ API и хотите избежать обнюхивания, тогда HTTPS определенно вам подходит. Если это не вариант, вы также можете использовать аутентификацию в стиле хеша, например oAuth 1.0 (http://oauth.net/core/1.0/) или аутентификацию Amazon AWS. Они работают путем выдачи вашим пользователям API идентификатора и секрета. Они используют секрет на стороне клиента, вставляя его в тело сообщения, вычисляя хэш и включая хеш (не секрет) в запрос. На входящей стороне вы сравниваете хэш с той же операцией, выполняемой над содержимым сообщения, с включенным их конкретным секретом.

Это означает, что вы можете проверить отправителя, не отправляя секрет по сети (обратите внимание, что содержимое по-прежнему небезопасно, но вы избегаете передачи ключа по сети с каждым запросом). Обратной стороной является сложность реализации разработчиками. Даже если вы используете шаблон oAuth 1.0, для которого есть библиотеки, это немного накладные расходы.

Я работаю в 3scale, и некоторые из наших инструментов также могут быть полезны - наши системы предоставляют ключи API, совместное использование секретов oAuth, а также ограничения скорости API из коробки (http://www.3scale.net и библиотеки PHP находятся здесь: https://github.com/3scale/3scale_ws_api_for_php).

person steve    schedule 16.05.2012