🤶🏽 🤞🏿 📴 広告システムAPIを操作するためにRパッケージを使用することの安全性 🙍🏿 ™️ 🔭

最近、かなりの頻度で、さまざまな既製の拡張機能を使用することの安全性について質問を受け始めました。 R言語用に書かれたパッケージ、広告アカウントが間違った手に渡る可能性があります

この記事では、広告サービスのほとんどのパッケージおよびAPI内での認証メカニズムの動作方法と、記事で説明されているパッケージを可能な限り安全に使用する方法について詳しく説明します。

したがって、この記事の情報は技術的に最も簡単ではないため、テキストが通常のヘルプほどドライで技術的ではないため、ガイドの役割を試してみて、この記事の内容を最も簡単に認識できるようにします。

観光バスがすでに到着しているので、席に着いて現在の旅程をチェックしてください。

内容

セキュリティの質問はどこから来たのですか

私たちは進んでいます、パッケージを使用するときにセキュリティの質問がどこで発生したのかを理解してみましょう

一般に、広告パネルへのアクセスのセキュリティの問題は正当化されています。広告オフィスにはお金があり、多くの場合十分に小さいため、広告アカウントのセキュリティは、たとえばソーシャルネットワークの通常のユーザープロファイルへのアクセスのセキュリティよりもはるかに深刻な問題です。

実際には、ほとんどの場合、Rは承認時にパッケージのユーザーをブラウザーにリダイレクトし、最初にアカウントへのアクセスを確認します。この時点で、作業するAPIのあるサービスページに移動します。確認後、ユーザーはトークンが生成されるページまたは承認確認コードにリダイレクトされます。このコードは後でRコンソールに入力する必要があります。

そのため、トークン自体または承認確認コードが生成されるサイトはサードパーティであり、広告サービス自体とは関係がないため、ほとんどのユーザーが心配しています。もちろん、Google AnalyticsカウンターまたはYandex.Metricaカウンターとサイト所有者のどちらか、多くの場合、ほとんどの場合、パッケージの作成者でもあり、このサイトを通じてトークンを取得し、それらを介して広告資料を管理するためのアクセスを取得できます。

トークンの傍受であなたを脅かすもの

トークンが攻撃者の手に渡った場合、一般的にトークンを作成できるものについて話しましょう。

トークンは、アカウントへのアクセスに必要な他のすべてのデータと同じ方法で保存する必要があります。トークンがどちらかの手に落ちた場合、トークンを所有している人は広告資料を管理できます：トークンを削除、変更します。たとえば、広告のテキストとそれが導くリンクを変更することができます。

良いニュースは、上で書いたように、OAuthプロトコルを使用すると、アカウントからユーザー名とパスワードを提供せずに広告資料を管理する機会を与えることができるということです。誰かがあなたのトークンを手に入れたとしても、彼の助けを借りてあなたのアカウントを盗むことはできません。単一のAPIを使用してパスワードをリクエストしたり、さらに変更したりすることはできません。そのため、アカウントが奪われることはありませんが、アカウントからサイトを宣伝するのは簡単です。

誰かがトークンを所有している場合の対処方法

誤ってトークンを転送してしまった場合でも、パニックに陥らないでください。実際、これは世界の終わりではありません。ほとんどの場合、以前に発行されたトークンをリセットする多くのアクションがあります。たとえば、 Yandex.Direct APIのこのヘルプセクションでは、以前に発行されたトークンを呼び出すプロセスが詳細に説明されています。

ほとんどの場合、どの広告システムAPIを使用しているかに関係なく、アカウントのパスワードを変更するだけで十分です。

Rパッケージを最も安全に使用してAPI広告システムを操作する方法

そして今、私たちはツアーの最も興味深い部分に行きました。次に、私が開発したパッケージを使用するのが最も安全である方法についてお話します。彼らが使用するシステムAPIに精通しているからです。

発行されたすべてのトークンは、Rパッケージが機能するアプリケーションではなく、広告プラットフォームの側に保存されるため、広告プラットフォームAPIを操作するための登録済みアプリケーションのユーザーでさえ、トークン自体にアクセスできません。

ryandexdirectおよびrym-Yandex.Direct APIおよびYandex.Metricaを操作するためのパッケージ

どちらのパッケージもYandex OAuthサービスを使用しています;詳細については、このリンクを参照してください。

ryandexdirectパッケージには、承認のための2つの機能があります。

yadirAuth

-2段階認証
yadirGetToken

認証トークンのリクエスト

yadirAuth関数を使用する場合、つまりryandexdirectを使用する場合に使用することをお勧めします。承認プロセスはここで説明するスキームに従って進行します。この場合の唯一の脆弱性は、確認コードが生成されてからRコンソールに入力されるまでの期間です。

