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について説明しました。 しかし、問題はこれだけではありません。正常
Twitter の JSON に罪はない
TwitterのステータスIDが53bitを越えたお話 - tmytのらくがき http://d.hatena.ne.jp/tmyt/20101201/1291166929 から引用。 このうちXMLで処理してる場合は内部で64bit INTで処理していれば特に問題は起きません。 こういう微妙なまちがいをしてる人はこの記事書いた人だけでなく大勢いるようだけど、記事としてはまとまっていたので参照。 JSON という書式は、確かに JavaScript から派生したサブセットですので、 JSONを仕様書通りにパースするとidの値はdouble と考えてしまうのも無理はない気はします。 が、まちがいであるのも確かです。 RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON) http://t
はてなブックマークのJSONとlivedoor clipのJSON - hogehoge @teramako
はてな http://b.hatena.ne.jp/entry/json/URL livedoor http://api.clip.livedoor.com/json/comments?link=URL でJSONコードを取得できるのだが、微妙に仕様が異なる。 はてなはオブジェクトの前後に()が付くのに対してlivedoorのは付かない はてな:({"count":"100","bookmarks":[{....}]}) livedoor:{"link":"URL","Comments":[{....}]} という感じ。 Firefox3から導入されたJavaScriptモジュールを使用して両者のコードをデコードしようと試みたのだが、()が付いているとデコードできずにエラーが返ってしまう。 Chrome特権上でコードを動かしているので単純にevalを使うのは危険かなと思い、SandBox上
JSONとオブジェクトリテラルとの違い - 旧燈明日記
JSONは、JavaScriptのオブジェクトリテラルと似ていますが、以下が違います。 キーとして使うデータ型は、文字列に限る(キー項目をダブルクォート）。 コードは、Unicodeに限る（デフォルトUTF-8）。 {"kaisha":'日産',"run":'ブーン',"model":'セレナ'}今回テストしてみて確認しましたが、JSONはデータだけでなく、メソッドもＯＫですね。 （メソッドが実行されないようなチェックが必要かも･･･） 参考(JSON)： http://okilab.jp/project/document/japanate/rfc/RFC4627J.txt http://d.hatena.ne.jp/brazil/20050915/1126709945 http://d.hatena.ne.jp/brazil/20050915/1126717649 http://tool
BrEdiMa - FrontPage
現在サイト整備中です。一部情報が抜けていますがご了承下さい。 BrEdiMa † BrEdiMa は既存の Web ページ内に簡単な変更で GUI 数式エディタを追加できる、 JavaScript で書かれた Web アプリです。 →動作サンプル Greasemonkey としてはてなダイアリーなどでも利用ができます。 ↑
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
Hawk's Laboratory JSONのキーはなぜ文字列でなけれなばらないのか
このドメインを購入する。 hawklab.jp 2019 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
ちょっとしたメモ - JSONがRFCに
JSONの文法などについて、今年の2月1月からインターネットドラフト（I-D）が出されているが、はやくもInformational RFCとすることが決まった（I-Dは現在04版draft-crockford-jsonorg-json-04.txt）。MIMEタイプはapplication/jsonとされている。 このI-D/RFCは、JSONの構文とMIMEタイプをオフィシャルな形で定義しようというもので、内容は基本的には既に知られている文法と違いはない。大まかに言えば、次のようなことが書かれている。 JSONは4つの基本型（string, number, boolean, null）と、2つの構造型（object, array）で表現される。 objectは、名前:値 の組の順不同のコレクションで、これらの組を , で区切り、{ と } で囲む。名前はstringで、値は上記6つの型の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer