第1章 総論
マッシュアップにおけるセキュアプログラミング

Webアプリケーションを一から企画・要件定義・設計する従来のソフトウェアの構成ではなく、他者の Web サービスを主要な部分に利用して開発する「マッシュアップ」の構成においては、想定される脅威の構図が変化している。脅威の構図の変化に対応するセキュアプログラミングの論点が存在する。

マッシュアップとは

近年、Web アプリケーションの開発プロセスに特徴的な変化が見受けられる。その要因として顕著なのはソフトウェア部品や機能が Web インタフェイスをもつサービスとして公開されるようになったことが挙げられ、これらを利用する Web サイトが増えている。

音楽 DJ の世界において複数の既存の楽曲を組み合わせて新たな楽曲を創造することが「マッシュアップ」と呼ばれていることになぞらえて、Web アプリケーションを組み合わせによって開発することも「マッシュアップ」と呼ばれるようになった。短期的も変化する業務要件の変化に応じてアプリケーション開発を行うために、「マッシュアップ」は広く行われるようになってきているようである。

ユーザに「マッシュアップ」されたコンテンツやサービスを提供するためのシステム構成方法には複数の方法がある。Web ブラウザ側の機能を利用する場合もあれば、Web サーバ側の機能を利用する場合もある。

マッシュアップのふたつのタイプ

「マッシュアップ」には「クライアント側マッシュアップ」と「サーバ側マッシュアップ」のふたつの形態がある。

「クライアント側マッシュアップ」は、ブラウザにロードされた JavaScript コードの中から主催者の異なる複数の Web サービス（異なる複数の「源泉（origin）」）を利用する形態のマッシュアップである。

「サーバ側マッシュアップ」は、ブラウザにロードされたコンテンツの出身元の Web サーバ上のプログラムが、主催者の異なる複数の Web サービスから集めたリソースを編集・統合した上でブラウザへ引き渡す形態のマッシュアップである。

本稿で用いる名称

以降、登場するサーバ等の名称として下記の用語を用いる。

「主催者サーバ」と「素材サーバ」

マッシュアップの全体構成を企画する主催者が提供するWebサーバを「主催者サーバ」と呼ぶ。
ユーザによって意識的に直接アクセスされる。

マッシュアップの部分を構成する素材を提供するサーバを「素材サーバ」と呼ぶ。

「ホストコンテンツ」と「ゲストリソース」

「主催者サーバ」からユーザのブラウザにロードされるプログラムコードを「ホストコンテンツ」と呼ぶ。

「素材サーバ」から提供されるリソースを「ゲストリソース」と呼ぶ。

「集約地点」

「ゲストリソース」が「ホストコンテンツ」によって最初に取り込まれる地点。
集約地点が「クライアント側」にあるか「サーバ側」にあるかによって、「クライアント側マッシュアップ」と「サーバ側マッシュアップ」に分かれる。

「自源泉」と「他源泉」　（図には明示していない）

「同一源泉（Same Origin）」概念に照らして同一源泉内のサーバのリソースへのアクセスを「自源泉」へのアクセスと呼び、同一源泉の範囲外のサーバのリソースへのアクセスを「他源泉」へのアクセスと呼ぶ。
（「同一源泉（Same Origin）」概念については、後述する。）

マッシュアップを容易にした技術

マッシュアップは下記の技術の進歩と普及によって実装することが容易になった。

(1) JavaScriptプログラミング環境の進歩

• AjaxのXMLHttpRequest
• HTML5
• サーバサイドJavaScript
• CommonJS

(2)「Webサービス」技術の普及

• XML
• SOAP
• JSON
• REST風（RESTful）
  

マッシュアップとWebサービスの寿命

programmable web によると、マッシュアップ素材として最も多く使われているWebサービスの上位には、「Google Maps」、「Twitter」、「You Tube」、「Flickr」、「Amazon eCommerce」等が名前を連 ねている。これらは、マッシュアップの中に組み入れることのできる視覚的要素、テキスト、決済機能等を提供するものである。

上記のWebサービスが多用されている理由のひとつには、支持者を 多数もつWebサイトが提供しているWebサービスである点が挙げられる。これらポータルのサイトの周囲には、Webサービスを通じてそ のサイトから情報を分けてもらう複数のマッシュアップサイトが付 随し、ある種の「共生関係」が形成される。

これらポータルのサイトのWebサービスは、数年前から存在しており、今後も比較的長期にわたって存続するものもあろう。一方、マッシュアップサイトの方は短い寿命で終わる可能性が高い。既存Webサービスを組み入れる形をとり、短期間かつ低コストで立 ち上げることができるのが、マッシュアップサイトである。しかし、立ち上げが早いからこそ、目的に合わなくなればすぐに捨てて別のマッシュアップを構成することになる。

