Electronでアプリを書く場合は、気合いと根性でXSSを発生させないようにしなければならない。 - 葉っぱ日記
そのうちもう少しきちんと書きますが、とりあえず時間がないので結論だけ書くと、タイトルが全てでElectronでアプリを書く場合は気合いと根性でXSSを発生させないようにしなければならない。 これまでWebアプリケーション上でXSSが存在したとしても、影響範囲はそのWebアプリケーションの中に留まるので、Webアプリケーションの提供側がそれを許容するのであればXSSの存在に目をつむることもできた。しかし、ElectronアプリでDOM-based XSSが一か所でも発生すると、(おそらく)確実に任意コード実行へとつながり、利用者のPCの(そのユーザー権限での)全機能が攻撃者によって利用できる。 そのため、Electronでアプリケーションを作成する開発者は気合いと根性でXSSを完全につぶさなければならない。 nodeIntegration:falseやContent-Security-Pol
JavaScriptでリンク先URLがhttp/httpsか確認する方法 - 葉っぱ日記
JavaScriptで動的にリンクを生成する際に、DOM-based XSSを防ぐためにリンク先がhttpあるいはhttpsに限定されていることを確認したい場合がある。典型的には以下のようなコードとなる。 var div, elm; // 変数 url は攻撃者がコントロール可能な文字列 if( url.match( /^https?:\/\// ) ){ div = document.getElementById( "info" ); elm = document.createElement( "a" ); elm.setAttribute( "href", url ); elm.appendChild( document.createTextNode( url ) ); div.appendChild( elm ); } この場合、変数urlに「http://example.jp」や「
mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ（1）：［これはひどい］IEの
機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
XMLHttpRequestを使ったCSRF(補足編) - 葉っぱ日記
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
GoogleのJSON(モドキ)の先頭にwhile(1); がつく理由 - 葉っぱ日記
なぜGoogleはJSONの先頭に while(1); をつけるのか #JavaScript #HTML #Ajax #StackOverflow - Qiita これはクロスサイト・リクエスト・フォージェリ対策。違うよ！全然違うよ！ 攻撃者の作成した罠ページにてJSONを<script src="target.json">みたいに読み込んで、ゴニョゴニョやることでJSON内の機密情報に攻撃者がアクセス可能というのは合ってるけど、それを「クロスサイト・リクエスト・フォージェリ」とは言わない。無理に何か名前をつけて呼ぶとすれば、「JSON Hijacking」という俗称や、あるいは単純にクロスサイトでの情報漏えい、程度ですかね。 ちなみに、ArrayコンストラクタやObjectでのアクセサを定義してJSONをJSとして読み込んで内部にアクセスする手法は、現在のところ公にされているところでは古
「Ajaxブラウザセキュリティ - 主戦場をDOMに移したXSS」 - 葉っぱ日記
IPAから情報セキュリティ技術動向調査（2011 年上期） のひとつとして「Ajaxブラウザセキュリティ - 主戦場をDOMに移したXSS」という報告が公開されていますので、ちょっと読んでみた感想などを…。 まずは些末なツッコミから。 (5.2. Ajaxの登場と進化) JavaScriptの中からのWebサーバとの間の非同期の通信を可能にしたAPIは、XMLHttpRequestという組み込みオブジェクトであるXMLHttpRequest として最初に実装されたIEのそれは、ActiveX Object であり「組み込みオブジェクト」ではありません。 (5.5. 「同一源泉」の制約) 「同一源泉」の制約「同一源泉」なんていう独自用語使わずに、"Same Origin Policy" そのままか、あるいは「同一生成元ポリシー」と書けばいいのに。 (5.9. XHRレベル2) 例えば、次のよ
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
ブラウザでJavaScriptが動く時代がやってきた！ - 葉っぱ日記
というわけで、昨日から話題沸騰の Javascript PC Emulator すごいですね。JavaScript で書かれた x86 PC エミュレータ上で Linux 動かして、入ってる tcc 使えばそこそこのソースもコンパイルして動いたり。 もとのディスク容量が少ないので、適当な母艦を用意して、こんな感じ で新しいディスクイメージ作って、CocProxy や Fiddler の AutoResponder を使って root.bin へのリクエストをローカルのファイルに差し替えてやれば、好きなファイルも入れられますね。 というわけで、SpiderMonkey を入れて動かしてみました。ブラウザ内でJavaScriptが動くなんてムネアツですね！ 手順としては、コンパイルの簡単な SpiderMonkey 1.7 を x86 の32ビットマシンで -static 付きでビルドして、r
IE9 RC マイナーな変更点リスト - 葉っぱ日記
Eric Lawrence さんから、IE9 RC Minor Changes List - EricLaw's IEInternals - Site Home - MSDN Blogs の翻訳の許可をもらったので訳してみました。間違い等あれば教えてください。 遡ること9月に、私はIE9のマイナーな変更点のリスト*1を公開しました。今日は、IE9リリース候補版で変更された点について紹介します。注意：このリストは当時言及しなかったBetaでの変更点もいくつか含んでいます。 もちろん、ここには含まれていない多数の変更点があるので、この記事を完全なリストとは思わないでください。また、IEBlog上で論じられているような大きな機能変更については意図的に飛ばしている点にも注意してください。 過去にこのブログで論じた、IE9の新機能や改善点については BetterInIE9タグを検索することで参照でき
1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記
最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty
IE9 Beta のマイナーな変更点リスト - 葉っぱ日記
Eric Lawrence さんから、IE9 Beta Minor Changes List - EricLaw's IEInternals - Site Home - MSDN Blogs の翻訳の許可をもらったので訳してみました。間違い等あれば教えてください。 ブラウザの各リリースにおいて我々が行う様々な機能の追加変更のほとんどは、IEBlog の投稿において読むことができます。しかしながら、我々は同時に、見落とされがちな、あるいはあまり広くは知られていないような多数の小さな改善も行っています。この記事では、それらの小さな改善のうち私が興味深いと考えるものについてピックアップしてみます。影響を与える改善点やこれまでにこのブログ上で議論された機能などは、BetterInIE9 を検索することにより見つかります。 もちろん、私が把握していない何千もの変更があるので、これを包括的なリストと誤
JavaScript変態文法最速マスター - 葉っぱ日記
Java変態文法最速マスター - プログラマーの脳みそをリスペクト。 JavaScriptの変態文法・技法一覧です。あんまり使わないけど、知ってるとXSSとか攻撃したいのにWAFに妨害されるなど、いろいろ制約があるという場合に便利。 文字列の生成 引用符を使わずにさくっと文字列を作る。fromCharCode とか使ってもいいけどめんどくさいので、正規表現やE4Xを利用。 alert( /string/.source ); alert( <>string</> ) 空白文字を使わず記述 文脈上、スペースを書きたいけれどいろいろ制約があって書けない場合にはコメントで代替。実行するコードを作り上げてevalしてもいいけど大袈裟なので。 var/**/x=1; */ を含むコードブロックをコメントアウト コードの塊りをコメントアウトしようと思って /* */ で囲むと、コード内に string.
葉っぱ日記 - レジストリの HKCR￥MIME￥Database￥charset 以下に定義されています。
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
