Наскільки безпечно використовувати R пакети для роботи з API рекламних систем

Останнім часом мені досить часто стали задавати питання про те, наскільки безпечно використовувати різні готові розширення, тобто пакети, написані для мови R, чи є ймовірність того, що рекламний акаунт потрапить у чужі руки

У цій статті я детально розповім про те, як влаштований механізм авторизації всередині більшості пакетів та інтерфейсів API рекламних сервісів, і про те, як використовувати наведені в статті пакети максимально безпечно.

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

Наш екскурсійний автобус вже прибув, займайте місця зручніше і ознайомтеся з нашим сьогоднішнім маршрутом.

 

Зміст

 

  1. Як влаштований процес авторизації в більшості сучасних рекламних сервісів
  2. Звідки виникло питання безпеки
  3. Чим вам загрожує перехоплення токена
  4. Що робити якщо хтось заволодів вашим токеном
  5. Як найбільш безпечно використовувати R пакети для роботи з API рекламних систем
    5.1. ryandexdirect і rym — Пакети для роботи з API Яндекс.І Яндекс Директ.Метрики
    5.2. rfacebookstat – Пакети для роботи з рекламним кабінетом Facebook
    5.3. rvkstat — Пакети для роботи з рекламним кабінетом Вконтакте
    5.4. rmytarget — Пакети для роботи з рекламним кабінетом MyTarget
  6. Висновок

 

Як влаштований процес авторизації в більшості сучасних рекламних сервісів

 

Місце збору нашої екскурсійної групи — протокол OAuth.

 

 

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

 

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

Замість логіна і пароля в протоколі OAuth використовуються токен, це згенерована рядок складається з набору букв і цифр, яка в зашифрованому вигляді зберігає інформацію:

 

  • Від імені якого користувача додаток виконує запит
  • Дійсно користувач дозволив цим додатком доступ до своїх даних
  • Є у самого користувача потрібні повноваження для роботи з тими рекламними матеріалами, до яких він звертається

 

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

 

Звідки виникло питання безпеки

 

Ми з вами рухаємося далі, давайте спробуємо розібратися, звідки виникло питання безпеки при використанні пакетів?

 

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

 

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

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

 

Чим вам загрожує перехоплення токена

 

Давайте поговоримо про те, що взагалі дозволяє робити токен якщо він потрапив в руки зловмисника.

Токен треба зберігати так само як і всі інші дані, які необхідні для доступу до облікового запису, тобто якщо токен потрапить не в ті руки, то той хто ним заволодів зможе керувати вашими рекламними матеріалами: видаляти їх, змінювати, наприклад, цілком можна буде поміняти текст оголошення та посилання на яку вона веде.

 

Хороша новина-це те, що як я вже писав вище протоколу OAuth дозволяє вам дати можливість керувати вашими рекламними матеріалами не надаючи логін і пароль від свого облікового запису, тобто навіть якщо хтось заволодів вашим токеном то викрасти ваш аккаунт він з його допомогою не зможе. Жоден API не дозволяє запитувати, і тим більше міняти ваш пароль, так що акаунт у вас не заберуть, а от рекламувати свій сайт через ваш обліковий запис — це запросто.

 

Що робити якщо хтось заволодів вашим токеном

 

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

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

 

Як найбільш безпечно використовувати R пакети для роботи з API рекламних систем

 

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

Хочу зазначити, що всі видані токени зберігаються на стороні рекламної платформи, а не програми, через яке працює R пакет, тому доступу до самим токена немає навіть у користувача зареєстрував програми для роботи з API рекламної площадки.

 

ryandexdirect і rym — Пакети для роботи з API Яндекс.І Яндекс Директ.Метрики

 

Обидва пакети використовують OAuth сервіс Яндекса, детальніше ознайомитись з ним можна за цим посиланням.

У пакеті ryandexdirect для авторизації є 2 функції:

  • yadirAuth — двоетапна авторизація
  • yadirGetToken — запит авторизаційного токена

При використанні функції yadirAuth, а саме її я рекомедную використовувати при роботі з ryandexdirect, процес авторизації йде за описаною тут схемою, єдиним вразливим місцем в даному випадку є період від моменту генерація коду підтвердження до введення його в консоль R.

 

Поясню чому, ось як відображаються в Google Analytics дані про відвідування сторінки генерації коду підтвердження.

 

 

Тобто код йде після символу ‘?’, і вважається GET параметром, який фіксує лічильник Google Analytics, але термін життя такого коду підтвердження закінчується відразу після його використання, тобто відразу після того, як ви ввели його в консоль R. Максимальний термін життя такого коду — 10 хвилин.

