seccamp'15

paper.txt

2015年度セキュリティキャンプ応募用紙Write up
※いつかgithub.ioで書き直します

<注意事項>
まとまってないです．そのままです．
途中支離滅裂であったり，それは間違ってるでしょって部分もあるかと思いますが，これを出したということで．．．
また，本名バレしそうな部分，画像部分は伏せました．ご了承ください．
選択問題は4,7,9,11,14を選択しました．
</注意事項>

<基本情報部分>
年齢:20才
twitterアカウント書きました
</基本情報部分>

<共通問題1>
中学生のころよりセキュリティ・キャンプに参加したいと思っており，今回技術的に応募してもよい点に達したと考えたため応募しました．
セキュリティについて勉強しようと思った理由は，共通問題2でも書きますが，過去にクラッキングによって自分の気に入ったWebサイトが閉鎖
に追い込まれたことがあったことからです．この事件から，セキュリティに関する知識や技術があって，それを実際に使えないと，自分の所属
する組織や友人を守れない可能性があると思いました．そこから，情報処理やサーバ管理技術について学ぶうちにセキュリティ・キャンプの存
在を知り，こちらに参加させていただくことによって，よりセキュリティに関する知識・技術を身に着けられると考え，応募したいと思うよう
になりました．本年度のセキュリティ・キャンプでは，特に検知トラックの「フォレンジック技術を用いたインシデントレスポンス」，「完全
性を支える技術 –デジタル署名から実用的な改ざん検知まで-」の講義を受講したいと思っています．より正確に，素早く不正アクセスや改ざん
を検知し，対策することによって，データの損失を最小限に防ぎ，システムの復旧を早く行うことができるため，この講義のような技術が必要
だと考えました．また，トラックは違いますがWebアプリケーションのセキュリティに関わる「バグハンティング入門」の講義も受講していきた
いと考えています．
私は，セキュリティ・キャンプで学んだ知識・技術をつかって自分の守りたいものを守れるようになりたいです．また，そこから多くの人の大
事なWebサイトやデータを守ることにつなげることが出来たらと考えています．私は，Webサイトやデータを守ることは，単にデータを壊さない
・他人に盗聴されないだけでなく，そこにあるコミュニティや誰かの居場所を守ることにつながると考えています．なので，よりセキュリティ
について詳しくなって，人と人とのつながりや信用が第三者によって壊されないような社会をつくっていくことに貢献したいです．(834文字)
</共通問題1>

<共通問題2>
10才のころに，自分がよくアクセスしていて気に入っていたWebサイトが何者かにクラッキングされ，改ざんされたことにより閉鎖に追い込まれ
たことが最も印象に残っています．ある掲示板サイトで，多くのユーザが議論を交わしたり，チャットをしたりしてコミュニティを形成してい
た賑やかなWebサイトだったのですが，最初の改ざんを受けてからわずか数日で第三者にアクセス権を掌握され，そのWebサイトにアクセスする
ことは不可能になりました．管理人の方が避難所サイトを立てる等の対策をしていたのですが，改ざんを受けたことによってユーザが他の競合
Webサイトに流れて行ってしまい，さらに改ざんを受けたデータを復旧できないことにより，閉鎖することになってしまいました．改ざん初期の
Webサイトはまだ掲示板が機能していて，多くのユーザが「こんなことはやめてほしい」「お願いだからこんなことしないでください」と犯人に
対してコメントを残していったことを今でも思い出すことができます．印象に残った理由として，当時の私には少しずつ崩れていくWebサイトの
様子を見ることしかできず，とても歯がゆい思いをしたことが第1に挙げられます．もう1つの理由は，このWebサイトが閉鎖されたことによって
，それまで確かにあったはずのコミュニティがあっけなく壊れてしまい，それに強くショックを受けたことにあります．
この事件以来，Webサイトのユーザの立場でも何かWebサイトの役に立てるはずだと考え，訪れるWebサイトにバグがないかチェックするようにな
りました．また，自分でもWebサイトを運営したいと考え，大学入学後に所属した学生団体で自ら志願してWebサイトの構築・管理をするように
なりました．この事件があって悲しい思いをしましたが，このWebサイトのどこがいけなかったのか考えることが，Webサイトをクラッキングさ
れないためにはどうしたらいいのか，またWeb上のセキュリティについて考えるきっかけになりました．(801文字)
</共通問題2>

