Як Карти Google захищають свій ключ API? Як зробити щось подібне?

В даний час Google вимагає від вас створення ключа API, який відповідає домену, звідки карта буде обслуговуватися. Як Google застосовує це? Я хочу зробити те саме.

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

Я завжди розумів, що ця концепція неможлива, але Google якимось чином добре виконує її завдання.

Редагувати - Здається, Google все-таки не зробив нічого дивовижного. Їх API, швидше за все, призначений лише для відстеження, а не насправді для того, щоб гарантувати, що їх API використовує особа, що має ключ.

Я цілком впевнений, що вони використовують URL-адресу REFERER, щоб визначити, звідки надходить дзвінок. Якщо домен не відповідає призначеному ключу, це недійсний запит.

Для практичного прикладу, використовуючи PHP, ви можете перевірити домен за допомогою $_SERVER['HTTP_REFERER']перевірки реферала. Якщо домен збігається, поверніть дійсну відповідь. Якщо цього не сталося, ви можете повернути 401 несанкціоновану або іншу відповідь.

Сам ключ API - це, швидше за все, односторонній хеш домену, з яким пов’язаний ключ, і секрет, про який знає лише сервер Google API. Він може містити деякі інші відомі (для Google, звичайно,) відомості. Коли ви робите запит із цього домену, сервер API бере домен, з якого надходить запит, і робить той самий односторонній хеш-розрахунок і порівнює ці два значення.

Для викликів Ajax вони, швидше за все, використовують реферал, щоб отримати домен хоста документа. Незважаючи на те, що реферал може бути підроблений, врешті-решт, щоб використовувати API, вам потрібно отримати Google JavaScript для виконання в документі. На даний момент цей javascript може підтвердити, що документ, який викликав виклик API Ajax, походить з цільового сервера. Звичайно, це також можна підмінити, за умови, що у вас є власна реалізація DOM або модифікація сценарію на льоту. Однак це підмінювання повинно відбуватися на стороні клієнта, і шанси на те, що веб-сайт, який хоче використовувати Google API, зможуть підробляти клієнтське програмне забезпечення, досить малі.

Зауважте, що оскільки API по суті безкоштовний, вони також могли запропонувати анонімний доступ до свого API. Очевидно, що Google не має на меті захистити несанкціонований доступ до нього, а гарантувати, що вони зможуть зібрати якомога більше даних про використання цих даних і зможуть пов’язати це використання з іншими даними, які вони зібрали про цільовий домен. Як такий, я би не очікував, що перевірка ключа API буде набагато складнішою, ніж описана вище - рентабельність інвестицій у більш просунутий підхід занадто низька.

І, звичайно, є також стурбованість можливими атаками XSS через їх API. Але я не вірю, що їх ключ API занадто прив'язаний до будь-якого анти-XSS-коду, який у них є.

Як сказано в моєму коментарі:

REFERER можна підміняти, тому, мабуть, малоймовірно, що Google використовуватиме його як засіб перевірки. Дивіться цей запис у Вікіпедії.

Я припускаю, що Google, ймовірно, використовує IP-адресу абонента разом із пошуком DNS. DNS насправді не можна підміняти, оскільки ваші записи DNS повинні бути правильними, щоб веб-сайт навіть потрапляв до вас.

Але навіть у цього є свої проблеми, оскільки якщо сервер використовує налаштування DNS з ІР-адресою Round-Robin, Google буде перенаправлено на іншу IP-адресу під час пошуку DNS.

З поширених запитань

Зверніть увагу, що ключ для http://www.mygooglemapssite.com/ буде прийнятий лише тоді, коли веб-сайт отримає доступ за цією адресою. Це не приймається, якщо веб-сайт отримує доступ за IP-адресою (наприклад, http://10.1.2.3/ ) або за допомогою імені хосту, яке є псевдонімом www.mygooglemapssite.com за допомогою запису DNS CNAME.

Я припускаю, що він, можливо, використовує Hostзаголовок, який надсилається при запиті сторінки, який би працював, як зазвичай, Google просить вас включити його сценарій API безпосередньо на сторінку. Тоді цей скрипт має доступ до заголовків поточної сторінки і може використовувати його для перевірки.

Моє припущення підтверджується тим фактом, що він не працює для IP-адрес або псевдонімів, а це означає, що він не робить перевірку DNS.

ЦЕЙ метод не може бути підроблений, оскільки він повинен бути правильним заголовком для доступу до сторінки. Однак це означає, що будь-які псевдоніми домену не працюватимуть.

Однак це також означає, що ви ПОВИННІ надати бібліотеку Javascript для доступу до коду, оскільки ви не можете перевірити цю сторону сервера, я вважаю.

Я погоджуюся з усіма пунктами, які перелічив Франці Пенов. Я хотів би трохи детальніше розповісти про використання чужого ключа API. Припустимо, ви зареєструвались key1у example.com.

1. Перша спроба - Якщо anothersite.comє <script src="http://www.google.com/jsapi?key=key1">, Google може перевірити свою реферальную (схему хешування згадується) і в цьому випадку існує невідповідність. Як злий зловмисник долає це, оскільки багато людей згадували, що реферала можна підробити? Тут насправді це не стосується. Звичайно, ви можете надіслати довільні заголовки, якщо зробите запит, але як злий хакер підробляє реферал для користувачів anothersite.com? Це взагалі непросто. Існували старі версії flash на IE 6, які дозволяли зловмисникові встановлювати довільні заголовки під час надсилання міждоменних запитів, але загалом це не працює для сценарію src. Я не впевнений, що включений Javascript робить перевірку, document.locationщоб запобігти цьому (можливо, ні).

2. Друга спроба - злий зловмисник копіює Google Javascript для ключа API із mysite.comджерела сторінки, а потім вбудовує змінений javascript у anothersite.com. Тепер Google не може нічого перевірити (віддалений IP буде комп’ютером користувача, і ви не можете багато чого зробити ви або Google).

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

Причина, по якій це працює, полягає в тому, що ви не можете здійснювати виклики API за допомогою JavaScript. Захист браузера забороняє javascript робити запити де завгодно, крім домену, з якого javascript походить. Через це будь-які виклики API з javascript повинні бути відбиті через ваш сервер, де зберігається ключ API (ключ api ніколи не бачить javascript).