もうすでに、こことかこことか、なんと言っても講師の方の所とかでいろいろ盛り上がっているのであんまり書くことはないんだけど（汗
＃若干名、ここで盛り上がることを期待していた向きもあるので（汗

そもそも標準機能ではない、いわばオーダーメイドなアプリケーションですから、証拠がそろうかどうかは基本的にそのツールの出来不出来に左右されるからなぁ、と言うのが正直な感想。それは講演を聴く前も聞いた後も変わりませんでした。
ですから、（セッションハイジャックを除き）ほとんどの攻撃を検知する、という事は、どれだけまともなログ機能が実装されているかに依存するんだろうな、と。
大体、攻撃というものは、見つからないようにするものだから、防御する側はさらにその裏をかいてナンボのもんでしょう？それができていない時点で無理だよな、と言うのが正直な感想。
なので、個人的には、すべてのWeb Appに対応したいならばWebサーバ｛に向かう｜から出ていく｝トラフィックをダンプしておくしかないんだろうな、と思っています。よっぽど「tcpdumpでHTTPなアクセスをためてしまうしかないだろーよ」と言おうと思ったというか（苦笑）
＃snortでダンプするのもありですな（笑）。
＃ただし、プリプロセッサ通すと生ダンプじゃなくなるんだっけか？（汗

あと、ログ機能、と言う観点から言えば、CGIの引数をデフォルトで全部ログに吐き出す、と言う至極簡単なものでも結構な情報が得られるんじゃないかと思っています。

セッションハイジャックですが、この攻撃は、条件が悪ければ検知不能なのは当然だと思います。セッションハイジャックって言うから語弊があるんじゃないかなぁ。なりすまし、って言った方がこの場合適当な気が。
なりすましをどう見つけるか、と考えた場合、直接証拠は多分得られず、状況証拠の蓄積でしか発見できないでしょう。その蓄積された状況証拠から実際のなりすましアクセスを見付けることが可能かどうかは、状況証拠の質、それと検知しようとする人間の腕と直感に左右されると思っています。
プロキシ経由の云々、というネタもありますが、プロキシの吐くデータから元IPが拾える場合が多いので、企業内同一プロバイダ内同一NAT内でのセッションハイジャックの状況証拠を見付けることも不可能じゃないだろ、とか思わなくもないですが。
＃OS違っていればpassive OS fingerprintingできるかも？tcpdumpしていれば。

つーことで、Web Appを作っている方々、設計段階からセキュアになるよう、心がけて下さいね。（実はこれが言いたかった、笑）