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文とバインド値が個別にサーバー側に送られる。
ということで。ふつうはサーバーサイドのプリペアードステートメントを使うでしょうし、その場合は「エスケープするから安全」というより、「そもそも別々に送られるから原理的にエスケープする必要がない」という話のように思いますね。
※もっとも、最近ではフレームワークのO/Rマッパーを使うことになる場合が多いような気もしますが。
- 「PostgreSQLセミナー2009春〜セキュリティ事故のケーススタディ〜」へのコメント (1件)
- 前(古い): 2009年5月7日(Thursday)のえび日記
- 次(新しい): 2009年5月10日(Sunday)のえび日記