Shibuya.XSS techtalk #11 の発表資料です。
![JSでDoSる/ Shibuya.XSS techtalk #11](https://cdn-ak-scissors.b.st-hatena.com/image/square/11dfeb67a728f0327178747bee47c808d887fa0a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fba6578ce2cf84cc0ab1f3a1037fa6b24%2Fslide_0.jpg%3F12617252)
Shibuya.XSS techtalk #11 の発表資料です。
ちょっとタイトルが言いすぎていて大反省です (適宜アップデートします, 仮)
JavaScriptによるブラウザ上での処理量およびコード量の増加に伴い、JavaScript上のバグが原因で発生する脆弱性も増加しています。そのような脆弱性の最も代表的なものが、DOM-based XSSです。今回から数回に分けて、DOM-based XSSについて説明していきます。 DOM-based XSSとは 本連載第2回で説明したような一般的な反射型および蓄積型のXSSのほとんどは、Webアプリケーションがサーバ上でHTMLを生成する際に、攻撃者が指定した文字列のエスケープが漏れていることが原因で発生します。一方、DOM-based XSSは、サーバ上でのHTMLの生成時には問題はなく、ブラウザ上で動作するJavaScript上のコードに問題があるために発生します。 たとえば、以下のようなJavaScriptコードがあったとします。 // bad code div = docum
Electronを使ってブラウザのようなアプリケーションを作る場合には webviewタグが使用される。例えば、アプリケーション内にexample.jpのサイトを表示するには以下のようにHTMLに記述する。 <webview src="http://example.jp/"></webview> ここで、webviewタグにallowpopups属性を付与すると、example.jpサイト内のコードからwindow.open等を使って新たにウィンドウを開くことができるようになる。このとき、example.jpに悪意があり以下のようなコードが含まれているとする。 if( typeof require === "undefined" ) window.open( 'http://example.jp/', '', 'nodeIntegration=1'); else require( "chi
XSS対策としての ES6テンプレートリテラル Shibuya.XSS Yosuke HASEGAWA ES6テンプレートリテラル ES6テンプレートリテラル ❤バッククォートで囲って改行も含められ る var x = `改行も ダブルクォート「"」も シングルクォート「'」も 使えるよ!`; alert( x ); ES6テンプレートリテラル ❤ヒアドキュメントというには少し残念 ❤円記号でのエスケープが生きてる… var x = `改行も¥nバッククォート¥`も ¥¥も使えるよ!`; alert( x ); ES6テンプレートリテラル ❤リテラル内に${...}で埋め込んだ式を評価 var name = "hasegawa"; var x = `Hello, ${name}-san`; console.log( x ); // "Hello, hasegawa-san" x = `ab
5/11の日記XSS対策:JavaScriptなどのエスケープ - ockeghem(徳丸浩)の日記に対する金床さんのコメントに触発されて、JavaScriptのエスケープについて検討してみよう。ただし、現実のアプリケーション開発においては、私はJavaScriptの動的生成を推奨していないが、これはエスケープ処理をどのように考えるかと言うレッスンのつもりで検討することにする。 金床さんのコメントで紹介されたリンクには、以下のようなガイドライン案が提案されている。 JavaScriptの文字列でのエスケープ手順としては、以下が今のところ正解っぽい感じです。 1. 「\」を「\\」に置換する 2. 「"」を「\"」に置換する 3. 「'」を「\'」に置換する 4. 「/」を「\/」に置換する 5. 「<」を「\x3c」に置換する 6. 「>」を「\x3e」に置換する 7. 「0x0D(CR)
Content-Security-Policy の nonce を利用すると、XSS の脅威をかなり軽減できます。 そこで、Web Application Framework ではデフォルトで対応したほうがよいのではないか、という旨を @hasegawayosuke さんから教えて頂いたので、実装について考えてみました。 とりあえず CSP の nonce はどういうものなのかを考慮するために、コード例を探していたのですが、実際に動くサンプルというものが nonce 関連のもので見当たりませんでした。 そこで、実際に動くサンプルを用意しました。 https://github.com/tokuhirom/csp-nonce-sample 以下は Sinatra で書かれたサンプルコードです。 require 'sinatra' require 'securerandom' get '/' d
フロントエンド開発のためのセキュリティ 第1回 XSSの傾向と対策 本シリーズではフロントエンドの開発に関係するセキュリティについて、理解を深めます。第1回目はXSS(クロスサイトスクリプティング)です。実装失敗例を挙げつつ、対策のポイントを解説します。 セキュリティはサーバーサイドの問題? セキュリティに関わるミスは「知らなかった」ではすまされない場合が、往々にしてあります。 ちょっとしたミスでプログラムにバグを作ってしまい、サービスが一部動かなくなったとしても程度にもよりますが、すぐに修正すれば一部のユーザーに少し不便をかけてしまう程度ですむでしょう*。 *注:サービス運営 この記事ではセキュリティの技術的な側面を扱います。ユーザーに不便をかけてしまったことに対するサービス提供側の倫理的問題についてはそのつど言及はしませんが、これらの側面を軽視すべきでないことはいうまでもありません。
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Stack Overflowに面白い質問があったので紹介する javascript - Why does Google prepend while(1); to their JSON responses? - Stack Overflow 質問 Googleのサービス内で使われるJSONの先頭に while(1); てついているのは何故? 例えばGoogle Calendarではカレンダーを切り替えるときに以下のような内容のデータがサーバから返される。 while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],['remindOnRespondedEventsOnly','true'],['hideInvitations_remindOnRespondedEventsOnly','false_true'],['C
DOM Based XSSに関しては、IPA「安全なウェブサイトの作り方」でも、拙著でもごく簡単にしか触れておらず、まとまった解説が要望されていましたが、本日(2013年1月29日)にIPAから「IPA テクニカルウォッチ『DOM Based XSS』に関するレポート」が公開されました。 同冊子の目次は下記の通りです。 はじめに 1. DOM Based XSSの概要 2. IPAに報告されたDOM Based XSSの脆弱性 3. DOM Based XSSの事例 4. DOM Based XSSの対策方法 コラム おわりに IPAのレポートと言うことで、DOM based XSSの届出の状況も説明されています。以下にグラフを引用します。 一見して「急増」していることと、昨年の10月から12月の3ヶ月で92件も届出があったということで、対策が急務となっている状況が見て取れます。これは、こ
今日は、 そもそもホストの前に任意の文字列を置けるということを忘れていると、うっかりそこにJavaScriptで触ってしまった時に問題が起こる場合があるよね、という話をします。 以前紹介したlocation.hrefの問題に似ていますが、今回取り上げているのは文字列がデコードされることにより起きうる問題ではなく、文字列が取得されることで起きうる問題についてです。 まずは、様々な形でJavaScriptでURLを確認できるスーパーウェブサイトを用意致しましたので、ホストの前に文字列を含むURLが、どの値で取得されているかを実際に見てみてください。 http://user:pass@vulnerabledoma.in/location/ (※このページはURLをそのまま書きだしているため、当然DOM based XSSがありますが 、その挙動も含めて確認できるようにする目的があるので、あえてそ
jQuery の $ 関数はセレクタによる絞り込み、HTML 生成、ready イベントコールバックの3つのケースに使われますが、開発者がセレクタとして想定したものが HTML 生成として解釈され、XSS を引き起こすことがあります。次のコードは HTML と解釈され、error イベントハンドラに指定された alert が実行されます。 $("#<img src=/ onerror=alert(1)>"); 防衛策として jQuery 1.9 では $ 関数に渡すことのできる HTML に見える文字列の制約を厳しくするため、従来は認識できた文字列が認識できなくなる場合の回避策および、特に単独の要素を生成したり、外部のデータから文字列を生成する場合のために $.parseHTML を使うことをおすすめするとリリース記事に書いてあります。 .parseHTML メソッドの実装を見ると戻り値が
概略 サイトのコメント欄の外部委託系サービスの disqus.comにいくつか DOM based XSS がありまして修正されました.location.hash 部分の url encode が行われない IE, Chrome, Opera で問題があったことは確認しています. まず一つ目は,コメント欄の埋め込みスクリプトにありました. 脆弱性とその修正を確認しているのは,blogid.disqus.com/admin/universal/ にて表示されるコードを埋め込むタイプで,blogid.disqus.com/embed.js というスクリプトです. こちらのコードは,埋め込んだドメイン上で動作していましたので,このタイプのコードを埋め込んでいたドメインで提供されているサービスに影響があった可能性があります.disqus.com ではuniversal code とは別に,特定の幾
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く