Amon2とJSONとセキュリティ - tokuhirom's blog
[1]http://d.hatena.ne.jp/ockeghem/20110907/p1[2]http://www.atmarkit.co.jp/fcoding/articles/webapp/05/webapp05a.html[3] http://msdn.microsoft.com/ja-jp/asp.net/ff713315[4] http://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/cross-site_including.phpあたりをよんで、JSON とセキュリティについてかんがえてみた。 ここで、有効とされている対策のうち while(1); を先頭に付与するPOST ですべて処理するといったあたりは、RESTful でないし、BK 感がひどいというか本質的ではないのでできるだけやりたくない。 また、Amon2 では互換
PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)～JSON等の想定外読み出しによる攻撃～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
9/5（月）のmemo - F&R:ITmemo
jQueryについて text()メソッド - エスケープされる。 jQuery.get( url, data, callback ) - HTTP(GET)通信でページを読み込み get() - DOMエレメントの配列にアクセス html() - 最初の要素をHTML文字列で返す。組み込みであるinnerHTMLの値と同じ。 empty() - 各要素の子要素を全て削除し、空にする。 同時にイベントハンドラや内部でキャッシュしているデータも削除する。 PHPについて eval — 文字列を PHP コードとして評価する XSSについて XSSに関して split関数で\タグで分けるのがいいみたい。 splitー指定した区切り文字で分割し、その結果を配列として返す 格納する配列名=文字列.split(区切文字) 通常のWebアプリケーションの場合、 HTMLで表示するパラメータのエスケープ
JSON U+2028, U+2029 問題回避方法
Unicode の文字 U+2028 (Line Separator) および U+2029 (Paragraph Separator) が含まれる JSON コードを解釈して JavaScript オブジェクトに変換しようとするとエラーになる問題の回避方法を示し、その問題の発生状況と回避方法の効果を実証する。更に当ページをさまざまなブラウザで参照することで発生する/しないの判定も行う。 この問題を回避するには幾つかの方法がある。それを検討してみる。 問題が発生しないブラウザを使用する。 デベロッパーにとっては最も楽な回避方法である。しかし企業のイントラネットなどでブラウザを固定することができない限りこの選択肢を採用できないだろう。更にたとえ企業のイントラネットであったとしてもサポート対象のブラウザで問題が発生しているからこのページを参照しているのだと思われる。 主要ブラウザの中で問題が発
U+2028 と U+2029 が JSON データに含まれていると JavaScript の eval でエラーになる
Unicode の文字 U+2028 と U+2029 が JSON データに含まれていると、JavaScript の eval 関数がこれをうまく評価できずに例外を出してしまいます。これについてまとめました。 Unicode Consortium の Unicode Character Database から辿れる UnicodeData.txt には文字 U+2028 と U+2029 が次のように載っています。 2028;LINE SEPARATOR;Zl;0;WS;;;;;N;;;;; 2029;PARAGRAPH SEPARATOR;Zp;0;B;;;;;N;;;;; UnicodeData.txt から2010年1月18日に引用 一種の改行みたいなものです。JSON データの文字列にこの二つが含まれているとブラウザの JavaScript がその JSON データを取得して J
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
SaaSに潜む脅威「JSONハイジャック」，IPSで情報漏えい対策を
インターネット上のWebサイトでグループウエアやERP（統合基幹業務）といった業務アプリケーションを提供するサービスが注目を集めている。いわゆるSaaS（software as a service）だ。ユーザーは，インターネット回線さえあればいつでもアプリケーションを利用できる。 このようなサービスを利用する際，サービス提供者の情報漏えい対策が気になるIT管理者は少なくないだろう。ただ実際には，ユーザーは複数のサービス提供事業者のサービス，自社のシステムを組み合わせて利用するケースが多くなる。もちろん，取引先などのシステムとの連携も考えられる。こうした環境に備えるなら，提供者側のセキュリティ・レベルに注意するだけでなく，ユーザー側で可能な限り対策を施すことが重要になる。 そこで今回は，様々なWebアプリケーションを連携させる際に使われるJSON（JavaScript object nota
JSONデータをクロスドメインアタックから守るためにwhile(1)を使うことをやめましょう - hoshikuzu | star_dust の書斎
これはなに 既にご存知の方がいらっしゃるかどうかも知りませんが今さっき関連文献に行き当たって驚愕したので念のためにメモを書いておきます。私はメーリングリストなどに加入していませんので論議が済んでいるかどうかも知らないのです。もしもウェブ上に解説記事があるようでしたら逆に私に是非とも教えてください。 JSONデータの先頭に JSONデータの先頭にwhile(1)を置いておくことで無限ループを発生させておいて、受動的攻撃のページの悪意あるscriptの実行を失敗させるというアイデアには欠点があるということを、先程とある文献から知りました。これはwhile(true)についても同様です。JavaScriptは柔軟で強力な言語ですから、ブラウザがJavaScriptエンジンをまじめに実装しているのであれば、アタックのチャンスを与えていることになります。しかしこれはブラウザの脆弱性とは捉えられません
Twitter でベーシック認証越しになにかやるのは控えた方が良い - nothing but trouble
なんでも JSONP で取れるので、どこかでベーシック認証通していると、認証ダイアログも出ずに DM のぶっこ抜きなんかが出来てしまったりする。 DM を JSONP で取得するデモ(ソース見て貰えればわかるけど、サーバサイドにデータ送ったりしてません) http://kaz.july.7.googlepages.com/twitter_dm_jsonp.html まあ予想通りといえば予想通りだけど DM なんかが JSONP できるのはちょっと問題なんじゃないかなと思う。 最初から一貫して、セキュリティなどに関しては twitter はあてに出来ないのは何も変わっていないので protected や DM なんかで、公開されたら不味い情報のやりとりをしているような人は気をつけた方が良いでしょう。
[Think IT] 第1回：JSONってなにもの？ (1/3)
JSONとは何か? JSONとはJavaScript Object Notationの略で、XMLなどと同様のテキストベースのデータフォーマットです。 その名前の由来の通りJSONはJavaScriptのオブジェクト表記構文のサブセットとなっており、XMLと比べると簡潔に構造化されたデータを記述することができるため、記述が容易で人間が理解しやすいデータフォーマットと言えます。 なお、JSONは2006年に「RFC 4627（http://www.rfc-editor.org/rfc/rfc4627.txt）」として公開されています。 例としてXMLとJSONで同じデータを記述したものをリスト1とリスト2に示します（図1）。 リスト1のXMLではすべての情報をタグで囲んだテキストノードとして記述していますが、XMLでデータを表現する場合、データの記述方法として属性とテキストノードの使い分けが
ここが危ない！Web2.0のセキュリティ 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル
« Japanize - IE 系の User JavaScript エンジンに対応しました | メイン | 安全な JSON, 危険な JSON (Cross-site Including?) » 2007年01月04日 クロスサイトのセキュリティモデル あけましておめでとうございます。 昨年、社内で「XMLHttpRequest は何故クロスサイトで使えないのか。画像や SCRIPT タグは使えるのに」という疑問 (というより試問) を耳にしました。おもしろい話なのでブログネタにしようと思っていたのですが、新年早々 GMAIL の事例がスラッシュドットされていたので、自分の現時点での理解をまとめてみることにしました。文書を確認して書いているわけではないので、間違いがあれば指摘してください。また、よい参考文献をご存知の方がいらっしゃいましたら、教えていただければ幸いです。 ウェブブラウザ
Kazuho@Cybozu Labs: 安全な JSON, 危険な JSON (Cross-site Including?)
« クロスサイトのセキュリティモデル | メイン | E4X-XSS 脆弱性について » 2007年01月06日 安全な JSON, 危険な JSON (Cross-site Including?) 先のエントリで、 JSON については、JavaScript として副作用をもたない (もたせようがない) ゆえに文法違反であるがゆえに、秘密情報を含むデータフォーマットとして使用することができるのです。 (Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル) と書いたのですが、認識が甘かったようです。Jeremiah Grossman: Advanced Web Attack Techniques using GMail によると、配列の初期化演算子 [] の動作を外部から変更することができる注1とのこと。 実際に手元の Firefox 1.5 で試してみたところ、JS
JavaScript Hijack/JSON Hijackのぜい弱性
今回で，ratproxyで検出できる特徴的なぜい弱性の解説は終わりです。最終回となる今回は，JavaScript Hijackについてです。JavaScript Hijack，そしてJSON Hijackは，JavaScriptファイルやJSONデータ内に含まれる情報を盗む攻撃です。ratproxyは，この攻撃を成立させてしまうぜい弱性を見付けやすくなっています。 JavaScript Hijack まず最初にJavaScript Hijackについて説明しましょう。JavaScript Hijack攻撃にぜい弱になるのは，個人情報などの機密情報を内容として含むJavaScriptファイルを動的に生成しているアプリケーションです。筆者が過去の検査で実際に見たケースには，以下のようなものがありました。 （index.htmlの一部） <script src="greeting.cgi"></
バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ
もう一度、ちゃんとJSON入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕自身も僕の周辺もJSONをよく使います。でも、細かい点でけっこうミスをやらかしています(苦笑)。このエントリーで、JSONを使う上で注意すべきこと／間違いやすい点をすべて列挙します。 内容 兼チェックリスト： 仕様原典さえ読めば完璧（のはずだが） 数値の前にゼロを付けてはいけない 16進数表記も禁止だよ 数値の前にプラスを付けてはいけない 小数点からはじまる数値はダメ 用語法が違うよ：プロパティとメンバー メンバー名には常に文字列を使う 空文字列""もメンバー名に使える 配列要素はキッチリと並べよう 文字列を囲むには二重引用符だけ 文字列内のエスケープが微妙に違う 仕様にないエスケープは構文エラー undefinedもNaNもありません ラッパーオブジェクトは使わないのが吉 型システムとtypeofに関する注意 最後に 仕様原典さえ読めば完璧（のはずだが） JSONは、小さくて簡単な仕様
JSONのXSS脆弱性を修正--Ruby on Rails 1.2.5
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 12日Ruby on Rails 1.2.5がリリースされた。 今回のリリースは、JSON（JavaScript Object Notation）のXSS脆弱性を修正したもので、バージョン1.2.4で生じたいくつかの退行バグの修正もされている。そして、2.0プレビューリリースからのいくつかの機能と修正がバックポートされている。 Rails1.2.4以前のすべてのユーザーは、1.2.5にアップグレードさせるように推奨する。JSONを利用していない場合には、厳密にアップグレードは必要ではない。しかしながら、JSONを利用している場合は、そうではないことに注意されたい。 詳細な情報に関しては、CVE-2007-3227を参照していただきたい。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mundane Life: JSON を eval する場合
http://homepage.mac.com/yuji_okamura/iSawIt/archives/2010/01/entry_2448.html
freeml（フリーエムエル）｜新しい生活をはじめる羅針盤