セキュリティ・キャンプ全国大会2016資料まとめ - 葉っぱ日記
セキュリティ・キャンプ全国大会2016の講義で使用された資料のまとめ。公開されていない講義が多いので、すべての講義資料があるわけではありません。随時追加。 TLS徹底演習 次世代プラットフォームのセキュリティモデル考察 (前半) (講義の動画) 次世代プラットフォームのセキュリティモデル考察 (後半) ID連携入門 (実習編) なぜマルウェア解析は自動化できないのか クラウドセキュリティ基礎 インフラセキュリティブートキャンプ HTTPプロキシ発展 チューター発表 プロトコルスタック自作で学ぶOSのNW処理実装と高速パケット処理 "どこ"から脆弱性を発見するか 解析基盤技術を用いた効率的なソフトウェアテスト 参加者ブログ セキュリティ・キャンプ2016 全国大会 感想ブログまとめ - Null Thinking
ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
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の
JavaScript文字列の動的生成におけるエスケープ - 葉っぱ日記
「JavaScript文字列を動的生成する」と一言で言っても、例えば <html>... <script> // HTML内のscript要素内に生成 var s = "ここに動的生成される"; </script> だったり、 <div onclick='foo("ここに動的生成される");'> だったり、 <script src="external.js"></script> // external.js var s = "ここに動的生成される"; だったり、さらに複雑な組み合わせだったりといろんな状況があって、基本的には「JavaScriptとしてのエスケープ」に加えてその外側の(場合によってはネストしている)コンテキストに応じたエスケープが必要、という話。 で、面倒だったら var s = decodeURIComponent( "ここに動的生成される" ); にして、生成する側はU
アセンブラ短歌 - 葉っぱ日記
世の中には常人には理解できない趣味を持っている人がいまして、組み込みOSを作っている坂井さんもその一人で、最近は「アセンブラ短歌」という新しい遊びを提案しています。アセンブラ短歌というのは坂井さんによると、“「アセンブラ短歌」は五・七・五・七・七の三十一バイト(みそひとバイト)から成る 機械語コードでプログラムを書いてみるという近未来の文化的趣味であり，近年， 国内のハッカー間で密かなブームが起きています．” ということらしいですが、さっぱり意味がわかりません。 まあ意味がわからないのですがとりあえず嗜みとしてアセンブラ短歌くらい詠めないと恥ずかしい感じなので、自動的にアセンブラ短歌を生成するやつを作りました。 8086アセンブラ短歌ジェネレータ これを使うと、こんな感じの8086のアセンブラ短歌が誰でも簡単に詠めちゃいます。 a7 03 87 13 b7 03 65 a8 fb 1f 2
補足編：機密情報を含む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について、このレポートには記載されていない点についていくつか補足
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として読み込んで内部にアクセスする手法は、現在のところ公にされているところでは古
脆弱性関連情報の非開示依頼の取下げ申請の結果が返ってきた - 葉っぱ日記
2008年8月5日に届け出た脆弱性というか仕様というか問題ある挙動について、いつまで経っても修正されず、むしろ問題を公にしてユーザーが自衛するほうが社会的公益性が高いと思い、2012年10月21日に脆弱性関連情報の非開示依頼の取下げ申請をIPAに送ってみたら以下のような返事が返ってきた。 ドキュメント検査だけでは不十分なので、とりあえず、自分の名前や所属、使用しているコンピュータ名等が公に知られたくないという人は、Microsoft Officeで作成されたファイル(PDFに変換したのを含む)を他人に配布するのを避けるとよいと思います。 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------- このメールは、取扱い番号 I
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