<共通問題3>
高等学校は***立***商業高等学校***科に進学しました．プログラミングの勉強に打ち込み，友人とチームを組み第31回全国高等学校IT・簿記選
手権大会IT部門近畿中国四国ブロック大会団体6位，第24回全国高等学校情報処理競技大会大阪府大会団体優勝，個人3位を受賞しました．また
，高校2年生の8月にITパスポートを取得しました．
大学は***大学***学部に進学し，コンピューティング系の講義・実習を主に履修しています．特に，プログラミング実習ではC言語，Javaについて学
習しました．また，大学2年生の11月に基本情報技術者試験に合格することができました．私の大学では3年生からゼミに入るのですが，私は
***について取り扱っている***ゼミに所属しています．ゼミでは，現在先輩の卒業論文の再現を行うべく，Ubuntu-serverを使ったWebサーバの
構築やネットワークの勉強をしています．また，4月から5月にかけてゼミの先輩と第19回サイバー犯罪に関する白浜シンポジウム併設の第10回
情報危機管理コンテストの2次予選まで参加させていただきました．決勝まで行きたかったのですが今年は行けなかったので来年再チャレンジす
るためにインシデントレスポンスについて学んでいきたいと考えています．特に，今回はどういった場所が改ざんを受けていて正しくWebページ
が表示できないのかまでは理解できたのですが，根本のどこから第三者に侵入されたかについて理解できていない部分が多いため，来年までに
トラブルの原因究明を進めていけるように勉強したいです．最近はゼミ内の活動としてCTF部が立ち上がり，そこでゼミの先輩や同期と一緒に常
設型CTFの問題を解いています．攻撃者の思考を知ることができれば，防御する側でも攻撃者の考えに沿った防御システムを考えることができる
と思うので，参加しています．部活動等ですが，***という大学公認の映像制作団体に所属し，Webサイトの管理をしています．平成25年度，26
年度はメインでhtml/cssでのコーディングを担当していたのですが，最近Webサイトをリニューアルし，後輩にコーディングの引き継ぎをしまし
た．また，部活動ではありませんが，実習のアシスタントを担当するStudent Assistantを積極的に行っています．2年生の春学期はソフトウェ
ア実習でTeX，SAS-JMP，html/cssの基本について，2年生の秋学期ではネットワーク実習でUNIX環境でのコマンド操作について，3年生の春学期
(現在)ではEnjoy ComputingでWord/Excel，Photoshop，javascriptについて教えています．教えることによって他の人がどのような点で躓くこ
とが多いのかわかり，毎回の実習で受講者の方に学ばせていただいていると感じています．最近は，自分がプログラミングやセキュリティに興
味を持ち始めたころと同じくらいの年齢の人にITについて教えられるようになりたいと思い，***のメンター候補として研修に参加し，Webプロ
グラミングについて教えられるようRubyやjavascriptの勉強に取り組んでいます．
私が上記のような活動をしてきた理由は様々ありますが，一貫した理由は「いかにしてセキュアなWebサイトやシステムをつくるか学びたい」と
いうことです．情報学の基礎知識を資格等の取得で得ることはもちろん，セキュリティに関するゼミに所属させてもらったこともこういった理
由からです．また，他者に正しく情報システムについて理解してもらうことによって少しでも全体のセキュリティリテラシのレベルを上げてい
きたいと考えて，Student Assistantなどの教育関係でも活動をしています．Web社会が現実社会とリンクすることが多くなってきた昨今では，
Webサイトからの情報流出で多数の被害を生むことが多くなりました．セキュアなWebサイト・システムをつくるには素早くシステムの異常を察
知することが必要となってきます．そのため，検知トラックの講義を主に受講したいと考えています．(1565文字)
</共通問題3>

