7pay「外部ID連携」の脆弱性に対するソーシャルPLUSの見解と本当の問題点

スマホ決済サービス「7pay」の一部アカウントが第三者による不正アクセスを受けた事件を受けて、一部のメディアにおいてソーシャルログインの安全性や外部ID連携の脆弱性について話題になりました。

本記事では、「外部ID連携」の脆弱性に対するソーシャルPLUSの見解と本当の問題点はどこにあるのかをまとめています。

はじめに

7payの「外部ID連携」の脆弱性について話題になっており、下記のBUSINESS INSIDERの記事に詳細が書かれています。

記事では、ネイティブアプリ上での外部ID認証 (以下ソーシャルログイン) 実装に不備があったことが原因とあります。

ソーシャルログイン自体が脆弱であったわけではないではないのですが、第一報がソーシャルログインのみ一時停止するという発表だったことが不安を煽る結果となり、弊社のお客様から、7payのソーシャルログインはソーシャルPLUSでの実装ですか?という問い合わせがいくつかよせられました。

結論から申し上げると7payのソーシャルログインはソーシャルPLUSではございません。

今回のようなことが起こることでソーシャルログインが安全ではないという誤解が広まらないよう、本記事で以下の2点について述べたいと思います。

  • ソーシャルPLUSのセキュリティ
  • セキュリティ以上に考えなければならない問題点

ソーシャルPLUSのセキュリティ

弊社のサービスはWEBサイトでもアプリ上でも使われておりますが、大半はWEBサイト上で使われています。
基本的に情報のやり取りは WebAPI で行いますが、IDの書き換えによる”なりすまし”のログインや、IDの特定、トークンの入手ができないよう対策しています。細かく挙げればキリがないのですが、大まかにわかりやすいソーシャルPLUS側でのセキュリティ対策をまとめました。

  • WebAPI を呼び出すためには API Key が必要
    • API Key はお客様サイトごとに事前に発行するシークレットキー
    • API Key には十分な長さのランダムな文字列を利用
  • ネイティブアプリ実装時は API Key の代わりに公開鍵暗号方式による署名検証を用いてセキュリティを担保している
  • トークンは「一度きり有効」かつ「有効期限が短い」ワンタイムトークン
  • WebAPI の呼び出し元 IP アドレスも予め指定出来る
  • 年に1回、外部の脆弱性検査も受けている

WebAPI を呼び出すためには特定困難な文字列の API Key が必須で、利用するトークンは一度きり有効なワンタイムトークンです。加えて WebAPI の呼び出し元 IP アドレスも予め指定出来るので、外部からアクセスすることは出来ません。さらに年に1回、外部の脆弱性検査も受けて自分達で気付けていないセキュリティホールがないかも確認しています。

間接的ではありますが、導入事例に大手企業が並んでいることから、企業側の厳しいセキュリティチェックを通過した上でサービス導入に至っている点も考慮していただけると幸いです。

ただし、ソーシャルPLUSとしてセキュアな環境を用意しても、ソーシャルPLUSの WebAPI で取得した情報をWEBサイトがフロント側で引き渡しをするような実装をされてしまうと、フロント側で情報を引き渡しているタイミングにIDの書き換えが出来てしまいます。

とにかくサイト改修を最小限に抑えたいという思いで、工数やコストを最優先のプライオリティにしてしまうことは非常に危険です。今回の事件を機に、ソーシャルログインに限らず各企業がサイト改修の際にセキュリティ面をより一層配慮していただけるようになることを願います。

セキュリティ以上に考えなければならない問題点

今回の問題については単純なセキュリティの問題ではないと思いました。

先進的な企業では過去に比べてエンジニアの立ち位置も大きく変わったと思います。ただし経営陣がエンジニアリングに対して理解が少ない企業については過去から大きく変わった印象はなく、そういった企業の方がまだまだ多い印象です。

別記事にもありましたが、一番の問題点はリリース日ありきの開発スケジュールではないかと思っています。

当たり前の話ですが、機能を開発する際に要件を定めて開発工数を見積もることで、リリースする目標の日程を事前に決めます。要件を全て満たしてリリース目標の日程を守れることに越したことはありませんが、経験上、今まで作ったことがない新しい機能を作るための見積もりの精度はさほど高くありません。また見積もりの精度を高めるために見積もり作成により多くの時間を割くのであれば、見積もりはある程度にして作り始めながらリリース日を探る方が合理的です。

と理想論を述べましたが、自社開発ならまだしも受託開発であればそうもいかないことは理解しています。

ビジネス視点で考えると、競合に負けたくない、どこよりも早く、1日でも早くリリースしたい、他社に先行されたのでパイを奪い返したい等、時間を急ぐ理由はいくらでもあるからです。だからと言って、開発者を疲弊させてまでリリースを急いでしまうことは非常に危険です。

実際にどうだったのかを知る由はないと思うのですが、時間をかけて作った機能があのような結果になってしまっては開発者が一番報われないのではと言うのが正直な感想です。

サービスを利用するユーザー・サービスを提供する企業・サービスを企画/開発する人達の全てが幸せになるよう、リリース日ありきの開発ではなく現場の意向や進行状況を踏まえた流動的な開発が進められると、今回のような悲しい事件がなくなり、インターネットにより世の中がより良くなっていくと思います。

※2019年7月27日:「共通鍵暗号方式」→「公開鍵暗号方式」に修正しました。

「ソーシャルPLUS」について

弊社フィードフォースが提供するソーシャルPLUS では、ソーシャルログイン機能を既存のWebサイトに手軽に導入することが出来る「ソーシャルログイン/ID連携サービス」を提供しています。

>お役立ち資料ダウンロード

お役立ち資料ダウンロード

データフィード、ダイナミック広告、ソーシャルログインについてもっと詳しく知りたい!という方に向けてお役立ち資料をご用意いたしました。
最新トレンドや事例、活用ポイントを解説した資料を無料でダウンロードいただけます。是非ご活用ください。

CTR IMG