高木浩光＠自宅の日記

■ プログラミング解説書籍の脆弱性をどうするか

印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。

ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。

久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。

• 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月
• GIJOE, PHPサイバーテロの技法―攻撃と防御の実際, ソシム, 2005年11月

「PHP実践のツボ」は「セキュアプログラミング編」と謳っているわりに、いきなり最初のサンプルコードからしてクロスサイトスクリプティング脆弱性がある。――(A)

<?php
$strdate = $_GET['strdate'];
echo <<<EOD
日時文字列を入力してください。
<form>
<input type="text" name="strdate" value="{$strdate}">
<input type="submit" value="OK">
</form>
EOD;
if (!$strdate) {


（以下略）

山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.3

動かしてみると図1のように脆弱性が確認できる。

図1: 「PHP実践のツボ」の最初のサンプルコードが脆弱である様子*1

p.158にはこんな解説がある。――(B)

危険な文字列は削除する

この問題に対しては、変数 $filename の中に上位ディレクトリを示す「../」という文字列があった場合、適切に変換するしかありません。

1つは上位ディレクトリ指定の文字列を削除する方法です。

$filename = $_GET["filename"];
// 上位ディレクトリ指定を削除
$filename = str_replace("../", "", $filename);

山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.158

これは典型的によくあるまずい対策だ。

$filename = "----..././----";
$filename = str_replace("../", "", $filename);
echo $filename;

の実行結果は「----../----」と表示される。

そしてp.213にはこの記述ときた。

商用サイトなどでSSLを使用する場合は、一般的に認証局（Certificate Authority:CA）で発行された証明書を使用します。

非商用サイトなどで単に暗号化の目的だけならプライベートCAで発行した証明書でも問題ありません。ただし、プライベートCAで発行した証明書を使用する場合、SSLでの接続時にブラウザから警告メッセージが表示されます（図5）。

山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.213

こういう記述が誤解を拡大再生産してきたのだろう。今の時代に、焚書というわけにもいかないか……。

■ 「サニタイズ言うなキャンペーン」とは何か

もう一冊のPHPサイバーテロの技法―攻撃と防御の実際はどうかというと、抜け目なく書こうとする配慮が見られ、たしかにわりとよく書かれた*2本である。

しかし、安全なプログラミング手法という視点ではなく、あくまでセキュリティ対策だという視点で書かれているところに問題が残る。

たとえば、p.28のクロスサイトスクリプティング脆弱性の対策コードを見てみる。――(C)

ここを以下のように修正します。

while ( $row = mysql_fetch_array( $result , MYSQL_ASSOC ) ) {
    echo '<p>' ;
    echo 'No.'.$row['id'].'<br />' ;
    echo '題名:'.htmlspecialchars($row['title'],ENT_QUOTES).'<br />' ;
    echo '名前:'.htmlspecialchars($row['name'],ENT_QUOTES).'<br />' ;
    echo '日時:'.$row['postdate'].'<br />' ;


（略）

ソースコードの違いは一目瞭然だと思います。過去の投稿内容の各テキストが、ブラウザに表示される直前*04に、htmlspecialchars(（テキスト）,ENT_QUOTES)を通過しています。これが「HTML出力用サニタイズ」です。

GIJOE, PHPサイバーテロの技法―攻撃と防御の実際, ソシム, p.29

これのどこが悪いかというと、「id」と「postdate」について htmlspecialchars を通していない点である。

たしかにこれは脆弱性ではない。プログラムの全体を精査すれば、「$row['id']」の値が数値しかとらないことを確認できるだろうし、「$row['postdate']」の値が日付を表す文字列しかとらず、HTTPリクエストの値（CGI入力）に依存していない式だとということも確認できるのだろう。

だが、そのような確認作業をしないと正しいコードかどうかわからないような、プログラムの書き方をすべきでない。セキュリティ云々以前に、プログラムの開発方法論として、できるだけ局所的な視点でコードの正当性を確認できるように書くのが、近代プログラミングの基本だ。つまり、このコード断片だけ見て、問題がないとわかるように書くべきである。例えば次のように。――(D)

while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
    echo '<p>';
    echo htmlspecialchars('No.' . $row['id']).'<br />';
    echo htmlspecialchars('題名:' . $row['title']).'<br />';
    echo htmlspecialchars('名前:' . $row['name']).'<br />';
    echo htmlspecialchars('日時:' . $row['postdate']).'<br />';


ここで、「'No.' や '題名:' や '名前:' や '日時:' の定数文字列まで htmlspecialchars に通すなんて無駄じゃないか」などということを考えてはいけない。いまどき、そんな貧民的プログラミング思考をするのはプログラム職人として恥ずかしいことだ。

元々、HTMLを出力するときは、その出力全体に対して「<」「>」「&」のエスケープ処理の検討が要求されているのであって、CGI入力に依存しているかどうかは無関係である。そこの考え方に「無毒化」だの「無害化」だの「消毒」だの「サニタイズ」だの「サニタイジング」だのという（最近流行の）発想は出てこない。

HTML出力を書くときは、むしろタグを出力したいときの方が例外的であると考えるのがよい。たとえば、echo を全面的に使用禁止として次のように書くのもよいだろう。――(E)

while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
    htmlout_tag('<p>');
    htmlout('No.' . $row["id"]);
    htmlout_tag('<br />');
    htmlout('題名:' . $row["title"]);
    htmlout_tag('<br />');
    htmlout('名前:' . $row["name"]);
    htmlout_tag('<br />');
    htmlout('日時:' . $row["postdate"]);
    htmlout_tag('<br />');

タグの属性部分を出力するときは次のように書く。

    htmlout('日時文字列を入力してください。');
    htmlout_tag('<form>');
    htmlout_tag('<input type="text" name="strdate" value=');
    htmlout_quote($strdate);
    htmlout_tag('>');

使用した関数の定義はたとえばこんな感じだ*3。

function htmlout($str) {
    echo htmlspecialchars($str, ENT_NOQUOTES);
}
function htmlout_quote($str) {
    echo '"' . htmlspecialchars($str) . '"';
}
function htmlout_tag($str) {
    echo $str;
}

広義のクロスサイトスクリプティング脆弱性、つまり、掲示板へのタグ付き文字列の書き込みの問題が語られるとき、「HTTP_USER_AGENT もサニタイズしないといけないんだよ」ということがよく言われる。上のサンプルコードに User-Agent も加えるとき、

    echo 'No.'.$row['id'].'<br />' ;
    echo '題名:'.htmlspecialchars($row['title'],ENT_QUOTES).'<br />' ;
    echo '名前:'.htmlspecialchars($row['name'],ENT_QUOTES).'<br />' ;
    echo '日時:'.$row['postdate'].'<br />' ;
    echo 'ブラウザ:'.$row['useragent'].'<br />' ;


というコードを書きがちであるわけだが、それを見て、「$row['user_agent'] もサニタイズしないといけないんだよ」ということになる。対策マニアからすれば、

HTTP_USER_AGENTってのはね、攻撃者側でブラウザをいじって勝手に変えられるんだよー。ツールとか使ってね。HTTP_REFERERも偽装できるんだ。だから、User-Agent: とか Referer: とか、あと、X-Forwarded-For: や Via: に由来する変数もサニタイズしないといけないんだよー。

と、ハッカー気取りで語ってみせる大チャンスであるわけだが、そんなことはどうでもいい。(E)の書き方や(D)の書き方（つまり、タグ以外は一律に全部エスケープして出力する書き方）をしていれば、そんなことはどうでもよいのだ*4。

ではなぜ、解説書でさえ(C)のようなコードを書いてしまうのか。3つ考えられる。1つ目は、貧民的プログラミングの発想。2つ目は、煩雑な見栄えを嫌がってということがあるだろう。

まず、「htmlspecialchars」という名前が長い。これをあちこちに埋め込まないといけない。文字列連結している文の部分部分に htmlspecialchars を入れて、入れて、入れていかないといけない。これが嫌で嫌で堪らないプログラマが、それでも「セキュリティ対策しないと……」ということで仕方なく必死に作業していくと、必要最小限の場所にだけ htmlspecialchars と書くことになりがちだ。

その結果として何が起きるかというと、いわゆる「サニタイズ漏れ」だ。それを目を皿にして探していく作業も、たいへんなコストがかかることになる。

上に挙げた(A)の事例について、こうした脆弱性を指摘された本の著者はこう反論するかもしれない。「PHPの入門書なので、まずは PHPによる HTML formの基本的な書き方を説明したいだけ。最初からそこらじゅうに htmlspecialchars と散りばめたのでは、読者がついてこなくなってしまう。セキュリティ対策の方法は後半で書いているのだから、これでよいのだ……」と。

事実、2002年に、ある@ITの解説記事の脆弱性を指摘したとき、関係者の方から

記事の主旨はサーバサイドアプリケーションの諸環境の紹介を第一としておりますことご了解いただけますと幸いです

という釈明を受けたことがある。また同じころ、知人が書いていた書籍について、出版前に読んで欲しいと依頼されて読ませてもらったところ、やはり、SQLの使い方を紹介する章のサンプルコードがモロにSQLインジェクション脆弱性のある安易な書き方になっていて、「こういう書き方、やめようよ」と言ったことがあるのだが、著者は、「ここはSQLの使い方をわかってもらうためだから余分なコードは入れたくない」と主張して、全面的な書き直しはしなかった（注意書きが添えられ、後ろの章にセキュリティ対策の章が付け加えることで対処された）ということがあった。

このように、コードの見た目が煩雑になることがプログラマ達に嫌われていて、特に解説本の著者がひどく嫌っていることがわかるが、それが脆弱プログラマを増殖させる原因となっている。

そして3つ目の原因が、「サニタイズ」という言葉が安易に流行りすぎていることの弊害である。

「サニタイズ」というのは、「無害化」という意味の言葉であることから明らかなように、あくまでも「セキュリティ対策」としての文脈でしか語られない。そうすると、「CGI入力の（に依存した）変数はサニタイズせよ」というスローガンになってしまう。これが悪しきプログラミングスタイルを助長して困る。

正しくは全ての変数をエスケープ対象とせよが基本であるし、変数だけじゃなくて式全体をエスケープの対象とするべきなのに、「サニタイズ」という言葉で教育が行われていると、その考え方に至る機会が殺がれてしまう。

だから、「サニタイズ言うな」なのだ。

解説本の著者にとって、煩雑なコードはただでさえ避けたいところ、こうした処理のことを「サニタイズ」という言葉で理解していると、本質的に必要な処理としてではなく、「あくまでセキュリティ対策として必要なんだ」という誤った理解をしてしまいがちだ。その結果、「サンプルコードでは脆弱なまま、後の解説でセキュリティ対策として教える」という書き方になってしまう。

この種の処理が、セキュリティ対策以前に元来本質的に必要な処理（SQL文を構成するコードでは元々常に必要な処理であるし、HTMLを出力するコードでは元々常に必要な処理）であることは、たとえば、次の事例を見れば明らかであろう。

• サポート&サービス FAQ紹介, 文書番号 763, オービックビジネスコンサルタント

  [Q]
  起動時に下記のエラーが発生する。
  「行1:’XXXX’の近くに不正な構文があります。
  文字列’)’の前で引用符が閉じていません。
  state:37000，Native:170
  state:37000，Native:105」

  【文書番号】763 【更新日】2003/08/12
  【対象商品】奉行21シリーズ全製品，奉行2000シリーズ全製品

  ---

  [A]
  原因・理由

  コンピューター名に「’ シングルクォーテーション」が含まれている場合に発生します。

  回答・対処方法

  コンピューター名に「’ シングルクォーテーション」を使用しないようにして下さい。

  （略）

これはローカルで動くソフトウェアのバグの話なので、セキュリティ脆弱性とは関係がないため、このような対処方法が案内されているのだろう。このように、セキュリティとは無関係なところでも、SQL文を構成するときに「'」で囲んだ中に式（上の場合は「コンピュータ名」）を埋め込むときには、式の評価結果中の「'」をエスケープする処理は、元々当然のこととして必要なのだ。これは、入門書としてSQLの使い方を解説する場面で、一番最初に叩き込むべきことである。セキュリティとかを持ち出すまでもない。

SQL文やHTMLだけでなく、文法を持つ文字列一般を文字列連結で生成するときに、こういった処理が必要となることを、プログラミング一般を教えるときに体験させておくべきかもしれない。

11月22日の日記「攻撃者視点ではなく開発者視点での解説を」で批判したその連載記事でも、サニタイズという言葉に毒されている様子がうかがえていた。

セキュアプログラミングの限界

Webアプリケーションの脆弱性を生み出さないために、Webアプリケーション開発者の間ではセキュアプログラミングという概念が浸透していった。この概念には、セキュアなプログラムを作成するためのあらゆる方策が含まれているが、よくいわれることはユーザーからの入力データをそのままプログラムに受け渡すのではなく、一度必ず浄化作業（サニタイジング）を行うという考え方である。

例えば、プログラムやコマンドで意味を持つメタキャラクタ（メタ文字：\、[、]、|、$、*など）の入力を禁止し、正規表現にて入力文字列のパターンを限定することによって入力データの浄化を行う。

Webアプリケーションファイアウォールの必要性 第1回 機密情報に合法的に近づけるWebアプリケーションを守れ, @IT, 2005年8月17日

セキュアプログラミングが何たるかを取り違えているのだから、「セキュアプログラミングの限界」などという誤った帰結にたどり着いている。「サニタイズ」という概念は攻撃者視点の発想であり、攻撃者視点で対策を考えていると、攻撃者視点ではなく開発者視点での解説を」で示したような、誤った対策手法を導いてしまいかねない。

上に挙げた(B)の事例にも、「サニタイズ」という流行語の害が見られる。

「危険な文字列は削除する」という発想をすることが間違いなのだが、「サニタイズ」という言葉からは「削除」とか「変換」という対策を連想させやすい。

パス名を受け取ることを想定したパラメタに「../」や「..\」が含まれていたら、削除とか変換をするのではなく、エラーとして例外処理して終了するというのが、本来のそのプログラムの正しい動作だろう*5。

「サニタイズする」という対策屋発想には、「不用意にプログラムの挙動を変えてはいけない」という背景があるように思える。つまり、既に稼働中のシステムに対して脆弱性検査を行ったときに脆弱性が見つかると、プログラムの他の部分に影響を与えないように、最小限の変更で脆弱性を排除したいと考えるだろう。「○○のときはプログラムを終了」などという大それたプログラムの意味の変更を、対策屋が実施するべきでないという考え方は頷ける。そのような考えに基づくと、CGIの入力段階で削除したり変換するということになる。これが、元々の「サニタイズ」という言葉だったはずだ。先の引用にあった、

ユーザーからの入力データをそのままプログラムに受け渡すのではなく、一度必ず浄化作業（サニタイジング）を行うという考え方である。

Webアプリケーションファイアウォールの必要性 第1回 機密情報に合法的に近づけるWebアプリケーションを守れ, @IT, 2005年8月17日

という記述は、まさにそうした「サニタイズ」の発想で書かれている。

既存のシステムに応急手当としてそのような対策をする場面ではそれでもよい。「サニタイズする」と言って正しい。だが、これから新規に開発するシステムにおけるセキュアプログラミングを語るときに、「サニタイズ」とか言うのはもうやめたらどうか。

もっとも、万が一に脆弱性があるかもしれないことを想定しての保険として、CGIの入力段階でパラメタを洗浄する（サニタイズする）ことには賛成だ。とくに、制御コードはサニタイズしてしまうことを検討した方がよいかもしれない（真に改行コードの入力を必要とする部分では、改行コードは削れないが）。だが、それはそれなのであって、ごちゃ混ぜにしてはいけない。「本来の正しいプログラム方法 + 万が一のための保険としてのサニタイズ処理」という整理を常に心がけるべきである。

「サニタイズ」というあたかも専門用語であるかのような香りの漂う、このカタカナ化された輸入語は、とても安易に使えて一度使うとやめられない麻薬のような言葉なので、セキュアプログラミングの本質を理解していない素人対策屋（つまり、脆弱性検査の経験はあっても開発者としての経験がないような人）でも、「それさあ、サニタイズしてないのがいけないんだよねー」と、訳知り顔で語ってみせることができてしまう。

もちろん、「サニタイズ」を「エスケープ」に言い換えるなどというのは超大間違いだ。実際、どこだったかで、パス名パラメタの「../」チェックの対策を解説する文書で、

「../」を「..%2F」にエスケープしましょう。

などというものを見た記憶があるが、超大間違いだ。

とりあえず「サニタイズ」も「エスケープ」も口にしないようにしてみたらよい。サニタイズという言葉を使わずに自分が言いたいことを表現しようとしてみたらいい。正しく説明することの困難から逃げようとするな、ということだ。

■ ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに

ERBをWebページに使うとき、クロスサイトスクリプティング脆弱性のないように書くには、 「<%=h ... %> 」という記法を使って、次などのように書く。

No. <%= row["id"] %><br />
題名: <%=h row["title"] %><br />
名前: <%=h row["name"] %><br />
日時: <%= row["postdate"] %><br />
 

これは(C)のプログラムをERBに置き換えたものだ。

「h」というのは「html_escape」というメソッドの別名として定義されており、エスケープ処理が煩雑にならないようにすることを意識して設計されていることがうかがえる。

このようにすっきりした書き方を見ると、「title」と「name」のところだけ「<%=h ... %>」とするのが不自然で、全部「<%=h ... %>」にしてしまうのが自然だという感じがしてくるだろう。

そうすると、「h」付きと「h」無しを逆にしたらよかったのにと思えてくる。

<%= ... %> の外は静的なHTML断片であるのに対し、<%= ... %> の部分は動的なものを埋め込みたいときに使う。動的なものを埋め込みたいときというのは、そのほとんどは、タグ自身を埋め込みたいわけではないだろう。とすると、デフォルトで全部HTMLエスケープしてしまうのが自然ではないだろうか。逆に、タグをどうしても動的に埋め込みたいときに <%=h ... %> と書く方がよかったのではないか。（名前は「h」以外にした方がよさげだが。）

そのようにして考えると、そもそも、ASPから始まって、JSP、PHP、ERBと受け継がれてきた、HTML中にプログラムを埋め込むというこの仕組みが、最初からデフォルトでエスケープされるように作られていたらよかったのに……と思えてくる、そんな今日この頃だ。