<選択問題4>
(1) 私は共通問題3で述べました所属団体のサイトにpingを打ちました．このサイトにpingを打とうと思った理由は，管理しているにも関わらず
，レンタルサーバ上で動かしているからと日ごろサイトにpingを打ったりすることがなく，試しに打ってみたいと思ったからです．以下は自分
の端末からサイトへpingを打った結果です．
(図1:pingを打った画面のキャプチャ)
(2) ｔracert(UNIX系のOSではtraceroute)というコマンドを使うと，自分の端末から対象の端末への通信がどのようなIPアドレスをたどって行
われているかを見ることができます．図2は自分の端末から(1)のサイトへtracertを行った結果です．
(図2:tracerouteキャプチャ)
一番左の数字はいくつめのホップかを表し，その次の○mが3列続いているものは，各ルータの反応速度を表しています(3度試行できるため，3つ
数字があります)．最後のものが各ルータのホスト名とIPアドレスで，ホスト名がないものもあります．どの通信をする上でも，自分の端末から
ネットワークを通してパケットが目的のホストまで届けられます．パケットというものは，送りたいデータとデータを送る際に必要な情報を結
びつけたデータの小包で，送信元である自分の端末の情報(IPアドレス，MACアドレス)や，送信先の情報(IPアドレス，MACアドレス)などが含ま
れています． 
各ルータにこの小包がバケツリレーのように回っていき，目的のホストまで届けられています．上記のtracertの結果は，自分の端末から所属団
体のサイトまで，どのルータを通って通信しているかを表しています．
まず，端末が別の端末にデータを送りたいと思った時に，指定されたアドレスがIPアドレスではなくホスト名だった場合は，DNSサーバに問い合
わせてホスト名をIPアドレスに変換します．そして，自分のルーティングテーブルを見て，送信先のIPアドレスがある場合は直接そのIPアドレ
スにパケットを送ります．(これをダイレクトルーティングと言います．) 自分のルーティングテーブルに送信先のIPアドレスがない場合は，パ
ケットをデフォルトゲートウェイのMACアドレスに送信します．このとき，デフォルトゲートウェイのMACアドレスがARPテーブルに無い場合，A
RPコマンドをデフォルトゲートウェイに送信し，デフォルトゲートウェイのMACアドレスを入手してから，デフォルトゲートウェイのMACアドレ
スにパケットを送信します．デフォルトゲートウェイは，自身のルーティングテーブルを見て，該当のIPアドレスがある場合はそのIPアドレス
を持つMACアドレスへパケットを送信します．また，ここでもMACアドレスが分からない場合は該当のIPアドレスへARPコマンドを送信しMACアド
レスを入手します．ルーティングテーブルに該当のIPアドレスが無い場合は，ルーティングテーブル内のネットワークアドレス部が最も長いIP
アドレス(プレフィックス長が長いIPアドレス)に対応するMACアドレスにパケットを送信します(ロンゲストマッチ)．パケットを受け取ったルー
タはデフォルトゲートウェイと同じく，自身のルーティングテーブルに該当のIPアドレスがある場合はそのIPアドレスに対応するMACアドレスに
パケットを送信し，該当のIPアドレスが無かった場合はルーティングテーブル内のネットワーク部がもっと長いIPアドレスに対応するMACアドレ
スにパケットを送信します．そしていくつかのルータを同じような手順で経由したのち，送信先のMACアドレスにパケットが送られることになり
ます．図2のtracertの結果では，計17個の端末を経由していることがわかります．
(3) サイトを見る際は，TCP，IP，HTTPの3種のプロトコルを使うことが一般的です．また，TCP，IPをまとめて，TCP/IPと言うことが多く，TCP
/IPが使うことのできるプロトコルとまとめてTCP/IPプロトコルスイートと呼ぶこともあります．TCP/IPは，TCP/IP5階層モデルというOSI参照モ
デルの各階層に対応する階層構造を持っています．高レイヤーから順に，アプリケーション層はアプリケーション層，プレゼンテーション層，
セッション層に，トランスポート層はトランスポート層に，ネットワーク層はネットワーク層に，ネットワークインタフェース層はデータリン
ク層に，物理層は物理層に対応しています．TCPはTCP/IP5階層モデルのトランスポート層のプロトコルで，よく比べられる同じ階層のプロトコ
ル・UDPとは違い，通信は多少UDPより遅いが確実かつ正確な情報を届けることのできるプロトコルです．3-Wayハンドシェイクという通信相手と
SYN/ACKパケットを送りあうことで通信を確立する仕組みや，ネットワーク上でパケット同士が衝突してしまい，パケットを紛失した場合に再度
送信するCSMA/CAという仕組み，指定されたポート番号へ通信を送り届ける仕組みがTCPによって提供されていることによって，確実で正確な通
信が保たれています．IPはTCP/IP5階層モデルのネットワーク層のプロトコルです．IPは，IPアドレスをパケットのIPヘッダに付与する仕組み，
経路制御情報(ルーティングテーブルなど)によって，宛先までパケットを届ける経路を制御する機能，送信先まで各ネットワーク機器を経由し
てパケットを送り届ける仕組みを持ちます．IPというプロトコルが無ければIPアドレスは機能しなくなります．HTTPは，TCP/IP5階層モデルのア
プリケーション層，OSI参照モデルのアプリケーション層のプロトコルです．また，TCPのポート80番はHTTPのために割り振られています．HTTP
は，ユーザ側からサイトのサーバへのコマンドと，サイトのサーバからの応答メッセージを規定するプロトコルです．ユーザは，GETコマンドを
打ってページの転送要求をしたり，PUTコマンドでURL上のデータを保存することができます．また，サイトのサーバは自分の状態に合わせて3桁
の数字の応答メッセージを返し，ユーザに知らせます．有名なもので200 OK(正常処理完了)，404 Not Found(該当URLが見つからない)や403 
Access Denied(アクセスが禁止されている)などがあります．
また，サイトにアクセスするのに当然インターネットへの接続が行われますが，ここではPPPoEというPPPプロトコルをEthernetのフレームでカ
プセル化したもので行っています．PPPはOSI参照モデルではデータリンク層にあたります．TCP/IPのために開発されたシリアルインタフェース
で，特定の媒体には依存せず1対1接続を実現することができます．PPPのデータリンク層のコネクション確立に，LCPという新たなプロトコルが
必要になります．LCPはPPPによるコネクションの確立と切断，フレーム長や認証プロトコル，データ圧縮，通知品質の監視についての設定を行
うことが出来ます．LCPの認証プログラムは，PAPやCHAPのどちらかの暗号方式が利用されます．これらのプロトコルが普段自分の端末とサイト
間をつないでいるものであると考察しました．
最後に将来のことですが，もしほかの惑星への移住に成功すれば，地球とほかの惑星で通信をすることがあるかもしれません．そんなときに人
工衛星間をルーティングするような規格が出来ていくのではないかと考えました．もっと近い未来なら，IPv6とIPv4の互換プロトコルなどが出
来ていくのではないかと予測します．(2863文字)
</選択問題4>

