クロスドメイン通信とはなんぞや。CORSとはなんぞや。
25 May 2011 2011-10-5 仕様の変更に伴い、大部分を書きなおす。 経緯 僕は今まで、ブラウザのクロスドメイン通信の制約とは、ホスト等が異なるサーバへのアクセスをブラウザが禁止する事だと思っていました。しかし、Chrome Extensionを開発中にどうもそれでは説明が付かない事があり、クロスドメイン通信に関して基本から学び直す機会があったので、せっかくなのでまとめました。この記事の結論を先に言うと、CORSという標準化されたクロスドメイン通信制約のもとでは、ブラウザは主にレスポンスを検閲する、という事です。 ただし、以下の文章は私が個人的に調べた事をまとめたものであり、正しさの保障はありません。むしろ間違いを見つけたら、指摘して頂けるとありがたいです。 なぜクロスドメイン通信が制約されるのか まずは基本から。 ブラウザ上のスクリプトが行うクロスドメイン通信には、ご存知の
Node で使える ECMA Script 5 の新機能 - Block Rockin’ Codes
追記 11/9/24 Gistのリンクを本家Wikiに貼ってみました。 11/9/24 log 関数を修正しました。 11/7/10 JSON.stringify の第二引数 replacer について、補足しました。 11/7/14 os0x さんの指摘を反映しました。 String.trimRight、trimLeft は ECMA Script 5 非標準です。 JSON.stringify の第3引数には"\t"などの文字列も渡せます。 JSON.parse の第2引数 reviver について補足しました。 Array.prototype.forEach の第2引数 について補足しました。 "use strict" 時の Object.freeze 等の挙動について補足しました。 「ECMA5 というのはちょっとおかしな略し方」について補足しました。 タイトルを修正しました。(旧
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
