タグ

ブックマーク / hasegawa.hatenablog.com (25)

  • 安全な脆弱性の作り方 - 葉っぱ日記

    この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」16日目の記事です。具体的な脆弱性の話でなくてすみません。いろいろコードを書いていると、安全に脆弱性を発生させたくなるときがあります。って書くとさっぱり意味がわからないと思いますが、セキュリティの講義のための演習環境とかそういうやつです。 受講生自身の手でWebアプリケーションの脆弱性を探してもらうような演習では、検査対象となる脆弱性を含むWebアプリケーションを用意する必要があります。こういった「脆弱なWebアプリケーション」は例えば Broken Web Applications Project のようなものを代表にいくつかのものがありますが、これらはUI英語であったり、あまりにもメジャーすぎて受講生も触っている可能性があったりと、場合によっては利用が難しいことがあります。特に、単一のWebサーバに対して複

    安全な脆弱性の作り方 - 葉っぱ日記
  • Electronのwebview要素ではallowpopups属性をつけてはいけない - 葉っぱ日記

    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

    Electronのwebview要素ではallowpopups属性をつけてはいけない - 葉っぱ日記
  • 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属性

    iframe sandbox は万能ではない - 葉っぱ日記
  • 脆弱性"&'\ Advent Calendar 2014 (17日目) - 葉っぱ日記

    この記事は脆弱性"&'<<>\ Advent Calendar 2014の17日目の記事です。今日は少し昔話をしようと思います。がはは。 かつて、日TwitterのようなWassrというサービスがありました。当時、Twitterは数日に一度くらいはサービスが落ちていて、Twitterユーザーも「またか」と思いながら我慢して使うようなサービスであり、Twitterが落ちるたびにWassrはユーザーを増やすとともに、画像の添付のように当時Twitterにはまだなかった機能をどんどんアグレッシブに取り入れていく、使っていて楽しいサービスでした。 さて、そんなWassrがある日絵文字機能を導入しました。当時はUnicode絵文字もなくスマートフォンも普及しておらず、主にレガシーな携帯電話で使える絵文字をなんとかWeb上でも使えるようにしたという感じのものでした。 絵文字をパレットから選択すると

    脆弱性"&'\ Advent Calendar 2014 (17日目) - 葉っぱ日記
  • 脆弱性"&'\ Advent Calendar 2014 (12日目) - 葉っぱ日記

    この記事は脆弱性"&'<<>\ Advent Calendar 2014の12日目の記事です。 Enjoy!

    脆弱性"&'\ Advent Calendar 2014 (12日目) - 葉っぱ日記
    TokyoIncidents
    TokyoIncidents 2014/12/12
    理解するのにちょっと時間がかかった
  • ファイアウォール内のサーバに対するShellshockを利用した攻撃 - 葉っぱ日記

    2014-09-27: 該当サイト上にXSSがなくても攻撃可能であることが id:mayuki さんのコメントで判明しましたので全面的に書き直しました。ファイアウォール内であっても攻撃者はファイアウォール内のShellshock攻撃が通用するCGIのURLがわかっているだけで攻撃可能ですので早急に対応が必要です!会社のブログにも書いてますが、ファイアウォール内に置いてあるサーバで攻撃者が直接アクセスできないからといってbashの更新を怠っていると、条件によっては攻撃が可能となります。 条件としては、 そのサーバにはシェルを経由して外部コマンドを起動するCGI等が動いている(通常のShellshockの攻撃と同条件) 攻撃者がそのURLを事前に知っている(あるいは推測可能) となります。 攻撃者は、ユーザーを罠URLへ誘導し、以下のようなJavaScriptを罠ページ上で動かし、攻撃対象のW

    ファイアウォール内のサーバに対するShellshockを利用した攻撃 - 葉っぱ日記
  • LINE株式会社 に行ってきた! - 葉っぱ日記

    台風一過!はせがわです。 というわけで、Shibuya.XSSの会場を快く貸してくださったLINE株式会社さんに行ってきた! サイボウズのバグハンター合宿で疲れた体を引きずりながら大勢で魔宮である渋谷駅を抜けヒカリエへ。 出迎えてくれたのはおなじみのコニー、ブラウン、ムーンをはじめとする愛らしいキャラクターの面々。 ジェームズとジェシカもお出迎え。 見晴しのいい窓際にも。 遠くには夕焼けの富士山も見える! 大量のレッドブルを前にご満悦の941さん。 というわけで、夜遅くのグデグデな勉強会なのに快く会場をお貸しくださったLINE様、941さん、ありがとうございました! 雑なパクリ風味記事ですみません>< - ちなみに、Shibuya.XSS テクニカルトーク #5の内容や資料については、いつもどおり azu さんによる記事:Shibuya.XSS テクニカルトーク #5 アウトラインメモ |

    LINE株式会社 に行ってきた! - 葉っぱ日記
  • 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の

    mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記
  • 5分でテンションを上げる方法 - 葉っぱ日記

    ちょっとテンションを上げたくなる時ってありますよね!今日はそんなときに簡単にテンションをあげる方法をお伝えします! まず、PowerPoint(画像は2010)に適当な写真を張り付け 四角形を置き、写真と同じ大きさの四角形を置きます。 四角形の枠線を「なし」にし、「塗りつぶし」の図を先ほどの写真にします。これで同じ写真が2枚ならぶ恰好になります。 「図ツール 書式」から「背景の削除」を選び、顔と首を残し残りの背景を削除します。 顔パーツの「透過性」を40%くらいにします。 「図ツール 書式」の「回転」で顔パーツを左右反転させ、位置を調整すれば完成! テンションあがってきたー!

    5分でテンションを上げる方法 - 葉っぱ日記
  • 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対

    HTML5関連のセキュリティ情報 - 葉っぱ日記
  • アセンブラ短歌 - 葉っぱ日記

    世の中には常人には理解できない趣味を持っている人がいまして、組み込みOSを作っている坂井さんもその一人で、最近は「アセンブラ短歌」という新しい遊びを提案しています。アセンブラ短歌というのは坂井さんによると、“「アセンブラ短歌」は五・七・五・七・七の三十一バイト(みそひとバイト)から成る 機械語コードでプログラムを書いてみるという近未来の文化趣味であり,近年, 国内のハッカー間で密かなブームが起きています.” ということらしいですが、さっぱり意味がわかりません。 まあ意味がわからないのですがとりあえず嗜みとしてアセンブラ短歌くらい詠めないと恥ずかしい感じなので、自動的にアセンブラ短歌を生成するやつを作りました。 8086アセンブラ短歌ジェネレータ これを使うと、こんな感じの8086のアセンブラ短歌が誰でも簡単に詠めちゃいます。 a7 03 87 13 b7 03 65 a8 fb 1f 2

    アセンブラ短歌 - 葉っぱ日記
  • 機密情報を含む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として読み込みます。もちろ

    機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
  • Same-Origin Policy とは何なのか。 - 葉っぱ日記

    ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:

    Same-Origin Policy とは何なのか。 - 葉っぱ日記
  • Web StorageやindexedDBを扱う上でのセキュリティ上の注意点 - 葉っぱ日記

    localStorageやsessionStorage、あるいはindexedDBのようなブラウザ上でのデータの保存が可能になったことで、これらを取り扱ううえでもセキュリティ上の注意点が必要である。 これらのストレージは、localStorageやindexedDBは永続的に、sessionStorageはブラウザやタブを閉じるまでの間データが保持され続けるので、例えばWebアプリケーションがログイン機構を持っている場合にログイン中にこれらのストレージに書き込まれたデータは、ログアウト後も当然参照および書き換えが可能である。Webアプリケーション上のアカウントに紐づいたデータをこれらのストレージに書き込んでいる場合、ログアウト後もアクセス可能なことが問題を引き起こす可能性がある。 例えばTwitterのようなサービスがあったとして、(navigator.onLineプロパティなどを利用して

    Web StorageやindexedDBを扱う上でのセキュリティ上の注意点 - 葉っぱ日記
  • 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

    XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
  • 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として読み込んで内部にアクセスする手法は、現在のところ公にされているところでは古

    GoogleのJSON(モドキ)の先頭にwhile(1); がつく理由 - 葉っぱ日記
  • 脆弱性関連情報の非開示依頼の取下げ申請の結果が返ってきた - 葉っぱ日記

    2008年8月5日に届け出た脆弱性というか仕様というか問題ある挙動について、いつまで経っても修正されず、むしろ問題を公にしてユーザーが自衛するほうが社会的公益性が高いと思い、2012年10月21日に脆弱性関連情報の非開示依頼の取下げ申請をIPAに送ってみたら以下のような返事が返ってきた。 ドキュメント検査だけでは不十分なので、とりあえず、自分の名前や所属、使用しているコンピュータ名等が公に知られたくないという人は、Microsoft Officeで作成されたファイル(PDFに変換したのを含む)を他人に配布するのを避けるとよいと思います。 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------- このメールは、取扱い番号 I

    脆弱性関連情報の非開示依頼の取下げ申請の結果が返ってきた - 葉っぱ日記
  • Shibuya.XSS テクニカルトーク#1 開催しました。 - 葉っぱ日記

    Shibuya.XSS テクニカルトーク#1を開催しました。 参加して頂いたみなさん、発表してくださったみなさん、そして会場を快くお貸しくださったうえにビールとピザまでご用意くださったmixiさん、ありがとうございました。 私の発表した資料を置いておきます。 MBCS文字コードを使ったJS配列の乗っ取り 次回予定はまったく未定ですが、もし開催することがありましたらまたみなさんのご参加をお願い致します。

    Shibuya.XSS テクニカルトーク#1 開催しました。 - 葉っぱ日記
  • IE6/7のでは「;」で区切ってURLが複数指定できる問題 - 葉っぱ日記

    Masato Kinugawaさんのブログ「Masato Kinugawa Security Blog: Googleのmetaリダイレクトに存在した問題」を読んで、 <meta http-equiv="refresh" content="0;url=http://good/;url=http://evil/"> みたいな書き方をするとIE6、IE7ではevilなほうにリダイレクトされるということを初めて知ったわけですけど、それをTwitter上で言ったら みたいに言われてしまって軽くショック受けたんで追試してみたけど、「;」をエスケープしようと <meta http-equiv="refresh" content="0;url=http://good/&#x3b;url=http://evil/"> みたいに書いても、「;url=」みたいな文字列が出現してしまって、やっぱりevilにリダ

    IE6/7のでは「;」で区切ってURLが複数指定できる問題 - 葉っぱ日記
  • 私はいかにして様々なブラウザの脆弱性を発見したか - 葉っぱ日記

    先日、Twitterでどのように脆弱性を見つけるかに興味あるんだろうかと書いたら、意外に色々な人から反応があったので、これまでに自分が見つけた脆弱性のいくつかについてどういう経緯で見つけたのかちょっと書いてみます。 JVN#89344424: 複数のメールクライアントソフトにおける、添付ファイルによりメールクライアントソフトが使用不能になる脆弱性 これは、添付ファイル名にUnicodeの円記号を含めておくと、メーラ側でShift_JISに変換する際にバックスラッシュに変換されてしまって想定外のディレクトリに添付ファイルが展開されてしまったり、あるいは「©on」のような名前のファイルを添付しておくことでShift_JISに変換してCONというファイルを開こうとしてメーラが固まってしまうという問題です。これは、私自身が文字コードの問題について調べ始めた初期段階で、Unicodeからの変換で問題

    私はいかにして様々なブラウザの脆弱性を発見したか - 葉っぱ日記