http://www.securiteam.com/unixfocus/6N00D0AKKM.html
に解説されている脆弱性は基本中の基本です。
Most database query in WordPress uses escape() method to sanitize SQL string, which is essentially filtering input via addslashes() function. However addslashes() fails to consider character set used in SQL string, and blindly inserts backslash before any single quote, regardless of whether such backslashes will form another valid character or not.
addslashes()によるエスケープは行ってはならない、とよく言っていますがWordPressでさえaddslashes()を使っていたのですね。WordPressはUTF-8だけでなくGIB5とか使えるのですね。WordPressをSJISを使っている方は同じ脆弱性があるので要注意です。
本質的には私のブログでも指摘している脆弱性と同じ種類の問題です。
追記
CVEが出てます。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6318
(1) Big5, (2) GBK, or possibly other character set encodings that support a “\” in a multibyte character.
BIG5, GBKエンコーディングが影響を受け他の文字に¥が現れる文字エンコーディングにも影響があると思われる、と書いてあります。つまりSJISが該当します。
対策を書いておきます。
- データベースを正しい文字エンコーディングで作成する
- アプリケーションからデータベースやクライアント文字エンコーディングを変更する場合、データベースのAPI(pg_client_encoding, mysql_set_charsetなど)を利用する(SQL文で変更しない)
- 文字列をデータベースクエリ用にエスケープする場合はデータベースAPIを利用する(pg_escape_string, mysql_real_escape_stringなど)
別の対策として、プリペアードクエリを利用する方法もあります。
壊れた文字エンコーディングの文字列を無理矢理扱えるようにする方法があります。しかし、壊れた文字エンコーディングを扱えるようにするとアプリケーションや環境に存在する未知の脆弱性により攻撃可能になるかもしれないリスクがあります。壊れた文字エンコーディングを扱えるようにするのではなく、既にあるデータは綺麗にして、新しい文字データは全て正しい文字エンコーディングであるように入力時にバリデーションすべきです。
Leave a Comment