Electronでアプリを書く場合は、気合いと根性でXSSを発生させないようにしなければならない。 - 葉っぱ日記
そのうちもう少しきちんと書きますが、とりあえず時間がないので結論だけ書くと、タイトルが全てでElectronでアプリを書く場合は気合いと根性でXSSを発生させないようにしなければならない。 これまでWebアプリケーション上でXSSが存在したとしても、影響範囲はそのWebアプリケーションの中に留まるので、Webアプリケーションの提供側がそれを許容するのであればXSSの存在に目をつむることもできた。しかし、ElectronアプリでDOM-based XSSが一か所でも発生すると、(おそらく)確実に任意コード実行へとつながり、利用者のPCの(そのユーザー権限での)全機能が攻撃者によって利用できる。 そのため、Electronでアプリケーションを作成する開発者は気合いと根性でXSSを完全につぶさなければならない。 nodeIntegration:falseやContent-Security-Pol
Host:リクエストヘッダによるXSS - 葉っぱ日記
本日、とある会合にてTwitterで交わされていたこの会話が話題になりました。 紹介されている例はHostヘッダの操作を経路とする攻撃ということであり、Hostヘッダインジェクションという脆弱性はないと思いますよ / “PHPにおけるHostヘッダインジェクション脆弱性 ― A Day in Serenit…” https://t.co/sTzTQEE7a8— 徳丸 浩 (@ockeghem) 2015, 11月 6 @ockeghem @okumuri 実はIEでは細工したホストヘッダを送出できる手法が知られています。間違いなくIEのバグですが、このせいで値をそのまま出力しているサイトではXSSがありえてしまいます。ここが参考になります： https://t.co/G419aaUgNi— Masato Kinugawa (@kinugawamasato) 2015, 11月 9 知る人ぞ
ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
脆弱性"&'\ Advent Calendar 2014 (17日目) - 葉っぱ日記
この記事は脆弱性"&'<<>\ Advent Calendar 2014の17日目の記事です。今日は少し昔話をしようと思います。がはは。 かつて、日本製TwitterのようなWassrというサービスがありました。当時、Twitterは数日に一度くらいはサービスが落ちていて、Twitterユーザーも「またか」と思いながら我慢して使うようなサービスであり、Twitterが落ちるたびにWassrはユーザーを増やすとともに、画像の添付のように当時Twitterにはまだなかった機能をどんどんアグレッシブに取り入れていく、使っていて楽しいサービスでした。 さて、そんなWassrがある日絵文字機能を導入しました。当時はUnicode絵文字もなくスマートフォンも普及しておらず、主にレガシーな携帯電話で使える絵文字をなんとかWeb上でも使えるようにしたという感じのものでした。 絵文字をパレットから選択すると
LINE株式会社 に行ってきた！ - 葉っぱ日記
台風一過！はせがわです。 というわけで、Shibuya.XSSの会場を快く貸してくださったLINE株式会社さんに行ってきた！ サイボウズのバグハンター合宿で疲れた体を引きずりながら大勢で魔宮である渋谷駅を抜けヒカリエへ。 出迎えてくれたのはおなじみのコニー、ブラウン、ムーンをはじめとする愛らしいキャラクターの面々。 ジェームズとジェシカもお出迎え。 見晴しのいい窓際にも。 遠くには夕焼けの富士山も見える！ 大量のレッドブルを前にご満悦の941さん。 というわけで、夜遅くのグデグデな勉強会なのに快く会場をお貸しくださったLINE様、941さん、ありがとうございました！ 雑なパクリ風味記事ですみません＞＜ - ちなみに、Shibuya.XSS テクニカルトーク #5の内容や資料については、いつもどおり azu さんによる記事:Shibuya.XSS テクニカルトーク #5 アウトラインメモ |
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の
JPCERT/CCの「HTML5(中略)調査報告書」が安全になっていた - 葉っぱ日記
JPCERT/CCは「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」(PDF))を以下のURLから公開しています。 http://www.jpcert.or.jp/research/html5.html 「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」はお勧めである、とするエントリを書こうかと思い、久しぶりにJPCERT/CCのトップページを確認すると改定されていました。 古いJPCERT/CCのトップページは右肩のお知らせ欄で「HTML5(中略)調査報告書」をリンクしていました。国内情報セキュリティの向上を目指しているのがJPCERT/CCですが、多数のお知らせに流れて「HTML5(以下略)」が消えてしまいました。はっきり言うと当然でした。 しかし、今も「HTML5を利用したWebアプリケーションのセキュリティ問題に関す
Chromeで(☝ ՞ਊ ՞)☝ウイーン - 葉っぱ日記
この記事はEject Advent Calendar 20133日目の記事です。ちなみに今日は僕の誕生日です かつて一世を風靡し世界中のChromeユーザーを病院送りにしたCD-ROM トレイを取り出せる Chrome拡張、「chrome-eject」ですが、内部でNPAPIを使っていたために近い将来確実に動かなくなります。 Chromium Blog: Saying Goodbye to Our Old Friend NPAPI そこで人類が平和に暮らせるようEjectできる代替措置を探す必要に駆られ、非常に限定的ながらChromeからEjectする方法を確立し、Chrome-eject2としてリリースしましたのでAdvent Calendarの記事として記す次第です。 Chrome-eject がこの先生きのこるには from Yosuke HASEGAWA 上記スライド内にも書いてあ
補足編：機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記」の補足編です。 結局、よくわからないんだけど。 よくわからない場合は、とにかく全てのレスポンスに X-Content-Type-Options: nosniff をつけましょう。 機密情報を含むJSONにX-Content-Type-Options:nosniffをつける理由はわかったけど、「あらゆる」コンテンツにつける理由はなぜ？ 機密情報を含まなくても、<script>のような文字列を含むコンテンツをIEで直接開いた場合にはXSSにつながる可能性もあります。どのようなコンテンツにX-Content-Type-Options:nosniffが必要かを考えるくらいであれば、全てのコンテンツに付与したほうが間違いがなくていいでしょう、ということです。 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:
IPAから「クリックジャッキング」に関するレポート出ました - 葉っぱ日記
Webアプリケーションのセキュリティの分野で「新しい攻撃手法」は実はそれほど多くないのですが、比較的新しく対応が求められているものとしてクリックジャッキングがあります。クリックジャッキングは、CSRFと同じように「Webアプリケーションのサーバー側機能」を利用者（被害者）に実行させる手法です。CSRFは、当該機能を実行するHTTPリクエストを送信させる罠を使いますが、クリックジャッキングの方は、iframe等に当該機能を呼び出す画面を表示しておき、利用者（被害者）に実行ボタンを押させる（=クリックジャック）手法です。クリックジャッキングに関しては4年前にすでにJPCERT/CCが詳しい解説を出していたのですが、この3月26日にIPAからも「クリックジャッキング」に関するレポートが公開されました。 X-FRAME-OPTIONSについて、このレポートには記載されていない点についていくつか補足
楢葉町の思い出 - 葉っぱ日記
ずいぶん前に、仕事で福島県の楢葉町というところに行ったことがあり、そのときにJヴィレッジのすぐそばにある柏屋旅館というところにお世話になった。楢葉町というところはとてもサッカーの盛んなところで、その旅館も少年サッカーチームが毎年合宿に来るということで、彼らがゆっくり宿泊できるようにと少し前に全面改装したところだったそうで、まだ木の香りの残るとてもきれいな旅館だった。旅館のおばちゃんは「これでサッカーチームが泊ってくれなかったら困るわ」と言いながらも誇らしげに笑顔を浮かべていた。とはいえ、僕が泊ったときには他にお客さんもいないようで、露天風呂付きの部屋でのんびりと過ごしたのだった。 旅館なのでもちろんのことながら朝食、夕食も付いてるわけで、白いご飯と焼き魚、名前もよくわからないような煮物や佃煮のような、ほんとうに台所でおばちゃんが作ってくれた手料理が出された。このときほど、和食がおいしいと思
Web StorageやindexedDBを扱う上でのセキュリティ上の注意点(続編) - 葉っぱ日記
先日書いた「Web StorageやindexedDBを扱う上でのセキュリティ上の注意点」の続き。 sessionStorage を使うと解決するか この用途なら sessionStorage でよい (はてなブックマーク - ssig33 - 2013年3月9日)sessionStorageはウィンドウあるいはタブが開かれてから閉じるまでの間をひとつのセッションとして管理し、そのセッションの期間中だけデータを保持します。ウィンドウやタブを閉じる際にはセッションは終了し、ストレージ上のデータは破棄されます。通常のWebアプリケーションでは、ログイン/ログアウト間というアプリケーション側が想定しているセッションと、sessionStorageのいうところのセッションとは異なる概念であり、ウィンドウを閉じる前に異なるユーザでログイン/ログアウトを繰り返した場合には同種の問題が発生する可能性があ
Web StorageやindexedDBを扱う上でのセキュリティ上の注意点 - 葉っぱ日記
localStorageやsessionStorage、あるいはindexedDBのようなブラウザ上でのデータの保存が可能になったことで、これらを取り扱ううえでもセキュリティ上の注意点が必要である。 これらのストレージは、localStorageやindexedDBは永続的に、sessionStorageはブラウザやタブを閉じるまでの間データが保持され続けるので、例えばWebアプリケーションがログイン機構を持っている場合にログイン中にこれらのストレージに書き込まれたデータは、ログアウト後も当然参照および書き換えが可能である。Webアプリケーション上のアカウントに紐づいたデータをこれらのストレージに書き込んでいる場合、ログアウト後もアクセス可能なことが問題を引き起こす可能性がある。 例えばTwitterのようなサービスがあったとして、(navigator.onLineプロパティなどを利用して
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として読み込んで内部にアクセスする手法は、現在のところ公にされているところでは古
CD-ROM トレイを取り出せる Chrome拡張、「chrome-eject」作った。 - 葉っぱ日記
Chrome 使ってると良く CD-ROM を取り出したくなりますよね。 ならないとしたら、今すぐこの記事を読むのをやめて病院に行って下さい。 hasegawayosuke/chrome-eject · GitHub https://github.com/hasegawayosuke/chrome-eject インストールすると というアイコンが追加されるので、ボタンを押すだけで CD-ROM トレイがゲロっと排出されます。 便利ですね！ 皆さんもぜひ、使ってみて下さい。 (今日の参考文献: http://mattn.kaoriya.net/software/lang/ruby/20130110212633.htm)
脆弱性関連情報の非開示依頼の取下げ申請の結果が返ってきた - 葉っぱ日記
2008年8月5日に届け出た脆弱性というか仕様というか問題ある挙動について、いつまで経っても修正されず、むしろ問題を公にしてユーザーが自衛するほうが社会的公益性が高いと思い、2012年10月21日に脆弱性関連情報の非開示依頼の取下げ申請をIPAに送ってみたら以下のような返事が返ってきた。 ドキュメント検査だけでは不十分なので、とりあえず、自分の名前や所属、使用しているコンピュータ名等が公に知られたくないという人は、Microsoft Officeで作成されたファイル(PDFに変換したのを含む)を他人に配布するのを避けるとよいと思います。 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------- このメールは、取扱い番号 I
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
