[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 では互換
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
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で表示するパラメータのエスケープ
Unicode の文字 U+2028 (Line Separator) および U+2029 (Paragraph Separator) が含まれる JSON コードを解釈して JavaScript オブジェクトに変換しようとするとエラーになる問題の回避方法を示し、その問題の発生状況と回避方法の効果を実証する。更に当ページをさまざまなブラウザで参照することで発生する/しないの判定も行う。 この問題を回避するには幾つかの方法がある。それを検討してみる。 問題が発生しないブラウザを使用する。 デベロッパーにとっては最も楽な回避方法である。しかし企業のイントラネットなどでブラウザを固定することができない限りこの選択肢を採用できないだろう。更にたとえ企業のイントラネットであったとしてもサポート対象のブラウザで問題が発生しているからこのページを参照しているのだと思われる。 主要ブラウザの中で問題が発
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日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
インターネット上のWebサイトでグループウエアやERP（統合基幹業務）といった業務アプリケーションを提供するサービスが注目を集めている。いわゆるSaaS（software as a service）だ。ユーザーは，インターネット回線さえあればいつでもアプリケーションを利用できる。 このようなサービスを利用する際，サービス提供者の情報漏えい対策が気になるIT管理者は少なくないだろう。ただ実際には，ユーザーは複数のサービス提供事業者のサービス，自社のシステムを組み合わせて利用するケースが多くなる。もちろん，取引先などのシステムとの連携も考えられる。こうした環境に備えるなら，提供者側のセキュリティ・レベルに注意するだけでなく，ユーザー側で可能な限り対策を施すことが重要になる。 そこで今回は，様々なWebアプリケーションを連携させる際に使われるJSON（JavaScript object nota
これはなに 既にご存知の方がいらっしゃるかどうかも知りませんが今さっき関連文献に行き当たって驚愕したので念のためにメモを書いておきます。私はメーリングリストなどに加入していませんので論議が済んでいるかどうかも知らないのです。もしもウェブ上に解説記事があるようでしたら逆に私に是非とも教えてください。 JSONデータの先頭に JSONデータの先頭にwhile(1)を置いておくことで無限ループを発生させておいて、受動的攻撃のページの悪意あるscriptの実行を失敗させるというアイデアには欠点があるということを、先程とある文献から知りました。これはwhile(true)についても同様です。JavaScriptは柔軟で強力な言語ですから、ブラウザがJavaScriptエンジンをまじめに実装しているのであれば、アタックのチャンスを与えていることになります。しかしこれはブラウザの脆弱性とは捉えられません
なんでも JSONP で取れるので、どこかでベーシック認証通していると、認証ダイアログも出ずに DM のぶっこ抜きなんかが出来てしまったりする。 DM を JSONP で取得するデモ(ソース見て貰えればわかるけど、サーバサイドにデータ送ったりしてません) http://kaz.july.7.googlepages.com/twitter_dm_jsonp.html まあ予想通りといえば予想通りだけど DM なんかが JSONP できるのはちょっと問題なんじゃないかなと思う。 最初から一貫して、セキュリティなどに関しては twitter はあてに出来ないのは何も変わっていないので protected や DM なんかで、公開されたら不味い情報のやりとりをしているような人は気をつけた方が良いでしょう。
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でデータを表現する場合、データの記述方法として属性とテキストノードの使い分けが
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
今回で，ratproxyで検出できる特徴的なぜい弱性の解説は終わりです。最終回となる今回は，JavaScript Hijackについてです。JavaScript Hijack，そしてJSON Hijackは，JavaScriptファイルやJSONデータ内に含まれる情報を盗む攻撃です。ratproxyは，この攻撃を成立させてしまうぜい弱性を見付けやすくなっています。 JavaScript Hijack まず最初にJavaScript Hijackについて説明しましょう。JavaScript Hijack攻撃にぜい弱になるのは，個人情報などの機密情報を内容として含むJavaScriptファイルを動的に生成しているアプリケーションです。筆者が過去の検査で実際に見たケースには，以下のようなものがありました。 （index.htmlの一部） <script src="greeting.cgi"></
Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ
僕自身も僕の周辺もJSONをよく使います。でも、細かい点でけっこうミスをやらかしています(苦笑)。このエントリーで、JSONを使う上で注意すべきこと／間違いやすい点をすべて列挙します。 内容 兼チェックリスト： 仕様原典さえ読めば完璧（のはずだが） 数値の前にゼロを付けてはいけない 16進数表記も禁止だよ 数値の前にプラスを付けてはいけない 小数点からはじまる数値はダメ 用語法が違うよ：プロパティとメンバー メンバー名には常に文字列を使う 空文字列""もメンバー名に使える 配列要素はキッチリと並べよう 文字列を囲むには二重引用符だけ 文字列内のエスケープが微妙に違う 仕様にないエスケープは構文エラー undefinedもNaNもありません ラッパーオブジェクトは使わないのが吉 型システムとtypeofに関する注意 最後に 仕様原典さえ読めば完璧（のはずだが） JSONは、小さくて簡単な仕様
印刷する メールで送る テキスト 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 する場合