マッシュアップのふたつのタイプ

クライアント側マッシュアップ

クライアントサイドマッシュアップでは、ブラウザ内で動くスクリプト (JavaScript コード) が第三者のサーバ (複数可) からリソースをロードし、それらの組み合わせによって自己のサービス提供内容を生み出す。

サーバ側マッシュアップ

サーバサイドマッシュアップでは、ひとつの Webサービスが、その処理の中でさらに別の Webサービスを呼び出し、得られた結果を編集・統合して自己のサービス提供内容を生み出す形をとる。

分散されたサーバを組み合わせてWebサーバアプリケーションを構築することはしばしば行われることであるが、このうち他者が運営するWebサービスへの呼び出しを用いるものを「マッシュアップ」と呼ぶ慣行が定着している模様である。

対比表

「クライアントサイドマッシュアップ」と「サーバサイドマッシュアップ」には、それぞれ異なる長所・短所が存在する。主な事項は下表の通りである。

分類		クライアントサイド マッシュアップ		サーバサイド マッシュアップ
機能	API 呼出し形態の バリエーション	◎	次の 3 種類のマッシュアップ API 呼出し形態を利用できる：(1)Web サービス呼出し型実装、(2)スクリプト取り込み型実装、(3)ウィジェット型実装	△	次の 1 種類のマッシュアップ API 呼出し形態に限定される：(1)Web サービス呼出し型実装
性能	レスポンス	◎	クライアント側で迅速に行える処理はレスポンスが早い	△	サーバに委ねる処理はネットワーク通信を待つ分レスポンスが遅い
	ネットワーク通信	△	端末が行うネットワーク通信は比較的多くなる	◎	端末が行うネットワーク通信を必要最小限にとどめることができる
同一源泉ポリシー	他源泉リクエスト における制約	△	他源泉の Web サービス呼出しのプログラミングに制約がある。制約を越えるための複数の実装手法が知られているが、中には JSONP 等、セキュリティリスクの大きなものもある	◎	クライアントにおいては他源泉リクエストを必要としない。 サーバにおいては複数源泉の Web サービス呼出しのプログラミングに制約はない
侵害のリスク	悪意のAPIサイト への対抗	△	供給された悪意のデータ (スクリプト) によって、ブラウザ、ユーザ、他の Web サービスサイト等が侵害されるおそれがある	◎	悪意のデータが供給されても検出して排除し、ブラウザ、ユーザ、他の Web サービスサイト等を保護する機会がある
	APIキー の暴露	△	Web サービスを呼出せる資格を表す「APIキー」をユーザに秘密にできない	◎	「APIキー」をユーザに知られずに済む
	ソースコード の暴露	△	クライアントサイドプログラムのソースコードをユーザに秘密にできない	◎	ユーザに暴露されるソースコードの量を少なくできる
	リクエスト強要攻撃 への対抗	△	Web サービスサイトが第三者からのリクエスト強要（CSRF）攻撃を受けるおそれがある。自サイトに関しても警戒と対策が必要	◎	Web サービスサイトへのリクエスト強要（CSRF）攻撃は成立しない。自サイトに関しては警戒と対策が必要

 

マッシュアップのために提供される API、「マッシュアップAPI」の形態の中には、HTTPプロトコルによる通信の形をとるもの（「Webサービス」） の他に、スクリプトモジュールやウィジェットの形をとるものもある。これらは、HTML タグやクライアント側スクリプトを用いてロードされるよう作られていることが多い。すなわち、クライアントサイドマッシュアップを前提としたマッシュアップ API が存在する。これらはサーバサイドマッシュアップによる利用に向いていない。

また、ブラウザの機能は年々進化しているので、担える機能も変化しつつある。継続的にブラウザが備えるマッシュアップ関連機能の動向を見まもる必要がある。

事前にサーバ間で取り決め

サーバ側マッシュアップにおいては、その前提として、主催者サーバと素材サーバとの間で事前に何らかの取り決めが行われる。（例： 識別子の配布・交換、シークレットの共有等）

注：

• あらかじめサーバ間の事前連携を行わず、必要となった時点で初めて主催者サーバと素材サーバとが関係を結ぶ形態は、現時点のマッシュアップにおいては考えにくい。将来、サーバが自らの信頼レベルを相互に主張し合い、条件が合えば自動で連携するといった枠組みが登場した暁には、起こる可能性がある。
• 上記2点は、素材サーバから提供されるゲストリソースが、公開された、アクセス制限の設けられていないリソースのみからなる場合はその限りでない
• 単純に、利用側がAPIキーを取得するのみ、という事前連携もある

マッシュアップにおける脅威と対策

マッシュアップにおけるセキュアプログラミングの考慮事項を、「マッシュアップ」の章において述べる。