<選択問題7>
シナリオとしては，小さな会社のネットワーク内に，外部の1つのWebサーバに対して不審なほど更新ボタンが押されている状況を仮定します．
ネットワークの帯域を1台のPCで食いつぶしている状況で，通信が重くなっていることも仮定します．この会社ではDHCPサーバによって各PCにI
Pアドレスを割り振っています．
まず，社内のPCをつないでいるスイッチングハブのポートミラーリング機能(あるポートが送受信しているデータを，別のポートにも流していく
機能)を利用してパケットキャプチャをとります．パケットキャプチャとは，ネットワーク上に流れているパケットを採取することです．パケッ
トキャプチャを分析するソフトウェアとして，主にWiresharkが用いられます．Sourceが自分のIPアドレス，Destinationが通信先のIPアドレス
を表します．キャプチャをとった中から，一番多く通信をしているIPアドレスを突き止め，それがHTTPプロトコルで大量の通信を行っていると
わかった時点で，そのIPアドレスがどのPCに割り振られているか調査します．一番多く通信をしているIPアドレスにARPコマンドを送り，MACア
ドレスを返してもらいます．これによって，社内でのIPアドレスの割り振りはDHCPサービスを使っていますが，それぞれのPCのNICで違うMACア
ドレスを手に入れたことによって，不審な通信を行うPCを突き止めることができました．しかし，分かったのはMACアドレスで，MACアドレスか
らどのPCか特定しようとなると，厳密にMACアドレスと各PCの対応表をつくっている会社しか対応できません．そこでdigコマンドをつかってIP
アドレスのホスト名を抽出します．「dig www.xxx.yyy.zzz(IPアドレス)」といった風に使います．すると，「????????.?????????.?????????.
?????.??(ホスト名)  ????.????.??(ドメイン名)」といった反応が返ってきます．このホスト名をつかってどのPCかを特定します．特定できま
したら，そのPCを誰がつかっているのか社内で確認します．そして，使っている人を特定できたら，使っている人に意図して多量の更新をして
いるのかどうか確認します．もし，意図的に行っているのであれば，直ちに更新を停止してもらうように頼みます．説明としては外部に迷惑が
かかっている，自社ネットが重くなるためと言います．また，大量の更新を行った理由が必ずあるはずなのでそれを聞き，それに対する対策を
提示します．意図せず大量の更新を行っている場合は，第三者からbotとして踏み台攻撃に利用されている可能性があります．まずは，該当PCを
使っている人に怪しいプログラム・ファイルを開かなかったか聞いてみて，心当たりがあるようなら，そこから確認します．もし，不正なプロ
グラムを見つけた場合は消去します．その後は，Windows系のOSなら，タスクマネージャを起動して不正なプロセスがないかチェックし，あれば
プロセスを終了することを勧めます．UNIX系のOSなら，psコマンドで現在動いているプロセスをチェックし，不正なプロセスをkillコマンドで
停止させます．また，該当のPCを他のPCへの影響を考え，社内ネットワークから隔離します．ウイルススキャンを行ってウイルスに感染してな
いかチェックし，ログインパスを変更することを勧めます．また，他のPCも現時点で何も被害がなくてもウイルススキャンを行いログインパス
の変更をすることを勧めます．該当のPCのOSがUNIX系のOSだった場合は，lastコマンドを使って最近のログイン履歴を見て，意図しない時間に
アクセスされていないか見ます．また，アクセスされていた場合はシステムログをチェックし，どこのホストからログインを試行されたか確認
します(OSによって違いますが，*BSD系なら/var/log/auth.log，Redhat系なら/var/log/secureがシステムログです)．どこのホストからか確認
できたら，一時的な対策ではありますがそのホストを社内ネットワークからdenyするようにします．その後，該当のPCの中身を調べ，原因の究
明に努めればよいと考えました．(1559文字)
</選択問題7>

