水無月ばけらのえび日記

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

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)

その他サイト