サイボウズ バグハンター合宿に行ってきた - 葉っぱ日記
先週の11月3日-4日に開催されたサイボウズ バグハンター合宿に参加してきた。 サイボウズ バグハンター合宿 - connpass 3年前は個人戦だったけれど今回はチーム戦ということに加え、クソつまらない脆弱性を多数報告した場合は評価が下がる採点方式だったので、最初はチームの足を引っ張らないようホームラン級のバグを探そうとしたけれど、最近すっかり技術的なことをやっていないのでなかなかそういうバグも見つけることができず、ゼロよりマシだろうということで結局わりとくだらないバグをいくつか報告した次第。とはいえ、他の人はあまりやらないだろうなという「クロスオリジンでの情報漏えい」みたいな自分としては好きなタイプのバグをひとつ見つけて報告することができたので、その点は満足。結果的にチーム順位は最下位、個人順位ではかろうじて10位に入るという感じでした(下から数えた方が早い)。Masato Kinug
安全な脆弱性の作り方 - 葉っぱ日記
この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」16日目の記事です。具体的な脆弱性の話でなくてすみません。いろいろコードを書いていると、安全に脆弱性を発生させたくなるときがあります。って書くとさっぱり意味がわからないと思いますが、セキュリティの講義のための演習環境とかそういうやつです。 受講生自身の手でWebアプリケーションの脆弱性を探してもらうような演習では、検査対象となる脆弱性を含むWebアプリケーションを用意する必要があります。こういった「脆弱なWebアプリケーション」は例えば Broken Web Applications Project のようなものを代表にいくつかのものがありますが、これらはUIが英語であったり、あまりにもメジャーすぎて受講生も触っている可能性があったりと、場合によっては利用が難しいことがあります。特に、単一のWebサーバに対して複
30xリダイレクトのレスポンスボディでもXSS(その2) - 葉っぱ日記
この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」11日目の記事です。昨日のネタの続きです。 昨日は30x応答のレスポンスボディを表示させるために21/tcpなどへのポートへリダイレクトさせるという方法を紹介しました。Firefoxではレスポンスボディを表示させるそれ以外の方法として、CSPを使うという方法があります。 リダイレクタが設置されているサイトが http://page1.example.jp/、リダイレクト先が http://page2.example.jp/ だったとします。 GET /redir?q=http://page2.example.jp/?"><script>alert(1)</script> HTTP/1.1 Host: page1.example.jp ← リダイレクト先と異なるオリジン HTTP/1.1 301 Moved Per
30xリダイレクトのレスポンスボディでもXSS - 葉っぱ日記
この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」10日目の記事です。小ネタですみません。 301や302のリダイレクトのレスポンスボディにてXSSが存在することが稀にありますが、30x応答ではボディ部分は表示されないのでXSSが存在しても脅威は発生しないというのが多くの方の理解ではないでしょうか。 GET /redir?q=http://example.jp/?"><script>alert(1)</script> HTTP/1.1 Host: example.jp HTTP/1.1 301 Moved Permanently Location: http://example.jp/?"><script>alert(1)</script> Content-Type: text/html; charset=utf-8 document has moved to
Visual Studio Code における任意コード実行の問題 - 葉っぱ日記
Microsoftの提供するテキストエディタ Visual Studio Code にはローカルに保存されている特定の名前のファイルを起動時に読み込み、その内容をコードとして実行してしまう問題があります。現在のv1.7.1では問題は解消されていますが、問題が発生することを確認したv0.8.0との間のどのバージョンで問題が修正されたのかは不明です。 Microsoftでは本件を脆弱性として取り扱っているのか不明です。 以下、IPA経由でのMicrosoftとのやり取りです。 2015-10-04 IPAへの報告 2) 脆弱性を確認したソフトウエア等に関する情報 名称：Visual Studio Code for Windows (https://code.visualstudio.com/) バージョン： v0.8.0 パッチレベル： 言語： 設定情報： ※ パッチレベルについては、マイナー
iframe sandbox は万能ではない - 葉っぱ日記
HTML5で導入されたiframe要素のsandbox属性は、そのiframe内のコンテンツに対しJavaScriptの実行を始め様々な制約を課すことでセキュリティの向上に役立つ機能である。例えば、以下のように指定されたiframeでは、iframe内からformのsubmitなどはできるが、iframe内でのJavaScriptの実行やtarget=_blankなどによってウィンドウを開くことなどは禁止される。 <iframe sandbox="allow-forms" src="..."></iframe> sandbox属性に明示的に allow-scripts という値を指定しない限りはiframe内では直接的にはJavaScriptは実行できないが、かといってiframe内から間接的にJavaScriptを必ずしも実行させることが不可能かというとそうでもない。 sandbox属性
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 知る人ぞ
セキュリティ・キャンプ全国大会2015資料まとめ - 葉っぱ日記
セキュリティ・キャンプ全国大会2015の講義で使用された資料のまとめ。公開されていない講義が多いので、すべての講義資料があるわけではありません。随時追加。 高レイヤートラック Webプラットフォームのセキュリティ JavaScript難読化読経 HTTP/2, QUIC入門 SSL/TLSの基礎と最新動向 フレームワークに見る Web セキュリティ対策(これからのWebセキュリティ) これからのWebセキュリティ フロントエンド編 クラウドセキュリティ基礎 バグハンティング入門 解析トラック 仮想化技術を用いたマルウェア解析 講義内容 TOMOYO / AKARI / CaitSith ハンズオン（アクセス解析初級・中級） セキュリティ・キャンプ全国大会2015でのマルウエア分析講義(2015-09-10) チューター発表 「脆弱性をみつける」から「脆弱性をなくす」へ カーネル空間からのセ
ブラウザ上で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上でも使えるようにしたという感じのものでした。 絵文字をパレットから選択すると
脆弱性"&'\ Advent Calendar 2014 (12日目) - 葉っぱ日記
この記事は脆弱性"&'<<>\ Advent Calendar 2014の12日目の記事です。 Enjoy!
AVTOKYO 2014で「CSPが切り開くWebセキュリティの未来」という題で話してきた - 葉っぱ日記
AVTOKYO2014で、にしむねあさんといっしょに「はせむねあ」というユニット名でContent-Security-Policyをテーマに話をしてきました。 Future of Web Security Opened up by CSP from Muneaki Nishimura 内容はスライドのとおりで、攻撃者はFiddlerなどを使って任意のCSP違反レポートJSONを送信可能であること、Firefoxの場合にはCSP違反レポートのJSON内に「<」「>」などが含まれるので、違反レポートを表示する管理画面でのエスケープ漏れがあると違反レポートを通じて管理画面内でXSSする、などの話を行い、実際に管理画面でのXSSのデモを行いました。 デモはあんまり細かいことは考えてなかったんですが、アドリブ苦手なにしむねあさんがいい味を出してて、横で見ていても楽しかったです。ちなみに直前の打ち合わ
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の
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
HTML5関連のセキュリティ情報 - 葉っぱ日記
HTML5に関連したセキュリティの話題で、とりあえずこれまでに話した資料の一覧や、考察した記事。今後もっと増える予定です。「このAPI使う上で気を付けることないの？」みたいなリクエストもあればぜひ言って下さいませ。 JavaScript Security beyond HTML5 (2013-09-20 Developers Summit Kansai 2013) HTML5セキュリティ その1:基礎編、XSS編 (2013-06-13 OWASP Night 6th) Web::Security beyond HTML5 (2012-09-28 YAPC::Asia 2012) HTML5時代のWebセキュリティ (2012-09-15 第5回愛媛情報セキュリティ勉強会) Same-Origin Policy とは何なのか。 - 葉っぱ日記 XMLHttpRequestを使ったCSRF対
セキュリティ・キャンプ2013 お疲れ様でした - 葉っぱ日記
今さらという感じもありますが、セキュリティ・キャンプ2013にWebセキュリティ・クラスの講師として今年も参加しました。 Webセキュリティ・クラス以外の実施内容については様々な記事をご参照いただくとして、ここではWebセキュリティ・クラスでの講義内容をご紹介したいと思います。 今年のWebセキュリティ・クラスでは、DOM based XSSを中心に、クライアントサイドで発生する脆弱性を中心に取り上げて講義および実習を行いました(参考:▶ セキュリティ・キャンプ2013：Webセキュリティクラスのご紹介)。ビデオ内でも話していますが、取り上げる内容をクライアントサイドに限定したのは、SQLインジェクションのような古くから存在するサーバ上の問題点については根本的な解決方法も見出されているものの、DOM based XSSのようなクライアントサイドで発生する問題についてはJavaScriptコ
補足編：機密情報を含む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として読み込みます。もちろ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
