JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性

補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2008年12月22日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 今年のBlack Hat Japanには、はせがわようすけ氏が「趣味と実益の文字コード攻撃」と題して講演され話題となった。その講演資料が公開されているので、私は講演は聞き逃したが、資料は興味深く拝見した。その講演資料のP20以降には、「多対一の変換」と題して、UnicodeのU+00A5（通貨記号としての￥）が、他の文字コードに変換される際にバックスラッシュ「\」（日本語環境では通貨記号）の0x5Cに変換されることから、パストラバーサルが発生する例が紹介されている。 しかし、バックスラッシュと言えばSQL

[yssk22]

これはあとで確認...

[nilab]

徳丸浩の日記 - JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 : U+00A5（通貨記号としての￥）が他の文字コードに変換される際に「\」（日本語環境では通貨記号）の0x5Cに変換:パストラバーサル

[cubed-l]

追記部分

[nihen]

ServerPreparedStatement(useServerPrepStmts)使えばいんでない？/といいつつここんとこJDBCなんてご無沙汰だったのであとでためす/このコメント編集しすぎだろ俺

[T-miura]

げ、PreparedStatementで回避できないのか。SQLインジェクションはPreparedStatementで回避でしょと思っていたので吹いた（ｍｙSQLのみですよね・・？）

[iakio]

インジェクションというより実装がダメ。こんなコードありえん

[hiront_at_nagoya]

不用意な文字コードの変換は脆弱性を呼び込む

[mrmt]

prepared statementを使いましょう、という話ではなくて?

[sakuragaoka]

SJISのDB使うなら、文字コード変換後にエスケープしよう、ということで。

[todesking]

utf8,文字コード変換でU+00A5が0x5Cに、jdbcの設定(characterEncoding)

[ikepyon]

つhttp://d.hatena.ne.jp/ikepyon/20061215#p2 http://d.hatena.ne.jp/ikepyon/20070216#p1　<s>ただし、MySQL4.xのときのみ5.0以降は直ってるらしい</s>どうも、MySQLのJDBCに問題ありみたいです

[FTTH]

standard_conforming_stringsをOffにしていいのは小学生まで。　＞postgresql　／　詳細はgugure

[ghostbass]

メモメモ / 文字コード変換の場所がおかしいって事かい/昔やったoracle+jdbcはとても怪しいが手が出せない

[gayou]

SQLインジェクション。セキュリティのお話。

[hasegawayosuke]

DB全然わかってないけれど、ファイル名以上に知らない間に暗黙の変換がかかりそうで怖いです。

[ockeghem]

/id:Kanatoko、id:ikepyon preparedStatementで試したところ結果は変わりませんでした(-_-)