第6回　WebAPI、認証APIのセキュリティ

WebAPIの公開

APIとは、何らかの機能を提供するプログラムのことです。WebAPIとは、Webで提供されたAPIということです。たとえば、地図データを提供するAPIや商品の検索結果を提供するAPIが有名です。なるべく多くの人にアクセスしてほしい情報を持っている企業は、WebAPIとして情報を提供することが多くなりました。WebAPIという便利なインターフェースを用意することで多くのユーザにアクセスしてもらい、広告ビジネス等につなげていくのが狙いです。

またWebAPIは、多くの形式に対応していたほうが、多くのユーザに利用してもらうことができるため、なるべく多くの出力形式に対応しようとする傾向があります。以前はSOAPという形式が多く使われていましたが、実装方法が煩雑であったため、現在ではREST、JSON、JSONPのように実装がシンプルな形式のものが多く使われています。

WebAPIを公開する際のセキュリティ

WebAPIを公開する場合に発生しやすい脆弱性を紹介します。発生原理はすでに紹介したものもありますが、WebAPIという観点から見て、もう一度まとめておきたいと思います。実際にWebAPIを公開しているサイトで多く見つかっているものです。

WebAPIのクロスサイトスクリプティング対策

たとえば、JSONP形式で出力を行うWebAPIは、パラメータとしてコールバック関数名を取得します。

http://www.example.com/json?func=callback

レスポンスは、以下のようにJSONPのデータになります。

callback( { "name" : "Fukumori" } );

この場合、コールバック関数名を指定可能なのですが、関数名の中に不正なスクリプトを挿入することが可能です。

http://www.example.com/json?func=<script>alert('xss')</script>

すると、レスポンスは次のようになります。

<script>alert('xss')</script>( { "name" : "Fukumori" } );

このレスポンスはJSONPのデータであって、HTMLファイルではないので、本来であればスクリプトは実行されません。しかし第1回で紹介したように、Internet Explorerの「内容によってファイルを開く」仕様があるため、HTMLとして解釈されてしまいます。その結果として、スクリプトが実行されてしまいます。

WebAPIを公開するドメイン

WebAPIを公開するドメインは、他のサービスとは別のドメインにするほうが安全です。クロスドメインアクセスを許可するドメインと、そうでないドメインを分離することで、Flash等を利用した意図しないクロスドメインアクセスによって、情報が漏えいすることを防ぐためです。

WebAPIでの認証

機密情報を提供する場合には、ユーザ認証を行う必要があります。WebAPIでの認証は一般のWebアプリケーションとは異なる点があります。基本的に、WebAPIを利用するのは人間ではなくプログラムです。そのため一般のWebアプリケーションと同じようなログイン、セッション管理、ログアウト等を考える必要がない場合もあります。その場合はBasic認証や、Digest認証を使用することができます。

WebAPIへのクロスドメインアクセス

第3,4回で説明したように、機密情報をJSON、JSONP形式のデータとして提供する場合には、SCRIPTタグから読み込まされた際にデータが漏洩しないように注意が必要です。

機密情報の通信

機密情報を含んだデータをやりとりする場合には、WebAPIをHTTPSで提供する必要があります。最も初歩的なことのように思われますが、不備のあるサイトが意外と多く存在します。

認証キーの利用

WebAPIはプログラムから利用されることを前提として作られているため、攻撃者から見ても攻撃に役立つ便利な機能になります。そこで、不正利用されにくくする手段として、認証キーの利用が考えられます。メールアドレス等をもとにユーザ登録を行い、WebAPIを利用するための認証キーを発行し、WebAPI利用の際には認証キーを必須にします。その結果、不正利用のハードルを上げ、不正利用された場合には発見しやすくなります。しかし、簡単に他人の認証キーを利用することができたり、使い捨てのメールアドレスでユーザ登録されたりと、完全に不正利用を防ぐことはできません。あくまで不正利用のハードルを上げるためという位置づけで考えてください。

また、WebAPIはプログラムから利用されるため負荷が高くなりがちですので、認証キーを利用して、利用回数制限を設けることもできます。

