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

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

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

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

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

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

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

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

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

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

Теоретически, если ключ связан с доменом, вы не можете зависеть от 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.

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

Похоже, вы делаете здесь, превращая свои файлы 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. Я буду лапшой на этом.