「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ASP.NETでのCSRF(XSRF)対策方針について纏める。
対応方針の案 †
案件依存だが・・・。
フレームワーク毎の違い †
- POST
ViewState の ViewStateUserKey? にセッション ID を割り当てる方法がメジャー。
- GET
- 攻撃しやすいのでQueryString?で予期せぬCRUD等の操作がされないように作る。
- 具体的には、画面の初期表示のみにGETを使用するなどする。
- POST
ValidateAntiForgeryToken?属性とHtml.AntiForgeryToken?ヘルパを使う。
- GET
- 攻撃しやすいのでQueryString?で予期せぬCRUD等の操作がされないように作る。
- 具体的には、画面の初期表示のみにGETを使用するなどする。
- 主に、業務系SPAの裏のWebAPIは同様に対応が必要になる。
- Cookieに設定したX-CSRF-TOKENを、HTTPヘッダに設定する方式が一般的。
- ソレ以外のWebAPIは、client_id, client_secretの基本認証やbearer tokenを使用。
判断材料 †
案件毎にCSRF(XSRF)対策のポリシーを持って対応する必要がある。
診断ツールと診断結果 †
- GETが通れば即、warningになるので診断ツールの誤検知が多い。
- CSRF(XSRF)になっても実際に問題は起きるかどうかはアプリの作りによる。
攻撃対象サイト †
一般的に、足がつかない、
- 匿名アクセス可能なサイトか、
- フリーメールサービスのアドレスでサインアップ可能なサイト
が多いと考える。
攻撃者の属性 †
- 攻撃方法の特定
- 匿名アクセスが可能なサイトの場合、誰でも攻撃可能。
- 会員制サイトの場合、そのサイトを利用可能な会員でしないと、攻撃方法を見い出せない。
- 攻撃方法が解れば、
- 攻撃自体は誰でも出来る。
- しかし、最近は、SameSite属性の件の対策もあり、
同一サイトでないとPOSTでの攻撃も、し難くなって来ている。
参考 †
Tags: :テスト
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