認証APIの仕組み

あるサイトの認証情報(たとえばユーザID)を、別のサイトから利用したい場合があります。たとえば、ブログでのコメント書き込みの際に認証を行いたい場合などです。その場合、ID／パスワードを別のサイトに入力する必要がありました。しかし、セキュリティのことを考えると、ユーザはID／パスワードを別のサイトに入力したくはないはずです。また、サイトの管理者も余計な個人情報を受け取りたくはありません。

そこで考え出されたのが認証APIです。認証APIを使うことで、ユーザは認証情報利用サイトにIDとパスワードを入力せず、認証情報提供サイトと直接認証を行うことができます。いくつかのサイトが認証APIを提供していますが、細かい違いはあるものの、基本的な考え方は同じですので、一般的な認証APIの説明をしたいと思います。

ユーザが認証情報利用サイトにアクセスします。(1)

認証情報利用サイトがユーザの認証情報を利用したい場合、ユーザを認証プロバイダ（認証情報提供サイト）にアクセスさせます。(2)

認証プロバイダにアクセスしたユーザは、そのサイトが確かに認証プロバイダであることを確認して、認証プロバイダ用のIDとパスワードを入力します。(3)

認証に成功すると、認証プロバイダは認証情報利用サイトへとユーザを遷移させます。(4)

認証情報利用サイトは、認証プロバイダへ問い合わせることで、ユーザの情報を受け取ることができます。(5)(6)

このように認証プロバイダが認証APIを提供していれば、ユーザと認証情報利用サイトの間でIDとパスワードをやりとりしなくても、認証情報利用サイトは必要な情報のみを取得することができます。

認証APIのセキュリティ

これまで、各企業や団体は独自の仕様で認証APIを提供していました。そのため、認証APIを提供するサービスが増えた場合、ユーザは各サービスごとにID、パスワードを入力する必要がありました。そこで特定の認証プロバイダに頼るのではなく、誰でも認証プロバイダになれるようにしようという動きがあります。OpenIDはその代表例です。認証APIを提供する方法を規約として定め、その規約に則ってサービスを開発すれば、任意の認証プロバイダを利用することができ、ユーザの負担を減らすことができるというわけです。ユーザから見れば、シングルサインオンが実現されます。

しかし、どの認証プロバイダを利用するかはユーザに委ねられています。そのため、セキュリティを考慮していない認証プロバイダを選んでしまった場合には、認証プロバイダがSQLインジェクションやセッションハイジャックのような攻撃に遭うことで、認証情報が盗まれることも考えられます。また、フィッシングのように、偽物の認証プロバイダに情報を入力させられてしまうことで、認証情報が盗まれることも考えられます。

以下に、セキュアな認証プロバイダを見分ける上での最低限のポイントを紹介します。

SSLが適切に使われているか

ログイン画面およびログイン後の画面で、HTTPSが使われているかを確認します。

情報利用先のURLが表示されるか

どのサイトにユーザの情報を送信するかについて、ユーザに確認してもらうためです。ユーザが意図しないサイトに情報を送信することを防ぐことができます。

フィッシングの可能性について注意を促しているか

偽物のサイトに情報を入力させられてしまった場合の被害は甚大になります。そのようなリスクを把握しており、ユーザに注意喚起しているということは、その認証プロバイダがセキュリティに気を遣っているということがわかります。

現在、認証プロバイダはより多くのユーザ数獲得に乗り出しています。ユーザ数が多いということが、認証プロバイダとしての信頼性につながると考えているためだと思われます。ユーザがセキュリティの観点から認証プロバイダを選択することで、セキュリティ意識の低い認証プロバイダが淘汰されていくのではないでしょうか。

また、認証情報利用サイトの側からも、どの認証プロバイダを信頼するかについて気を配るべきです。認証プロバイダの中にはまったく認証を行わないで、匿名サービスを提供するものも存在します。認証情報利用サイトで提供するサービスの種類によっては、匿名サービスを提供する認証プロバイダを拒否することも、検討する必要があります。