<前の日記(2005年12月25日) 次の日記(2005年12月31日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 900   昨日: 2734

2005年12月27日

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

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

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

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

「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中にプログラムを埋め込むというこの仕組みが、最初からデフォルトでエスケープされるように作られていたらよかったのに……と思えてくる、そんな今日この頃だ。

*1 PHPの設定で「magic_quotes_gpc = On」にしているので、無駄な「\」が現れている。

*2 ただし、p.67のCSRF対策などには問題がある。「対策4」として、

管理者セッション内の各種データの受け渡しに、$_GET や $_POST ではなく、$_SESSION を利用する。

という手法が挙げられていて、これが本命の対策のように書かれているが、これは対策にならない。4月27日の日記に書いていたように、必要なパラメタ値がセッション変数にセットされているということは、前のどこかのページでその値をセットするリクエストがあるはずで、そのリクエストにCSRF攻撃した後に実行ページにもCSRF攻撃するような仕掛けで破られてしまう。

また、4-1-7節「SSLの効果」のp.125の記述に、パケット盗聴されたときの問題について、

Webアプリケーションを作るために、そのレベルでのクラッキングの可能性まで考えなければならないなんてナンセンスです。*15

逆に、SSLを利用し、かつ、クッキーに「SSL以外ではやりとりしない」という属性をつけていたとしても、XSSすら防げません。

と書かれていて、何を言いたいのかちょっと意味不明になっている。

もうひとつ問題点を挙げると、p.228のコラムで「magic_quotes_gpc」について、

magic_quotes_gpc機能についてはその副作用から批判も強く、この設定はOffとすべきと書かれた文献も多く存在しますが、プログラマーのスキルレベルが信用できないWebアプリケーションを利用するケースでは、magic_quotes_gpcをOnにする方が、ほんの気持ち程度は安全と言えます。

と書かれているが、magic_quotes_gpcをOnにすると、CGIパラメタがShift_JISで渡されたときに文字化けが発生してしまうため、これが邪魔になるという問題が起きているようだ。そのため、酷いことに、magic_quotes_gpc がOnのPHP環境でも動くようなプログラムを作るテクニックと称して、PHPプログラムの冒頭で、CGIパラメタの全部に対して「stripcslashes」をかけるという「前処理」が、一部のPHPプログラマの間で定番となっているようだ(この本に書かれているわけではない)。magic_quotes_gpc = On したり stripcslashes したり、また htmlspecialchars してみたりと、ほんと汚いPHPコードがたくさん Googleで見つかる。magic_quotes_gpc は Off で徹底がよいだろう。

それから、p.197の「7-1 ソースコードが手元にないときの脆弱性の見つけ方7-1-5 実際に攻撃してみる」で、

本当の悪意あるクラッキングであるなら、当然、プロキシやネットカフェを利用するなどのアクセス元の隠蔽も必要ですが、その手段については本書の範囲外です。

などと書かれているのが危ない。不正アクセス行為にあたらないことが確信できる操作しかしてはいけないのに、これでは勘違いする読者もいるのではないか?

とはいえ、この本では、session.use_trans_sid を off にすることや、session.use_only_cookie = 1 とすること、session.auto_start を off にすることなど、PHP特有の危険を回避するための重要な設定について書かれているところが良い。なお、このあたりの内容は以下のサイトでも読める。

*3 さらに発展させると、HTMLの要素を入れ子状に追加したり挿入して構成していくメソッドを用意するという方向性に行き着くが、やりすぎると、かえって煩雑になる、あるいは処理が重くなるなどの理由で、使われなくなってしまう。どこまで構造化された方法を使うのが、最もバランスがとれているかということになる。

*4 書籍「PHPサイバーテロの技法―攻撃と防御の実際」においても、p.48に「クッキー表示のサニタイズ」というコラムがある。cookieの値をHTML出力するときに「<」「>」のエスケープが必要かということが議論されていて、「XSS脆弱性があれば……クッキーを操作可能であるため……万が一のため……」としてエスケープするコードを示しているが、そういったことは、全部エスケープする正統なコーディングをしていれば考えるまでもない。

*5 この書籍には、続くページで、

また、上位ディレクトリ指定があった場合に不正な入力として終了する方法もあります。

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

という補足が書かれてはいるが、こちらが本来なすべきこととは書かれていない。

本日のTrackBacks(全82件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20051227]

隣のオフィスの人がこんなことを書いていました: 高木浩光@自宅の日記 - プログラミング解説書籍の脆弱性をどうするか, 「サニタイズ言うなキャンペーン」とは何か, ASPとかJSPとかPHPとかERBとか、逆だ.. なるほどね、「サニタイズ言うなキャンペーン」とはそういう意味..

「エスケープ対称」→「エスケープ対象」

「GGI」→「CGI」

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

27日のひろみちゅ日記が面白い。論点が多岐にわたりながらそれぞれ微妙につながっていて((ある意味まとまりがないともいえるがまとめる前の段階の論考だろうからしょうがないか。))色々考えさせられた。以下色々考えたメモ。僕はWebプログラミングについてはほとんど素人..

高木氏の「サニタイズ言うなキャンペーン」てのがちょっと面白い身につまされる話だっ

珍しくサニタイズという考え方自体が間違っているという意見を見ました。 私もサニタイズと言う考え方はNagative Security(禁止事項を定義する考え方)からの発想なので、Positive Security(許可する事項を定義する考え方)でプログラムを作るべきと考えていますし、あ..

MugeSoの日記:[PHP]現実問題 (2006年01月04日 16:40)

2ちゃんねるを見ていた。 【PHP】下らねぇ質問はここに書き込みやがれpart14 http://pc8.2ch.net/test/read.cgi/php/1134868212/ XSSすら考慮していないやからがまだまだいる現実。

HTML用のテンプレートにおいてエスケープされた状態がデフォルトであるべきだというのはその通りだが、ERBは(少なくとも建前上は)汎用テキスト処理用であってHTMLのエスケープ状態デフォというのはちょっと違う、では正しいアプローチはどーゆーモノかというと[http://jakarta...

高木さんの日記
・プログラミング解説書籍の脆弱性をどうするか
・ぜひ買いたいこの一冊(脆弱性コードレビュー練習用その1)
・しばらく日記をちゃんと書けそうにない



後藤さ

snapcount:もう一回読んでみた。 (2006年03月23日 15:31)

http://takagi-hiromitsu.jp/diary/20051227.html


そっか、autoincrementしているだけでの数値が帰ってくるとしても
やっておくということね。

凄く反応が遅いけど。 高木浩光@自宅の日記 - プログラミング解説書籍の脆弱性をどうするか, 「サニタイズ言うなキャンペーン」とは何か, ASPとかJSPとかPHPとかERBとか、逆だ.. 最近のプログラム入門書は、文字列解析機構があるという考え方がないのかな。書いてる人も..

これだけ (PHP5)。 &lt;?php foreach(simplexml_load_file('http://www.flickr.com/services/feeds/photos_public.gne')->entry as $it) echo $it->content ?&gt; すいませんすいません via 5-second RSS parser。 開発合宿でも simple_xml...

EUCの補助漢字をPHPでどのように処理するかを調べていて、1年前に自分で書いた

PHPのセキュリティについて調べていたら、このような論争を発見しました! [http://takagi-hiromitsu.jp/diary/20051227.html プログラミング解説書籍の脆弱性をどうするか] [http://xoops.peak.ne.jp/md/news/article.php?page=article&storyid=80&easiestml_lang=xlang%..

いわゆる「サニタイズ」です。 仕事で検索文字列の強調表示処理(Googleのキャッシュ表示みたいなやつ)を作ってたのですが、記号は全て無視して検索する仕様だったので強調用に挿入したspanタグの不等号を含めて強調してしまうというバグを作りこんでしまい、HTML特殊文..

つらつらと駄文を書き連ねるこのブログ、誰の目にも留まっていないだろうと思っていたら、本日初めてのコメントをいただきましたΣ(・ω・ノ)ノ!
内容は、昨日書いたphpでの入力値の...

検索

<前の日記(2005年12月25日) 次の日記(2005年12月31日)> 最新 編集

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2005年12月25日) 次の日記(2005年12月31日)> 最新 編集