<選択問題9>
makeUrlLinks関数は，テキスト内のid要素がoutputである文を変数htmlの内容に更新するものです．html変数には，変数textをreplaceメソッド
で/[\w]+:\/\/[\w\.\-]+\/[^\r\n \t<>"']*/gの正規表現の結果をfunction(url)に変数urlとして読み込ませています．また，[\w]+は記号
(アンダースコア除く)を含まない任意の文字列が1つ以上ある状態，\/はスラッシュ(/)がある状態，[\w\.\-]+は記号(アンダースコア除く
)を含まない任意の文字列もしくはドット(.)，もしくはハイフン(-)が1つ以上ある状態，[^]で囲まれている部分は否定の部分なので，\r\nの改
行コード，スペース，Tab，タグの括弧(<>)，ダブルクォーテーション(“)，シングルクォーテーション(‘)を含まない状態を指し，*指定によっ
てこれらが0個であれば良いという状態になります．最後のgは/で囲まれた部分とマッチングするものを表示する正規表現です．つまり，前述の
状態を順番通りにすべて満たす文字列が変数urlに入ります．そして，<a href=" + url + ">" + url + "</a>";のurlの部分に置換したものが入
り，id要素がoutputの文に挿入されます．
この関数を作った方はhttp://www.hoge.com/などのURLが素の文で書かれていた場合に<a>タグで囲んでそのURLにジャンプできるようにしたいと
考えて作られたということがわかります．ですが，2行目のreplaceメソッド内の正規表現で最初の[\w]+:\/\/という指定を見る限り，a
://など，urlとして使えないものからftp://でFTPプロトコルを呼び出すことや，C://でユーザの内部ファイルにリンクするようにできます．も
し，http://形式のもののみにリンクを貼りたいのであればhttp://のみマッチングするように変更する方がよいと考えました．次の[\w\.\-]
+指定ですが，このままだと../../../といった指定ができるため，上位のディレクトリのファイルを参照することができます．通常，Webサーバ
ではDocument Rootより上位のディレクトリにさかのぼることは出来ないのですが，Webアプリケーションでは，上位ディレクトリにあるファイ
ルを参照するために上位ディレクトリの指定が可能であることがあります．ドメインの構造上，.は必ず1つ入るため，[\w\-]+\.[\w\.\-]
+という指定に変更した方が良いと思いました．最後の\/[^\r\n \t<>"']*指定ですが，この指定のままだとhttp://www.hoge.com/javascript
:alert(document.cookie);といったように，上記の禁則文字を含まない任意のスクリプトを実行される可能性があります．これを防ぐには禁則
文字に:()を含める必要があるため，\/[^\r\n \t<>"':()]*という指定にした方がよいと思います．また，この関数だとhttp://www.hoge
.comではリンク付けされないため，さらにこの指定を[\/]*[^\r\n \t<>"':()]*という風にすると有用性が高まると考えました．よって，/http
:\/\/ [\w\-]+\.[\w\.\-]+[\/]*[^\r\n \t<>"':()]*/gという指定が良いと考察します．(1017文字)
</選択問題9>

<選択問題11>
上記のバイナリをWiresharkで調べたところ，
No.	Time	   Source	   Destination	     Protocol	Length	Info
1	0.000000   192.168.146.1   192.168.146.128   TLSv1.2	82	Heartbeat Request
というフレームを得ることができ，このバイナリは192.168.146.1から192.168.146.128へのTLSプロトコルバージョン1.2によるHeartbeat 
Requestのパケットキャプチャであることが分かりました．Heartbeat Requestとは，オープンソースソフトウェアのHeartbeatを呼び出すもので
，Heartbeatはコンピュータやネットワーク機器自身が正常に稼働しているということを他のコンピュータに知らせていくものです．通常，Hea
rtbeatはメッセージとそのメッセージのペイロード長を相手に送り，相手から同じメッセージと同じペイロード長が返ってくることによって相
手の端末が正常に動いているか確認するものとなります．
さらに，フレーム内の細かい動作について調べていきます．ツリー情報を見ていると，Secure Socket Layerの部分が赤く表示されます．Wires
harkでは，エラーのある部分が赤く表示されます．この部分は，バイナリファイルの 18 03 03 00 17 01 0E FB 06 F6 CD A3 69 DC CA 0B 99 
FF 1D 26 09 E1 52 8F 71 77 45 FAの部分に該当します．Secure Socket Layerを展開すると，TLSv1.2 Record Layer: Heartbeat Requestのみ
があり，赤く表示されています．これも，上記のSecure Socket Layerと同じバイナリ部分を指しています．TLSv1.2 Record Layer: Heartbeat 
Requestを展開すると，Heartbeat Messageの部分が赤く表示されています．この部分は前述のSecure Socket Layerのバイナリファイルの01 0E 
FB 06 F6 CD A3 69 DC CA 0B 99 FF 1D 26 09 E1 52 8F 71 77 45 FAの部分に該当します．Heartbeat Messageを展開すると，Payload Length: 
3835 (invalid, using 4 to decode payload)の部分が赤くなっています．この部分は，前述のHeartbeat Messageのバイナリファイルの0E 
FBの部分を指しています．Payload Length: 3835 (invalid, using 4 to decode payload)を展開すると，Expert Info (Error/Malformed): 
Invalid payload heartbeat length (3835)というエラーメッセージを確認することができました．これは形式の正しくないペイロード長を与え
ているというエラーです．Heartbeat Message内の下から2番目のメッセージで，Payload (4 bytes)とあります．つまり，本来ならPayload 
Lengthは4バイト分の長さでよいはずが，3835という長すぎる値が指定されています．この3835という値を4バイト分の長さになるように短くす
れば，このエラーは消えます．
補足ですが，このエラーがOpenSSL1.0.1やOpenSSL1.0.1fでは出ずに，送られてきたペイロード長を本来の長さより多く指定された分だけ，Hea
rtbeat Messageとメモリ上で隣り合うデータが相手に返されるという脆弱性がありました．この脆弱性のことをHeartbleedと呼ぶそうです．も
し，Heartbeat Messageとサーバ上の秘密鍵などが隣り合って設置されていれば，秘密鍵を相手に送ってしまうことになる重大な脆弱性であった
ため，出血するほどショックが大きいことからHeartbleedと名付けられたようです．なお，現在のバージョンではこの脆弱性は修復されていま
す．(1032文字)
</選択問題11>

<選択問題14>
まず，コメント行のCVEをすべて調べてみました．
1.	CVE-2012-4009
ユーザのAndroid端末内に細工されたデータがあった場合，file://で始まるリンクをクリックすることで，細工されたファイルが読み込まれ，
その端末のデータ領域の情報が漏えいする可能性のある脆弱性
2.	CVE-2012-6636
Android API が、WebView.addJavascriptInterface メソッドを適切に制限しないため、Java オブジェクトの任意のメソッドを実行される脆弱
性
3.	CVE-2014-5991
Android 用 Skin Conditions and Diseases (別名 com.appsgeyser.wSkinConditions) アプリケーションがSSL サーバからの X.509 証明書を検証しないため、サーバになりすまされ、重要な情報を取得される脆弱性
4.	CVE-2014-1883
Android 上で稼働する Adobe PhoneGap が、適切な shouldInterceptRequest コールバックの代わりに shouldOverrideUrlLoading コールバッ
クを使用するため、デバイスリソース制限を回避される脆弱性
5.	CVE-2012-6637
Apache Cordova および Adobe PhoneGap が、ドメイン名の正規表現の終わりを固定しないため、ホワイトリスト保護メカニズムを回避される脆
弱性
6.	CVE-2014-3500
Apache Cordova Android には、スタートページを変更される脆弱性が存在する
1番目の脆弱性は，CVEに書いてあるとおりで，file://でローカルデータにアクセスすることが可能であるがゆえに，情報が漏えいする可能性が
あるというものです．setAllowUniversalAccessFromFileURLs()は，javascriptが任意の点からfile://を実行できるかどうかを判断するメソッ
ドで，ここではtrueを指定しているため，javascriptは任意の点からfile://のURLを開くことが出来ます．2番目の脆弱性は，webview
.addJavascriptInterface(this, "android");の一文で，webviewクラスのjavascriptに，this，つまりonCreateメソッドにアクセスできる権限
を渡しています．”android”は，javascript上でのグローバル変数の名前になります．3番目の脆弱性は，onReceivedSslError()という引数のUR
Lがssl証明書のエラーを起こしているときに知らせてくれるメソッドの内で，handler.proceed()を呼ぶことによってエラーを無視するような動
作になっていることです．4番目の脆弱性は，webviewで使われているAdobe PhonegapというAndroid上でhtml,css,javascriptを動かすことがで
きるようにするAPIが，shouldInterceptRequest ()メソッドではなくShouldOverrideUrlLoading()メソッドを使うことによって起こる脆弱性で
す． ShouldOverrideUrlLoading()メソッドはURLがクリックされた際や次のページに行く際に，webview上でサイトを開くか(false)，別のブラ
ウザを開くか(true)を判断するものです．ですが，このメソッドはiframeタグ内や，XMLHttpRequestでうまく動かず，これらにアクセスが来た
場合に，アクセスがバイパスされる可能性があります．5番目の脆弱性は，private static final String ALLOW_ORIGIN = "http://www.ipa.go
.jp";と3行目で指定してあるALLOW_ORIGINですが，正規表現に変換するPattern.compileメソッドを実行した際に正規表現の末尾を指定しなかっ
たために，http://www.ipa.go.jp以降に文字を追加できる仕様になっています．また，入力できない文字の指定もないためhttp://www.ipa.go
.jp<script>alert(“xss”)</script>のようなURLでも通ってしまいます．6番目の脆弱性は，アプリが呼び出された際にintentに細工がされてい
ると，スタートページを書き換えることができるというものです．
　これらを総合すると，クロスサイトスクリプティングにより悪意のあるページをwebview上で開いたり，file://がjavascript上で実行できる
ことから個人情報を悪意のあるページに引き渡したりすることができます．また，悪意のあるページはssl証明書を持たなくともユーザをページ
にアクセスさせることができます．(1198文字)
</選択問題14>