www.sbcr.jp
参加者は7名でした。
内容は4.5.1 クロスサイト・リクエストフォージェリ(CSRF)
書籍の中でCSRF対策方法として以下が紹介されている
対策方法を実装した際の開発工数や利用者への影響、利用シーンが表で記載(p.196)されていて非常にわかりやすい。
話題としては
パソコン遠隔操作事件ってあったね
- このあたりのセキュリティってフレームワーク側でよしなにやってくれてるからあまり意識しないですね
など。
フレームワーク側で～の話は以前XSSあたりを読んでるときにも出てた。
Rails3以降だとテンプレートに埋め込まれた変数はデフォルトでエスケープされるので、そのあたり意識せずRails3以前やSinatra等、デフォルトでエスケープしないFWでView作るとXSS盛りだくさんのWebアプリケーションが生まれてしまう。
気になったこと
/45/45-003.htmlのCSRFのサンプルがうまく動作してないようで、ユーザーIDが表示されず、DBを見てもパスワードは変わっていなかった。
多分セッションIDの値周りでこうなっているのだけど、この現象は自分だけ？
トークンに加えてリファラのチェックも必要というコメントがあるが、これは間違い。XSSがある前提ではリファラをチェックしても意味ないし / “PHP - とっても簡単なCSRF対策 - Qiita [キータ]” http://t.co/m3ZavYaj68
— 徳丸 浩 (@ockeghem) 2014年11月21日
XSSがあるとCSRF対策のトークンが読まれてしまうのは正しい指摘だけど、XSSがあると攻撃対象と同じドメイン（オリジン）から攻撃できるので、それはCSRFではく、単にXSSの応用だし、リファラのチェックでは対策できない。XSSはXSSとして対策すべし
— 徳丸 浩 (@ockeghem) 2014年11月21日
（昨日の某発表資料でもCSRFがセッション管理の問題と分類されていたけど、CSRFはセッション管理の問題とは違うと思うんだよね。リクエストを受け付けて良いか否かの問題なので…）
— 徳丸 浩 (@ockeghem) 2015年1月15日
HttpOnlyをつけなくても大丈夫かという質問は、XSS脆弱性があることが前提かと思いますが、XSSがあればCSRF対策をしていても突破されます（例: hiddenパラメータのトークンをXSSで読める）ので、どっちみちHttpOnlyにより脅威は減りません=(2)に対する回答
— 徳丸 浩 (@ockeghem) 2018年11月8日
ENDO氏との会話が今ひとつ噛み合わなかったのですが、XSS脆弱性が *あれば* *一般的に* CSRF対策は機能しません。たとえば、XSSからのXHRにより入力フォームにアクセスすればhiddenパラメータ記載のCSRFトークンを取得できます。それを用いて2回目のXHRでCSRF攻撃できます https://t.co/BlKU9A1aAC
— 徳丸 浩 (@ockeghem) 2018年11月8日
海外の文献だと、CSRF対策の説明に「XSSにも注意」と書いてあることがありますが、日本の文献だと見かけない感じです。だって、XHRでトークン読んで…という攻撃はCSRF攻撃ではなくXSS攻撃ですからね。つまり、書かないほうが技術的には正確だと思いますが、実用的には、書いておいたほうがよいのかも
— 徳丸 浩 (@ockeghem) 2018年11月8日
このように考えるのも良いと思います。件の質問はWeb APIのCSRFに関するものでしたが、XSSがあるとWeb APIを用いたスクリプトを注入することもできます。当然、CSRF攻撃に相当するスクリプトも書けるわけです。というわけでXSSがあるとCSRF対策は無力になります https://t.co/AYz51aJMDt
— 徳丸 浩 (@ockeghem) 2018年11月8日
