入力バリデーションで文字列の妥当性を検証（保証）しないと、不正文字問題の解決はできません。
よく「文字エンコーディングバリデーションは入力バリデーションしなければならない」と紹介はするのですが、その理由を詳しく解説していませんでした。これは文字エンコーディング攻撃の仕組みを理解してれば分かる事なのでしていませんでした。
しかし、文字エンコーディング攻撃の仕組みを理解していても必要なし、とする意見があるので理解り易く説明します。（理解りづらかったら教えてください）UTF-8のみですが、他の文字エンコーディングでも基本は同じです。
PostgreSQL Advent Calendar 9日目用のエントリです。
PostgreSQL 10のICUコレーション（照合順序）サポートの概要と基本的な使い方は以下のエントリに記載しています。ICUコレーションの使い方は以下を参照してください。
https://blog.ohgaki.net/postgresql-10-icu-locale-collation-enables-natural-japanese-sorting
今回は日本語ソート順のJIS規格である JIS X 4061-1996にどの程度対応しているのか確かめてみます。
PostgreSQL 10からICU（International Components for Unicode）のロケール/コレーションがサポートされました。
これまでサポートされてきた、libcのja_JPロケールの貧弱な日本語ソート機能とは比べ物にならないくらい高機能な文字比較をサポートしています。日本語や他の言語での照合順序を柔軟に変更できます。
といったことがPostgreSQL 10から行えます。
PHP 5.4 RC1が公開されています。PHP 5.4のリリースが近いです。PHP 5.3の–enable-zend-multibyeの問題でバグレポートをした関係でinternals MLでメールのやり取りをして分った事とその他をまとめておきます。主にSJISを使う場合の注意点です。間違い・勘違いもあるかも知れないので気が付いたらコメントを下さい。
php -c php.ini-development -d zend.multibyte=1 SJIS_script.phpとしてSJISが含まれるスクリプト（例えば、echo “表”)を実行するとSJISの文字が?に変換されてしまいます。正しく処理するには-d mbstring.internal_encoding=UTF-8などを追加し
php -c php.ini-development -d zend.multibyte=1 -d mbstring.internal_encoding=utf-8 SJIS_script.php
などとしなければなりません。
全般的にマルチバイト文字エンコーディングのサポートが改良されていますが、以前と多少異なる部分があるので注意が必要です。
Mac上でEmacsを使うと言っても、コードを見るくらいでAquaemacsを使っています。Aquaemacs 2.0以上からはタブも使えてかなり便利です。今は2.1を使っています。PHP、RubyはEclipseやNetBeansを使っています。
Aquaemacsでコーディングはしていなかったので今まで困らなかったのですが、PHP本体のコーディングとビルドをMac上で出来るようにしました。Cのコードは普通はEmacsで書いているので、AquaemacsでCのコードをコーディングしようと思ったら「バックスラッシュ(\)が円記号(¥)になる」現象で困ってしまいました。
(さらに…)
PHPが文字エンコーディング攻撃に比較的強い理由は入出力の文字エンコーディングのバリデーション（サニタイズ）が行えるだけではありません。PHPが提供するHTMLエスケープ関数が文字エンコーディング攻撃に対して強い事も理由の一つです。
PerlでHTMLエスケープと言えば、<,>,&,”,’をエンティティ変換するコードが一番に見つかります。
「perl html escape」でググると一番に見つかったページは次のページです。このページではまだ3バイトEUCの場合の例、CGIモジュールを使った例も載っているので良い方でしょう。
http://saboten009.blogspot.com/2008/04/perlhtml-xss.html
少し前にPerl, Ruby,Pythonユーザは検索で有用なセキュリティ情報を得られるのか？と疑問に思い調べました。これだけ知っていれば取り合えず十分というページはそう簡単には見つかりませんでした。
いつも問題になるのは PHP だけど Perl は問題ないのか、すでに議論し尽くされた問題なのか、PHPer のモラルが低いせいか。
Perl,Ruby, Pythonで議論し尽くされ対策が浸透している、とは到底思えません。Railsで文字エンコーディングを利用したXSS脆弱性が話題になっていることからも明らかです。PHPがいつも問題になるのはよく使われていて、初心者も多く、公開されているWebアプリも圧倒的に多いからです。モラルの問題ではありませんし、このページで紹介されているPerlのエスケープ方法だけではPHPのhtmlentities()やhtmlspecialchars()よりも脆弱です。文字エンコーディングを考慮するようになっていないからです。 (さらに…)
MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。（PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります）この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。
Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。
PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が追加されていたりするので、たまたま最近読んだRoRの本だけでなく、多くの開発向け情報ソースにSET NAMESを利用した例が載っていると思います。
ストアドプロシージャだけ使っていれば安全ですが、アプリケーションからDBMSの文字エンコーディングを設定する場合、SQL文ではなく必ず文字エンコーディング設定APIを利用するよう紹介しなければならないです。MySQL4はストアドプロシージャが使えないので、フレームワークなどではエミュレートしています。ストアドプロシージャだけ使って防御している「つもり」で防御になっていない場合もあります。これもフレームワークを使っていてもアプリケーションが脆弱になる良い例ですね。
脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり「SET NAMES（PostgreSQLのSET CLIENT_ENCODING等も)は禁止」です。
PHPのMySQL：
PHPのPostgreSQL：
PHPのPDO：
<?php
// MySQL
$pdo = new PDO(
'mysql:host=yourhost;dbname=yourdb;charset=sjis',
'user', 'password'
);
// PostgreSQL
$pdo = new PDO(
"pgsql:host=yourhost;dbname=yourdb;options='--client_encoding=sjis'"
);
Rails：
config.encoding = 文字コード
b2evolutionをいい加減アップグレードしておかないと問題があっても困るのでアップグレードしました。HTTP_ACCEPT_CHARET/HTTP_ACCEPT_LANGUAGE処理の不具合がまだなおっていないようです… 日本語のように単語区切りがない言語（または正規表現の文字エンコーディング設定）の不具合も直っていないようです。
昨日から今日までMac版のFirefoxなら正常に表示、Win版だとISO-8859-1になって文字化けしていました。（多分IEも同様だったはず）
文字列の比較はできるかぎり厳密に行う方が良いですがHTTP_ACCEPT_CHARSET/HTTP_ACCEPT_LANGUAGEの比較では大文字／小文字を無視した方が無難だと思います。Win版Firefoxがへんな値に設定しているとは思いますが、統計アプリなどでみるとかなり変わったエンコーディング名になっている場合もあるようです。
エンコーディングをUTF-8で統一しているなら
conf/_locales.phpを以下に設定し
$evo_charset=’utf-8′;
$force_io_charset_if_accepted=’utf-8′;
$db_config[‘connection_charset’]=’utf-8′;
$default_locale=’ja-JP’;
必要ないような気もしますがこのファイルに定義してあるlocaleでiso-8859-1エンコーディングは全てutf-8に変更しました。
inc/MODEL/settings/_locale.funcs.phpのinit_charset関数でなにもせずにreturn
function init_charset( $req_io_charset )
{
return;
すれば文字化けは解消します。
追記：
これでもISO-8859-1になって文字化けするケースがありますね… 時間がないので場当たり対処策としてindex.phpの最後に
header(‘text/html; charset=UTF-8′);
を追加しました。ロケールの処理にはいろいろ問題があるようです。どこかで無理矢理ISO-8859-1にするくらいならデフォルトUTF-8にしておけば良いと思います。
さらに追記：
上記の変更を行うとRSSフィードのXMLエンコーディングの部分が空になり、XMLエラーとなってRSSリーダが処理できない不具合が発生する事が分かりました。ソースを見れば一目瞭然で文字エンコーディングを指定する変数が空であることが原因でした。
conf/_basic_conf.phpに
$io_charset=’utf-8’;
を追加すると直ります。アップグレードマニュアルにはこのファイルは前のファイルで上書きするように、と書いてあったのですが追加設定が必要だったのかも。
日本人には必要なオプションがmysqldのオプションに追加されたようです。4.1.15、5.0.15以降なら使えるそうです。
A new command line argument was added to mysqld to ignore client character set information sent during handshake, and use server side settings instead, to reproduce 4.0 behaviour (Bug #9948):
mysqld –skip-character-set-client-handshake
ちょっと乱暴ですがPostgreSQLなら「initdbのオプションに–no-localeを付ける」にあたいするくらい重要かも知れません。