ヾノ*>ᄉ<)ノシ帳スマートフォン用の表示で見るヾノ*>ᄉ<)ノシ帳ノンジャンルのふりーだむなブログです。以下のコードは、与えられたテキスト内からURLらしき文字列を探して、それらを<a>要素でリンクにしたHTMLを生成するJavaScriptの関数であるとします。中身を自由に制御可能な場合、このコードにはどのような問題点があるか、またこのコードを修正するとすればどのようにすればよいか、自分なりに考察して書いてください。}問題点makeUrlLinksでは、通常の文字列にhtmlコードがあった場合にそのまま表示されてしまいます。問題文は入力文字列の属性を(単なる)"テキスト"と定めているのでhtmlコードがhtml要素として表示される必要性は無いと判断しました。セキュリティ対策をするならば、今回の場合はphpでいうhtmlspecialcharsを適用すれば十分です。XSSAではonclick属性またはjavascriptのスキームを利用して任意のjavascriptコードを実行できることを実証しています。Scriptiong)攻撃と呼ばれています。XSSができてしまうとcookie(PHPSESSIDなど?)の読み取り・改竄や悪意のあるサイトへの誘導などが可能となります。cookieの方ではセッションの横取り、サイトへの誘導の方では誘導するサイトの例としてアクセスするだけでウイルスに感染するサイトがあります。forgeries)が可能です。高度なCSRFはCSRFの中で「高度」に分類できる攻撃の意味合いで使っています。今回の脆弱性を利用した高度なCSRFの例として、特定のセッションで進行しているネットショッピングで決済ボタンを押させるようなものや、掲示板で犯罪予告や荒らしを行わせるようなものが挙げられます。XSSのバリエーションA-1は本来のリンクの真上に悪意のある透明なa要素(今回は分かりやすいように色付き)を配置し、意図しないクリックを誘発させるものである。かわいい悪意に限ると、amazonの商品ページへのリンクをクリックしたつもりだったのに広告を押したことにできたりする。A-2はページが読み込まれたときにonerror属性に指定したjavascriptコードが実行されるものである。ユーザの操作が要らないのがポイント?A-3の攻撃は目に見えた悪意ではあるが、他のリンクの前に割り込んでそれを無効にしつつ、自分のリンクは表示させるというようなことが可能。「他のリンクの前に割り込んでそれを無効に」はコメントアウトさせることで実現した。なんかSQLインジェクションに似ていますね。iframeインジェクション攻撃Bではリンクを置き換えさせる仕様のことは一旦忘れて、makeUrlLinksの脆弱性を突くような攻撃をしてみました。XSSに飽きたのでiframe入れて2chを表示してみました(実際に攻撃するときはこんな露骨な表示のさせ方はしない模様←サイズを0px×0pxにする等)。iframeを悪意を持って意図的に表示させる攻撃はiframeインジェクション攻撃と呼ばれるようです。この攻撃を利用した過去の例としてGumblarがあります。iframeのsrc属性ではhttp(s)スキーム(B-1)やdataスキーム(B-2)が利用できます。修正編htmlspecialcharsするとhtmlコードは単なるテキストとしてブラウザがパースしてくれます。htmlsecialcharsの元ネタはphpの関数で、この関数はhtmlコードを片っ端からhtmスケープしてくれます。htmlspecialcharsをコードにすると次のようになります。text;}php界隈では、htmlspecialcharsは長いので関数hでオーバーラップするのが好まれているのでやってみました。htmlspecialchars(text);}htmlspecialcharsのタイミングはリンクを検出する(html.replace)の前でよいでしょう。);makeUrlLinkの正規表現中のスキームのチェックが甘いのでついでに直しました。ftpに上がっているファイルを指す場合もあるかもしれないのでこれを正規表現に含めるのもありだと思います。\w+のような甘いチェックは良くないと思います(セキュリティ対策はホワイトリスト方式が基本です←このあたりは専門家でも分かれるらしい)。結論makeUrlLinksを次のように変更し、補助関数を追加する。個人的にはこういう元栓を閉めずにパイプ漏れを直すような解決法は好きではないですが、これらを適用するのも一つの方法です。onclickなどを無効にするそのイベントがキャンセル可能である場合、event.preventDefault()でハンドラの実行を阻止できます。onclickがキャンセルできるかは未検証ですが...https://developer.mozilla.org/ja/docs/Web/API/Event/preventDefault[任意]cookieにセキュア属性を付ける直接的な対策ではありません。cookieをhttpsでしか利用しないようにする設定です。httpに切り替わったときに丸見えになるのを防ぐことができます。改変は防げませんhttp://blog.tokumaru.org/2013/09/cookie-manipulation-is-possible-even-on-ssl.htmliframeに外部ページを読み込ませないWebサーバ側での対策です。X-Frame-Optionsを利用すると、iframeで表示できるサイトを制限することができます。FAテキストで示されたバイナリ列をバイナリファイル化stirlingで手打ちで作成しました(ポケモンのROMを弄ったり、大学の某英語教材のセーブデータを解析したりするのに使ったことが思い出される...)asciiテキストらしきものが見当たらないのでウイルスのような実行ファイル系の可能性が低い...?objdump深く考えず実行ファイルかなと思ったので適当にネットの記事を参考にobjdumpしてみましたが、これは的外れのようでした。Type】を調べるようにプログラムしたことを思い出しました(他の班は拡張子で判定する安直な方法をしていたのでげんなり)。僕の班のテキストフォーマッタのプログラムでは内部的にLinuxのfileコマンドを使用したので、今回もその方針でファイルの種類を調べてみました。fileコマンドはオプション無しでは本来の拡張子はぱっと見ではわかりません。いう場合はiオプションが便利です。charset=binary結果を見る限り、pcapファイル(pcapはWireSharkのファイルの保存形式の一つ)っぽいことが分かります。00でぐぐってみると、本当にpcapっぽいことが分かりました。Heartbeatのパケットだけが出てきました。[f:id:katc:20150625110034p:plain]【←はてなブログのバグ?で出ないんだけど...】パケットを観察してみたまず画面を見てぱっと分かる情報を書き出してみます。(3835)Wiresharkを開いて分かるのは、このパケットが警告されているということです。lengthフィールドの値が実体よりも大きいからのようです(これが意味することは後で考察します)。現時点で、このパケットについて以下のことが分かります。2014年10月17日にキャプチャされたパケットローカルネットワーク(192.168.0.0/16)を流れたパケットMACアドレスが偽装されているTLSのHeartbeatのパケットpayloadとその長さのくだりで警告が出ているもしかしてネタ元はHeartbleedでは?【Heartbleedの解説なので省略】Heartbleedと今回のパケットの関連は?観察でわかったように、payloadの長さの指定がpayload自身よりも長くなっています。パケットはTLSプロトコルを使用したHeartbeatリクエストのパケットであるため、Heartbleed脆弱性を突いた攻撃をキャプチャしたものではないかと察することができます。宛先のSSLにその脆弱性がないのかをチェックする行為(もしくは攻撃?)をタイミングよく捉えたのかもしれませんし、ただ問題を作成するためにとりあえず投げたパケットなのかもしれません。用いてダウンロードできるようにすることを意図した、以下に示すログインシェルが使われています。内容がデフォルト設定のままであると仮定して、このログインシェルの脆弱性と、このログインシェルから起動されるプログラムの脆弱性の両方を突いて、書き込み可能なディレクトリ(好きな場所を仮定してよい)の中に任意のファイルをアップロードする手順を、コマンドラインを交えながら解説してください。1;}今回利用する脆弱性(方針立て)CVE-2014-7817を利用します。この脆弱性の内容をRedHatのBugzillaから引用します(https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-7817)。【ソースを見て、最初にWRDE_NOCMDでググったらあっさり出てきました。ように実行したいコマンドを入れることを目指します。作戦を練る完全に任意なコマンドを実行できるというわけではありません。そこはよく考えられている問題で、十数時間苦しめられた箇所です。クリアせねばなりません。実行する攻撃コマンドはスペースを含んではならない(strspnのacceptはスペースを含まない)実行する攻撃コマンドは大文字を含んではならない(strspnのacceptは大文字を含まない)ログインシェルを正常に終了するなら/home/などを先頭に含まねばならない(大した壁ではない)よって、最低でも次の制限事項が発生します。echoなど)システム環境変数を使えない(←$IFSとかダメ)URLなどは含められない一見突破できないように見えますが、コマンド単体である程度任意の処理を行う方法がシェルスクリプト(*.shファイル)以外に一つあります。シェル(bash)を起動すればよいのです(本当にSSH越しでシェルでもなんでもないようなこのログインシェルから呼ばれるシェルが使えるか不安でしたが、うまくいきました~)。作戦が決まったので検証しました。6.5を起動して、環境を構築しました。するときは次のコマンドを実行する。/home/$((1`bash`))'(パスワードを入力して)ログインが成功すると、ログインシェルの後にbashが起動する(ただし特にバーナーなどがない黒い画面のまま)ので、ファイルが作成されるようなコマンドを実行する。次のコマンドはその例(この場合アップロード先はtestのホームディレクトリ)。僕の応募用紙は一週間クオリティです。6万字書いた方もいるそうで、すごいですね。問題9の関数がリンクを見つけてa要素で囲って、その結果をreturnする関数だったら、htmlspecialcharsするのは不正解ですね(呼び出し元でそれをしている可能性が高いので)。この場合、問題の難易度が爆上がりしそうです。bashを起動させるという発想が斜め上過ぎません?Tanakaxaさんは後悔してらっしゃいますが、徳丸本から学んだHTTPヘッダ・インジェクションの攻撃用のリンクを作るアイデアは個人的に好きです。僕はそれを持っていながら応募のために一度も開きませんでしたし。僕の拙文が来年応募される方々の参考になれば幸いです。業務連絡:Tanakaxaさん、載せていいですよ。(1)はてなブログをはじめよう!katcさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。