補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2007年11月26日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 本稿ではSQLインジェクション対策として、SQLのエスケープ処理の方法について検討する。 最近SQLインジェクション攻撃が猛威を振るっていることもあり、SQLインジェクションに対する解説記事が増えてきたようだが、対策方法については十分に書かれていないように感じる。非常に稀なケースの対応が不十分だと言っているのではない。ごく基本的なことが十分書かれていないと思うのだ。 SQLインジェクション対策には二通りある。バインド機構を使うものと、SQLのエスケープによるものだ。このうち、SQLのエスケープについて、十分
なお、iLogScannerでSQLインジェクション攻撃が検出された場合や、特に攻撃が成功した可能性が検出された場合は、ウェブサイトの開発者やセキュリティベンダーに相談されることを推奨します。 iLogScannerは簡易ツールであり、ウェブサイトの脆弱性を狙った攻撃のアクセスログが無ければ脆弱性を検出しません。また、実際の攻撃による脆弱性検査は行っていません。攻撃が検出されない場合でも安心せずに、ウェブサイトの脆弱性検査を行うことを推奨します。 IPAとしては、ウェブサイト運営者が、この脆弱性検出ツールを利用することにより、自組織のウェブサイトに潜む脆弱性を確認するとともに、ウェブサイト管理者や経営者に対して警告を発し、セキュリティ監査サービスを受けるなど、脆弱性対策を講じるきっかけとなることを期待しています。 また、ウェブサイトの開発者やセキュリティベンダーが、本ツールを取引先等に紹介
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く