ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
アセンブラ短歌 - 葉っぱ日記
世の中には常人には理解できない趣味を持っている人がいまして、組み込みOSを作っている坂井さんもその一人で、最近は「アセンブラ短歌」という新しい遊びを提案しています。アセンブラ短歌というのは坂井さんによると、“「アセンブラ短歌」は五・七・五・七・七の三十一バイト(みそひとバイト)から成る 機械語コードでプログラムを書いてみるという近未来の文化的趣味であり，近年， 国内のハッカー間で密かなブームが起きています．” ということらしいですが、さっぱり意味がわかりません。 まあ意味がわからないのですがとりあえず嗜みとしてアセンブラ短歌くらい詠めないと恥ずかしい感じなので、自動的にアセンブラ短歌を生成するやつを作りました。 8086アセンブラ短歌ジェネレータ これを使うと、こんな感じの8086のアセンブラ短歌が誰でも簡単に詠めちゃいます。 a7 03 87 13 b7 03 65 a8 fb 1f 2
セキュリティ・キャンプ2013 お疲れ様でした - 葉っぱ日記
今さらという感じもありますが、セキュリティ・キャンプ2013にWebセキュリティ・クラスの講師として今年も参加しました。 Webセキュリティ・クラス以外の実施内容については様々な記事をご参照いただくとして、ここではWebセキュリティ・クラスでの講義内容をご紹介したいと思います。 今年のWebセキュリティ・クラスでは、DOM based XSSを中心に、クライアントサイドで発生する脆弱性を中心に取り上げて講義および実習を行いました(参考:▶ セキュリティ・キャンプ2013：Webセキュリティクラスのご紹介)。ビデオ内でも話していますが、取り上げる内容をクライアントサイドに限定したのは、SQLインジェクションのような古くから存在するサーバ上の問題点については根本的な解決方法も見出されているものの、DOM based XSSのようなクライアントサイドで発生する問題についてはJavaScriptコ
機密情報を含む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について、このレポートには記載されていない点についていくつか補足
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 って他のドメインにリクエストを発行できないんじゃ い
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CD-ROM トレイを取り出せるIE用ブックマークレット、「ie-eject.vbs」作った。 - 葉っぱ日記