なぜ、Googleアナリティクスが確認コード生成ページへのアクセスに関するデータを表示するかを説明します。

つまりコードは「？」記号の後に来て、GoogleアナリティクスカウンターをキャプチャするGETパラメーターと見なされますが、このような確認コードの有効期間はそれを使用した直後に終了します。コンソールRに入力した直後。このようなコードの最大有効期間は10分です。

2番目の関数yadirGetToken

、ここで説明する他のスキームに従って承認を実行します。そして、それを使用するとき、確認コードは生成されません。パッケージにデータにアクセスする許可を与えると、トークン生成ページが表示されます。 URL自体のトークンは「＃」記号の後に返されます。これはgetパラメーターではなく、アンカーです。URLのこの部分はハッシュとも呼ばれます。ブラウザはこのデータを送信しないため、Google Analyticsレポートにそれ以上転送されません。レポートのこのページへのアクセスは次のように表示されます。

この2番目のケースでは、リスクはありませんが、yadirGetToken関数を使用するマイナス面は、資格情報をPC上のファイルに保存しないため、異なるRセッション間でこのデータを使用できないことです。これはあまり便利ではありません。ヘルプを使用して受け取ったトークンを保存し、スクリプトでテキスト文字列として使用します。そのようなトークンの有効期間は1年です。その後、yadirGetAuth関数を使用する場合のように、パッケージは自動的にトークンを置換できません。

承認用のrymパッケージにはrym_auth関数があります。これはyadirAuth関数の完全な類似物であり、その操作スキームについては既に詳細に説明しています。

rfacebookstat -Facebook広告アカウントを操作するためのパッケージ

Facebook Marketing APIの認証プロセスについては、ここで詳しく説明します。

認可を渡すために、rfacebookstatパッケージにはfbGetToken

関数があります。これは、 fbGetToken

ryandexdirectパッケージのfbGetToken

関数と同じように機能します。すべてがワンステップ認証によって実装されます。 Google Analyticsレポートでトークンが傍受される危険はありません。GoogleAnalyticsがトークン生成ページにアクセスしたときの画面があります。

rvkstat - VKアカウントを操作するためのパッケージ

Vkontakte認証プロセスは、 APIヘルプで説明されています。

rvkstatでは、許可に2つの機能のいずれかを使用できます。

vkAuth

承認スキーム承認コードフロー、つまり 2段階認証。
vkGetToken

デバイスにバインドされたトークンを使用した暗黙的なフロースキーム、ワンステップ認証による認証。

vkAuth

は、基本的にこのブロックの冒頭で説明したyadirAuth

関数に類似した2段階認証を提供しますが、Yandexではなく、Vkontakte APIでの承認のみです。

この場合、Vkontakte APIを使用することの特徴は、アプリケーションの登録とAPIへのアクセスが非常に簡単であり、APIを使用する方法と理由を詳しく説明する必要があるフォームに記入する必要がないことです。そのため、rvkstatを操作するときにアプリケーションを使用するため、確認コードのインターセプトも機能しません。アプリケーションに関連付けられており、トークンをインターセプトするには、アプリケーションのIDとシークレットを知る必要があります。コード自体ではトークンを取得できません。

vkGetToken

関数を使用すると、トークンを最速で取得できます。また、受信したトークンは、要求元のデバイスに関連付けられます。たとえ誰かがそれを入手したとしても、彼はそれが要求されたのと同じPCからのみそれを使うことができます。同時に、トークンは生成時にURLの「＃」記号の後に配置され、前述したように、Googleアナリティクスのレポートには含まれません。

rmytarget - MyTargetダッシュボードパッケージ

現時点では、MyTarget APIには3つの承認スキームがあります。それぞれの詳細については、ドキュメントを参照してください。

myTarAuth関数は、rmytargetのMyTarget APIでの承認を目的としています。デフォルトでは、 承認コード付与承認スキームを使用します。これにより、個人的にアクセスすることなくMyTarget APIを操作できます。つまり私はすでにアプリケーションを登録しており、MyTarget APIサポートによって承認されており、あなたはあなたに代わってアカウントを操作するためのアクセス権を与えます。

承認コードの付与は2段階の承認スキームであり、その意味はryandexdirectパッケージのyadirAuth

関数によって実装されるものと似ています。

次のように機能します。

関数を起動すると、ブラウザが開きます。
MyTargetサービスページで、アカウントにアクセスする許可を与えます。
確認コードが生成されるパッケージページにリダイレクトされます。このコードの最大有効期間は1時間ですが、トークンを受け取った直後に停止します。
コピーした確認コードをRコンソールに入力し、APIを操作するためのトークンを取得します。

この場合、確認コードは取得パラメーターであり、Google Analyticsレポートに記録されます。

