へぼへぼCTO日記 - useServerPrepStmtsを使うのが根本解決だとはおもう。けど…？
UnicodeのU+00A5問題 JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 なるほど。この問題は初耳だったので驚いた。 しかも、PreparedStatementを使っても解決されないという。この部分に非常に驚いたのでどういうことなのか少し調べてみた。 PreparedStatementとは？ mysqlにおける話としてはPrepared Statement (訳）がとてもわかりやすい。 なかでも重要なのは以下の部分だ。 PerlとJava のユーザはかなり長い間prepared statementを使って きました。しかし、これらはクライアント側のprepared statementでした。 クライアント側のprepared statementは同じようなセキュリティの恩恵 をもたらしますが、性能向上には至りません。でも心配
MySQL+Java でサーバサイドプリペアードステートメントを使うべきで「ない」理由 - kazuhoのメモ置き場
useServerPrepStmtsのここの説明ではデフォルトがtrueになっているが、これは上述の通り嘘である。 (中略) そしてなぜfalseにされたかということの背景を察すると、trueにすることの弊害もありそうで、手放しでこれをtrueにすることを勧めることが少しはばかられる。 http://www.geminium.com/chiba_blog/2008/12/23/33/ 自分は Java 使ってないですが、MySQL の中の人が使うなって言ってます *1。その理由はメモリリークのような症状が出る可能性があるから。 So why are prepared statements a problem? Because users do not clean up/close unused prepared statements. Multiply the number of prep
JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2008年12月22日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 今年のBlack Hat Japanには、はせがわようすけ氏が「趣味と実益の文字コード攻撃」と題して講演され話題となった。その講演資料が公開されているので、私は講演は聞き逃したが、資料は興味深く拝見した。その講演資料のP20以降には、「多対一の変換」と題して、UnicodeのU+00A5（通貨記号としての￥）が、他の文字コードに変換される際にバックスラッシュ「\」（日本語環境では通貨記号）の0x5Cに変換されることから、パストラバーサルが発生する例が紹介されている。 しかし、バックスラッシュと言えばSQL
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
