Як уникнути несанкціонованого використання API?

Мені потрібно розробити "віджет", сценарій, який партнери вставлятимуть на свої веб-сайти, щоб відобразити якийсь інтерфейс користувача та здійснити дзвінки до нашого API.

В основному він відображатиме наші дані на цих сайтах на основі деяких ідентифікаторів, які вони надають у наших дзвінках API. Чого ми хотіли б уникнути, це те, що хтось зловживає API та використовує його, щоб викреслити весь наш каталог.

Кожному партнеру, який вбудує наш сценарій, буде надано відкритий ключ, який потрібно надати під час виклику API. Ідеєю було б попросити їх додати цей ключ під час завантаження сценарію, наприклад:

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

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

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

Що ви думаєте про це рішення і що б ви зробили з цими обмеженнями?

Вам потрібно кілька видів захисту.

По-перше , вам потрібно не допустити використання ключа Сайта А на Сайті B.

Теоретично, якщо ключ прив’язаний до домену, ви не можете залежати від 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, але тоді вони також можуть зламати Амазонку). Без SSL, спеціалізований хакер може нюхати ваші дзвінки, підробляти IP та знищувати ваш каталог. Тож це свого роду судження закликає до ризику.

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