しかし、注意深く見ると、コード（パラメーターコードの取得）に加えて、URLにはもう1つのパラメーターstateが含まれています。これは文字列であり、rmytargetパッケージ自体によって生成され、関数の開始直後にブラウザーに送信されるトークンです。このパラメーターは一意であり、承認確認コードが添付されます。確認コードと状態トークンの両方をインターセプトしても、この組み合わせを使用することはできません。まず、状態トークンを入力する場所がありません。既に記述したように、それは一意であり、入力する場所があったとしても、再度送信することはできません。したがって、この認可スキームは完全に安全です。

しかし、すべて同じ場合、このオプションは依然として疑わしいと思われるため、rmytargetとmyTarAuth

関数を使用すると、残りの2つの認証スキームを使用できます。

APIを介して個人アカウントデータを操作するために使用されるクライアント資格情報付与
代理店クライアント資格情報付与 、代理店/マネージャーの自身のクライアントのデータを操作するために使用されます。

この場合、MyTarget APIに個別にアクセスする必要があります。現時点では法人のみが取得でき、手動で発行されます。フィードバックフォームを使用するために必要なアクセスを要求するには、すべての詳細をこちらで確認できます。

したがって、MyTarget APIを使用するためにアプリケーションを登録することができた場合、 myTarAuth

関数を使用して上記の2つのスキームのいずれかを使用して簡単に認証できます。

grant_type-アカウントのタイプ（この場合は通常のクライアントアカウント）は、「client_credentials」または「agency_client_credentials」の値を取ります。
agency_client_name-エージェントアカウントからのクライアントのログイン。grant_type= "agency_client_credentials"の場合にのみ使用されます。
client_id -MyTarget APIへのアクセスを確認するときにIDが発行されます。
client_secret-クライアントIDとともにMyTarget APIへのアクセスを確認すると発行されます。

クライアント資格情報付与承認のサンプルコード

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

認可スキームの代理店クライアント資格情報付与のサンプルコード

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

このアプローチを使用する場合、認証はrmytargetパッケージサイトとの対話なしで渡されます。

おわりに

今日、10,000を超えるパッケージがメインリポジトリ（CRAN）で公開され、GitHubで80,000を超えるパッケージが公開されているため、ここでツアーを終了します。結論として、それらの使用の安全性についてもう少し言いたいと思います。

まず、CRANに必要なパッケージがあるかどうかに注意してください。これはR言語の公式リポジトリであるため、パッケージは、そこに公開される前に、このリポジトリの専門家チームによるかなり厳格なモデレーションの対象となります。そして、 CRANポリシーに完全に準拠するまで、パッケージはそこに公開されません。したがって、パッケージがCRANに存在する場合、その使用が安全であることを確認できます。

さらに、R言語のすべてのパッケージのコードが開いていることに注意してください。起動する前に、その関数のコードをいつでもプレビューできます。

また、このパッケージのアプリケーションに関する記事を見つけてみてください。Rユーザーは情報を共有することを望んでおり、多かれ少なかれ人気のあるパッケージを使用するケースを見つけるでしょう。彼らがパッケージについて書いている場合、それは彼らがそれを使用していることを意味し、明らかに誰もそれに関して問題を抱えていなかった。

また、パッケージの作成者を確認します。これを行うには2つの方法があります。

パッケージをインストールした後、 utils::packageDescription("_")$Author

コマンドを実行します
パッケージソースのDESCRIPTIONファイルを表示します。

広告アカウントや広告資料へのアクセスのトークンを取得するために、少しでも公開されている人が評判を危険にさらす可能性が低い場合は、世界中のネットワークで著者に関する情報を見つけてください。多くの場合、評判は疑わしい方法で受け取ったお金よりも高価です。

GitHubからパッケージをインストールし、ブランチからではなく、作者のリポジトリからインストールする場合、原則として、一般的なリポジトリにはそのようなブランチが多数あります。

Ryandexdirectブランチ

実際、ブランチはパッケージの作成者によって更新されないため、最新バージョンを受け取ることはできません。さらに、ブランチを作成したGitHubユーザーは、そのような変更を信頼するかどうかにかかわらず、コード自体に変更を加えることができます。

GitHubのページでブランチが作成されたリポジトリを確認できます。

どんな状況でもトークンを誰かに転送しないでください。コードの例を示す必要がある場合でも、トークンを指定せずに、アカウントからパスワードを保存するのと同じ方法でトークンを保存してください。

ほとんどの場合、Rパッケージの使用は完全に安全です。この記事でこれを納得させ、最も人気のある広告プラットフォームのAPIでの承認プロセスがどのように機能するかについて説明します。

頑張って、注意してください。しかし、偏執症に屈しないでください。

広告システムAPIを操作するためにRパッケージを使用することの安全性

内容

最新の広告サービスでの承認プロセスの仕組み