PHPカンファレンス2011にて、徳丸浩さんの講演を聞いてきたのですが、
タイトルの内容の部分について、筆者が感じた事を書きたいと思います。
あ、別に内容がダメだったという事ではありません、念の為。

まず、XSS対策として使われる、htmlspecialchars関数の第「２」引数について。
属性値内に書く場合は、

ダブルクオートで囲った属性値は、ENT_COMPATかENT_QUOTES、
シングルクォートで囲った属性値はENT_QUOTES、
属性値はダブルクォートで囲むことにすれば、ENT_COMPATで統一してもOK

ということで、筆者も同じ意見です。
以下の様なコードがあって、$valが「' onMouseOver=alert(document.cookie); 」だったら、
XSSが成立してしまいますし。

<input type='text' name='id' value='<php echo htmlspecialchars($val, ENT_COMPAT, "UTF-8"); ?>' />

ただ、「X」HTMLでも、HTMLでも、
要素値をダブルクオートやシングルクォートで囲まなくても、
「ぶっちゃけ動く」んですよねえ（苦笑)
無論、ダブルクオートやシングルクォートで囲んでも動くと。
で、これは、
「書く人が悪い(ちなみに筆者は、属性値は"多分必ず"ダブルクオートで囲む派)」で終わりなんですが、
「現場の実態」を考えると、
「一応、ENT_QUOTESで囲んでおこうかな」って、筆者は考えてしまいました（苦笑）

次に、クリックジャッキングについて。
まあ、こっちは徳丸さんご本人と少しお話したのですが。
現在、夜中（苦笑）だし、筆者も大して詳しくないのでサラッと書くと。
Firefox3.0など、2011年9月現在では古いバージョンのブラウザ(他の該当ブラウザは不明)において、
frameかiframeを使った画面では、クリックジャッキングを「防げない」という。
新しいバージョンのブラウザでは、上記のリンク先に書いてある通りという事だったんですけどね。
で、まあこれも「古いブラウザ使っている方が悪い」という、
XSSと同じ様な話ではあるんですけど、
こっちは開発者ではなくユーザーですからね。
だからもう、筆者的には「frameとiframeを使わずに代替案を検討する」で良いのではないかという。
あ、筆者はやってないし、よく知りませんが、
Facebookでiframeがガンガン使われているのはどうなのでしょうね。

あと、パスワードの保存も悩ましい感じだったのですが、
これは、筆者では対抗出来なさそうなので、
他の優秀な技術者さん達にバトンタッチw
鍵を「捨てる」とか、ボソッと言ってましたけどね。

筆者は、以下の記事の評価について「微妙なスタンス」なのですが。
「どうしてダメなのか分からない」という質問を頂きましたので、
それに答えてみたいと思います。

なぜPHPアプリにセキュリティホールが多いのか?　第42回 PostgreSQL 9.0に見るSQLインジェクション対策

関連記事
togetterでのまとめ記事その１
togetterでのまとめ記事その２

まず、上記の記事の対策内容が「間違っている」とは特に思いません。
じゃあ、どの辺が「微妙」なのか。
最も違和感を感じたのは、まとめ記事の方でちょくちょく出てくる「多重」って言葉です。
まとめ記事その１の中の以下の発言に、筆者は完全に同意します。

@ikepyon 多重防御ってさ、もし、一つがだめだった場合に他のもので防御しようと言う奴だよね。そもそも、一つで必要十分な対策で別の方法で対策する必要ってあるの？

筆者の基本的な考え方は、
「単純で簡単で必要最小限が最も良い」でして。
ソースコードの量しかり、
セキュリティ対策しかり、
プログラムの内容しかり。
勿論、実際にはそんなに簡単で単純ではないのですが、
でも「単純で簡単であるに"越したことはない"」と思います。
プログラムのバグって、処理を「書けば書くほど」、発生する確率が高くなるじゃないですか。
極端な話、１行も書かなければ、バグは発生しません。
だから、「多重」防御は「必要なら行う、必要ないなら行わない」でよろしいのではないかと。

「エスケープかプリペアドステートメントのどちらが良いか」については、
筆者は「対策が"きっちり"出来ればどちらでも良い」というスタンスです。
ただ、「多重」の考えに否定的な方は、
プリペアドステートメントを選択している印象があるので、
「現時点では」プリペアドステートメントの方が良いかなといった感じです。
で、プリペアドステートメントで不十分であれば、
まとめ記事内に書かれている「ホワイトリストでのチェックなど」を追加で良いと思います。

ああ、ただ、SQLインジェクションが何故発生するのかと、
それを防ぐ為の原理を知る為に、
「エスケープ」についての理解は必要だとは思います。
でも、「頑張って覚えたい！」と思っている初心者に対して、
すぐに「原理」を理解せよというのも、それはちょっとハードルが高い気がするのですが。
まずは、習うより慣れろとでもいうか、
対策方法から学んでいけば良いのではないでしょうか。
なので、まずは「目の前に存在している脆弱性を無くす」。

ああ、あと、本記事中に「完全に撲滅」という言葉があって、
使わない方が良いという理由が分からないって話もありました。
これは、完全に筆者の「予想」ですが、
「完全じゃない撲滅」って存在しないと思うので、
撲滅の前に完全って言葉を付けると、意味が「二重」になり、
撲滅って言葉を使っている意味が失くなるからだと思います。
例えば、以下の文章はどっちも同じ意味になると思うのですが。

１．SQLインジェクションを撲滅しましょう。
２．SQLインジェクションを完全に撲滅しましょう。

SQLインジェクションとは全然関係ありませんが、
これも「多重（二重）」ですね。

ついでに、筆者がお薦めする、セキュリティ対策を学ぶ順序を最後に書いてみたいと思います。
まあ、筆者自身も勉強中なので、少ししか分かりませんが。

１．がる先生のセキュリティ講座

これは、対策内容に関しては「もう古い」のですが、
セキュリティというモノについての「考え方」について、
「分かりやすく」解説されていると思います。

２．「安全なウェブサイトの作り方」 + 「安全なSQLの呼び出し方」

記事が新しい事もあって、上記よりも対策内容はしっかりしていると思います。
ただ、内容が難しくなった事もあって若干読み辛くなっているのでココ。

３．体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践

良い書籍なのですがっていうか、「とっても」良い書籍なのですが、
内容が「濃くて深い」ので、全くの初心者には厳しいと思ったのでココ。

これら以外のWebページや書籍は、「現時点では」良く分かりません。
まあ、こんな所でしょうか。