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

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

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

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

内容

1. 最新の広告サービスでの承認プロセスの仕組み
2. セキュリティの質問はどこから来たのですか
3. トークンの傍受であなたを脅かすもの
4. 誰かがトークンを所有している場合の対処方法

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

   
   

   5.1。 ryandexdirectおよびrym-Yandex.Direct APIおよびYandex.Metricaを操作するためのパッケージ
   5.2。 rfacebookstat- Facebook広告アカウントを操作するためのパッケージ
   5.3。 rvkstat-VKアカウントを操作するためのパッケージ
   5.4。 rmytarget-MyTargetダッシュボードパッケージ

   
   
6. おわりに

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

ツアーグループの会議場所はOAuthプロトコルです。

APIで作業しなければならなかったほとんどすべてのサービスは、OAuth 2.0プロトコルを使用して認証しますが、ハブについてはすでに詳細を書いています。その荒野を散歩したい人は、このような機会があります、 こことここでできます

その意味を一言で説明すると、OAuthは、ユーザー名とパスワードを広告アカウントからこのアプリケーションに転送することなく、ユーザーに許可を与えたアプリケーション（この場合、Rパッケージはそのようなアプリケーションになります）に許可を与えます。セキュリティ上の理由からです。

ユーザー名とパスワードの代わりに、OAuthプロトコルはトークンを使用します。これは、暗号化された形式で情報を保存する文字と数字のセットで構成される生成された文字列です。

• アプリケーションがリクエストを実行するユーザーに代わって
• ユーザーは、このアプリケーションによるデータへのアクセスを本当に許可しましたか
• ユーザー自身が参照する広告資料を使用するために必要な許可をユーザー自身が持っていますか

承認プロセスとAPIを使用するには、通常、アプリケーションをAPIに登録する必要があります。 さらに、このアプリケーションは、特定の広告システムのAPIサポートチームから確認を受け取る必要があります。 著者は最初に、APIを使用する方法と理由を詳細に説明します。これはすべてチェック、モデレートされ、広告プラットフォーム側のサポートにセキュリティの質問がない場合にのみ、パッケージの作成者はAPIにアクセスし、登録されたアプリケーションの助けを借りて、パッケージでは、このアプリケーションに発行されたIDとシークレットを使用して認証できます。

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

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

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

実際には、ほとんどの場合、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つの方法があります。

1. パッケージをインストールした後、 utils::packageDescription("_")$Authorコマンドを実行します
2. パッケージソースのDESCRIPTIONファイルを表示します。

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

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

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

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

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

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

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