Как избежать несанкционированного использования API?

10

Мне нужно разработать «виджет», скрипт, который партнеры будут вставлять на свои веб-сайты для отображения некоторого пользовательского интерфейса и выполнения вызовов нашего API.

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

Каждому партнеру, который встраивает наш скрипт, будет предоставлен открытый ключ, который необходимо указать при вызове API. Идея состоит в том, чтобы попросить их добавить этот ключ при загрузке скрипта, например:

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

Таким образом, запрос на скрипт может использоваться для регистрации пары ключ / источник IP и ответа на последующие вызовы API, только если пара ключ / IP совпадает с зарегистрированной (с ограниченным временем жизни и ограничением количества запросов в день).

Я не уверен, что это хорошая идея, так как это, очевидно, безопасность через запутывание (кто-то, перезагружая скрипт, полностью обойдёт его); но я не вижу другого способа ограничить доступ. Я не могу предоставить уникальный ключ каждому пользователю, только партнерам. Я не могу использовать систему с закрытым ключом, так как весь код будет доступен любому. Это в основном ограничение доступа к общедоступному API, то есть противоречивое в его определении.

Что вы думаете об этом решении, и что бы вы сделали с этими ограничениями?

security api-design web-api Antoine
источник
Можете ли вы сделать ключ динамическим? MD5 хэш идентификатора партнера плюс время UTC, округленное до ближайших 10 минут?
Дан Пичельман,
2
Я могу, но это будет вычислено в сценарии, и, как таковое, доступно для свободного воспроизведения. Я не вижу, как это улучшает безопасность.
Антуан
Я думал о том, чтобы партнер вычислил его на стороне сервера. Если это не вариант, то я подозреваю, что ваш единственный реальный выбор - сделать упомянутое регулирование (ограниченный срок службы, ограничение запросов / день). Не забывайте, что IP-адрес, который вы видите, не обязательно соответствует одному компьютеру.
Дэн Пичельман,
Мне нужно проверить с бизнесом, если вычислить это на стороне сервера выполнимо. В противном случае это то, чего я боялся, только решение проблемы.
Антуан

Ответы:

12

Вам нужно несколько видов защиты.

Во-первых , вы должны предотвратить использование ключа сайта А на сайте Б.

Теоретически, если ключ связан с доменом, вы не можете зависеть от refererзаголовка, но, поскольку ваш клиент встраивает скрипт напрямую, вы можете разумно полагаться document.locationна клиентскую часть. Отправка этого местоположения (или его частей) на сервер напрямую ненадежна; но вы можете использовать его для генерации ключа сеанса:

  1. Клиент встраивает client_keyзапрос в библиотеку API.
  2. Сервер определяет хост, который имеет доступ к API, если таковой имеется.
  3. Сервер выбирает «соль» для ключа сеанса и отправляет его клиенту с библиотекой [или как часть другого обмена перед авторизацией].
  4. Клиент рассчитывает session_keyиспользование hash(document.location.host + session_salt).
  5. Клиент использует session_key+ client_keyдля вызова API.
  6. Сервер проверяет вызов, просматривая client_keyхост и «соль» в сеансе, вычисляя хеш и сравнивая с предоставленным client_key.

Во-вторых , вам нужно помешать Hacker Hank открыть консоль отладки или использовать модифицированный клиент на сайте A, чтобы делать все, что он хочет, с вашим API.

Обратите внимание, что очень трудно, если не невозможно, полностью предотвратить использование Hacker Hank API. Но вы можете сделать это более сложным. И самый разумный способ помешать Хэнку, насколько я знаю, это ограничение скорости.

  • Ограничить количество запросов / сек / сеанс и запросов / час / сеанс. (Пики в активности, вероятно, разумны, но не поддерживаются трафиком выше среднего от одного клиента.)
  • Ограничить количество сеансов / IP / час.
  • Ограничить количество запросов / IP / час. Разрешить пики, но не поддерживать интенсивный трафик с одного IP.

В-третьих , как вы, вероятно, уже делаете: шифруйте трафик. Конечно, АНБ увидит это; но Хакер Хэнк менее склонен.

svidgen
источник
0

Похоже, вы делаете здесь, превращая свои файлы JavaScript в защищенные ресурсы. И в то же время связывать его с неким поколением токенов. Это интересно.

Сотрудники службы безопасности, с которыми я работаю, обычно отклоняют IP-адрес из-за того, что IP-адрес может быть подделан Но если вы используете ограничение IP в сочетании с SSL, это обычно помогает.

Но вы должны «занести в белый список» IP-адреса, иначе любой хакер может просто войти в парадную дверь.

Я был настроен скептически, но на самом деле я думаю, что ваша схема работает довольно хорошо. Если 1) файл .js и последующие вызовы API выполняются с использованием TLS (т. Е. SSL или https), и 2) IP-адреса заносятся в белый список. Затем я сделаю смелое заявление и скажу, что думаю, что вы пройдете проверку безопасности даже для взаимодействия с PCI (кредитной картой).

ИМХО ... Но если вы просто пытаетесь защитить служебную информацию компании, а не кредитную карту (PCI) или личную / личную информацию (PII), то это, вероятно, хорошо, даже без SSL, в зависимости от того, насколько вы готовы рискнуть разоблачением вашего каталога.

Или, скажем так: с SSL выделенный хакер не может получить ваш каталог. (Если они не нарушают SSL, но тогда они могут также сломать Amazon). Без SSL выделенный хакер может прослушивать ваши звонки, подделывать IP-адреса и просматривать ваш каталог. Так что это своего рода суждение о риске.

Я пытаюсь придумать, как обойтись без белого списка IP-адресов, потому что это обычно - трудная задача;), не переходя к полномасштабной OAuth. Я буду лапшой на этом.

обкрадывать
источник