高木先生からの今夜分かるSQLインジェクション対策への意見 その２
また上野宣か。顔見知りなのでズバリいくことにする。
はい、お手数をおかけします。
次回から指摘していただけるようでしたら、私信で頂けると対応も早くできるので嬉しいところです。
対策部分は高木先生の指摘を加味して修正することにします。ありがとうございます。
●Webアプリケーションの対策 ・入力値のSQLのを埋め込むことろで特殊文字を適切にエスケープ入力値＝プログラム（プロセス）に外部から入ってくるもの・シフトJISの場合には1バイト文字を整理 ・SQLの記述をなくすためにO/R（Object/Relational）マッピングを活用 ・攻撃者に役立つ情報を与えないために、不要なエラーメッセージ（データベースが出力するエラーなど）の表示を抑止 ・バインドメカニズムの利用
技術文書として駄目なのかもしれませんが、他に指摘されている点はこのコラム欄では不適切ではないと判断し、修正する必要はないと判断しました。
高木先生からの今夜分かるSQLインジェクション対策への意見
こちらの方でかなり厳しく言われてしまったので、反省する点は反省して見直し作業も進めることにする。
とりいそぎ、高木先生が最後の方で言っている下記の点は本当に忘れていたので、早速修正することにしました。申し訳ありません。
「100%」て何？ 攻撃を防ぐ話をしているのだから、防げないなら対策じゃないでしょ。（しかも、CSRFの文脈でRefererは偽装できないと言ったのに、まだ直してないね。去年会ったときに、「直します」って約束してたよね？）
以下の文脈です。
●リファラーで発信元をチェック HTTPリクエストを受けたとき、そのリクエストがどこのWebページから発行されたものかを示すリファラー（REFERER）と呼ばれる情報を得ることができる。この情報を活用し、本来意図したWebページ以外からのリクエストを拒否することで、CSRFによる外部からのリクエストを防ぐことができる。 この方法は簡単に実装できて比較的効果の高い方法である。しかし、リファラー情報はリクエスト発信者が自由に発行できる情報であるので、偽装されてしまう恐れもあり100％防ぐといった効果はない。
これをの後半を以下のように修正します。
リファラー情報はリクエスト発信者が自由に発行できる情報であるため、偽装されることを懸念するかもしれない。しかし、CSRFの場合には踏んでしまった自分自身がリクエストを発信するので、自分自身でリファラー情報を偽装する余地はない。 ただし、ユーザーがリファラー情報を出力しないブラウザを使っている場合、このチェックを導入すると正当な操作でも受け付けなくなってしまう。
編集部にも依頼だしておきました。
