水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > PostgreSQLセミナー2009春〜セキュリティ事故のケーススタディ〜

PostgreSQLセミナー2009春〜セキュリティ事故のケーススタディ〜

2009年5月8日(金曜日)

PostgreSQLセミナー2009春〜セキュリティ事故のケーススタディ〜

公開: 2009年5月10日21時10分頃

セキュリティホールmemo (www.st.ryukoku.ac.jp)より、「PostgreSQLセミナー2009春〜セキュリティ事故のケーススタディ〜 (www.ipa.go.jp)」(PDF)。

良い資料だと思いますが、ちょっと思ったところをメモ。

p10.「ショッピングサイトの裏側」

……なんでHTMLの構造が? ここで言う「裏側」ってそういう意味ではないと思うのですが、適切な画像がなかったのでしょうか……。

※どうでも良いですが、こういう構造だと、お知らせの文言が増えたときや文字サイズ拡大時に、シンボルマークとロゴタイプ(なのか?)が泣き別れになりそうな気がしますね。いや、そこはつっこむところではありませんが。

p23.「問題のポイント」

これもどうでも良い話ですが、「脆弱性関連情報を発見」という表現には違和感がありますね。「脆弱性を発見」「脆弱性関連情報を入手」とかのような。

p31.「エスケープ処理の方法」

バインド機構の利用がエスケープの方法の一つとして紹介されていますが、「SQLのバインド機構は「エスケープ処理された値」をはめ込むのか (d.hatena.ne.jp)」によれば、

たしかにエスケープ処理を使ってバインド機構を実装する場合もある。

(~中略~)

サーバーサイドのプリペアードステートメントの場合は、エスケープ処理は行われない。その代わり、プレースホルダ記号が置かれたままのSQL文とバインド値が個別にサーバー側に送られる。

以上、SQLのバインド機構は「エスケープ処理された値」をはめ込むのか より

ということで。ふつうはサーバーサイドのプリペアードステートメントを使うでしょうし、その場合は「エスケープするから安全」というより、「そもそも別々に送られるから原理的にエスケープする必要がない」という話のように思いますね。

※もっとも、最近ではフレームワークのO/Rマッパーを使うことになる場合が多いような気もしますが。

関連する話題: セキュリティ / IPA

最近の日記

関わった本など