JavaScript++かも日記

【JSON】Remote JSON - JSONP

【Ajax , JSON , JavaScript , Webサービス , セキュリティ 】 ブックマーク-- Hatena  / Livedoor

Remote JSON - JSONP
http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/

Web 2.0で変わるWebプログラミングの常識：
実は、Ajaxのウラにこそ勝算がある (2/5)
http://www.itmedia.co.jp/enterprise/articles/0608/25/news010_2.html

Yahoo! Web Services　の Using callback=function:
http://developer.yahoo.com/common/json.html#output

追記2006.8.27 JSON with Padding Test
http://www.geocities.jp/stormriders999/jsontest.html

追記2006.8.27 [json]ブラウザからJSONで呼び出せるサービス一覧
http://d.hatena.ne.jp/shinichitomita/20060825/1156504036

1.ドメイン超えをするためにXHR+プロクシではなくJavaScriptのロードを使う、

ということと、

2.着信コールバック名を、クライアント側からURLクエリとしてサーバーへ渡し/返してもらう、ことで着信後の動作を自動化する

という仕組みのようです。信頼のできる関係の中で、有益な方法かなと思います。

サーバーからJavaScriptデータの着信コールバックを渡す仕組み自体は、私の関係では、古くは、たとえば10年前のNewGameWeb　用ランキングなどもそうですけれど、普通に使われていた手法だと思いますが、この新しい所は、「XHRのクロスドメインを超えて最近普及してきたWebサービスをクライアントがコールバックを指定する形で利用したい」という歴史性?かもしれません。

まだ、ざっとみただけで断言はできないので、勘違いなど指摘いただけると有り難いのですけれど、この場合のリスクには要注意かなと思います。クライアントの指定するスクリプトをサーバーが通過させなければならないからです。まさに、XHRが禁止したクロスサイトの攻撃が解禁されるわけです。

信頼不能な不特定多数のクライアント入力を前提とした(たとえば、掲示板など)では、どんなコールバックを渡されるかわからないので、防御構築には、結構手間が掛かるかもしれません。

このJSONPのページにある事例では、(new Date()).getTime();をuidに使用することで、リクエストとレスポンスの整合をはかっているようですが、クライアントの時間はあまり信用できないことと、getTime()だけでは、経験的には、複数入力時に衝突する可能性も低くないような気がしますし、推測も簡単そうです。(ちなみに、程度の違いで気休めといわれてしまうかもしれませんが、AjaSQLでもリクエストとレスポンスの整合を解決するルーチンをもうけているのですが、そこでは、クエリ+α+getTimeにMD5をかけています。)

YahooのUsing callback=functionの方は、信頼すべき相手は、Yahoo!です。その信頼を確保することが、ポイントのひとつかなと思います。

#ところで、少なくとも、こういう仕組みを利用するときには、たとえ相手が、Yahoo!やGoogleであっても、ログインページなど重要な入力要素の設置されたページで使わない心得は必須かも。
参考:ドメイン間のデータ送信テスト
http://game.gr.jp/secur/door/test1.htm

#で、もし、サーバー側をいじれる立場の人が、クライアントでクロスサイトなデータのやりとりをしたいなら、クライアントからいじれない、たとえば、使い捨て着信コールバックなどをサーバー側から出力してダイナミックロード関数とか使うのも良いかも。

#ただ、こういうものの使われ方には無数のケースがあり得るので一律に語るのは難しいです。ま、どんなときも、作る側の注意は必須ということでしょうか。＜一般化しすぎ(笑;;;

---

---

【コメント】(←clickで入力欄open)