大垣氏が寄稿された『なぜPHPアプリにセキュリティホールが多いのか? 「第42回 PostgreSQL 9.0に見るSQLインジェクション対策」』の内容を受け、つぶやかれたものをまとめました。
![なぜPHPアプリにセキュリティホールが多いのか? 「第42回 PostgreSQL 9.0に見るSQLインジェクション対策」のまとめ](https://cdn-ak-scissors.b.st-hatena.com/image/square/ccd2f3674f83eff34efc485016fe3bf278950440/height=288;version=1;width=512/https%3A%2F%2Fs.tgstc.com%2Fogp3%2F9b239984c007d9813f1d064905837327-1200x630.jpeg)
PostgrSQL 9.0から追加されたエスケープ関数から、SQLインジェクション対策を再度解説してみたいと思います。 SQLインジェクション対策の4原則 基本的にはSQLインジェクション対策として以下の原則を守っていれば、SQLインジェクションに脆弱なアプリケーションを作ることはありません。 すべてのパラメータを文字列としてエスケープする すべてのパラメータをプリペアードクエリのパラメータとして処理する 文字エンコーディングの設定をAPIで行う パラメータとして処理できない文字列はバリデーションを行う 原則1と原則2は重複して適用する必要はありません。どちらかを行います。文字エンコーディングの設定やプリペアードクエリのエミュレーション・抽象化ライブラリのバグ等でSQLインジェクションが可能になる場合もありますが、通常であればこの原則を守っている限りSQLインジェクション脆弱性を作ることは
以前このブログでも取り上げたことのある神戸デジタル・ラボの近藤伸明氏がThink IT上で「SQLインジェクション大全」という連載を執筆しておられる。その第三回「SQLインジェクションの対策」を読んで以下の部分が引っかかった。 バインド機構とは、あらかじめSQL文のひな型を用意し、後から変動個所(プレースホルダ)に実際の値(バインド値)を割り当ててSQL文を生成するデータベースの機能だ。バインド値はエスケープ処理した後にプレースホルダにはめ込むので、悪意あるSQL文が挿入されても、その実行を阻止することができる(図1-2)。 http://thinkit.jp/article/847/1/ たしかにエスケープ処理を使ってバインド機構を実装する場合もある。JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 | 徳丸浩の日記から派生して、MyS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く