DBとセキュリティ今昔
- 編集部の見解や意向と異なる内容の場合があります
- 編集部は内容について正確性を保証できません
- 画像が表示されない場合、編集部では対応できません
- 内容の追加・修正も編集部では対応できません
ヒューマンリソシア株式会社はコラム「DBとセキュリティ今昔」を公開しました
お初にお目にかかるかたもいらっしゃるかと思いますので、簡単に自己紹介などさせていただければ。
このたび、こちらでしばらくの間コラムを書かせていただくことになりました、古庄ともうします。よろしくお願いいたします。
「上級試験対策連載コラム」とのことなので、コラムでは「試験対策」と「実務」とを良い感じで混ぜつつ、時々違う要素などをスパイス的にあしらって行ければ、と思います。
今回のお題はDBで、その中でも「セキュリティ」の話に傾けたあたりを展開することにいたしましょう。
なんと言っても「SQL-Injection」
DB関連の脆弱性といえば、なんと言っても「SQL-Injection」が最大級のインパクトになります。
SQL-Injectionの脆弱性ががっつりと存在すれば、DBの中身を「読んでよし」「書いてよし」「消してよし」の3連続コンボが完成するので、脆弱性の診断などでもこれがあると大抵「緊急警報」レベルで連絡がいくようなごっつい脆弱性です。
実際問題、IPAさんでも、「安全なウェブサイトの作り方」というPDFを出してますが、SQLについてはわざわざ、これとは別に「安全なSQLの呼び出し方」というPDFを出しているあたりからも、その温度感がうかがわれようというものです。
「その割には今でも時々この脆弱性に起因しているっぽい悲鳴がニュースに持ち上がるよねぇ」という物騒な話は置いておきまして、対策についても色々と検討され練られているのが昨今の一般的な状況かと思われます。
古くは「エスケープ処理を用いてSQL文を安全に組み立てる」という方法が提議され、今でも「他の手段がとれない場合におけるやむを得ない緊急手段」として生存は確認されておりますが、どちらかというと「可能な限り博物館行きにしたい」対応であります。
実際問題、上級試験用の本テキスト「プログラミングPHP 第2版」においても、エスケープ処理は「最適」とは呼称されておりません。
この続きは以下をご覧ください
http://resocia.jp/column/7/
ソーシャルもやってます!