ikepyonのお気楽な日々〜技術ネタ風味〜 このページをアンテナに追加 RSSフィード

気になった日々のニュースとメモのためのリンクと戯言のページ

To Do(というかやりたいこと。何時終わることやら)
-ITIL導入のための成熟度チェックシートみたいなの(あると便利だよね?)
-Hacknotes Web Security Portable Reference和訳(出版社募集中)
-Webアプリケーションセキュリティ検査ツールの改良(一応完成)
-Hacker HighSchoolの資料の日本語訳
-OSSTMMの日本語訳
-「燃えるセキュアプログラミング」若しくは「サルでも分かるセキュアプログラミング」とか書いてみたいなぁみたいな。

これだけはチェックしときなはれ!!受入れテスト用セキュリティチェックリスト公開中
Webアプリケーションセキュリティはてなぐるーぷ(テスト中やで)
SQL Injectionの仕組みと対策公開中
RSS feed meter for http://d.hatena.ne.jp/ikepyon/
Secure Coding に入ろう!! [MLの詳細]
メールアドレス
SKUF Meeting なかのひと

2007-06-06 くらくら

朝起きたら、クラクラしたので、午前中は寝てました。でも、未だ復活して無い感じorz

[]JSON JSONを含むブックマーク JSONのブックマークコメント

http://tools.ietf.org/html/rfc4627

Security considerations:

Generally there are security issues with scripting languages. JSON

is a subset of JavaScript, but it is a safe subset that excludes

assignment and invocation.

A JSON text can be safely passed into JavaScript's eval() function

(which compiles and executes a string) if all the characters not

enclosed in strings are in the set of characters that form JSON

tokens. This can be quickly determined in JavaScript with two

regular expressions and calls to the test and replace methods.

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(

text.replace(/"(\\.|[^"\\])*"/g, ''))) &&

eval('(' + text + ')');

これを見ると、しっかりセキュリティの事書いてあるね。まあ、普通に考えれば、当たり前か。

一応、サンプルコードで何とかなりそうな気もしないでもないけど、文字コードがらみで抜け道ありそうだなぁ。

はせがわはせがわ 2007/06/07 11:42 そもそもapplication/jsonやtext/javascriptはIEが認識しないので、適当なPATH_INFOをつけることでHTMLと認識させてのXSSが可能になります。http://d.hatena.ne.jp/hasegawayosuke/20070404/p1

ikepyonikepyon 2007/06/07 11:59 JSONの場合、JavaScriptで受け取ったデータを扱うために、受け取ったデータをeval関数に食わせるようです。
このため、JSONの中にJavaScriptのコードが含まれていたらそのコードが実行できてしまうという結構怖い自体に^^;
なので、チェック部分とeval関数での文字コードの取り扱いが違うとまずいかなぁということなんです。

はせがわはせがわ 2007/06/07 13:01 JSONデータの提供側と利用側が別の場合、当然JSONデータのcharsetについても合意しているはずで、その場合 JSONデータ提供側は、受け取った側が正しくJSONデータを扱えるようcharset指定をつけてHTTPレスポンスヘッダを返す等の対応をしていると思います。にも関わらず、受け取った側がそれとは異なるcharsetであると解釈するための方法が存在するのでしょうか?

ikepyonikepyon 2007/06/07 14:06 そのあたりが分からないので、確認しようかと思っています。
意図的に、JSONのデータに受け取り側が想定していない文字コードのデータが含まれたとき問題が発生しないかどうかがわからないので・・・
内部で変に変換してしまって問題が発生しないかなぁと。

ockeghemockeghem 2007/06/07 23:41 RFC4627では、JSONの文字エンコーディングはUNICODEと規定されていてデフォルトではUTF-8です。

3. Encoding
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.
Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets.
00 00 00 xx UTF-32BE
00 xx 00 xx UTF-16BE
xx 00 00 00 UTF-32LE
xx 00 xx 00 UTF-16LE
xx xx xx xx UTF-8
一応、シフトJISとかが入ることは想定されてないようですが・・・そういう問題ではないのかな?

ikepyonikepyon 2007/06/08 00:05 そのあたりは一応読んでいて、Unicodeが規定されているにもかかわらず、Shift JISなどが入ってきた場合どうなるか?というところに興味があります。

ockeghemockeghem 2007/06/08 08:47 了解ですが、通常は、はせがわさんの言われるようにサーバーとクライアントで合意しているはずのもので、どのような(悪い)状況を想定してのことかをはっきりさせないといけませんね。あるいは、どのような悪い状況が想定しうるかという議論でしょうか?

ikepyonikepyon 2007/06/08 10:34 どういった時に、問題が発生するのか?(具体的にコードが実行できてしまうのか?)ということを調べないとと思っています。
UTF-8でも、ブラウザによってはこういうこともあるみたいですし・・・
http://iandeth.dyndns.org/mt/ian/archives/000621.html

トラックバック - http://d.hatena.ne.jp/ikepyon/20070606

1900 | 01 | 06 |
2003 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 02 | 03 | 04 |
2011 | 01 | 02 |
Connection: close