[B! SQLインジェクション] yamashiro0110のブックマーク

今夜こそわかる安全なSQLの呼び出し方　～高木浩光氏に聞いてみた

「安全なSQLの呼び出し方」というSQLのセキュリティに焦点を当てたドキュメントが、2010年3月にIPA（独立行政法人情報処理推進機構）から公開された。これは2006年1月から提供されている、Webサイト開発者や運営者向けのセキュアWebサイト構築のための資料「安全なウェブサイトの作り方」の別冊として書かれたものである。「安全なウェブサイトの作り方」が92ページなのに対して、SQLインジェクションについてだけで40ページもの分量がある。なぜこんなに分厚いのだろうか。このドキュメント作成に協力したという、独立行政法人産業技術総合研究所情報セキュリティ研究センターの高木浩光氏にお話を伺うことができた。高木氏は個人ブログ「高木浩光＠自宅の日記」で、セキュリティ関連の問題を追求する論客としても知られている。筆者も以前、この連載の「今夜わかるSQLインジェクション対策」の回（2006年11月

yamashiro0110 2013/10/22

SQLインジェクション

リンク

高木浩光＠自宅の日記 - 駄目な技術文書の見分け方その1

■ 駄目な技術文書の見分け方その1 はてなブックマークのホッテントリを見ていたところ、300を超えるユーザに登録された以下の記事があった。今夜分かるSQLインジェクション対策, 上野宣, @IT, 2006年11月2日また上野宣か。顔見知りなのでズバリいくことにする。しかし、その対策はまだ本当に理解されていないように思える。へえ。終わりの方を見てみると、 Webアプリケーションの対策入力値のSQLの特殊文字を適切にエスケープ入力値＝プログラム（プロセス）に外部から入ってくるものシフトJISの場合には1バイト文字を整理 SQLの記述をなくすためにO/R（Object/Relational）マッピングを活用攻撃者に役立つ情報を与えないために、不要なエラーメッセージ（データベースが出力するエラーなど）の表示を抑止対策に「準備された文」(prepared statement)

yamashiro0110 2013/07/24

SQLインジェクション

リンク

「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog

このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策どこまで調べるかですが、以前NH

yamashiro0110 2013/07/24

SQLインジェクション

リンク

[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ

SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。単にプリペアドステートメントを使え絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むことなんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使うダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。単にプリペアドステートメントを使え文字列結合でSQLを構築するなイケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーション

yamashiro0110 2013/07/24

SQLインジェクション

リンク

自己流のSQLインジェクション対策は危険

HTMLエスケープの対象となる < > & " の4文字は、文字実体参照に変換された後、preg_replace関数でセミコロンを削除してしまうので、中途半端な妙な文字化けになりそうです。一般的な原則としては、データベースにはHTMLの形ではなくプレーンテキストの形で保存しておき、HTMLとして表示する直前にHTMLエスケープする方法で統一することで、上記のような文字化けやエスケープ漏れをなくすことがよいでしょう。脆弱性はないのかこのsanitize関数に脆弱性はないでしょうか。上表のように、バックスラッシュ（円記号）を素通ししているので、MySQLや、設定によってはPostgreSQLの場合に、問題が生じそうです。以下、それを説明します。以下の説明では、MySQLを使う想定とします。以下のように、ログイン処理を想定したSQL文組立があったとします。 $sql = sprintf(