APIの承認方法の1つはOAuthです。 つまり、すべてが次のように行われます。VKアプリケーションを作成し、そのIDを取得してから、ユーザーのブラウザーをそのアドレスに送信します。
https://oauth.vk.com/authorize" + "?client_id=123" // ID + "&display=page" + "&redirect_uri=https://oauth.vk.com/blank.html" // URL, . . , + "&scope= " + "&response_type=token" + "&v=5.52" + "&state=123456"
これは暗黙的なフロー認証です。
ユーザーがログインしている場合は、すぐにアプリケーションをインストールするように求められます。そうでない場合は、最初にログインしてからインストールします。 アプリケーションが既にインストールされている場合、ハッシュ内のトークンを使用してページに直接移動します。 次は、APIを使用した作業です。
最も興味深いことは、VCを去った後に始まります。 アプリケーションには、 vk.com/login.php?op=logoutのようなexitへのリンクがある場合があります。 これは、VKを終了するための標準リンクです。 ただし、ユーザーがVKを離れた後も、Cookieは機能し続けます。
したがって、再度認証ページを表示する場合は、まったく異なるユーザー名とパスワードを入力してください。最初のユーザーページを引き続き使用できます。
つまり 作業は次のように実行されます-ユーザーP1は、アプリケーションを介してVKによって承認されます。 上記の例では、スタンドアロンアプリケーションを使用していますが、他のタイプのアプリケーションでも動作する可能性があります。 次に、ユーザーP1が上記のVKの終了リンクをクリックします。 その後、ブラウザまたはアプリケーションを介して許可なしでVCにアクセスすることはできません 。 次に、ユーザーP2がアプリケーションからログインします。 次に、ブラウザを介して、ユーザーは自分のページP2ではなく、ユーザーのページP1にアクセスします。 そして、彼はこのページで絶対に何でもできます。この段階でのアプリケーションはもはや必要ではなく、何の役割も果たしません。
面白いのは、アプリケーションで最も無害な権利を使用できることです。 つまり、写真、オーディオ、ビデオ、メッセージ、その他すべてへのアクセスを求めることでユーザーを怖がらせる必要はありません。 基本的なものだけを残すことができます-それがすべてです。 Cookieは引き続き完全に機能します。Cookieを使用すると、ユーザーのページに直接アクセスできます。
この機能は脆弱性と見なされますか？自分で考えてください。 私の意見では、これは少なくとも、ユーザーが「終了」ボタンをクリックして、自分のページが安全になったことを期待することではありません。
このメモを書いているとき、VKユーザーは負傷しませんでした。
UPD。 認証中に、IE7ブラウザーが使用されました。
サポートとして、ここで記事を公開するずっと前に書きました。 実際、ここでの記事の公開は、サポートが「これはバグではなく機能であるが、おそらく何かが将来変わる可能性がある」という精神でこのシグナルを無視したという事実の結果として発生しました。