［さらに気になる］JSONの守り方

XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） 次は、JSONにおけるセキュリティ対策 皆さんこんにちは、はせがわようすけです。第4回「［気になる］JSONPの守り方」はJSONPについて説明しましたので、今回は「JSON」についてもセキュリティ上注意すべき点について説明します。 JSONは、XMLHttpRequestで受け取り、JavaScript上でevalするという使い方が一般的です。 まずはサーバ側から送られる情報と、クライアント側での処理、それぞれの内容を見ておきましょう。 ［サーバ側］ HTTP/1.1 200 OK Content-Type: application/json; charset=

[ghostbass]

JSONに直接ブラウザでアクセスしたときにXSS

[shimooka]

Access-Control-Allow-Originヘッダ

[mumincacao]

で～たの更新処理でもないのに POST 飛ばすのはなんだか気持ち悪いにゃぁ・・・すぐ使うものでもないし他によさそうな方法ないかちょっと考えてみないとかなぁ．．．〆（・ｘ・。【みかん

[bluerabbit]

良い記事。xhr.setRequestHeader、JSONによるXSS、json2.js

[ita-wasa]

このように、使いなれたXMLHttpRequestをそのまま利用して、クロスドメインのデータアクセスを実現可能としたのがXMLHttpRequest Level 2です。現在、Firefox 3.5、Google Chrome 3、Safari 4などのブラウザでXMLHttpRequest Level 2が利用可能です

[teppeis]

クロスドメインXHR

[raimon49]

JSON.parse ネイティブサポート, XMLHttpRequest Level 2, XDomainRequest

[tsupo]

XMLHttpRequestによる正規のアプリケーションからの要求では、X-Request-Sourceリクエストヘッダが付与されますが → 付与しないアプリケーションもあり得る(存在してもいい)と思うんだけど、どうなのかなぁ? / POSTで取得は不自然

[hasegawayosuke]

JSONPを紹介した次の回に「ついでにJSONと、不自然でないクロスドメインの通信方法」という流れはどこかで見た気がしますね。http://gihyo.jp/dev/serial/01/web20sec/0004