Друга функція yadirGetToken, здійснює авторизацію по інший, описаної тут схемою. І при її використанні ніякої код підтвердження не генерується, тобто після того, як ви дали пакету дозвіл на доступ до даних ви потрапляєте на сторінку генерації токена. Сам токен в URL повертається після символу ‘#’, це не get параметр, а якір, або як ще називають цю частину URL — хеш. Браузер не передає ці дані, відповідно вони не передаються далі в звітів Google Analytics, тобто відвідування цієї сторінки в звітах відображаються ось так:

 

 

В цьому другому випадку ніяких ризиків немає, але мінус використання функції yadirGetToken полягає в тому, що вона не зберігає облікові дані у файл на вашому ПК, і далі відповідно не може використовувати ці дані між різними R сесіями, а це не дуже зручно. Токен отриманий з його допомогою ви будете зберігати, використовувати в скриптах як текстовий рядок, термін життя такого сертифіката 1 рік, після чого пакет не зможе автоматично замінити його, як це відбувається при використанні функції yadirGetAuth.

У пакет rym для авторизації існує фукции rym_auth, яка є повним аналогом функції yadirAuth, схема роботи якій докладно я вже описав.

 

rfacebookstat — Пакети для роботи з рекламним кабінетом Facebook

 

Про те, як влаштований процес аутентифікації в Facebook Marketing API докладно описано тут.

 

Для проходження авторизації в пакеті rfacebookstat є функція fbGetToken, працює вона так само як і описана раніше функція yadirGetToken з пакету ryandexdirect, тобто всі реалізується через одноетапну аутентифікацію. Ніякої небезпеки в тому, що ваш розпізнавальний перехоплений через звіти Google Analytics немає, скрін того, як Google Analytics виглядає відвідування генерації сторінки сертифіката.

 

 

rvkstat — Пакети для роботи з рекламним кабінетом Вконтакте

 

Процес аутентифікації Вконтакте описаний в довідці з роботи з API.
У rvkstat для авторизації можна використовувати одну з двох функцій:

 

  • vkAuth — Авторизація за схемою Authorization code flow, тобто двоетапна авторизація.
  • vkGetToken — Авторизація за схемою Implicit flow, одноетапна авторизація, з прив’язкою токена до пристрою.

 

vkAuth здійснює двоетапну перевірку, по суті аналог описаної на початку цього блоку функції yadirAuth, але тільки для авторизації API Вконтакте, а не Яндекса.

 

Особливість роботи з API Вконтакте в даному випадку полягає в тому, що зареєструвати своє додаток і отримати доступ до API там досить просто, не потрібно заповнення форм в яких ви повинні докладно описати як і навіщо ви будете використовувати API. Так от, оскільки ви використовуєте при роботі з rvkstat свою програму, то навіть перехоплення коду підтвердження нічого не дає, оскільки він прив’язаний до вашого додатком, і для того, щоб з його допомогою перехопити маркер необхідно знати id secret вашого додатки, сам по собі код, не дозволить отримати за вас токен.

 

Функція vkGetToken дозволяє отримати токен найбільш швидким способом, до того ж отриманий токен прив’язаний до пристрою, з якого він був запитаний, тобто навіть якщо його хто отримає те може використовувати тільки з того ж ПК з якого він був запитаний. При цьому в URL при генерації токен варто після символу ‘#’, і як я вже говорив раніше, звіти Google Analytics не потрапляє.

 

 

rmytarget — Пакети для роботи з рекламним кабінетом MyTarget

 

На даний момент в API MyTarget існує 3 схеми авторизації, докладно про кожну можна дізнатися в документації.

 

Для авторизації API MyTarget в rmytarget призначена функція myTarAuth, за замовчуванням вона використовує схему авторизації Authorization Code Grant, яка дозволяє вам працювати з API MyTarget уникнувши процесу отримання персонального доступу до його використання. Тобто я вже зареєстрував додаток, воно було схвалено підтримкою API MyTarget, і ви надаєте йому доступ на роботу з аккаунтом від вашого імені.

 

Authorization Code Grant — це двоетапна схема авторизації, за змістом схожа на ту яку реалізує функція yadirAuth в пакеті ryandexdirect.

 

Працює вона наступним чином:

 

  • Ви запускаєте функцію, після чого відкривається браузер.
  • На сторінці сервісу MyTarget ви даєте дозвіл на доступ до вашого аккаунту.
  • Вас редиректит на сторінку пакета, де генерується код підтвердження. Максимальний час життя цього коду – 1 годину, але воно припиняється відразу після того, як ви з його допомогою отримали токен.
  • Скопійований код підтвердження ви вводите в консоль R і отримуєте токен для роботи з API.

 

При цьому код підтвердження є get параметром і фіксується в Analytics.

 

 

Але, якщо уважно подивитися, то крім коду (get параметр code), в URL присутній ще один параметр — state. Це рядок, теж маркер, який генерується самим пакетом rmytarget і відправляється в браузер відразу після запуску функції, цей параметр унікальний код підтвердження авторизації прив’язується до нього. Навіть якщо перехопити і код підтвердження state токен все одно скористатися цією комбінацією можна т. к. по перше ввести state токен нікуди, і як я вже писав він унікальний, і навіть якщо б і було куди його ввести повторно відправити його не можна. Тому ця схема авторизації повністю безпечна.

 

Але якщо вам все-таки такий варіант як здається підозрілим те rmytarget і функція myTarAuth дозволяє використовувати і залишилися дві схеми авторизації:

 

  • Client Credentials Grant, використовується для роботи з даними власного облікового запису через API
  • Agency Client Credentials Grant, використовується для роботи з даними власних клієнтів агентствменеджерів.

 

В даному випадку вам доведеться самостійно отримувати доступ до API MyTarget, на даний момент його можуть отримати тільки юридичні особи, і видається він у ручному режимі, для запиту доступу вам потрібно використовувати форму зворотного зв’язку, про всі подробиці ви можете дізнатися ось тут.

 

Отже, якщо все-таки вам вдалося зареєструвати своє додатки для роботи з API MyTarget ви цілком можете за допомогою функції myTarAuth пройти аутентифікацію за однією з двох перерахованих вище схем, для цього в аргумент code_grant передайте значення FALSE, і використовуйте наступні аргументи:

 

  • grant_type — Тип вашого аккаунта, у даному випадку звичайний клієнтський аккаунт, приймає значення “client_credentials” або “agency_client_credentials”.
  • agency_client_name — Логін клієнта з агентського аккаунта, використовується тільки якщо grant_type = “agency_client_credentials”.
  • client_id — ID видається вам за підтвердження доступу до API MyTarget.
  • client_secret — Видається для підтвердження доступу до API MyTarget разом з Client ID.

Приклад коду для авторизації за схемою Client Credentials Grant

myTargetAuth <- myTarAuth(code_grant = FALSE,
 grant_type = "client_credentials",
 client_id = "ХХХХХХХХ",
 client_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx") 

Приклад коду для авторизації за схемою Agency Client Credentials Grant

myTargetAuth <- myTarAuth(code_grant = FALSE,
 grant_type = "agency_client_credentials",
 client_id = "ХХХХХХХХ",
 client_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
 agency_client_name = "xxxxxxxxx@agency_client")

 

У разі використання цього підходу, аутентифікація буде проходить взагалі без взаємодії з сайтом пакету rmytarget.

 

Висновок

 

На цьому наша екскурсія закінчується, оскільки на сьогоднішній день вже більше 10000 пакетів опубліковано в основному репозиторії — CRAN, і більше 80000 на GitHub, у висновку хочу сказати ще кілька слів про безпеку їх використання.

 

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

 

До того ж хочу зазначити, що код всіх пакетів для мови R є відкритим, ви завжди можете попередньо переглянути код будь-якої його функції перед її запуском.

 

Так само спробуйте знайти статті про застосування цього пакета, користувачі R досить охоче діляться інформацією, і ви напевно знайдете кейси застосування більш-менш популярних пакетів. Якщо про пакет пишуть означає його використовують, і по всій видимості проблем з ним ні в кого не виникло.

 

Також подивіться хто є автором пакету, зробити це можна двома способами:

 

  1. Після установки пакета виконати команду utils::packageDescription("название_пакета")$Author
  2. Подивитися в исходнике пакету файл DESCRIPTION.

 

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

 

Якщо ставите пакет з GitHub то встановлюйте його саме з репозиторію автора, а не якогось відгалуження, як правило, у популярних репозиторіїв таких відгалужень досить багато:

 

 

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

 

Побачити з якогось сховища було створено його відгалуження можна на його сторінці на GitHub.

 

 

Нікому, ні за яких обставин не передавайте ваші токени, зберігайте їх так само, як зберігайте паролі від акаунтів, навіть якщо вам потрібно показати приклад коду, робіть це без вказівки токенів.

 

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

 

Успіхів вам, будьте пильні але не піддавайтеся параної.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *